드로우콜 DrawCall 최적화

-드로우콜
그림을 그리라고 CPU가 GPU에 내리는 명령
Render State 변경(변경을 위해서 드로우 콜이 필요)

렌더 상태 변경은 GPU 연산이 비쌈

CPU쪽에서 생긴 문제를 CPU Bound라고 함
GPU쪽에서 생긴 문제를 GPU Bound라고 함

1프레임을 계산하는데 걸리는 시간에서 CPU와 GPU의 지연이 발생하면 병목
CPU가 드로우콜을 던져줘야되는데 늦어지면 GPU처리도 늦어짐

이런 병목현상은 드로우콜을 줄이면 해결됌

-드로우콜의 상한치
콘솔게임:2~3k
pc게임:1k
모바일게임:100~200

-드로우콜의 발생

1메시 + 1머테리얼 = 1드로우콜
n메시 = n드로우콜
n메시 + 1머테리얼 = n드로우콜(n메시 + n머테리얼 보다 좋음) : 렌더스테이트 변경이 적음
1메시 + n머테리얼 = n드로우콜

셰이더 멀티패스의 경우 단일 메쉬에서도 여러번의 드로우콜 발생
ex)외곽선 등 여러번 그려지는 툰쉐이더

-드로우콜 줄이기

*렌더되는 오브젝트 줄이기
씬에 보이는 오브젝트 수 줄이기
Frustum 영역 조절하기(Near,Far Clipping Plane의 거리)
오클루전 컬링(카메라 시야를 가리는 오브젝트 뒤에 물체를 뺌)
오클루전 컬링의 경우 인도어 씬에 효과적
LOD

*오브젝트 렌더링 횟수 줄이기(주로 라이팅쪽)
리얼타임 라이트 대신 Baked 라이트 사용
라이트 개수 만큼의 드로우 콜 필요(포워드 렌더링 기준)
실시간 그림자의 경우 Quality Setting 조정
리플렉션 프로브 사용 최소화

*아틀라스(atlas)사용
1메시 + n머테리얼 = n드로우콜
이때 n개의 머테리얼 사용하지 않고 n개 보다는 줄여서 표현하는 방법
하나의 메시에 사용되는 여러개의 텍스쳐 맵을 하나로 합치기
ex)2d의 경우 스프라이트 시트

*배치 렌더링(batch rendering : batching) 사용
n메시 + 1머테리얼 =  n드로우콜
1개의 머테리얼을 공유 한다는 기준으로 n개의 메시를 1개로 묶음
텍스처만 다른 동일한 머테리얼2개가 있는 경우 atlas를 통해 하나의 머테리얼로 통합

*정적 배칭
움직이지 않는 오브젝트(주로 배경)를 배칭
움직이지 않으니 버텍스 연산이 필요하지 않아 동적배칭보다 효율적

오브젝트들을 합쳐서 하나의 메시로 새로 만듦으로 메모리가 추가로 필요

Scene을 모듈화하여 제작하는 방식 사용 가능(Scene을 하나의 단일 메시로 만드는것 : Merging 기법)
Merging기법의 경우 Visibility culling문제가 발생(덩어리가 커지니 카메라에 조금만 걸쳐도 큰 덩어리가 메시가 다 렌더되어버림)
일반적인 정적배칭은 드로우콜 이후 개별 오브젝트로 판별해서 컬링에는 문제 없음

모듈화하는 방식으로 스태틱 배칭을 사용
ex)파츠를 여러개 만들어 놓고 조합해서 여러 패턴의 건축물을 조합


*동적 배칭
동적으로 움직이는 오브젝트들끼리 배칭처리
동일한 머테리얼을 사용하고 특정 조건들을 만족하는 다이나믹 오브젝트들에 대한 자동 배칭
다이나믹 배칭에 쓰이는 정보를 모아 정점버퍼와 인덱스버퍼에 담음

매프레임마다 오버헤드 발생(매번 데이터 구축과 갱신 발생, 정적배칭 보다는 무거움)
그럼에도 불구하고 드로우콜을 줄임으로서 성능 향상
한계: Skinned Mesh 적용은 불가, 정점이 너무 많은 메시는 대상에서 제외(오히려 배칭이 비효율적이 되는 경우)

*GPU Instancing
한번의 드로우콜로 여러 오브젝트들을 한번에 처리
배칭과는 달리 동일한 메시의 복사본을 만듦 ex) 같은 오브젝트들을 수천개 생성, 파티클 같은 느낌
런타임 오버헤드가 적음
배칭은 여러 지오메트리 정보를 하나의 메시로 합치지만, 인스턴싱은 별도의 메시를 생성하지 않음(동일 메시라서)
처리방법 : 트랜스폼만 다르기 때문에 각기 다른 트랜스폼 정보를 별도의 버퍼에 저장, 그리고 한번에 처리(병렬 처리방식 GPU)

 

출처 - https://youtube.com/playlist?list=PLyuV91SJJre7DeREVCzx8VG599PCGTtL2 

게임 아티스트를 위한 CG 최적화이론