Ocean Cleaner 21.08.18. 개발일지 - 최적화

https://funfunhanblog.tistory.com/301

Unity) 드로우콜 DrawCall

 

오늘도 개념들에 대해 공부해보자.

위 블로그의 게시물을 읽으며 정리했다.

---

 

우선 최적화를 하기 위해서는 발열이 왜 나는지를 알아야한다.

발열이 나는이유는 크게 2가지가 있는데, CPU에서 할당된 작업을 수행하는데 너무 많은 작업을 할당받아 발열이 나는 경우와 또는 GPU에서 너무 많은 작업을 할당받아 발열이 나는 경우이다.

CPU의 경우엔 코드의 구조가 복잡하다던가 낭비되는 메모리가 많아 발열이 생길것이고 GPU의 경우엔 헤비한 텍스쳐, 모델을 쓴다던가 렌더링 구조, 구현형태에 따라 발열이 생긴다.

 

여기서 드로우콜(DrawCall)이 등장한다.

 

 

드로우콜

모델을 렌더링할 때는 GPU가 독립적으로 하지 않는다. CPU의 명령을 받고 렌더링을 실행하는데 이를 드로우콜이라고 한다. 보통 PC에서는 CPU는 RAM을 메모리로 사용하고 GPU는 VRAM을 메모리로 사용하지만 모바일 기기에서는 통합되어 있는 경우가 많다. 따라서 통합되어 있는 메모리를 논리적으로 나누어 사용한다.

 

▲드로우콜 // 출처 : https://funfunhanblog.tistory.com/301

 

데이터의 흐름

드로우콜은 // 저장소(HDD, SSD, SD) -> CPU -> GPU //의 흐름을 가진다.

CPU가 저장소에 존재하는 데이터를 파싱하여 GPU에 할당하는 방식인데, 렌더링을 할 때마다 파싱을 하게되면 당연하게도 메모리 소모가 클 것이다. 따라서 반복적으로 파싱해야 하는 경우에는 데이터를 올려두고 사용하는 것을 권장하고 그렇지 않은 경우엔 데이터를 해제하여 메모리에 부담이 가지 않도록 한다.

 

커맨드 버퍼(Commnad Buffer)

CPU에서 GPU에 렌더링 명령을 보낼 때 중간에 GPU의 작업을 보관하는 중재자가 존재한다. CPU와 GPU는 병렬적으로 작업을 수행하는데 이러한 과정을 중재하는 커맨드 버퍼가 있다. CPU가 GPU에게 명령을 하는 순간 GPU가 다른 일을 하고있을 수 있기 때문에 그 명령을 쌓아놓고 순차적으로 GPU가 처리할 수 있도록 한다.

 

CPU의 성능에 의존되는 드로우콜

CPU에서 GPU에 렌더링 명령을 보낼 때 CPU에서 GPU에 맞게 데이터를 변형하여 보낸다. 이런 과정들은 곧 CPU바운더리의 오버헤드이며 텍스쳐의 크기를 줄이거나, 폴리곤의 수를 줄인다고 드로우콜의 성능이 좋아지진 않는다.

 

배치(Batch)와 SetPass Call

드로우콜의 발생조건을 이해하기 전에 먼저 배치(Batch)와 SetPass를 알아야한다. 배치는 각각의 드로우콜 사이에서 그래픽스 드라이버 유효성 체크를 진행할 때 GPU에 의해 접근되어지는 리소스들을 변경하는 일련의 작업들을 총칭한다.(드로우콜과 혼용하여 사용하지만 드로우콜을 포함하는 상위 개념이다.) SetPass는 쉐이더로 인한 렌더링 패스 횟수를 의미하고 쉐이더의 변경 시 SetPass 카운트는 증가하게 된다. 드로우콜이 일어날 때 상태 변경의 발생 여부로 이해하면 된다.(메시 변경은 포함하지 않음)

 

▲ Unity Editor의 Game탭에서 Stats를 눌러보면 배치를 확인가능하다.

 

드로우콜의 발생 조건

오브젝트 하나를 그릴 때 메시1개, 머티리얼 1개로 이루어져 있다면 배치는 1이다. =>(드로우콜 1회) 

하지만 하나의 오브젝트가 여러파츠로 이루어져있고 메시가 여러개이면 하나의 머티리얼을 공유한다 해도 파츠 수만큼 드로우콜이 발생한다. 이러한 오브젝트가 여러개 있다면 <파츠 수 * 오브젝트 수 = 드로우콜 횟수>가 되는 것이다. 이는 성능에 많은 영향을 미칠 수 있으며 메시가 여러개인 경우 말고도 머티리얼이 여러개인 경우 ex. 툰쉐이딩처럼 외곽선을 그리기 위해서 2Pass같이 MultiPass를 사용하는 경우에는 메시가 1개더라도 Pass수만큼 드로우콜이 발생한다.

=> 결론) 오브젝트마다 <Material의 수 * Mesh의 수 = 드로우콜 횟수>가 된다.