[ 번역 ] Mali Performance 4: Principles of High Performance Rendering

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-4-principles-of-high-performance-rendering

주의 : 번역이 개판이므로 이상하면 원문을 참고하세요.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

---

이 시리즈의 이전 블로그에서, 타일 기반 렌더링 구조를 가능한 한 효율적으로 사용하기 위한 기본적인 필수 항목들에 대해서 살펴 보았습니다. 특히 불필요한 메모리 접근을 최소화하기 위해서 가장 효율적으로 프레임버퍼를 사용하는 애플리케이을 만드는 방법에 대해서 보여 주었습니다. 그런 기본들에서 벗어나서, 필자는 이제 OpenGL ES API 를 가장 효율적으로 사용해 Mali 를 사용하는 플랫폼에서 최상의 결과를 획득하는 방법의 세부사항에 대해서 살펴 보기 시작할 겁니다. 하지만 그렇게 하기 전에, 성능 최적화의 5 개 원칙에 대해서 소개하자 합니다.

Principle 1: Know Your Goals

최적화를 시작할 때, 그 활동은 끝내는 시점에 대한 매우 명확한 목표들을 가지고 있어야 합니다. 최적화에 대한 많은 목표들이 존재합니다; 가장 일반적인 것들을 이야기하자면 더 빠른 성능, 더 낮은 전력 소비, 더 낮은 메모리 대역폭, 더 낮은 CPU 부하 등이 있습니다. 애플리케이션을 리뷰할 때 보게되는 문제의 종류들은 여러분이 해야 할 개선의 종류에 따라서 매우 다양합니다. 그러므로 이를 시작부터 정확하게 하는 것이 매우 중요합니다.

또한 작은 성취를 위해 점점 더 많은 시간을 소비하기 쉽상입니다. 그리고 많은 최적화들이 애플리케이션의 복잡도를 증가시키고 유지보수 문제를 발생시킬 것입니다. "이제 충분해" 라고 이야기할 때를 결정하기 위해서, 작업을 하는 동안 정기적으로 진척도를 리뷰하고, 이 시점에 도달하면 작업을 중단하세요.

Principle 2: Don't Just Try to Make Things Fast

필자는 종종 Mali 를 사용하는 개발자들로부터 칸텐트의 특정 부분을 더 빠르게 실행할 수 있는 방법에 대해서 알려달라는 질문을 받습니다. 이러한 유형의 질문은 더 세부적인 질문들로 이어지게 마련입니다. 셰이더 코드의 특정 부분으로부터 좀 더 나은 성능을 짜내려면 어떻게 해야 하는지, Mali 구조에 가장 들어 맞는 특정 지오메트리( geometry ) 메시( mesh )를 튜닝( tune )하려면 어떻게 해야 하는지 등이 있습니다. 이런 것들은 모두 유효한 질문들이기는 하지만, 제 생각에는 프로세스 초기에 최적화 활동 범위를 지나치게 좁혔고, 가장 유망한 공격 수단들을 살펴 보지 않은 채 남겨둔 것으로 보입니다.

두 질문 모두 고정 워크로드들을 최적화하려고 시도하는 것이며, 둘 다 워크로드가 충분하다는 가정을 내포하고 만들어진 것입니다. 실제 그래픽스에서는 씬들이 종종 엄청난 양의 중복 - 화면을 벗어난 오브젝트들, 다른 오브젝트에 의해서 겹쳐 그려지는 오브젝트들, 삼각형의 절반이 사용자가 볼 수 없는 곳을 향하는 오브젝트들 등 - 을 포함하며, 그것들은 최종 렌더링에 어떠한 기여도 하지 않습니다. 그러므로 최적화 활동들은 두 개의 기본적인 질문들에 대답하려고 시도할 필요가 있습니다:

1. 어떻게 씬으로부터 중복 작업들을 가능한한 효율적으로 줄일 수 있을까?
2. 어떻게 남아 있는 것들에 대한 성능을 미세 조정( fine tune )할 수 있을까?

요약하면 - 무엇인가를 마냥 빠르게 만들려고 시도하지 말고, 가능할 때마다 그렇게 하는 것을 피하려고 시도하십시오! 이런 "작업 회피( work avoidance )"들의 일부는 애플리케이션에서 전적으로 처리되어야 하지만, 많은 경우에 OpenGL ES 와 Mali 는 그것들을 올바로 수행하는 데 도움을 줄 수 있는 도구들을 제공합니다. 뒤쪽의 블로그에서 이에 대해서 더 다루도록 하겠습니다.

Principle 3: Graphics is Art not Science

여러분이 CPU 상에서 전통적인 알고리즘을 최적화하고 있다면, 그것은 보통 올바른 답변이지만, 그렇지 않은 시스템에서는 잘못된 답일 것입니다. 그래픽스 워크로드의 경우에, 우리는 단순하게 가능한한 빠르게 보기 좋은 그림을 생성하려고 시도합니다; 만약 최적화된 버전이 정확하지 않아도 사람들은 알아 차리지 못할 것입니다. 그러므로 성능에 도움이 된다면 알고리즘을 사용하는 것을 두려워하지 마십시오.

그래픽스를 위한 최적화 활동은 사용된 알고리즘을 살펴 봐야 합니다. 그리고 그것의 비용이 그것이 가져오는 가시적인 이점들에 비해 합당하지 않다면, 그것을 없애버리고 완전히 다른 알고리즘으로 대체하는 것을 두려워하지 마십시오. 실시간 렌더링은 아트 형식이며 최적화와 성능은 그 아트의 일부입니다. 많은 경우에 부드러운 프레임율( framerate )과 빠른 성능이 단일 프레임에 포함되는 약간의 디테일( detail )보다는 더 중요합니다.

Principle 4: Data Matters

GPU 들은 데이터 영역( data-plane ) 프로세서( 역주 : [ Single-Chip Control/Data-Plane Processors ] 참조 )들이며, 그래픽스 렌더링 성능은 종종 데이터 영역 문제에 의해 지배됩니다. 많은 개발자들은 문제를 확인하기 위해서 OpenGL ES API 함수 호출 시퀀스들을 살펴 보느라 많은 시간을 허비하는데, 그들이 그런 함수들에 넘긴 데이터를 살펴 보지는 않습니다. 이는 거의 항상 심각한 실수가 됩니다.

물론 OpenGL ES API 호출 시퀀스들은 중요합니다. 그리고 많은 로직 이슈들이 최적화 작업을 하는 동안 이것들을 살펴 봄으로써 발견될 수 있습니다. 하지만 데이터 애샛( asset )의 포맷( format ), 크기, 패킹( packing )이 매우 중요하며, 무엇인가를 더 빠르게 만들기 위한 기회를 살필 때 잊어서는 안 되는 것입니다.

Principle 5: Measure Early, Measure Often

씬 렌더링 성능에서 단일 드로( draw ) 호출의 영향은 API 레벨에서 이야기하는 것은 보통 불가능합니다. 그리고 많은 경우에 무해하게 보이는 드로 콜들이 종종 큰 성능 부하의 일부가 되기도 합니다. 필자는 많은 성능 팀들이 며칠 혹은 심지어는 몇 주 동안 최적화를 하는데 시간을 보내고 나서야 뒤늦게 그들이 튜닝하던 셰이더가 단지 전체 씬의 비용 중의 1 % 밖에 기여하지 않음을 깨닫는 것을 보아 왔습니다. 그래서 그들이 2 배 더 빠르게 만드는 환상적인 작업을 했지만, 전체 성능은 0.5 % 만이 개선되었습니다.

필자는 항상 DS-5 Streamline 과 같은 툴을 사용해 일찍 그리고 자주 측정하는 것을 권장합니다. DS-5 Streamline 을 사용하면 통합 하드웨어 성능 카운터들을 통해 GPU 하드웨어 성능의 정확한 관점을 획득할 수 있으며, Mali Graphics Debugger 를 사용하면 렌더링 워크로드에 기여하는 드로 호출이 무엇인지 찾을 수 있습니다. 최적화 주요 지점( hot spot )을 식별하는 것 뿐만 아니라 애플리케이션이 여러분이 원하는 대로 동작하고 있는지 확인하기 위한 새너티( sanity ) 체크를 하기 위해서도 성능 카운터를 사용할 수 있습니다. 예를 들어 프레임 당 픽셀( pixel ) 개수, 텍셀( texel ) 개수, 메모리 접근 횟수들을 수동으로( 역주 : 애플리케이션에 삽입한 코드를 이야기하는 듯 ) 수집하고 이를 하드웨어의 카운터들과 비교하십시오. 만약 기대했던 것보다 2 배 많은 렌더링된 픽셀들을 확인했다면, 셰이더를 튜닝하는 것보다 훨씬 더 많은 이점을 주는 먼저 조사해야만 하는 구조적인 이슈들이 존재할 수도 있습니다.

Next Time

그래픽스에서 최적의 성능은 애플리케이션이 OpenGL ES API 에 데이터를 제출하는 방식의 구조적인 부분을 만들 때 가장 방해를 받습니다, so in my next blog I will be looking at some of the things an application might want to consider when trying very hard to not do any work at all.

TTFN,

Pete