https://youtu.be/-jTz47g91ZA?si=5oSkIO8Y4RirFM6D
위 영상을 요약해 본 것입니다. mobile GPU에서의 최적화 요소에 관한 기본적인 내용을 담고 있습니다.
Remember it's just an art
가장 쉬운 최적화는, 거의 대부분 결과물을 제거해버리는 것이다 - 충분한 가치를 더해주지 않는 요소는 제거하는 것이 좋다.
- if it looks good, it is good
- 좋아보이는 것이 좋은 것이다. 시각적인 부분에 이득이 되도록 cycle을 사용하자.
- 물리적으로 꼭 정확할 필요는 없다.정확히 동일한 결과가 나올 필요도 없다.
- 최적화 결과물이 bit 단위로 정확하지 않아도 된다.
- 여기에는 정해진 정답이 없으며, 시각적으로 괜찮은 결과를 제공한다면 보다 빠른 근사값을 사용해도 된다.
- 렌더링 해 보기 전에는 최적화가 야기한 시각적인 트레이드오프를 판단할 수 없다. 렌더링 해서 장면에 최적화가 어떤 영향을 미쳤는 지 측정해야 알 수 있다. 그래서 그래픽스 최적화는 반복적인 실험일 경우가 대부분이며, “시도하고 결과를 보는 (Try it and see)” 과정이다.
모바일 디바이스는 넓은 퍼포먼스 범위를 가지는데, 이것은 보급형 기기에서는 각 칩셋의 capability에 좌우되고, 하이엔드급 기기에서는 폼팩터의 온도 제한에 따라 달라진다.
폼팩터 (form factor)
제품 외형이나 크기, 물리적 배열을 의미하며, 일반적으로 모바일 기기 외형을 가리키는 용어
보통 게임은 기기의 capability 가 증가함에 따라 더 복잡한 시각 요소들을 도입하는데, 넓은 범위의 기기를 지원하고자 하기 때문에, 각 기기의 서로 다른 렌더링 퍼포먼스 규모에 대응하는 그래픽스 스테이징을 잘 계획해야 한다. 이것은 나중에 정할 수 없기 때문에, 퍼포먼스 스테이징에 대한 접근을 미리 계획하는 것이 좋다.
가장 중요한 결정들
대부분의 컨텐츠에서 가장 큰 비용이 드는 부분은 fragment 처리이다. 모바일 기기들은 높은 해상도와 더 높은 화면 refresh rate를 주도하고 있지만, 1440p 렌더를 초당 90프레임으로 렌더링하는 것은 여전히 꽤나 큰 도전이다. 특히 복잡한 라이팅이나, 각 픽셀에 포스트 프로세싱 효과를 적용하고 싶다면 더욱 그렇다.
타깃 디바이스와, 원하는 렌더링 파이프라인에 대한 현실적인 평가가 가장 중요한 시작지점이 된다. 그리고 나서, 어떤 해상도와 framerate가 다른 여러 종류의 기기의 budget에서 가능할 지 살펴본다. 화면 안팎의 렌더링에서 어떤 컬러 포맷을 사용할 지도 결정해야 한다. 픽셀 갯수, frame rate, 그리고 컬러 포맷의 크기가 모두 곱해져 필요한 메모리 bandwidth의 기준선이 될 것이기 때문에, 결과값이 세제곱이 됨에 주의하자. 총 합계는 아주 빠르게 증가할 수 있고, 메모리 bandwidth는 GPU가 사용할 수 있는 자원 중 -에너지 소비의 관점에서- 가장 비싸다.
타깃 해상도를 정했으면, 전체적인 셰이더 budget를 정할 수 있다. 타깃으로 하고 싶은 각 기기에서 초당 사용 가능한 셰이더 코어 cycle 합계를 알아본다. 이것을 타깃 해상도와 framerate 로 나눈다. 이렇게 하면 각 픽셀마다 소비해야 하는 shader cycle의 갯수를 알 수 있다. 이 budget은 버텍스 셰이딩, fragment 셰이딩 등 화면 안팎의 렌더링을 모두 고려해서 늘려져야 한다
이 예시에서는 2개의 코어를 가진 Mali-G72 GPU가 탑재된 보급 기기에서, 1080p 60FPS 를 타깃으로 했을 때의 컨텐츠 budget을 볼 수 있다. 베스트 케이스 budget이 픽셀당 11.25 cycle 임을 볼 수 있다. 실제에서는 절대 이렇게 될 수 없기 때문에, 85%로 낮춘다- 픽셀당 9.5 cycle이 된다.
GPU 1개는 9.5 shader cycle로도 많은 것을 할 수 있다. 따라서 이 기기에서도 1080p 를 60 fps로 돌아가는 컨텐츠를 충분히 만들 수 있다. 하지만, 비효율적인 요소들에 대한 여유나 복잡한 효과에 대한 공간이 없다.
Asset Budget을 계획하기
두 번째 단계는, 어셋의 budget을 살펴보는 것이다. 여기에는 세 가지의 중대한 고려사항들이 있다.
- 첫 번째는 드로우콜이다 - 드로우콜은 드라이버가 수행하는 가장 비싼 CPU 쪽의 동작이다. CPU가 전력소비를 많이 하거나, CPU 단에서 큰 퍼포먼스 저하를 야기하지 않도록 하려면, 프레임 당 드로우 콜 총 합이 500회 주변을 유지하도록 권고하고 있다. 하이엔드 기기에서는 이 숫자를 넘어 프레임 당 1000회의 드로우콜을 수행할 수도 있고, 여전히 CPU 병목이 아닐 수 있다. 하지만, CPU 부하가 너무 크기 때문에 전력을 많이 소비하게 될 것이다.
- 트라이앵글은 래스터라이징 렌더러에서 가장 기본이 되는 단위 블럭이다. 하지만, 아주 조심스럽게 사용되어야 한다. 지오메트리 비용은 크게 두 가지로 나뉘어진다.
- 그 중 첫 번째는 메모리에서 버텍스 데이터를 fetch 할 때 메모리에 접근하는 비용이다. 버텍스 데이터는 통상 32바이트이기 때문에, 픽셀이나 텍셀보다는 상당히 많은 메모리 공간을 차지하게 된다. 버텍스 갯수에 대한 budget과, 버텍스 개별 단위의 메모리 budget 두 가지 모두를 정해두어야 한다.
- 셰이딩 비용 또한 지오메트리와 연관되어 있다. 이 비용은 버텍스 단에서만 있는 것이 아님에 주의하자. 작은 트라이앵글은 fragment 셰이딩에서도 더 비싸다 - 트라이앵글 모서리에서 샘플을 부분적으로 차지하기 때문이다. 따라서 3D 컨텐츠들은 트라이앵글 사이즈를 가능한 한 최대 크기로 유지하기 위해 런타임에서 Level of Detail을 선택하게 하거나, 기타 다른 테크닉들을 사용해야 한다. 이 테크닉들로 직접적인 버텍스 처리 비용 뿐 아니라 트라이앵글 모서리의 fragment 처리 오버헤드 두 가지 모두 줄일 수 있다.
마지막으로, 머터리얼 세트가 있다. 이것은 배포 시에, 그리고 메모리 안에서의 텍스처 데이터를 관리하는 것을 주로 의미한다. 필요 텍스처 저장 공간은 아주 빠르게 커질 수 있다. 따라서, 머터리얼 갯수, 해상도, 그리고 오프라인에서의 압축을 사용하는 것이 여기에서는 모두 중요하다. 런타임에서의 효율을 위해 3D 오브젝트에서는 거의 항상 mipmap이 필요할 것이다. 그것이 메모리 공간을 약간 더 차지하지만 말이다.
'GPU' 카테고리의 다른 글
Ep 2.5 Content best practices (0) | 2024.05.26 |
---|---|
Ep 2.4 : Engine and API best practices (1) | 2024.04.15 |
Unreal에서의 GPU Crash Debugging (1) | 2023.12.17 |
Shader Programs 최적화 (0) | 2023.09.02 |