TA가 악기를 들면 타악기

3-섭디벽돌타일

대게 — Sun, 14 Dec 2025 00:16:37 +0900

쿼드 오버드로우 테스트(251207)

대게 — Sun, 7 Dec 2025 04:12:46 +0900

공부하다가 궁금한 부분이 생김

와이어를 정리할 때 왼쪽처럼 피자모양이 되게 하지 말라는건 상식이긴 한데 실제로 어느정도의 차이가 있을지 궁금해서 테스트해봄

결론부터 말하자면 우측의 정리된 방식이 40% 더 빨랐다.

처음 테스트는 쿼드 오버드로우 문제만 생각했었는데 측정치가 생각보다 많이 차이나서 살펴보니 메모리 캐시의 영향이 컸다.

측정 항목 (Metrics)	Case A (좌측)	Case B (우측)	비고
GPU Time	32.58 μs	19.49 μs	B가 약 40% 빠름

Texture L1 Bytes Read	6.56 MiB	32.36 MiB	B의 캐시 효율이 월등히 높음

Vertices	162	156	버텍스 수 자체도 차이남
Vertices Reused	64.20%	64.10%
Pixels per Vertex	4,397.79	4,554.86

Vertex Stage Time	9.00%	19.43%	전체 시간 중 차지하는 비중
VS Invocations	58	56
VS ALU Instructions	8,960	8,704
VS ALU Inefficiency	6.34%	8.14%

Primitives	54	52
Primitives Culled (Back-Face)	37.04%	38.46%
Primitives Rendered	62.96%	61.54%

Pixels Rasterized	257,760	258,240	픽셀 수는 거의 동일
Fragments / Primitive	4,773.33	4,966.15

Fragment Stage Time	90.99%	80.57%
FS Invocations	255,072	255,072	호출 횟수 동일
Average Pixel Overdraw	0.1	0.1	오버드로우 없음
FS ALU Instructions	58,101,760	57,877,760	연산량 자체는 비슷함
FS ALU Inefficiency	2.63%	2.57%

Texture Accesses	944,512	935,616
Mipmap Linear Sampler Calls	45.39%	45.00%
Texture Quads	235,968	233,856	2000정도 차이남
Total Resolved Pixels	292,848	291,828

피자처럼 정리한 경우보다 사각형으로 정리한 경우가 L1 캐시 효율이 훨씬 높았다.

애초에 생각했던 쿼드 오버드로우를 나타내는 지표는 Texture Quades일텐데 막상 여기서 차이는 2000정도밖에 안 났다.

Texture Quades는 GPU가 텍스쳐를 샘플링할 때 사용하는 최소 작업단위인 2x2 픽셀블록을 의미한다.

고작 이정도 더 그리는 것 보단 L1캐시 문제가 더 지배적인 영향인 것 같아서 좀 더 찾아봤다.

자료 참고

https://pixeljetstream.blogspot.com/2015/02/life-of-triangle-nvidias-logical.html

Life of a triangle - NVIDIA's logical pipeline

Hi, while gathering public material on how the hardware works, I tried to create a compressed architecture image. It is based on images and ...

pixeljetstream.blogspot.com

Again we batch up 32 pixel threads, or better say 8 times 2x2 pixel quads, which is the smallest unit we will always work with in pixel shaders. This 2x2 quad allows us to calculate derivatives for things like texture mip map filtering (big change in texture coordinates within quad causes higher mip). Those threads within the 2x2 quad whose sample locations are not actually covering the triangle, are masked out (gl_HelperInvocation). One of the local SM's warp scheduler will manage the pixel-shading task.

The same warp scheduler instruction game, that we had in the vertex-shader logical stage, is now performed on the pixel-shader threads. The lock-step processing is particularly handy because we can access the values within a pixel quad almost for free, as all threads are guaranteed to have their data computed up to the same instruction point (NV_shader_thread_group).

이 글의 13,14번 문단을 보면 이 메모리에 대한 내용이 나온다.

GPU가 동작하는 단위를 살펴보면 2x2 픽셀 쿼드 8개가 묶여있는 구조

-> 즉, 픽셀 셰이더에서 동작하는 최소 단위는 2x2 픽셀(4픽셀)인 것을 알 수 있다.

이렇게 4개의 픽셀을 묶어서 동작하는 이유는 미분값(Derivative)을 계산하기 위해서인데, 밉맵을 고르려면 텍스쳐좌표가 얼마나 급격하게 변하는 지 알 수 있어야하고 이를 위해 인접한 4개의 픽셀 값을 비교해야한다. (쿼드 내에서 텍스쳐 좌표의 변화량이 크면 멀리있거나 기울어진 면이라는 뜻이기 때문에 흐릿한(높은)밉맵을 사용하게 된다. )

14번 문단으로 넘어가서, 우측 경우처럼 인접한 정보끼리 잘 정리되어 있으면 실행 시점이 같을 때 픽셀 쿼드 내의 정보는 거의 무료로 접근 가능하기 때문에 효율적인데 피자모양처럼 정리한 경우는 삼각형들이 한 점으로 모이면서 uv좌표가 널뛰고 이런 부분에서 캐시 미스가 많이 발생하면서 그리는 픽셀의 양이 비슷한데도 시간이 더 걸리는 것으로 보인다.

Texture Quades 얘기도 이 부분에 있다. 실제 삼각형에 걸치지 않더라도 최소단위인 4개의 픽셀은 같이 계산되고 이때 남은 부분은 마스킹된다. 즉 4개를 돌려서 4개 다 사용하지 않고 버리는 낭비가 생긴다.

uv배치 때문에 그런 것 같은데 그럼 두 경우 다 uv를 정면에서 프로젝션한 것 처럼 펴두고 정면에서 찍으면 이런 차이가 줄어들까? 와이어 정리에 따른 부하 차이가 어느정도인건지 모르겠다.

0930까지 기록

대게 — Wed, 1 Oct 2025 00:03:54 +0900

오브젝트들 서로 색 다르게 생성하기

씬에 있는 오브젝트들을 5개씩 복제하기. 이때 색이 점점 연해지게 지정하기 / 씬에 있는 오브젝트들을 알아서 보기좋게 정리하기.

9월 30일

ai로 생성한 스크립트를 MaxUICustom 툴의 모듈 폴더에 복사하는 기능

앞으로 할 일

[ai 사용 준비]

- 프롬포트에서 1차적으로 필요한 씬 데이터 종류 추출하는 기능
- 추출한 데이터 종류를 사용해 프롬포트에 넘길 데이터 만드는 기능
- 씬 데이터 추출하는 방법 함수 데이터베이스 구축

[ai 생성]

- 스크립트 구성할 함수 데이터베이스 구축
- 스크립트 생성 규칙 구성

[모듈화]

- 생성한 스크립트를 모듈화 하는 방법

창 관련 코드 정리(제거) 필요
UI 구성 관련 연구
input,output, ai를 이용하는 로직에 대한 장치와 가이드 제공

- 파일명 자동 생성

0.ai 시작하기

대게 — Sun, 17 Aug 2025 15:42:09 +0900

0. ai 시작하기

Sunday, August 17, 2025 at 2:01 PM

LLM(Large Language Model) 개요
정의
LLM의 동작 원리 개요

LLM 동작 원리 세부 과정
2.1 Tokenizing (토큰화)
2.2 Embedding (임베딩)
2.3 신경망 처리 (Transformer)
2.4 텍스트 생성 (Generation)

언어모델은 어떻게 기능을 수행하는가?
기본 기능: 텍스트 이해·생성
Tool과의 상호작용 예시 (날씨 API 사례)

MCP (Model Context Protocol)
정의
역할 및 특징

RAG (Retrieval Augmented Generation)
정의
"검색"에 대한 오해와 정확한 의미
RAG의 동작 과정
Query 입력
Query 벡터화
Retrieval (외부 데이터 검색)
Context 보강
응답 생성

예시: "서울 날씨"
총정리

LLM(Large Language Model)

LLM은 인간의 언어나 데이터들을 해석할 수 있을 만큼 방대한 데이터를 학습한 인공지능 모델이다.

LLM(Large Language Model)은 대규모 데이터를 학습해 언어를 이해하고 생성하는 AI 모델 자체를 뜻한다.
ChatGPT 같은 서비스는 LLM을 활용해 만들어진 응용 프로그램이다.

LLM의 동작 원리 개요

1. 토큰화(Tokenizing): 입력 문장을 토큰 단위로 나눔

2. 벡터화(Embedding): 각 토큰을 수치 벡터로 변환

3. 신경망 처리: Transformer 구조로 문맥을 이해하고 다음 토큰의 확률 계산

4. 텍스트 생성: 확률이 높은 토큰을 순서대로 선택해 문장 완성

1. Tokenizing

:Tokenizing은 문자열(문장,코드,데이터 등)을 더 작은 단위(token)으로 쪼개는 과정을 의미한다.

Token : 의미를 가지는 최소 단위

"사과, 바나나, 포도"
-> ["사과", "바나나", "포도"]

"파스타 먹자"
-> ["파스타", "먹", "자"]

인간이 쓰는 자연어를 컴퓨터가 처리하기 위해 컴퓨터가 이해할 수 있는 구조로 변환해야한다.

이런 입력된 텍스트(자연어)를 모델에서 처리할 수 있는 데이터로 변환하기 위해 작은 단위로 쪼개는 과정을 토큰화라고 한다.

이런 토큰화되는 방식을 볼 수 있는 사이트가 있다 https://platform.openai.com/tokenizer

2. Embedding : 각 토큰을 수치 벡터로 변환한다

우리가 글로 쓰는 텍스트, char문자 형식도 컴퓨터는 결국 숫자로 받아들이기 때문에 토큰을 컴퓨터가 직접 이해할 수는 없다.

예를들어 "사과, 바나나, 포도"라는 문장이 있다. 이를 컴퓨터에게 입력한다고 생각해보자.

가장 쉽게 생각할 수 있는 방법은 ',' 단위로 끊어 세 문자열을 받아들이는 것이다.

"사과, 바나나, 포도"
-> ["사과", "바나나", "포도"]

사과: 0
바나나: 1
포도: 2

그럼 컴퓨터는 각 단어들의 인덱스로 이들을 구분할 수 있다.

그럼 이제 이 단어가 매우 많아지고 그 의미가 필요한 경우를 생각해보자.

"사과, 바나나, 포도, 오렌지, 자동차, 자전거, 오토바이, 비행기, 헬리콥터, 과일 , 식칼"
  1      2      3      4       5       6       7       8       9      10     11

우리는 사과, 바나나, 포도, 오렌지가 과일이란 것과 과일을 손질할 때 식칼을 쓴다는 것을 생각할 수 있다.

하지만 컴퓨터는 1,2,3,4가 10과 관련이 있다는 것과 11(식칼)이 1(사과)과 관련있다는 것을 알 수 없다.

단순히 숫자로 표현하는 방식으로는 컴퓨터가 데이터를 정리할 수는 있어도 그 단어들의 의미를 이해할 수는 없다.

그래서 단어들간의 관계성을 표현하기 위해 차원을 늘린다.

대충 이런 식으로 각 단어들의 관계성을 따라 배치하면 각 단어들 사이의 거리를 구할 수 있다.

자동차와 사과의 거리보다 식칼과 사과의 거리가 짧다. -> 즉 식칼이 자동차보다 사과와 더 관련이 있다는 것을 알 수 있다.

이렇게 단어를 고차원 공간에 배치해 의미적 유사성을 벡터 거리로 표현해 컴퓨터가 이해할 수 있게 숫자로 변환하는데 이 과정을 Embedding이라고 한다.

당연히 이정도 2차원 수준이 아닌 768차원, 1572차원, 그 이상의 고차원으로 표현하여 거리로 구분한다.

3.신경망 처리와 4.텍스트 생성은 안 배웠다.

대충 2의 결과를 통해 가까운 관계인 단어들을 연결짓고 다시 자연어로 텍스트를 생성한다는 뜻인 것 같다..

3. 언어모델은 어떻게 기능을 수행하는가?

위에서 계속 말했듯 LLM자체는 텍스트를 이해하고 분석하는 일을 한다.

이 자체로도 언어모델은 질문에 답하거나, 글을 쓰거나, 번역하는 것이 가능하다.

그런데 우리가 흔히 사용하는 요즘의 ai들을 보면 사용자의 요청에 따라 검색, 이미지 생성, 코드 생성, 데이터 분석 등 "언어"의 범위나 학습된 범위를 벗어난 다양한 "기능"도 수행한다.

이는 언어모델이 다른 도구(tool)과 상호작용해서 수행한다.

사용자: 오늘 날씨 어때?
-> "현재 날씨 정보에는 접근할 수 없지만 일반적으로 여름에는 덥고 습합니다"

사용자: 오늘 날씨 어때?
-> LLM이 파악: 사용자의 의도는 오늘의 날씨를 아는 것
-> tool 사용: 날씨 API 호출
-> 결과 종합: 응답 생성
-> 응답: " 현재 서울은 30도이며, 날씨는 맑습니다"

내가 공부할 부분이 이거!

즉, 언어모델에 내가 필요한 도구를 제공하면 더 다양한 활용이 가능해진다.

앞에서 LLM에 대해 간단하게 살펴봤다면 이제부터는 그걸 어떻게 활용할지에 대해 살펴보자.

4. MCP(Model Context Protocol)

MCP는 애플리케이션이 LLM에 컨텐스트를 제공하는 방법을 표준화하는 개방형 프로토콜이다.

MCP는 LLM이 외부 도구, 서비스, 데이터 소스에 일관된 방식으로 접근할 수 있게 해준다

MCP 개념: 모델이 외부 리소스/도구를 표준 방식으로 호출하고, 클라이언트가 실행해서 결과를 모델 컨텍스트에 다시 주입하는 상호작용 규약.

이 부분은 추후 직접 해보면서 따로 정리하겠다.

5. RAG( Retrieval Augmented Generation )

RAG에 대한 설명을 여기저기서 가져와봤다.

외부 소스에서 가져온 정보로 생성형 AI모델의 정확성과 신뢰성을 향상시키는 기술
대규모 언어 모델(LLM)의 출력을 최적화하여 응답을 생성하기 전에 학습 데이터 소스 외부의 신뢰할 수 있는 지식 베이스를 참조하도록 하는 프로세스 기술
대규모 언어 모델(LLM)에서 질문에 대한 답변이나 텍스트를 생성하기 전에 광범위한 문서 집합에서 관련 정보를 검색하고, 이를 이용하여 응답을 생성하는 방법

"생성형 AI가 답을 만들기 전에 관련 자료를 검색(retrieval)하여 이를 참고한 후 답변을 생성(generation)하는 방식"

한국에서 검색 기반 생성(검색 증강 생성)이라고 번역한 자료가 많다.

검색이라는 단어 때문에 구글 검색창 같은 곳에서 검색을 한다고 생각하기 쉬운데 여기서의 "검색"은 단순히 구글 검색창에서 찾는 것이 아니라 벡터DB나 API 같은 데이터 소스에서 유의미한 정보를 가져오는 과정에 가깝다.

RAG는 개념적으로는 "검색 기반 응답 생성"이라는 방법론을 뜻한다.
기술적으로는 벡터DB 같은 저장소와 Retrieval 모듈을 함께 지칭하는 경우도 있고, 이를 통째로 RAG라고 부르기도 한다.

작게 생각하는 게 이해하기는 편한듯?

간단하게 이 동작 방식을 살펴보면

Query 입력
사용자가 질문(Query)을 입력한다.
이때 단순히 텍스트만 모델에 들어가는 것이 아니라,
시스템 메시지, 대화 이력(context), 지시문 등이 합쳐져 Prompt라는 형태가 된다.

Query 벡터화 (입력 코딩)

사용자의 입력은 임베딩 모델을 거쳐 숫자 벡터로 변환된다.
이 벡터는 검색을 위한 키(key) 역할을 한다.

Retrieval (외부 데이터 검색)
변환된 벡터를 기반으로 벡터DB나 외부 API에서 관련 정보를 검색한다.

Context 보강
검색된 정보를 Prompt에 추가해 LLM이 참고할 수 있도록 한다.
→ 즉, 원래의 사용자 질문 + 검색된 자료가 하나의 새로운 Prompt가 된다.

Generation (응답 생성)
보강된 Prompt를 기반으로 LLM이 자연스러운 답변을 생성한다.

LLM은 인간의 언어나 기타 복잡한 데이터를 인식하고 해석할 수 있을 만큼 충분한 예제를 제공받은 컴퓨터 프로그램이다.

하지만 당연히 이 세상의 모든 데이터를 가지고 있을 수는 없다. 이런 한계를 보완하기 위해 추가적인 데이터베이스(벡터DB)를 붙이는데 이걸 RAG라고 볼 수 있다.

6. 예시

아래의 짧은 대화를 예시로 분석해보자.

1. 사용자의 Query 입력

사용자 입력

“서울 날씨”라는 채팅을 쳤다. 이는 Query가 된다.

하지만 이는 LLM이 이해할 수 있도록 시스템 메시지, context, 지시문과 합쳐서 Prompt로 만들어진다.

prompt로 확장된 형태

시스템: 너는 친절한 대화형 비서야. 
context: 사용자가 내일 한강에 놀러갈 계획이라고 말함. 
사용자: 서울 날씨

2. query 벡터화(입력 코딩)

“서울 날씨”라는 텍스트는 임베딩 모델을 통해 숫자벡터로 변환된다.

서울, 날씨, 예보 같은 그 벡터공간에서 가까운 데이터를 검색하는 기준이 된다.

3. 외부 데이터 검색(retrievel)

벡터 DB, 혹은 외부 API에서 “서울”, “날씨”와 가까운 정보를 가져온다.

여기서는 날씨 웹 검색 API가 호출되었을 것이다.

4. Context를 보강한다.

검색된 날씨에 대한 데이터를 Prompt에 추가한다.

시스템: 너는 친절한 대화형 비서야.
context: 사용자가 내일 한강에 놀러갈 계획이라고 말함.
사용자: 서울 날씨
참고 정보: 
- 8월 16일(금) 오전 11:00 기준
- 현재 31°, 구름 많음
- 폭염 주의보 발령
- 이번 주 최고 33°, 최저 24°
- 월~목 오전 중 소나기 가능

5. 응답 생성(Generation)

위의 결과를 통해 자연스러운 답변을 생성한다.

이때 사용자가 내일 한강에 가겠다는 정보를(context)제공했었다.

따라서 LLM은 내일의 날씨(글 쓰던 시점 기준 8월 17일, 사용자가 한강에 가겠다고 한 날)를 제공하고 모자, 선크림, 음료를 챙기라는 내용까지 추가해서 답변한다.

이번 주 서울의 날씨를 요약해 드릴게요:

- 전반적으로 덥고 습한 기운이 이어집니다. 최고 기온은 30~33°C, 최저 기온은 24~25°C 수준입니다.  
- 월요일부터 목요일까지는 오전에 소나기가 있을 수 있습니다.  
- 폭염 주의보가 발령 중이니, 낮 12시 전후에는 야외 활동을 피하시고, 한강 나들이 시에는 모자, 선크림, 시원한 음료를 챙기시면 좋습니다.

[User: "서울 날씨"]
      │
      ▼
[LLM: 의도 파악 → 최신성↑ → 툴 필요]
      │
      ├─▶ [툴콜: weather({location:"Seoul", tz:"Asia/Seoul"})]
      │        └─ 클라이언트 실행 → 결과(현재/예보/특보)
      ▼
[LLM: 결과 요약(근거) + 한강 맞춤 팁(생성)]
      ▼
[최종 응답]

총정리

LLM(Large Language Model)의 본질

언어모델은 인간의 자연어를 컴퓨터가 이해할 수 있는 형태(토큰, 벡터) 로 변환하여 처리한 뒤, 다시 사람이 읽을 수 있는 언어로 생성하는 시스템이다.
기본적으로는 학습된 방대한 텍스트 데이터를 바탕으로 확률적 단어 예측을 통해 답변을 만든다.

핵심 과정 요약
토큰화(Tokenizing): 텍스트를 모델이 처리 가능한 작은 단위로 분해
임베딩(Embedding): 단어·문장을 의미 공간에서 수치 벡터로 변환
맥락 처리(Context Handling): 이전 대화·검색 결과·시스템 메시지 등을 종합하여 입력 보강
생성(Generation): Transformer 기반 신경망이 확률적으로 가장 적절한 토큰을 이어붙여 문장을 만듦

Prompt, Query, Context의 구분
Query: 사용자가 실제로 입력하는 요청 (예: "서울 날씨 알려줘")
Context: LLM이 답을 더 잘하도록 제공되는 추가 정보 (검색 결과, 대화 이력, 지식 베이스 등)
Prompt: Query와 Context, 시스템 메시지, 지시어 등을 포함해 LLM에 최종적으로 전달되는 입력

한계와 확장
LLM은 세상의 모든 지식을 담고 있지 않음 → 최신 정보, 개인 데이터, 전문 지식은 부족할 수 있다.
이를 보완하기 위해 RAG(Retrieval Augmented Generation), MCP(Model Context Protocol), 외부 툴(API) 과 같은 방법이 사용된다.
RAG: 외부 데이터베이스에서 검색한 결과를 Context로 추가하여 응답 강화
MCP: LLM이 여러 툴과 표준화된 방식으로 연결될 수 있도록 하는 프로토콜
Tool 사용: 날씨 API, 코드 실행기, 이미지 생성기 등과 연동

LLM = 뇌(언어 능력)
Prompt = 질문+조건(입력 형태)
Context = 배경지식(외부 정보 포함)
RAG/MCP/Tool = 감각기관과 손발(현실 세계와의 연결)

Part03. 병목

대게 — Wed, 4 Jun 2025 15:22:07 +0900

1.CPU 바운드 vs GPU 바운드

CPU와 GPU는 서로 병렬적으로 작동합니다.

프레임이 시작하고 CPU가 GPU에게 렌더링 명령을 던지고, 그 결과를 기다리는 것이 아니라 계속 일처리를 수행합니다.

이때 만약 CPU가 처리를 끝냈는데 GPU가 아직 작업 진행중이면 렌더링의 결과를 기다리고 GPU의 처리가 끝나면 프레임이 화면에 출력됩니다.이런 경우는 GPU 바운드인 상태입니다.

반대로 CPU의 일처리가 많으면 CPU가 병목상태인 것으로 렌더링 어플리케이션에서 병목을 따질 때는 GPU와 CPU바운드인지 부터 시작해야합니다.

2. 유니티 내장 프로파일러를 이용한 측정

- 프로파일러를 연결하려면 디벨롭먼트 빌드로 수행해야 하는데 디벨롭먼트 빌드는 프로파일러 정보 등 각종 오버헤드ㄱㅏ 포함되어 있어서 릴리스 빌드보다 오버헤드가 발생합니다.

오버헤드(overhead)는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말한다.

3. 안드로이드 개발 환경 설정

3-1 빌드세팅에서 플랫폼 바꾸기

정상적으로 모듈이 깔려있다면 Importing창이 뜨고 완료되면 프로젝트창 상단에 타이틀바에서 확인할 수 있습니다.

유니티 2019이상 버전부턴 관련 설정이 자동으로 되어있다.

3-2 player Settings 에서 Color space Gamma로 바꾸기

OpenGL ES버전 호환성 때문에 컬러스페이스를 감마로 변경한다.

3-3 Auto Graphics API 활성화, Development Build 및 Autoconnect Profiler 활성화

3-4 핸드폰 개발자옵션 활성화

이제 프로젝트를 모바일에서 실행하려면 컴퓨터와 휴대폰을 연결하고 휴대폰의 개발자옵션에서 USB디버깅을 허용해야한다.

이제 플레이해보면 우측하단에 작게 Development Build라고 떠있을겁니다. 이건 Development Build 활성화 상태기 때문에 뜨는 것으로 이래야 프로파일러에 연결이 가능합니다.

4. 유니티 프로파일러 윈도우

플레이를 시작하면 자동으로 프로파일러 창이 뜰겁니다.

만약 프로파일러가 안 뜬다면 Windows -> Analysus -> Profiler로 켭니다.

Hierarchy 목록에서 각 항목들이 성능을 많이 차지하는 순서로 정렬되어있습니다.

그런데 CPU병목은 유니티 내장 프로파일러로 확인이 가능하지만 GPU는 GPU바운더리가 어느 정도인지만 유추할 수 있고 자세히 살펴볼 수 없습니다. 특히 플랫폼의 제한이 있어 대부분의 모바일 디바이스에선 사용이 불가능합니다.

따라서 다른 외부툴을 사용하여 상세하게 프로파일링 하기도 합니다.

5. GPU 병목

5 - 1. 필레이트 (Fillrate)

: 픽셀 처리에 대한 부담

필레이트 = 화면의 픽셀 수 x 프래그먼트 쉐이더 복잡도 x 오버드로우

화면에 렌더링 할 픽셀이 너무 많거나, 처리할 프래그먼트 쉐이더가 무거우면 렌더링파이프라인의 래스터라이저 스테이지에서 병목이 발생합니다. 이 경우를 필레이트가 병목이 된다고 표현합니다.

병목이 필레이트 바운드인지 여부는 디스플레이 해상도를 줄여서 확인 가능합니다.

Edit > Project Settings > Player 에서 Resolution Scailing모드로 해상도를 변경할 수 있쓰니다.

기본 Disabled에서 Fixed DPI로 변경하면 DPI에 맞춰 해상도 조절이 가능합니다.

DPI는 1인치에 몇 개의 화소가 들어가는지를 의미합니다.

5 - 2. 오버드로우 (Overdraw)

: 화면에 렌더링되는 하나의 픽셀이 여러 번 덧그려지는 현상

일반적인 불투명 물체는 z버퍼를 이용해 앞에 있는 물체에 가려진 픽셀은 걸러 오버드로우의 발생을 줄입니다.

그런데 투명한 오브젝트는 뒤에서부터 앞으로 렌더링하며 겹쳐진 픽셀에서 오버드로우가 발생합니다.

최종 픽셀 컬러 = 현재 픽셀 컬러 x 알파 + 프레임 버퍼의 픽셀 컬러 x (1-알파)

또한 투명한 오브젝트는 최종 픽셀 컬러를 연산하기 위한 과정에 이전 프레임 버퍼의 색을 가져와 블렌딩하고 그 결과를 다시 프레임버퍼에 기록하기 때문에 프레임 버퍼를 읽어오는 과정에서 병목이 발생할 수도 있습니다.

5 - 3 포스트 프로세싱

프래그먼트 쉐이더가 무거워지는 흔한 요인 중 하나로 포스트프로세싱은 픽셀 단위로 처리하기 때문에 이가 주된 병목 원인인 경우는 해상도를 줄이는 방법이 있습니다.

5 - 4 업스케일 샘플링

그런데 해상도를 줄이면 그만큼 픽셀이 도드라져 보기 안좋을 수 있다. 따라서 UI는 원래 해상도로 렌더링하고, 3D씬만 낮은 해상도로 렌더링 하는 방법이 있는데 이를 업스케일 샘플링이라고 합니다.

- 저해상도 렌더 텍스쳐 생성

- 3d씬을 렌더 텍스쳐에 렌더링

- 렌더 텍스쳐를 업스케일링 해서 현재의 백 버퍼에 렌더링

- 오버레이 UI를 렌더링

위의 과정으로 구현하게되면 전체 해상도는 줄이지 않고(디스플레이 되는 해상도는 그대로) 저해상도의 렌더 타깃으로 렌더 텍스쳐를 생성하여 3D씬만 저해상도로 렌더링하여 시각적인 퀄리티 저하를 줄입니다.

5 - 5 폴리곤

버텍스 프로세싱에서의 병목은 지오메트리 스테이지에서 병목이 일어나는 상황으로 씬에 렌더링 되는 버텍스들의 수 (즉 폴리곤의 수)가 많으면 지오메트리 스테이지에서 병목이 생깁니다.

이는 렌더링 되는 버텍스 수를 줄여보면 알 수 있습니다.

이런 경우는 LOD를 주로 사용하는데 오브젝트의 시각적인 디테일을 여러 단계로 나누어 카메라에서 먼 오브젝트는 그만큼 디테일을 낮춰 처리할 버텍스의 수를 줄입니다.

project settings > Quality에서 관련 설정을 볼 수 있고 LOD가 적용된 오브젝트에는 LOD Group컴포넌트가 존재해 오브젝트가 화면에서 차지하는 비율에 따라 어떤 레벨의 LOD가 적용되는지 확인하고 조절 할 수 있습니다.

5 - 6 텍스쳐

텍스쳐가 문제가 되는 경우는 텍스쳐의 해상도를 조절해 확인 가능합니다.

project settings > Quality 에서 텍스쳐 퀄리티 옵션을 통해 전체 텍스쳐 해상도를 줄일 수 있습니다.

[그래픽스 새싹4] 2. 1 삼각형 레스터화

대게 — Tue, 3 Jun 2025 01:01:39 +0900

이 글은 홍정모의 그래픽스 새싹코스 강의를 수강하며 기록하고 있습니다.

세부 코드는 생략하고 개인적으로 이해한 내용을 작성합니다

1. class Rasterization알아보기

오늘 직접 구현해볼 함수는 class Rasterization에 있는 EdgeFunction과 Render다.

그 전에 이 클래스가 어떻게 이용되는지 살펴보자.

main함수에서 윈도우세팅과 createWindow이후에 있는 while문을 보면 example을 사용해 Update와 Render 스왑체인등의 작업을 하고있다.

따라서 example 클래스를 살펴보면 Rasterization rasterization 을 생성해서 사용하고 있다.

- Example::Update()처럼 내부에서 rasterization을 사용해 여러 작업을 시행한다.

이번 시간에는 이 rasterization클래스의 두 함수를 구현하며 레스터화에 대해 익힌다.

float EdgeFunction(const vec2 &v0, const vec2 &v1, const vec2 &point);
void Render(vector<vec4> &pixels);

2.구현하기

기본적으로 보통 다렉에서 제공하는 기능이다. 여기선 간단하게 삼각형 하나만 그려본다.

- 왼손 좌표계 사용

1. 공간변환

- 월드좌표계에 정의된 정점들의 좌표를 Screen Raster좌표계로 변환한다

사용할 함수가 이미 정의되어 있다.

- 화면의 가로, 세로 길이를 이용해 화면비율을 구하고

- 그릴 점의 위치를 -1~1 범위로 정규화된 NDC로 변환한다.

- 이때 픽셀의 위치에서도 좌상단, 우하단 등의 범위에 따라 0.5의 차이가 발생하기 때문에 레스터된 좌표의 x범위는 -0.5 ~ width-0.5다

- 최종적으로 화면좌표계로 변환한다.

다시 Render로 돌아가 공간변환을 수행하자.

2. 바운딩 박스 구하기

화면의 일부 영역에 그려질 삼각형을 그리기 위해 모든 픽셀을 연산하는건 불필요하다.

따라서 삼각형이 포함된 영역을 구해서 해당 영역에서만 연산을 수행한다.

3. 바운딩 박스에 포함되는 픽셀들의 색 결정

여기서 사용된 EdgeFunction을 먼저 살펴보자

3-1 EdgeFunction

- a: 삼각형의 두 점을 이용해 한 변을 구하고

- b: 삼각형의 한 점과 위치를 판별할 대상인 p를 이용해 그 차를 구한다.

이 두 벡터를 cross 연산하면 그 결과의 부호를 통해 좌우판별이 가능하다.

이때, cross 연산은 원래 3차원에서 정의되기 때문에 z축을 0으로 하고 계산하면 식이 간단하게 a.x*b.y - a.y*b.x가 된다.

이 결과를 리턴하고 있다.

3-2 점이 삼각형 내부에 있는지 판별

삼각형의 세 변에 대해 EdgeFunction을 수행하여 점이 삼각형 내부에 있는지 확인한다.

3-3 각 픽셀의 색 구하기

EdgeFunction의 결과가 가지는 기하학적인 의미를 다시 생각해보자.

원래 벡터의 cross연산의 결과는 벡터고, 벡터의 방향은 두 벡터에 동시에 직교하며, 벡터의 크기는 두 벡터가 이루는 평행사변형의 크기다.

여기선 z축의 값들이 0이기 때문에 그 결과를 바로 숫자로 사용했다.

두 벡터가 이루는 평행사변형의 크기 -> 이 결과를 반으로 나누면 두 벡터가 이루는 삼각형의 넓이가 된다.

따라서 그 총합으로 각 영역을 나눠 가중치를 구하고 이 가중치를 각 점들의 색에 곱해 최종적인 삼각형의 색을 구한다.

[그래픽스 새싹4]1. 벡터와 포인트

대게 — Sun, 1 Jun 2025 13:22:19 +0900

이 글은 홍정모의 그래픽스 새싹코스 강의를 수강하며 기록하고 있습니다.

세부 코드는 생략하고 개인적으로 이해한 내용을 작성합니다

1.벡터 vs 포인트

1.1 벡터

: 벡터는 크기와 방향을 가진 물리량으로 보통 시작점부터 끝점까지 화살표로 표시합니다.

벡터는 크기와 방향만 같으면 어디에 위치했는지와 무관하게 같은 벡터로 볼 수 있습니다.

예) (1,3)

특히 원점에서 시작하는 벡터를 위치벡터라고 합니다.

1.2 포인트

반면 포인트는 단순히 위치만 표현합니다.

예) (1,3)

1.3 포인트 - 벡터 연산

연산	결과	예시
포인트 - 포인트	벡터	Q - P = v
포인트 +/- 벡터	포인트	P + v = Q
벡터 + 벡터	벡터

// 보통 API에서 포인트와 벡터를 구분해서 구현하지는 않음

위치 - 위치 = 얼마나 이동?

위치 +/- 얼마나 이동? = 위치

1.4 직선의 표현

R^2 또는 R^3에서 점 P0를 지나며 방향벡터가 d인 직전상의 임의의 점 P(a)의 위치벡터는 P0 + ad로 구할 수 있습니다.

1.5 선분의 표현

선분은 직선 직선 위에서 그 위의 두 점에 한정된 부분을 말합니다.

이미지에 아핀결합이라 쓰여 있는데. 아핀결합을 간단하게 말하면 선형결합 중에서 계수(가중치)들의 합이 1인 경우를 말합니다.

아핀공간이나 선형결합에 대해서는 나중에 글을 쓰겠습니다.

1.6 행렬 벡터

벡터는 각 차원의 수만큼 성분을 가집니다.

보통 (1,2,3) 처럼 표현하지만 앞으로는 행렬 벡터를 많이 사용합니다.

1.7 동차 좌표(homogeneous Coordinates)

어떤 목적을 위해 n차원 공간(n)에서 차원 하나를 추가해 표현하는 (n+1) 좌표계로 행렬을 이용해 연산을 할 때 이동변환을 수행하기 위해 주로 사용됩니다.

마지막 차원의 값이 0이면 포인트, 1이면 벡터라고 볼 수 있습니다.

1.8 코드에서 벡터의 사용

대부분 벡터와 포인트의 자료형을 따로 구분하진 않습니다.

(1) GLM

- glm::vec2, glm::vec3, plm::vec4

(2) DirectXMath

- XMFLOAT4 , XMVECTORF32

(3) Simple Math

- Vector2, Vector3, Vector4

[그래픽스 새싹 2] 0.4 벡터와 GLM

대게 — Fri, 30 May 2025 14:23:24 +0900

이 글은 홍정모의 그래픽스 새싹코스 강의를 수강하며 기록하고 있습니다.

세부 코드는 생략하고 개인적으로 이해한 내용을 작성합니다

면접에서 바로 실무 투입은 불가능한데 어느 정도 공부하면 TA로 궤도에 오를 것 같냐는 질문을 받았었다.

당시엔 깊게 생각하지 못하고 어느 정도 수준에서 갑자기 처음부터 큰 일을 맡게 될 리가 없고 작은 일부터 차차 배워가며 역할을 늘려갈 테니 어느 순간 궤도에 오르기보단 평생 조금씩 성장하게 되지 않을까.. 대충 이런 대답을 했던 것 같은데 지금 그래픽스 공부를 시작하면서 드는 생각은

" 혼자서 공부할 방법을 익히는 것"인 것 같다.

지금은 아직 뭘, 어떻게, 어디까지 공부해야 하는지 전혀 모른다. 그러니 책이나 강의를 의존하게 된다.

여기서 더 나아가 혼자 이렇게 공부하면 되겠구나 하고 스스로 탐구가 가능해질 때가 어느 정도 궤도에 올랐다고 할 수 있는 시점이 아닐까 싶다. 갑자기 공부 시작하려다가 든 생각

이 강의에선 처음에 좀 더 직관적인 glm을 사용한다. 이후 강의에선 다렉을 사용

1. glm 설치

vcpkg폴더 안으로 들어가 해당 문구를 치면 설치가 된다.

2. glm vector

//벡터 정의
glm::vec3 a(1.0f, 2.0f, 3.0f);
glm::vec3 b(7.0f, 8.0f, 9.0f);

// doubleVector 정의 - 광추적 같이 정밀도가 높아야 하는 경우 double을 사용하기도 함
auto doubleVector = glm::dvec3(1.0, 2.0, 3.0);



// cout : 문자열로 출력
cout << glm::to_string(b-a) << endl;



// 더하기&빼기 가능
auto c = b - a;



// length : 길이 구하기
float l = glm::length(c);

// normalize - 이때 길이가 0.0인 벡터를 유닛벡터로 만들려고 하면 오류 발생
auto u = glm::normalize(b-a);



// dot product
auto aDotB = glm::dot(a,b);

// cross
auto aCrossB = glm::cross(a,b);


// 벡터의 각 요소는 [r,g,b] , [인덱스] , [xyzw] 모두 가능하다

[그래픽스 새싹 2] 0.3 DX11 초기화와 IMGUI

대게 — Thu, 29 May 2025 16:37:33 +0900

이 글은 홍정모의 그래픽스 새싹코스 강의를 수강하며 기록하고 있습니다.

세부 코드는 생략하고 개인적으로 이해한 내용을 작성합니다

1. Vec4

2.1 실습1 : 움직이다 끝에 도착하면 돌아가는 네모 그리기

2.2 실습2: 움직이며 색이 변하게 만들기

3.1 실습: Gui 색으로 배경 색 변경하기

이번 강의에선 Update() 부분만 편집한다.

1. Vec4

std::vector는 데이터를 저장하는 컨테이너고 그래픽스에서 사용하는 vector는 수학적인 의미의 벡터를 의미한다.

2.1 실습1 : 움직이다 끝에 도착하면 돌아가는 네모 그리기

성공

> 수정

2.2 실습2: 움직이며 색이 변하게 만들기

성공

삼항 연산자로 수정

3.1 실습: Gui 색으로 배경 색 변경하기

- 슬라이더의 색을 배경색으로 지정

- update에서 지정한 backgroundcolor값으로 배경 색 변경

[그래픽스 새싹 2] 0. 2 환경설정_vcpkg

대게 — Thu, 29 May 2025 15:26:10 +0900

1. VS 설치

- visual studio 2022에서 시작

- c++를 사용한 데스크톱 개발 설치

2. vcpkg 설치

https://learn.microsoft.com/ko-kr/vcpkg/get_started/get-started-vs?pivots=shell-powershell

TA가 악기를 들면 타악기

3-섭디벽돌타일

쿼드 오버드로우 테스트(251207)

0930까지 기록

앞으로 할 일

[ai 사용 준비]

[ai 생성]

[모듈화]

0.ai 시작하기

0. ai 시작하기

LLM(Large Language Model)

LLM의 동작 원리 개요

1. Tokenizing

2. Embedding : 각 토큰을 수치 벡터로 변환한다

3. 언어모델은 어떻게 기능을 수행하는가?

4. MCP(Model Context Protocol)

5. RAG( Retrieval Augmented Generation )

6. 예시

1. 사용자의 Query 입력

사용자 입력

prompt로 확장된 형태

2. query 벡터화(입력 코딩)

3. 외부 데이터 검색(retrievel)

4. Context를 보강한다.

5. 응답 생성(Generation)

총정리

LLM(Large Language Model)의 본질

Part03. 병목

1.CPU 바운드 vs GPU 바운드

2. 유니티 내장 프로파일러를 이용한 측정

3. 안드로이드 개발 환경 설정

3-1 빌드세팅에서 플랫폼 바꾸기

3-2 player Settings 에서 Color space Gamma로 바꾸기

3-3 Auto Graphics API 활성화, Development Build 및 Autoconnect Profiler 활성화

3-4 핸드폰 개발자옵션 활성화

4. 유니티 프로파일러 윈도우

5. GPU 병목

5 - 1. 필레이트 (Fillrate)

5 - 2. 오버드로우 (Overdraw)

5 - 3 포스트 프로세싱

5 - 4 업스케일 샘플링

5 - 5 폴리곤

5 - 6 텍스쳐

[그래픽스 새싹4] 2. 1 삼각형 레스터화

1. class Rasterization알아보기

2.구현하기

1. 공간변환

2. 바운딩 박스 구하기

3. 바운딩 박스에 포함되는 픽셀들의 색 결정

[그래픽스 새싹4]1. 벡터와 포인트

1.벡터 vs 포인트

1.1 벡터

1.2 포인트

1.3 포인트 - 벡터 연산

1.4 직선의 표현

1.5 선분의 표현

1.6 행렬 벡터

1.7 동차 좌표(homogeneous Coordinates)

1.8 코드에서 벡터의 사용

[그래픽스 새싹 2] 0.4 벡터와 GLM

1. glm 설치

2. glm vector

[그래픽스 새싹 2] 0.3 DX11 초기화와 IMGUI

1. Vec4

2.1 실습1 : 움직이다 끝에 도착하면 돌아가는 네모 그리기

2.2 실습2: 움직이며 색이 변하게 만들기

3.1 실습: Gui 색으로 배경 색 변경하기

1. Vec4

2.1 실습1 : 움직이다 끝에 도착하면 돌아가는 네모 그리기

2.2 실습2: 움직이며 색이 변하게 만들기

3.1 실습: Gui 색으로 배경 색 변경하기

[그래픽스 새싹 2] 0. 2 환경설정_vcpkg

1. VS 설치

2. vcpkg 설치

- 해당 링크에서 설명에 따라 vcpkg 설치를 진행한다.

-설치하려는 파일이 vcpkg에 있는지 확인한다.

설치한다.

vcpkg integrate install 여기까지 하면 끝