원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-7-accelerating-2d-rendering-using-opengl-es

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

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

성능 블로그를 쓴지 한참 지났습니다. 지난 밤동안 작성하고 싶은 블로그에 대한 점심 커피 토론 중 하나가 wasim abbas 가 만든 기술 데모가 되었습니다. 글을 다시 쓰게 만들어 준 그에게 감사드립니다. 이번에는 2D 렌더링과 OpenGL ES 가 도울 수 있는 부분에 대해서 살펴 보도록 하겠습니다.

매우 많은 모바일 칸텐트들은 여전히 2D 게이밍이거나 2D 유저 인터페이스 애플리케이션입니다. 애플리케이션들은 스크린상에 생성되는 스프라이트( sprite ) 레이어들이나 UI 요소( element )들을 렌더링합니다. 이런 거의 대부분의 애플리케이션들은 OpenGL ES 를 사용해 렌더링을 수행하는데요, 일부 애플리케이션들은 3D 기능들을 사용하며, 알파 투명도를 다루기 위해 블렌딩을 사용하는 전통적인 back-to-front 알고리즘의 단순함( simplicity )을 선호합니다.

이 접근법이 동작하기는 하지만, 하드웨어의 3D 기능들을 이용하지는 않습니다. 그래서 많은 경우에 GPU 는 필요 이상으로 더 빡세게( harder ) 작동합니다. 이것의 영향은 저성능부터 포함된 GPU 에 의존하는 배터리 수명까지 다양합니다. 그리고 이 영향들은 모바일 디바이스에서 고해상도를 향할수록 더 증폭되는 경향이 있습니다. 이 블로그는 스프라이트 렌더링 엔진들에 대한 간단한 변경사항들에 대해서 살펴 볼 것입니다. 그 엔진은 3D 렌더링 API 가 제공하는 도구들과 비교했을 때 렌더링을 훨씬 더 빠르게 만들어 주며, 에너지 효율이 더 높습니다.

Performance inefficency of 2D content

2D 게임들에서 OpenGL ES 프래그먼트 셰이더들은 보통 단순합니다( trivial ) -- 텍스쳐 좌표를 보간( interpolate )하고, 텍스쳐 샘플을 로드( load )하고, 프레임 버퍼에 블렌딩( blend )합니다 -- 그러므로 최적화할 부분이 많지 않습니다. 이러한 칸텐트 유형을 위한 성능 최적화는 거의 대부분 중복 작업을 완전히 없애는 방식을 찾는 것과 관련이 있습니다. 그러므로 일부 프래그먼트에서는 셰이더가 심지어는 아예 실행되지 않습니다.

소개 섹션에서의 그림은 배경 레이어에 위에서의 사각 스프라이트의 전형적인 블리트( blit, 역주 : 블록 데이터를 빠르게 메모리로 옮기거나 복사하는 기법 )를 보여 줍니다; 실드 스프라이트의 바깥 부분이 투명( transparent )이며, 경계 부분은 부분적으로 투명합니다. 그래서 배경으로 갈수록 에일리어싱( aliasing ) 아티팩트( artifact )없이 완전히 투명하게 사라집니다. 그리고 몸통 부분은 불투명( opaque )합니다. 이 스프라이트 블리트는 알파 블렌딩을 활성화한 상태로 프레임버퍼에서 back-to-front 렌더링 순서로 최상위에 렌더링됩니다.

여기에서 비효율성이 발생하는 두 가지 주요 원인이 존재합니다:

• 먼저, 이 스프라이트를 둘러 싼 주변 영역들이 완전히 투명하므로, 그것은 출력 결과에 전혀 영향을 미치지 않고 있습니다. 하지만 처리하는데 시간은 걸립니다.

• 둘째로, 스프라이트의 몸통 부분은 완전히 불투명하므로, 그 밑에 있는 배경 많은 픽셀들을 완전히 무시하고 있습니다. 그래픽스 드라이버는 배경이 무시되는 빠르게 알 수 없기 때문에, 이 배경 프래그먼트들이 GPU 에 의해 렌더링되어야만 합니다. 이는 최종 씬에 유용하게 영향을 주지 않는 뭔가를 렌더링하기 위해서 처리 사이클과 나노줄( nanojules )의 에너지를 낭비합니다.

이는 상대적으로 단일 오우버드로( overdraw ) 만이 존재하는 합성 예제이지만, 1080p 화면에서 렌더링된 프래그먼트가 절반 이상 중복되는 실제 애플리케이션을 볼 수 있습니다. 만약 애플리케이션들이 OpenGL ES 를 다른 방식으로 사용해 이 중복을 제거할 수 있다면, GPU 는 애플리케이션을 더 빠르게 렌더링할 수 있거나, clock rate 와 operating voltage 를 줄이기 위해서 생성된 성능 헤드룸( performance headroom )을 사용할 수 있을 것입니다. 즉 상당한 양의 에너지를 절약할 수 있습니다. 이런 결과들은 어느 하나라도 매력적입니다. 그래서 "애플리케이션 개발자가 이를 성취하기 위한 방법은 무엇인가?" 라는 질문을 할 수 있습니다.

Test scene

이 블로그를 위해서, 위의 실드 아이콘들을 cover-flow 스타일의 정렬로 구성된 간단한 테스트 씬을 렌더링할 것입니다. 하지만 그 기법은 불투명 영역을 가진 모든 스프라이트 셋에 대해 동작할 것입니다. 테스트 씬은 아래와 같이 렌더링합니다:

여기에서 각 실드 아이콘들은 실제로는 알파 투명도를 사용하여 보이지 않는 부분들을 가리는 사각 프라이트입니다.

Tools of the trade

전통적인 전용 2D 렌더링 하드웨어에는, 사용할 옵션들이 별로 없었습니다; 애플리케이션은 스프라이트 레이어를 back-to-front 로 렌더링해 블렌딩 함수가 올바로 작동하도록 보장해야만 했습니다. 우리의 경우에는 애플리케이션이 3D API 를 사용하여 2D 씬을 렌더링하며, 3D API 가 애플리케이션에 중복 작업 제거를 위해 제공하는 도구가 무엇이냐는 질문을 할 수 있습니다.

완전한 3D 씬을 렌더링하는 데 있어 중복 작업을 제거하기 위해 사용되는 기본 도구는 깊이( depth ) 테스트입니다. 삼각형 안의 모든 버텍스들은 그것의 위치에 "Z" 요소를 가지고 있으며, 이는 버텍스 셰이더로부터 노출됩니다. 이 Z 값은 버텍스와 카메라의 거리를 인코딩하며, 래스터화( rasterization ) 프로세스는 버텍스 값을 보간해서, 프래그먼트 셰이딩을 할 필요가 있는, 각 프래그먼트에 깊이를 할당합니다. 이 프래그먼트 깊이 값은 현재 깊이 버퍼에 저장된 현존하는 값들에 대해 검사될 수 있습니다. 만약 그 값이 프레임버퍼에 있는 현재 데이터보다 카메라와 가깝지 않다면, GPU 는 그 프래그먼트를 버리게( discard ) 되는데, 그려면 그것은 셰이더 코어에 제출되지 않습니다. 왜냐하면 그 프래그먼트가 불필요하다는 것을 안전하게 알고 있기 때문입니다.

Using depth testing in "2D" rendering

스프라이트 렌더링 엔진은 이미 각 스프라이트의 레이어링( layering )을 트래킹했습니다. 그래서 그것들은 올바른 순으로 쌓여( stack )있습니다. 그래서 우리는 이 레이어 번호를 GPU 에 보내진 각 스프라이트의 버텍스에 할당된 Z 좌표 값으로 매핑할 수 있습니다. 그리고 실제로 그것이 3D 깊이를 가진 것처럼 씬을 렌더링할 수 있습니다. 만약 깊이 어태치먼트( attachment )를 가진 프레임버퍼를 사용하고, 깊이-쓰기( depth-write )를 활성화하고, 스프라이트들과 배경 이미지를 front-to-back 순서로 렌더링한다면( 예를 들어 back-to-front 인 일반적인 블리팅 패스의 반대 순서로 ), 깊이 테스트가 스프라이트와 백그라운드의 다른 스프라이트에 의해 가려지는 부분을 제거할 것입니다다.

이를 우리의 간단한 테스트 씬을 위해 실행하면, 다음의 결과르 얻을 수 있습니다:

오! 뭔가 잘못되었습니다.

여기에서 문제는 사각 스프라이트 지오메트리가 정확하게 불투명 픽셀의 모양과 일치하지 않는다는 것입니다. 카메라와 더 가까운 스프라이트의 투명 부분이 알파테스트로 인해 어떠한 컬러 값도 생성하지 않고 있음에도 여전히 깊이 값을 설정하고 있습니다. 아래쪽 레이더의 스프라이트가 렌더링될 때, 깊이 테스트를 하면 이전의 스프라이트의 투명 부분의 밑에서 가시적이어야만 하는 부분들이 부적절하게 제거( kill )된다는 것을 의미합니다. 그래서 OpenGL ES 클리어 컬러만이 보이고 있습니다.

Sprite geometry

이 문제를 해결하기 위해서, 스프라이트를 위해 유용한 지오메트리를 설정하는 방법에 대한 연구를 좀 할 필요가 있었습니다. 스프라이트 내에서 완전히 불투명한 픽셀을 위해 front-to-back 으로 렌더링할 때 깊이 값을 안전하게 설정할 수 있습니다. 그래서 스프라이트 아틀라스 생성은 각 스프라이트를 위해 두 가지 셋( set )을 제공할 필요가 있습니다. 한 셋은 아래의 가운데 이미지에서의 녹색 영역으로 지정되어 있으며, 이는 불투명 지오메트리만을 다룹니다. 그리고 두 번째 셋은 아래의 오른쪽 이미지에서 녹색 영역으로 지정되어 있으며, 완전히 투명( 완전히 버려질 수 있는 경우 )하지 않은 모든 것들을 포함하고 있습니다.

버텍스들은 상대적으로 비쌉니다. 그래서 이런 지오메트리 셋을 생성할 때는 가능한 한 적은 개수의 부가적인 지오메트리들을 사용하십시오. 불투명 영역은 완전히 불투명한 픽셀들만을 포함해야 합니다. 하지만 투명 영역은 안전하게 불투명 픽셀들과 완전하게 투명한 픽셀들을 부수 효과( side-effect )없이 포함할 수 있습니다. 그러므로 "best fit" 를 획득하려고 시도할 필요없이 "good fit" 를 위해 대충 근사계산하십시오. 일부 스프라이트의 경우에는, 불투명 영역을 생성할 가치가 없다는 것을 기억하세요( 불투명 텍셀을 가지고 있지 않거나 매우 작은 영역만이 불투명할 때 ). 그래서 일부 스프라이트들은 투명 렌더링으로 렌더링될 단일 영역만으로 구성될 수도 있습니다. 경험적으로 볼 때, 불투명 영역이 256 픽셀보다 적을 때, 그것들은 부가적인 지오메트리 복잡성을 사용해 경계처리될 가치가 없습니다. 하지만 항상 시도하고 확인할 가치는 있습니다.

이런 지오메트리를 생성하는 것은 상대적으로 성가십니다. 하지만 스프라이트 텍스쳐 아틀라스들은 보통 정적이며 이것은 애플리케이션 칸텐트 저작 과정에의 일부로 오프라인으로 수행될 수 있습니다. 그리고 런타임에 플랫폼 상에서 라이브로 수행될 필요가 없습니다.

Draw algorithm

각 스프라이트에 대해 두 개의 지오메트리 셋을 사용하여, 이제 테스트 씬의 최적화된 버전을 렌더링할 수 있습니다. 먼저 불투명 스프라이트 영역들과 배경을 font-to-back 순서로 렌더링합니다. 이 때 깊이 테스팅과 깊이-쓰기를 활성화합니다. 그 결과는 다음과 같습니다: 

다른 스프라이트 밑에서 가려진 스프라이트나 백그라운드의 영역은 절약될 수 있는 렌더링 작업입니다. 왜냐하면 그것은 셰이딩이 발생하기 전에 빠른 깊이 테스트를 통해 제거되었기 때문입니다.

불투명 지오메트리를 렌덜이했다면, 이제 각 스프라이트의 투명영역을 back-to-front 순서로 렌더링할 수 있습니다. 깊이 테스트를 켜 둔 채로 남겨 놨기 때문에, 아래쪽 레이어들의 스프라이트들은 논리적으로 위쪽에 있는 레이어들의 불투명 영역을 덮어쓰지 않습니다. 하지만 조금이라도 전력을 절약하려면 깊이 버퍼를 비활성화하십시오.

만약 불투명 스테이지의 컬러 출력을 지워버리고 깊이 값을 유지하고 투명 패스를 그리면, 이 패스에 의해서 추가된 부가적인 렌더링 결과를 가시화할 수 있습니다. 이는 아래 그림처럼 보입니다:

링들 외부의 불완전한 영역들은 작업이 절약된 영역을 가리킵니다. 왜냐하면 없어진 부분들은 첫 번째 드로잉 패스에서 렌덜이된 카메라에 더 가까운 불투명 스프라이트 영역의 깊이 값을 사용하는 깊이 테스트에 의해 제거되었기 때문입니다.

두 패스를 모두 같은 이미지에 함께 배치하고 렌더링하면, 원래의 back-to-front 렌더링과 동일한 가시적 결과를 다시 얻을 수 있습니다:

하지만 35 % 정도 더 적은 프래그먼트 스레드들이 시작되었고, 이는 이 씬을 렌더링하기 위해서 필요한 MHz 의 35 % 를 줄인 것으로 해석됩니다. 성공적입니다!

필요로 하는 마지막 연산 논리( operational logic )는 우리가 씬에 추가한 깊이 버퍼가 메모리에 다시 쓰여지지 않음을 보장하는 것입니다. 만약 애플리케이션이 EGL 윈도우 서피스에 직접적으로 렌더링하고 있다면, 여기에서 할 일은 없습니다. 왜냐하면 윈도우 서피스를 위한 깊이가 묵시적으로 버려지기 때문입니다. 하지만 여러분의 엔진이 오프스크린 FBO 에 렌더링하고 있다면, 오프스크린 타깃으로부터 FBO 바인딩을 변경하기 전에 ( OpenGL ES 3.0 이상에서는 ) glInvalidFramebuffer() 이나 ( OpenGL ES 2.0 에서는 ) glDiscardFramebufferEXT() 에 대한 호출을 추가하는 것을 보장하십시오. 세부사항을 원한다면 이 블로그를 확인하세요.

Summary

이 블로그에서 우리는 깊이 테스팅과 깊이-지향( depth-aware ) 스프라이트 기법의 사용이 3D 그래픽스 하드웨어를 사용하는 렌더링을 가속하는데 사용되는 방법에 대해서 살펴 보았습니다.

스프라이트의 불투명 영역과 투명 영역 사이의 분리를 제공하기 위해 부가적인 지오메트리를 추가하는 것은 복잡도를 증가시킵니다. 그래서 스프라이트들을 위한 버텍스의 개수를 최소화하려고 해야 하며, 그렇지 않으면 부가적인 버텍스와 작은 삼각형 크기를 처리하는데 드는 비용이 이점을 없애버릴 것입니다. 부가적인 지오메트리가 너무 복잡해질 것이 요구되거나 화면을 덮고 있는 영역이 너무 작다면, 그냥 불투명 영역을 무시하고 전체 스프라이트를 투명인 것처럼 렌더링하십시오.

이 기법이 3D 게임에서 2D UI 요소들을 렌더링하기 위해서도 사용될 수 있다는 것을 언급할 가치가 있습니다. 3D 씬을 렌더링하기 전에 near clip plane 과 매우 가까운 깊이로 UI 의 불투명 부분을 깊이와 함께 렌더링하십시오. 그리고 나서 3D 씬을 일반적인 경우처럼 렌더링하십시오( 불투명 UI 요소들의 뒤에 있는 부분들이 건너뛰어지게 될 것입니다 ). 마지막으로 UI 의 투명 부분들이 3D 출력의 최상위에서 렌더링되고 블렌딩될 수 있습니다. 3D 지오메트리들이 UI 요소에 간섭하지 않는다는 것을 보장하기 위해서 glDepthRange() 를 사용해 3D 패스에 의해 노출되는 깊이 값들의 범위를 매우 약간 제한할 수 있습니다. 이는 UI 요소들이 3D 렌더링보다 항상 near clip plane 에 더 가깝도록 보장해 줍니다.

Tune in next time,

Pete.

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-6-efficiently-updating-dynamic-resources

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

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

지난 번 블로그에서는 애플리케이션이 3D 칸텐트로부터 최적의 성능을 끌어낼 수 있도록 효율적으로 구현해야만 하는 중요한 영역들에 대해서 살펴 보았습니다. 씬의 큰 부분에 대한 개괄( Broad-Brush ) 컬링같은 것은 그 부분이 보이지 않음을 보장하기 때문에, 그것들이 GPU 에 전혀 보내지지 않게 됩니다. 이 블로그의 댓글 중의 하나에서 seanlumly01 님은 "드로 호출 사이에서 텍스쳐들을 수정하는 애플리케이션에 대해서는 성능 페널티가 없나요?" 라고 질문하셨습니다. 매우 좋은 질문입니다. 그것에 대한 답은 사소하지 않다( non-trivial )입니다. 그러므로 완전한 대답은 이 블로그 포스트로 연기해 놓았습니다.

Pipelined Rendering

리소스 관리를 해야 할 때 가장 중요한 것은 OpenGL ES 구현들은 거의 모두 심하게( heavily ) 파이프라인화되어 있다는 사실입니다. 이는 이전의 블로그에서 자세하게 언급되어 있지만, 요약을 하자면...

무언가를 그리기 위해서 glDraw...() 를 호출할 때, 그 드로는 즉시( instantly ) 이루어지는 것이 아닙니다. 대신에 GPU 에게 이 드로를 어떻게 수행해야 하는지를 알려 주는 커맨드가 연산 큐에 추가되며, 이것은 나중에 어떤 지점에서 수행됩니다. 이와 유사하게 eglSwapBuffers() 는 화면의 프론트 버퍼와 백 버퍼를 실제로 교환하는 게 아닙니다. 실제로는 그래픽스 스택( stack )에 애플리케이션이 렌더링과 렌더링을 표현하는 큐들에 대한 프레임 생성( composing )을 완료했음을 통보할 뿐입니다. 둘 다 행위에 대한 논리적인 명세 -- API 호출 -- GPU 상의 실제 작업 처리가 수십 밀리세컨드 길이일 수 있는 버퍼링 프로세스에 의해서 분리되어 있는 경우입니다.

Resource Dependencies

대부분의 경우에, OpenGL ES 는 동기화( synchronous ) 프로그래밍 모델을 정의합니다. 몇 가지 명시적인 예외들을 제외하고는, 드로 호출을 만들 때, 렌더링은 드로 호출이 만들어진 지점에서 발생하는 것처럼 보여야 하며, ( API 함수 호출과 이전에 지정된 GPU 커맨들에 기반해 ) 그 시간과 지점에 화면상의 모든 커맨드 플래그들, 텍스쳐들, 버퍼들의 상태를 올바로 반영하는 것처럼 보여야 합니다. 동기화 렌더링처럼 보여지는 것은 API 의 기저에 깔린 드라이버 스택이 만드는 정교한 환상입니다. 그것은 잘 동작하지만, 여러분이 최적의 성능과 최소한의 CPU 부하를 획득하고자 한다면 애플리케이션의 동작에 약간의 제약이 걸립니다.

앞에서 언급한 파이프라인 프로세스 때문에, 이 동기화 환상은 텍스쳐나 버프를 읽어들이는 대기중인( pending ) 드로 호출이 GPU 상에서 실제로 그 드로 호출에 대한 렌더링이 완료될 때까지 그 리소스에 대한 수정 잠금( modification lock )을 유지해야 한다는 것을 의미합니다.

예를 들어 다음과 같은 코드 시퀀스를 가진다고 합시다:

glBindTexture(1) // Bind texture 1, version 1 glDrawElements(...) // Draw reading texture 1, version 1 glTexSubImage2D(...) // Modify texture 1, so it becomes version 2 glDrawElements(...) // Draw reading the texture 1, version 2

그러면 첫 번째 드로 호출이 실제로 GPU 에 의해 처리가 되기 전까지는 glTexSubImage2D() 가 텍스쳐 메모리를 수정할 수 없습니다. 그렇지 않으면 첫 번째 렌더링 호출이 API 호출이 만들어진 지점에서의 GL 에 대한 스테이트( state )를 올바로 반영하지 못할 것입니다( 텍스쳐 버전 2 가 아니라 텍스쳐 버전 1 을 반영하는 물리 메모리의 칸텐츠를 사용해 드로를 렌더링할 필요가 있습니다 ). OpenGL ES 드라이버가 소비하는 시간의 많은 부분들은 이처럼 동기화 프로그래밍 "환상"을 유지하고 그 연산들이 너무 빠르거나( 리소스가 이용가능하기 전에 ) 느리게( 리소스 수정이 이미 된 후에 ) 발생하지 않도록 보장하기 위해 리소스 종속성들을 트래킹( tracking )하는 데 사용됩니다.

Breaking Resource Dependencies

리소스 종속성 충돌이 발생하는 시나리오에서 -- 예를 들어 여전히 대기중인 읽기 잠금( read lock )을 가지고 있을 때 버퍼 쓰기가 요구되는 경우 -- Mali 드라이버들은 어떤 특별한 처리 없이는 리소스 수정을 즉시 적용할 수 없습니다; 여기에 충돌을 자동으로 해결하기 위해 드라이버들에 열려 있는 여러 개의 가능한 방법들을 정리했습니다.

Pipeline Finish

충돌된 리소스들을 해결하기 위해, 대기중인 모든 GPU 에 대한 읽기와 쓰기를 하는 곳에서, 렌더링 파이프라인을 비울( drain ) 수 있습니다. 그 피니시( finish )가 완료된 후에, 리소스의 수정을 일반적인 것처럼 처리할 수 있습니다. 만약 이러한 일이 프레임버퍼 드로잉을 통해 발생한다면, 중간( intermediate ) 렌더링 스테이트를 메인 메모리에 강제로 플러싱( flush )하도록 하는 곳에서 점증적( incremental ) 렌더링 비용이 발생합니다; 세부사항에 대해서 더 알고자 한다면 이 블로그를 참고하세요.

파이프라인을 완전히 비우는 것은 CPU 가 다음 워크로드를 생성하는 동안 GPU 가 유휴상태가 된다는 것을 의미합니다. 이는 하드웨어 사이클을 낭비하는 것이며, 경험적으로 볼 때 좋지 않은 해결책입니다.

Resource Ghosting

약간의 메모리를 더 낭비한다면 동기화 프로그래밍 모델의 환상과 애플리케이션의 즉시 업데이트 처리를 모두 유지할 수 있습니다. ( 만약 그 변경이 부분 버퍼와 텍스쳐만을 대체하는 것이라면 ) 현재 리소스 메모리의 물리 칸텐츠를 수정하지 않고, 응용프로그램의 업데이트와 원본 버퍼로부터 데이터를 조립함으로써, 새로운 버전의 논리 텍스쳐 리소스를 간단하게 생성할 수 있습니다. 리소스의 최신 버전은 API 레벨에서 모든 연산을 위해 사용되며, 예전 버전들은 대기중인 렌더링이 완료될 때까지만 필요합니다. 이 시점에서 그것들의 메모리를 해제할 수 있습니다. 이러한 접근법은 리소스 고스팅( ghosting ) 혹은 copy-on-write 라고 알려져 있습니다( 역주 : Copy-On-Write 기법에 대해서는 [ [Study] Copy On Write (COW) ] 라는 포스트를 참고하세요 ).

이는 드라이버들이 가장 일반적으로 사용하는 접근법입니다. 왜냐하면 그것은 파이프라인을 온전히 유지하면서 GPU 하드웨어를 바쁘게 유지할 수 있도록 보장하기 때문입니다. 이 접근법의 단점은 고스트 리소스들이 살아 있는 동안의 추가적인 메모리들과 새로운 버전의 리소스를 메모리에서 할당하고 조합하기 위한 일부 추가적인 처리 로드( Processing load )입니다.

기억할 점이 하나 더 있는데요, 리소스 고스팅이 항상 가능한 것은 아니라는 것입니다; 특히 리소스들이 UMP, Gralloc, dma_buf 같은 메모리 공유 API 를 사용해서 외부 소스로부터 임포트( import )될 때입니다. 이런 경우에, 카메라, 비디오 디코더, 이미지 프로세서같은 다른 드라이버들이 이런 버퍼에다가 쓰기작업을 할 수 있으며, Mali 드라이버는 그런 작업이 발생했는지 여부를 알 방법이 없습니다. 이런 경우에, 일반적으로는 copy-on-write 메커니즘( mechanism )을 적용할 수 없습니다. 그래서 드라이버는 이 문제를 해결하기 위해서 대기중인 종속성들을 위해 멈춰서 대기하는 경향이 있습니다. 대부분의 애플리케이션의 경우에 이런 부분에 대해서 걱정할 필요는 없습니다. 하지만 다른 미디어 가속기( accelerator )로부터 가지고 온 버퍼들을 가지고 작업할 때는 주의해야 합니다.

Application Overrides

파이프라인 깊이 때문에 모든 하드웨어 렌더링 시스템들 상에서 리소스 종속성들이 문제가 된다는 점을 감안하면, 최신 버전의 OpenGL ES 에는, 응용프로그램 개발자가 필요할 때 순수하게 동기화 렌더링 환상을 재정의해( override ) 더욱 세부적으로 제어할 수 있도록 하는, 기능들이 추가되었다는 사실이 별로 놀랍지 않습니다.

OpenGL 3.0 의 glMapBufferRange() 함수는 애플리케이션 개발자가 버퍼를 애플리케이션의 CPU 주소 공간으로 매핑할 수 있도록 해 줍니다. 버퍼를 매핑하는 것은 애플리케이션이 GL_MAP_UNSYNCHRONIZED_BIT 라는 접근 플래그를 지정할 수 있도록 하는데, 이는 대충 해석하면 "리소스 종속성은 신경 꺼. 나는 내가 뭘 하고 있는지 알고 있어" 비트입니다. 버퍼 매핑이 비동기화되면, 드라이버는 동기화 렌더링 환상을 강제하려 시도하지 않으며, 애플리케이션은, 대기중인 렌더링 연산으로부터 여전히 참조되고 있는, 버퍼 영역들을 수정할 수 있습니다. 그러므로 버퍼 업데이트가 에러를 만든다면, 그러한 연산들을 위한 렌더링이 잘못될 수 있습니다.

Working With Resource Dependencies

GL_MAP_UNSYNCHRONIZED_BIT 와 같은 기능들을 직접적으로 사용하는 것과 더불어, 많은 애플리케이션들은, 지나친 고스팅 부하를 발생시키지 않고 유연한 렌더링을 생성하기 위해 파이프라인화된, 리소스 용법( usage )에 대한 지식을 사용해 작업하고 있습니다.

Seperate Out Volatile Resources

정적 리소스와 휘발성( volatile ) 리소스들이 분리되어 있음을 보장함으로써, 고스팅을 덜 비싸게 수행할 수 있습니다. 이는 할당되거나 복사될 필요가 있는 메모리 영역을 가능한 한 작게 만듭니다. 예를 들어, glTexSubImage2D() 를 사용해서 업데이트되는 애니메이션되는 글자( glyph )가 절대 변경되지 않는 정적 이미지들을 사용하는 텍스쳐 아틀라스를 공유하지 않음을 보장하거나, CPU 상에서 ( 애트리뷰트나 인덱스 업데이트를 통해 ) 소프트웨어적으로 애니메이션되는 모델이 정적 모델들과 같은 버퍼 안에 존재하지 않음을 보장하는 것입니다.

Batch Updates

이상적으로 FBO 렌더링이 발생하기 전에 대부분의 리소스 업데이트를 단일 블록( block )에서 수행( 하나의 큰 업데이트나 다중의 연속된 서브 버퍼/텍스쳐 업데이트들 )함으로써, 버퍼 업데이트와 관련된 부하를 감소시키고 고스팅된 복사의 개수를 최소화할 수 있습니다. 다음과 같이 드로 호출에 리소스 업데이트를 삽입하는 것을 피하십시오...

glBufferSubData glDraw glBufferSubData glDraw glBufferSubData glDraw

... GL_MAP_UNSYNCHRONIZED_BIT 를 사용할 수 있지 않는다면 말입니다. 이걸 다음과 같이 변경하는 것이 보통 훨씬 효율적입니다: 

glBufferSubData glBufferSubData glBufferSubData glDraw glDraw glDraw

Application Pipelined Resources

애플리케이션의 성능을 더욱 예측 가능하게 만들고, 드라이버에서 메모리를 재할당하는 고스팅의 부하를 피하고자 한다면, 적용할 만한 기법이 하나 있습니다. 렌더링 파이프라인에 존재하는 각 지연 시간 프레임마다 애플리케이션에서 각 휘발성 리소스들의 다중 복사본을 명시적으로 생성하는 것입니다( 일반적으로 Android 같은 시스템에 대해서는 3 개 입니다 ). 이 리소스들은 라운드-로빈( round-robin ) 순서로 사용되므로, 리소스에 대한 다음 변경이 발생할 때는 그 리소스를 사용하는 대기중인 렌더링이 완료되어야 합니다. 이는 애플리케이션의 변경들이 드라이버에서의 특별한 처리를 요구하지 않고 물리 메모리에 직접적으로 제출( commit )될 수 있음을 의미합니다.

애플리케이션의 파이프라인 길이를 결정하는 쉬운 방법은 없습니다. 하지만 텍스쳐를 사용하는 드로 호출 뒤에다가 glFenceSync() 를 호출함으로서 펜스 오브젝트를 삽입하고, N 프레임 후에 변경을 만들기 바로 직전에 glClientWaitSync() 를 호출함으로써 펜스 오브젝트를 빼내는 식으로, 디바이스에서 경험적으로 테스트해 볼 수는 있습니다. 만약 GL_TIMEOUT_EXPIRED 를 반환한다면, 렌더링이 여전히 대기중인 것이고, 여러분이 사용하고 있는 리소스 풀에다가 추가적인 리소스 버전을 추가할 필요가 있습니다.

좋은 질문을 찾아 준 Sean 에게 감사드립니다. 이게 대답이 되었으면 좋겠네요!

Cheers,

Pete

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-5-an-application-s-performance-responsibilities

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

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

OpenGL ES 를 사용해 Mali GPU 상에서 그래픽스 렌더링 성능을 살펴 보는 블로그 시리즈의 다음 회에 오신 것을 환영합니다. 이번 시간에는 3D 애플리케이션을 개발 중일때 OpenGL ES 호출을 전혀 하지 않은 상태에서 고려할 중요한 애플리케이션 측 최적화중 일부에 대해서 살펴 볼 것입니다. 나중의 블로그에서는 OpenGL ES API 의 용례의 특정 영역들에 대해서 더 세부적으로 살펴 볼 것입니다. 이 블로그에 서술된 기술들은 Mali 전용이 아닙니다. 어떤 GPU 에서든 잘 동작할 것입니다.

With Great Power Comes Great Responsibility

OpenGL ES API 는 드로잉( drawing ) 연산( operation )들에 대한 직렬 스트림( serial stream )을 지정하는데, 그것들은 드로잉 연산들이 처리되는 방식을 제어하기 위한 명시적인 스테이트( state )들과 함께 GPU 가 수행해야 하는 하드웨어 커맨드( command )들로 바뀝니다. 이 연산의 저수준 모드는 애플리케이션에 GPU 가 렌더링 작업들을 수행하는 방식을 제어할 수 있도록 해 줍니다. 그러나 그것은 디바이스 드라이버가 애플리케이션이 렌더링하고자 하는 전체 씬에 대한 정보를 별로 가지고 있지 않다는 것을 의미하기도 합니다. 전체 정보의 결핍은 디바이스 드라이버가 GPU 로 보내는 커맨드 스트림을 재구성할 수 없어서, 최대 효율과 고성능을 달성하기 위해서는, 애플리케이션이 API 를 통해 적절한 렌더링 커맨드들을 순서대로 보내야 한다는 것을 의미합니다. 고성능 렌더링 및 최적화의 첫 번째 규칙은 "작업을 적게 하라" 는 것이며, OpenGL ES API 호출이 밠애하기 전에 애플리케이션에서 그 작업을 시작할 필요가 있습니다.

Geometry Culling

모든 GPU 들은 뷰잉 프러스텀( viewing frustum ) 외부에 존재하거나 카메라와 멀어지는 방향을 향하고 있는 프리미티브들을 버리는 컬링을 수행할 수 있습니다. 이것은 매우 저수준 컬링이며, 이는 프리미티브 별로 수행되고, 버텍스 셰이더가 각 버텍스를 위한 클립-스페이스( clip-space ) 좌표계를 계산한 이후에는 적용될 수 없습니다. 만약 전체 오브젝트가 프러스텀 바깥쪽에 존재한다면, 이것은 GPU 처리 시간, 메모리 대역폭, 에너지를 굉장히 낭비하고 있을 수 있습니다.

3D 애플리케이션이 수행해야 하는 가장 중요한 최적화는 최종 렌더링 결과에서 보이지 않는 오브젝트를 미리 컬링하는 것과 이런 오브젝트들을 위한 OpenGL ES API 호출을 완전히 건너뛰는 것입니다. 여기에서 사용될 수 있는 몇 가지 기법들이 있는데요, 복잡도에 따라서 다양합니다만, 밑에서 몇 가지 예에 대해서 설명하도록 하겠습니다.

Object Bounding Box

애플리케이션을 위한 가장 단순한 정책은 각 오브젝트를 위한 바운딩 박스를 유지하는 것입니다. 박스는 각 축에 대한 최소/최대 버텍스( vertex )들을 가집니다. 8 개의 버텍스를 오브젝트 스페이스에서 클립 스페이스로 계산하는 것은 CPU 상의 소프트웨어에서 각 드로 연산들에 대해서 계산될 수 있을 만큼 충분히 가볍고, 박스는 클립 스페이스 볼륨과의 간섭( intersection )을 위해 테스트될 수 있습니다. 이 테스트에 실패한 오브젝트는 프레임 렌더링에서 배제될 수 있습니다.

화면 공간에서 많은 양을 차지하는 매우 기하학적으로 복잡한 오브젝트들에 대해서는, 오브젝트를 각각의 바운딩 박스를 가지는 더 작은 조각으로 나누는 것이 유용합니다. 이는 현재 카메라 위치에서 이득을 볼 수 있다면 오브젝트의 일부 섹션( section )을 거부하도록 만들어 줍니다.

위의 이미지는 우리의 오래된 Mali 테크 데모중 하나를 보여 줍니다. 인도어( indoor ) 공상 과학 공간 역( station ) 환경을 날아 다닙니다. 최종 3D 렌더링은 왼쪽에 보입니다. 오른쪽의 칸텐트 디버그 뷰는 씬 안의 다양한 오브젝트들의 파랗게 강조된 바운딩 박스들을 보여줍니다.

Scene Hierarchy Bounding Boxes

이 바운딩 박스 정책은 추가로 취할 수 있는 것입니다. 이것은 렌더링되고 있는 월드를 위한 더 완벽한 씬 데이터 구조로 바뀝니다. 예를 들어 월드의 각 빌딩을 위해서 바운딩 박스들이 생성될 수 있으며, 각 빌딩의 각 방들을 위해서 바운딩 박스가 생성될 수 있습니다. 만약 빌딩이 화면 밖에 있다면, 그것은 단일 바운딩 박스 체크에 기반해 빠르게 배제될 것입니다. 빌딩이 포함하고 있는 개별 오브젝트들을 위한 수 백개의 검사가 필요하지 않습니다. 이 계층에서, 방들은 부모 빌딩이 가시적일 때만 검사되며, 그것들의 부모 방이 가시적일 때만 렌더링 가능한 오브젝트들이 테스트됩니다. 이러한 유형의 계층 정책은 실제로는 렌더링을 위해 GPU 로 보내질 워크로드를 변경하지는 않습니다. 하지만 이 검사들을 위한 CPU 성능 부하를 더욱 관리가능하게 만드는 데 도움을 줍니다.

Portal Visibility

많은 게임 월드들에서 뷰잉 프러스텀에 대한 단순한 바운딩 박스 검사들은 많은 중복된 작업들을 제거하게 될 것입니다. 하지만 여전히 제출해야 할 양이 엄청나게 남아 있습니다. 이는 특히 서로 연결된 방들로 구성된 월드에서 일반적입니다. 왜냐하면 공간적으로 인접한 방들의 뷰가 많은 카메라 각도로부터 벽, 바닥, 천장 등에 의해 완전히 차폐될 수 있습니다. 하지만 뷰잉 프러스텀 내부에 포함될 수 있을 정도로 충분히 가깝습니다( 그래서 단순한 바운딩 박스 컬링을 통과합니다 ).

그러므로 바운딩 박스 정책은 미리 계산된 가시성 정보를 사용해 보충될 수 있으며, 이는 씬 내의 오브젝트들에 대한 더 공격적인 컬링을 가능하게 합니다. 예를 들어 아래에 보이는 것처럼 세 개의 방으로 구성된 씬에서, Room C 내부의 어떠한 오브젝트도 플레이어가 서 있는 Room A 에서 보이지 않습니다. 그러므로 플레이어가 Room B 로 이동하기 전까지는 Room C 내부의 모든 오브젝트들에 대한 OpenGL ES 호출을 그냥 건너뛸 수 있습니다.

이러한 유형의 가시성 컬링은 레벨 디자이너( level designer )들에 의해 종종 게임 디자인 요소( factor )로 포함됩니다; 만약 레벨 디자인이 모든 지점에서 가시적인 방들의 개수를 항상 적게 유지할 수 있다면, 게임들이 더 높은 가시 품질과 프레임 율을 달성할 수 있습니다. 이러한 이유로, 인도어 설정들을 사용하는 많은 게임들은 S 와 U 모양의 방과 회랑들을 매우 많이 만듭니다. 왜냐하면 그것들은 문이 적절하게 배치된다면 그 방을 통과하는 시선( line of sight )이 없다는 것을 보장하기 때문입니다.

이 정책은 추가로 취할 수 있는 것입니다. 이는 어떤 경우에는 테스트 바닥에서 심지어 Room B 를 컬링할 수 있도록 해 줍니다. 이는 프러스텀에 대해서 현재 방과 인접한 방을 연결하는 포탈( portal ) -- 문, 창문 등 -- 들의 좌표를 테스트함으로써 수행됩니다. 만약 Room A 와 Room 를 연결하는 포탈이 현재 카메라 각도에서 보이지 않는다면, 우리는 Room B 에 대한 렌더링도 배제할 수 있습니다.

이러한 유형의 개괄적인( broad-brush ) 컬링 검사는 GPU 워크로드를 줄여주는 데 있어서 효율적이며, CPU 나 GPU 드라이버가 자동으로 수행하기에는 불가능합니다 -- 그것들은 렌더링되고 있는 씬에 대한 이러한 수준의 정보를 알 수가 없습니다 -- 그러므로 애플리케이션이 이러한 유형의 빠른 컬링을 수행하는 것이 중요합니다.

Face Culling

GPU 에 대해 화면 외부의 지오메트리들을 전송하지 않는 것 이외에도, 애플리케이션은 가시적인 오브젝트들을 위한 렌더링 스테이트들이 효율적으로 설정되는 것을 보장해야 합니다. 이는 컬링 목적을 위해 불투명 오브젝트들에 대한 후면( back-face ) 컬링을 활성화하는 것을 의미합니다. 이는 GPU 가 카메라로부터 멀어지는 방향을 향하는 삼각형들을 가능한 한 빠르게 배제할 수 있도록 해 줍니다.

Render Order

OpenGL ES 는 깊이( depth ) 버퍼를 제공하는데, 이것은 애플리케이션이 지오메트리를 순서대로 보내는 것을 허용해 주며, 깊이-테스트는 올바른 오브젝트들이 최종 렌더링 결과에 나올 수 있도록 해 줍니다. GPU 에 지오메트리를 순서 없이 렌더링할 수 있기는 하지만, 애플리케이션이 앞에서 뒤( front-to-back ) 순서로 오브젝트를 그린다면 더 효율적입니다. 왜냐하면 이것은 빠른 깊이 및 스텐실 테스트 유닛의 효율성을 극대화하기 때문입니다( The Mali GPU: An Abstract Machine, Part 3 - The  Midgard Shader Core 를 참고하세요 ). 만약 뒤에서 앞의 순서로 오브젝트를 렌더링한다면, GPU 가 일부 프래그먼트( fragment )를 렌더링하는 데 몇 사이클이 소비될 수 있습니다. 카메라에 더 가까운 프래그먼트들을 사용해 나중에 겹쳐그리는 것은 매우 많은 GPU 사이클들을 낭비하게 됩니다.

삼각형들이 완벽하게 정렬( sort )되는 것을 요구하는 것은 아닙니다. 그것은 CPU 사이클 관점에서 매우 무겁습니다; 그냥 거의 올바르게 만든다는 목적을 가지고 있을 뿐입니다. 바운딩 박스를 사용하거나 그냥 월드 스페이스에서의 오브젝트 원점 좌표를 사용하여 오브젝트 기반 정렬을 수행하는 것만으로도 보통 충분합니다; 삼각형들이 약간 순서에 맞지 않아도 GPU 에서 완전한 깊이 테스트에 의해서 깔끔히 정리될 것입니다.

블렌딩되는( blended ) 삼각형들은 뒤에서 앞의 순서로 렌더링되어야 올바른 블렌딩 결과를 얻을 수 있다는 것을 기억하세요. 그러므로 모든 불투명 지오메트리들을 앞에서 뒤의 순서로 먼저 렌더링한 후에 블렌딩되는 삼각형들을 나중에 렌더링할 것을 권장합니다.

Using Server-Side Resources

OpenGL ES 는 클라이언트-서버( client-server ) 메모리 모델을 사용합니다; 클라이언트측 메모리는 애플리케이션과 드라이버에 의해 소유되는 리소스들과 비슷하고, 서버측은 GPU 하드웨어에 의해 소유되는 리소스들과 비슷합니다. 리소스들을 애플리케이션으로부터 서버측으로 전송하는 것은 일반적으로 무겁습니다:

• 드라이버가 데이터를 포함하기 위한 메모리 버퍼를 할당해야만 합니다.
• 데이터가 애플리케이션 버퍼로부터 드라이버가 소유한 메모리 버퍼로 복사되어야 합니다.
• 메모리가 메모리의 GPU 뷰와 일관성( coherent ) 있게 만들어져야 합니다. 통합( unified ) 메모리 구조에서 이는 캐시 유지( maintenance )를 내포하고 있을 것이며, 카드 기반 그래픽스 구조에서 이는 시스템 메모리로부터 전용 그래픽스 RAM 으로의 전체 DMA 전송을 의미할 것입니다.

그래서 초기 OpenGL 구현에서는 -- 지오메트리 처리는 CPU 에서 수행되고 GPU 하드웨어를 전혀 사용하지 않는 구현들에서는 -- OpenGL 과 OpenGL ES 는 지오메트리를 위한 클라이언트측 버퍼들이 API 에 넘겨지도록 하는 많은 API 들을 가지고 있었습니다.

• glVertexAttributePointer 는 사용자가 버텍스당 애트리뷰트 데이터를 지정할 수 있도록 합니다.
• glDrawElements 는 사용자가 드로 당 인덱스 데이터를 지정할 수 있도록 합니다.

이런 방식으로 지정되는 클라이언트측 버퍼들을 사용하는 것은 매우 비효율적입니다. 거의 대부분의 경우에 각 프레임에서 사용되는 그 모델들은 변경되지 않습니다. 그러므로 이것은 단순히 드라이버가 메모리를 할당하고 그 데이터를 그래픽스 서버로 전송하는 많은 양의 작업을 별 이득없이 수행하도록 강제합니다. OpenGL ES 의 훨씬 더 효율적인 대안( alternative )들은 애플리케이션이 버텍스 애트리뷰트와 인덱스 정보를 위한 데이터를 서버측 버퍼 오브젝트들에 업로드할 수 있도록 합니다. 이는 일반적으로 레벨 로드 시점에 수행됩니다. 버퍼 오브젝트를 사용할 대의 각 드로 연산에 대한 프레임 당 데이터 트래픽( traffic )은 그냥 GPU 에게 이들 버퍼 오브젝트들이 어디에서 사용되는 지를 알려주는 핸들( handle ) 집합일 뿐이며, 이는 명백히 더 효율적입니다.

이 규칙의 한 가지 예외는 유니폼 버퍼 오브젝트( Uniform Buffer Objects, UBOs )들입니다. 이것들은 셰이더 프로그램들에서 사용되는 드로 호출 당 상수들을 위한 서버측 저장소입니다. 유니폼 값들은 드로 호출 내부의 모든 버텍스 및 프래그먼트 스레드들에 의해 공유되므로, 그것들을 가능한 한 효율적으로 셰이더 코어에 의해 접근될 수 있도록 하는 것이 중요합니다. 그러므로 디바이스 드라이버들은 일반적으로 그것들이 하드웨어 접근 효율성을 최대화하기 위해서 메모리에 패킹( packed )되는 방식을 공격적으로 최적화할 것입니다. 서버측 UBO 들을 사용하는 대신에 드로 호출 당 작은 크기의 유니폼 데이터를 glUniform<x>() 함수 패밀리를 통해 설정하는 것이 선호됩니다. 왜냐하면 그것이 유니폼 데이터가 GPU 에 전달되는 방식에 대한 더 많은 제어를 제공하기 때문입니다. 유니폼 버퍼 오브젝트들은 여전히 버텍스 셰이더에서의 스켈레탈 애니메이션( skeletal animation )을 위해 사용되는 긴 행렬 배열과 같은 큰 유니폼 배열들을 위해서 사용됩니다.

State Batching

OpenGL ES 는 스테이트 기반 API 이며 각 드로잉 연산들을 위해 구성될 수 있는 매우 많은 스테이트 설정들을 가지고 있습니다. 단순하지 않은 씬들에서는 여러 개의 렌더 스테이트들이 사용됩니다. 그러므로 애플리케이션은 일반적으로 스테이트 변경 연산들을 수행해 드로 호출 자체가 제출되기 전에 각 드로 연산들을 위한 구성들을 설정합니다.

드라이버의 CPU 부하를 줄이고 GPU 에서 최적의 성능을 획득하려고 시도할 때 유념해야 할 두 가지 유용한 목표가 존재합니다:

• 대부분의 스테이트 변경은 낮은 비용을 소비합니다만, 공짜는 아닙니다. 왜냐하면 드라이버가 에러 검사를 수행해야 하며 내부 데이터 구조에 어떤 스테이트를 설정해야 하기 때문입니다.
• GPU 하드웨어는 상대적으로 큰 묶음( batch )의 작업을 다루도록 설계되어 있습니다. 그러므로 각 드로 연산은 상대적으로 커야만 합니다.

이 두 영역을 모두 개선하기 위한 애플리케이션 최적화의 가장 일반적인 형태 중 하나는 드로 콜 배칭( batching )입니다. 배칭을 통해 같은 렌더 스테이트를 사용하는 여러 개의 오브젝트들을 같은 데이터 버퍼로 미리 패키징하고, 단일 드로 연산을 사용해서 그것들을 렌더링할 수 있습니다. 이는 CPU 로드를 줄여 줍니다. 왜냐하면 더 적은 스테이트 변경과 드로 연산이 GPU 를 위해 패키징되어 있고 이는 GPU 가 더 큰 작업 묶음을 처리하도록 하기 때문입니다. 내 동료인 stacysmith 는 효율적인 배칭을 위한 전용 블로그를 가지고 있습니다: Game Set and Batch. 얼마나 많은 드로 호출들을 단일 프레임에 포함해야 하느냐에 대해서는 어렵거나 빠른 규칙이 존재하지 않습니다. 왜냐하면 대부분이 시스템 하드웨어의 능력( capability )과 원하는 프레임율에 의존하고 있기 때문입니다. 하지만 일반적으로 프레임 당 몇 백개의 드로 호출을 넘지 않는 것을 권장합니다.

또한 최적의 배칭을 하는 것과 깊이 정렬 및 컬링을 통해 중복 작업을 제거하는 것 사이에는 종종 충돌이 존재한다는 것을 기억하십시오. 드로 호출 카운트가 합리적이고 여러분의 시스템이 CPU 제약에 걸려있지 않다면, 일반적으로는 향상된 컬링과 front-to-back 오브젝트 렌더링 순서를 통해 GPU 워크로드를 줄이는 것이 더 낳습니다.

Maintain The Pipeline

이전의 블로그들 중 하나에서 언급했듯이, 최근의 그래픽스 API 들은 동기 실행에 대한 환상을 유지하지만 실제로는 성능을 극대화하기 위해 깊게( deeply ) 파이프라인화되어 있습니다. 애플리케이션은 이 렌더링 파이프라인의 동작을 저해하는 API 호출드을 사용하는 것을 피해야 합니다. 그렇지 않으면 성능은 급격하게 떨어지게 됩니다. 왜냐하면 CPU 는 GPU 가 종료될 때까지 대기하게 되고 GPU 는 CPU 가 더 많은 작업을 던져 줄 때까지 유휴상태가 되기 때문입니다. 이 주제에 대한 더 많은 정보를 얻기 원한다면 Mali Performance 1: Checking the Pipeline 을 참고하세요 -- it is was important to warrant and entire blog in its own right!

Summary

이 블로그에서는 Mali 를 사용하는 고성능 3D 렌더링을 성공적으로 성취하기 위해 고려해야만 하는 중요한 애플리케이션측 최적화들과 동작들에 대해서 살펴 보았습니다. 요약하면 기억해야 할 핵심들은 다음과 같습니다:

• GPU 에다가 보일 수 있는 가능성이 있는 오브젝트들만 보내세요.
• 불투명 오브텍트들을 앞에서 뒤의 순서로 렌더링하세요.
• 서버측 데이터 리소스들은 버퍼 오브젝트들에 저장됩니다. 클라이언트측 리소스들은 그렇지 않습니다.
• 렌더링 스테이트들을 배칭해서 불필요한 드라이버 부하를 줄이세요.
• 깊은( deep ) 렌더링 파이프라인을 유지하고 애플리케이션이 파이프라인 고갈( drains )을 유발하지 않도록 하세요.

다음 시간에는 튜닝하고 OpenGL ES API 자체를 사용하는 더 기술적인 관점에 대해서 살펴 보기 시작하도록 하겠습니다. 그리고 코드 샘플들을 추가하도록 하겠습니다.

TTFN,

Pete

원문 : 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

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-3-is-egl_5f00_buffer_5f00_preserved-a-good-thing

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

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

이번 주에 필자는 EGL_BUFFER_PRESERVED 를 통해 애플리케이션 프레임버퍼 관리의 영역으로의 전환( diversion )과 어디에서 이 기법을 사용하면 좋을지 결정하는 방법에 대해서 이야기하는 것을 마무리하고 있습니다. 이것은 사용자 인터페이스( user-interface ) 개발과 관련해 고객과 이야기할 때 정기적으로 제기되는 질문이며, 다른 그래픽스 요소들과 마찬가지로 그것의 효율성은 여러분이 수행중인 작업에 달려 있기 때문에, 이 블로그가 그것들을 명확하게 ( 혹은 적어도 약간 덜 혼란스럽게( murky ) ) 만들어 줄 수 있기를 바랍니다.

What is EGL_BUFFER_PRESERVED?

이전 블로그인 [ Mali Performance 2: How to Correctly Handle Framebuffers ] 에서 설명했듯이, 일반적인 상황에서는 윈도우 서피스의 칸텐츠가 한 프레임에서 다음 프레임으로 보존되지 않습니다. Mali 드라이버는 프레임버퍼( framebuffer )의 칸텐츠가 버려진다( discard )고 가정합니다. 그러므로 컬러( color ), 뎁스( depth ), 스텐실( stencil ) 버퍼의 어떠한 스테이트( state )도 유지될 필요가 없습니다. EGL 명세에서는 기본 EGL_SWAP_BEHAVIOR 를 EGL_BUFFER_DESTROYED 로 지정하고 있습니다.

윈도우 서피스를 EGL 을 통해서 생성할 때, 서피스를 EGL_SWAP_BEHAVIOR 를 EGL_BUFFER_PRESERVED 로 구성해서 생성할 수 있습니다. 이는 프레임버퍼의 컬러 데이터가 프레임 N 의 렌더링 끝에서 프레임 N+1 의 렌더링을 위한 컬퍼 버퍼의 시작 컬러로 사용된다는 것을 의미합니다. 이러한 보존은 컬러 버퍼에만 적용된다는 점을 기억하십시오; 뎁스 버퍼와 스텐실 버퍼는 보존되지 않으며, 그것들의 값은 모든 프레임의 끝에서 소실됩니다.

Great, I can render only what changed!

대부분의 사람들이 하는 일반적인 실수는 이 기법이 현존하는 프레임버퍼에 대한 적은 양의 렌더링만을 패치( patch )할 수 있도록 해 준다고 믿는 것입니다. 만약 이전 프레임 이후로 시계의 1 초만이 화면에서 변경되었다고 하면, 그냥 태스크바( taskbar )에서 시계를 수정하기만 하면 될 것입니다. 맞습니까? 아닙니다!

대부분의 실제 시스템들은 N-버퍼링 렌더링 체계( scheme )를 실행하고 있다는 점을 기억하십시오. 일부는 더블( double ) 버퍼링지만, 트리플( triple ) 버퍼링이 일반적이 되고 있습니다. N+1 프레임을 렌더링할 때의 최상위에 추가하고 있는 메모리 버퍼는 N 프레임의 컬러 버퍼가 아니라 N-2 프레임의 컬러 버퍼일 것입니다. EGL_BUFFER_PRESERVED 는, 단순한 패치 연산을 수행하는 것이 아니라, 드라이버로 하여금, 프레임 N 의 컬러 버퍼를 포함하는, 텍스쳐를 적용한( textured ) 사각형을 프레임 N+1 을 위해 작업중인 타일( tile ) 메모리에 렌더링하게 만드는 것입니다.

이전 블로그 중의 하나와 seanellis 의 블로그의 Forward Pixel Kill( FPK )에서 언급했듯이, Mali GPU 패밀리의 최근 멤버들은 겹쳐 그려지는( overdrawn ) 프래그먼트( fragment )들이 GPU 에 대한 주요한 비용이 되기 전에 제거하기 위한 기능을 지원하고 있습니다. 이전 프레임의 최상위에서 겹쳐 그려지는 것이 불투명( 블렌딩( blending ) 이 없고 프래그먼트 셰이더가 "discard" 를 호출하지 않음 )이라면, 겹쳐 그려지는 부분에 대한 리드백( readback )이 억제될 수 있으며, 결과적으로 성능이나 대역폭에 대한 영향이 없어집니다. 또한, EGL_BUFFER_PRESERVED 가 활성화되어 있지만 모든 것을 겹쳐 그리고 싶다면, 그냥 프레임의 렌더링의 시작 부분에서 glClear() 를 호출해서 리드백을 전혀 하지 않도록 할 수 있습니다. 

Is EGL_BUFFER_PRESERVED worth using?

전체 화면 리드백의 필요성을 받아들이면 멀티 프레임 렌덜이 파이프라인의 개념을 생각하기 시작할 때 상대적으로 직관적이 됩니다. 다음 질문은 "사용자 인터페이스 애플리케이션에 EGL_BUFFER_PRESERVED 를 사용해야 하느냐" 는 것입니다.

많은 가치있는 엔지니어링( engineering ) 질문들처럼, 그 대답은 단순하게 "네" 혹은 "아니요" 가 되기보다는 "그때 그때 달라요" 에 가깝습니다.

올바른 시작 컬러를 사용하는 프레임을 생성하기 위한 EGL_BUFFER_PRESERVED 의 비용은 ( FPK 에 의해서 건너 뛰는( killed ) 경우를 제외하면 ) 이전 프레임 데이터에 대한 전체 화면( full-screen ) 로드( load )입니다. 다른 대안은 클리어( clear ) 컬러를 사용해 프레임을 처음부터 다시 렌더링하는 것입니다. EGL_BUFFER_PRESERVED 를 사용하는 것이 좋을지의 여부는 다음의 두 가지 상대적인 비용에 달려 있습니다:

• 만약 UI 애플리케이션이 투명도를 많이 사용하는 다중의 비압축 레이어들로 구성되어 있다면, EGL_BUFFER_PRESERVED 가 합리적일 것입니다. 하나의 레이어에서 이전 컬러 데이터를 리드백하는 비용은 다중 레이어 + 블렌딩 루트( route )를 통해 처음부터 컬러를 재생성하는 것보다 훨씬 저렴할 것입니다.
• 만약 대부분이 단일 레이어이며 압축된 텍스쳐를 읽어들이는 단순한 UI 나 2D 게임을 가지고 있다면, EGL_BUFFER_PRESERVED 는 잘못된 것입니다. 이전 프레임의 컬러를 리드백하기 위한 대역폭 부하가 처음부터 프레임을 생성하는 것보다 훨씬 비쌀 것입니다.

이를 항상 칼로 자르듯이 명확하게 나누는 것은 불가능합니다 -- 이 두 개의 극단 사이에는 중간 지대가 존재합니다 -- 그러므로 분석을 수행할 때 주의를 기울여야 합니다. 만약 의심할 여지가 있다면, 제품 플랫폼에서 실행중인 실제 애플리케이션에서, EGL_BUFFER_PRESERVED 를 껐다 켰다 하면서, GPU 성능 카운터들을 사용해 성능을 리뷰( review )하십시오. 실제 장치에서 실제의 경우를 측정하는 것보다 더 나은 답을 주는 것은 없습니다. 이 시리즈의 다른 블로그에서는 애플리케이션 성능 분석을 하는 가이드를 제공하며 앞으로 몇 달 동안 계속해서 이 영역에 더욱 많은 내용들을 추가하도록 하겠습니다.

그런데, 그런 성능 경험을 수행할 때, 최적의 애플리케이션은 EGL_BUFFER_PRESERVED 를 명시적으로 사용( 혹은 비사용 )하도록 설계되어 있는 것이 중요하다는 점을 기억하십시오; 어떤 경로에서든 가장 효율적인 결과를 획득하려면, 일반적으로는 EGL 구성 스위치( configuration switch )를 단순하게 껐다 켰다 하는 것만큼 간단하지는 않습니다( 역주 : 이 옵션이 성능에 큰 영향을 준다는 의미인듯 ).

Mali-DP500 과 같은 ARM Frambuffer Compression( AFBC )가 활성화된 디스플레이 컨트롤러나 Mali-T760 과 같은 GPU 를 사용하는 시스템에서, EGL_BUFFER_PRESERVED 리드백의 대역폭 부하가 엄청나게 줄어들었다는 것을 언급하는 것은 가치가 있습니다. 리드백 대역폭이 압축된 프레임버퍼의 대역폭이므로 일반적으로 비합축 원본보다는 25-50 % 정도 더 작기 때문입니다.

A Better Future?

EGL_BUFFER_PRESERVED 의 동작은 훌륭한 아이디어입니다. 그리고 많은 경우에 여전히 유용하지만, 그것의 이론적인 이점들의 많은 부분들이 N 버퍼링 시스템에서 사라졌습니다. 왜냐하면 이것은 이전 프레임 데이터에 대한 전체 화면 리드백을 필요로 하기 때문입니다.

우리는, 이용가능한 애플리케이션 및 버퍼 보존 체계가 특정 플랫폼에서 N 버퍼 메모리 모델을 명시적으로 노출( 및 이용 )하면, 애플리케이션 -- 특히 사용자 인터페이스 -- 이 훨씬 더 효율적이 될 수 있다고 생각합니다. 만약 애플리케이션이 그 시스템이 더블 버퍼링을 사용하고 있다는 것을 알고 있고 현재 스테이트와 두 프레임 전의 스테이트 사이의 델타를 알고 있다면, 구조적으로 이상적인 렌더링과 변경된 메모리 영역에 대한 합성( compositing )에 가까워질 수 있습니다. 이것은 잠재적으로 대부분 안정적인 상태( steady-state )의 사용자 인터페이스를 위해 에너지 소비와 메모리 대역폭을 줄여줄 수 있습니다.

EGL_KHR_partial_update

EGL_KHR_partial_update 익스텐션( extension )은 애플리케이션이 N 버퍼링 레벨의 시스템-- 버퍼 에이지( buffer age ) --에 대한 질의를 할 수 있도록 허용하고, 그 정보와 버퍼가 마지막으로 렌더링된 후에 애플리케이션에서 변경된 부분에 대한 지식을 사용해, GPU 에 의해 렌더링되어야 하는 "dirty rectangles" 화면 영역을 식별할 수 있도록 허용하기 위해서 설계되었습니다.

이 익스텐션에서 버퍼 에이징 기능은 EGL_EXT_buffer_age 익스텐션에 의해 제공되는 것과 매우 유사합니다만, 타일 기반 렌더링의 경우에는 어떤 타일을 완전히 떨어뜨릴( drop ) 수 있는지 미리 알려 주는 dirty rectangle 을 제공합니다. 왜냐하면 그것들은 수정되지 않는 것이 보장되기 때문입니다. 만약 이 두 개의 익스텐션 중 하나를 선택해야 한다면, 최적의 성능을 위해서는 EGL_KHR_partial_update 기능을 사용하세요; 이러한 이유로 Mali 드라이버는 EGL_EXT_buffer_age 를 노출하지 않습니다.

EGL_KHR_swap_buffers_with_damage

EGL_KHR_swap_buffers_with_damage 익스텐션은 애플리케이션을 위해 시스템 합성 처리에 dirty rectangle 힌트들을 제공하기 위한 수단을 제공합니다. 이는 N 버퍼링 합성기( compositor )들과 디스플레이 컨트롤러들이 EGL_KHR_partial_update 으로부터 클라이언트 렌더링이 획득하는 최적화로부터 이득을 취할 수 있게 해 줍니다.

Do I need to use both extensions to get full benefit?

네, EGL_KHR_partial_update 는 GPU 를 버퍼 생성자( producer )로서 사용하여 애플리케이션이 렌더링하는 내용을 최적화합니다; EGL_KHR_swap_buffers_with_damage 는 버퍼 소비자로서 사용되는 디스플레이에 유효한 출력 이미지를 보낼 수 있도록 하기 위해 시스템 합성기가 리프레시( refresh )해야 하는 내용을 최적화합니다. 각각의 경우에 애플리케이션이 지정해야 하는 damage rectangle 은 일반적으로 다릅니다. 그러므로 두 개의 익스텐션이 모두 필요합니다.

Tune In Next Time

프레임버퍼 관리에 대한 짧은 전환이 마무리되었습니다. 그래서 다음 시간에는 Mali 에서 ARM DS-5 Streamline 을 사용해 애플리케이션 성능 병목과 최적화 기회에 대해서 살펴 보도록 하겠습니다.

TTFN,

Pete

Further reading:

• https://www.khronos.org/registry/egl/specs/EGLTechNote0001.html
• https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_partial_update.txt
• https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_swap_buffers_with_damage.txt
• https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-2-how-to-correctly-handle-framebuffers

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

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

이번 주에 렌더링 파이프라인의 하드웨어 중심 관점으로 약간 들어 갔는데요, 지금까지 어떻게 그리고 더욱 중요하게는 언제 Mali 드라이버 스택이 OpenGL ES API 활동( activity )를 렌더링에 필요한 하드웨어 워크로드가 되는지를 살펴 보았습니다. 앞으로 살펴 볼 것이지만, OpenGL ES 는 이 영역에서 특별히 탄탄하게 명세화되어( specified ) 있지는 않습니다. 그래서 개발자들이 피하기 위해서 주의해야만 하는 일반적인 함정들이 존재합니다.

Per-Render Target Rendering: Quick Recap

이전 블로그에서 설명했듯이, Mali 하드웨어 엔진은 2 패스 렌더링 모델 상에서 동작합니다. 렌더 타깃을 위해 모든 지오메트리를 렌더링하고 나서 프래그먼트 처리를 시작합니다. 이는 로컬 메모리에 존재하는 대부분의 작업 상태를 GPU 와 단단히 묶어서 유지할 수 있도록 해 줍니다. 그리고 렌더링 처리를 위해 필요한 전력을 소비하는 외부 DRAM 에 대한 접근을 최소화해 줍니다.

OpenGL ES 를 사용할 때 우리는 이 로컬 메모리 내부에서 프레임 버퍼 데이터의 대부분을 생성하고 사용하고 버릴 수 있습니다. 이는 프레임버퍼들을 외부 메모리에서 읽거나 외부메모리에 쓰는 것을 피하게 해 줍니다. 하지만 컬러 버퍼같은 것들을 유지하기 원한다면 그 버퍼에 대해서는 예외입니다. 하지만 이것은 보장된 동작이 아니며 어떤 패턴의 API 용법들은 GPU 가 추가적인 읽기 및 쓰기를 하도록 강제하는 비효율적인 행위를 유발할 수도 있습니다.

Open GL ES: What is a Render Target?

Open GL ES 에는 두 종류의 렌더 타겟이 존재합니다:

• 오프 스크린( off-screen ) 윈도우 렌더 타깃들.
• 오프 스크린 프레임버퍼 렌더 타깃들.

개념적으로는 이것들은 OpenGL ES 에서는 매우 유사합니다; 완전히 동일하지는 않습니다. 하나의 렌더 타깃만이 API 레벨에서 활성화되어 한 번에 하나의 점을 렌더링하는 데 사용될 수 있습니다; glBindFramebuffer( fbo_id ) 호출을 통해 현재의 렌더 타깃이 선택되면, 여기에서 0 인 ID 는 윈도우 렌더 타깃을 되돌려 놓는 데 사용될 수 있습니다( 또한 종종 기본 FBO 라 불리기도 합니다 ).

On-screen Render Targets

온 스크린( on-screen ) 렌더 타깃들은 EGL 에 의해 엄격하게 정의되어 있습니다. 한 프레임을 위한 렌더링 활동은 현재 프레임과 다음 프레임에 대한 매우 명확하게 정의된 경계를 가지고 있습니다; 두 개의 eglSwapBuffers() 호출 사이에서 FBO 0 을 위한 모든 렌더링은 현재 프레임을 위한 렌더링을 정의합니다.

또한 사용중인 컬러, 뎁스( depth ), 스텐실( stencil ) 버퍼들은 칸텍스트( context )가 생성될 때 정의되며, 그것들은 구성( configuration )은 변경될 수 없습니다. 기본적으로 컬러, 뎁스, 스텐실의 값들은 eglSwapBuffers() 후에는 정의되어 있지 않습니다( 역주 : 쓰레기 값이 들어 가 있을 수 있다는 의미인듯 ) - 예전의 값은 이전 프레임으로부터 보존되지 않습니다 - 이는 GPU 드라이버가 그 버퍼들의 사용에 대한 보증된 추정( guaranteed assumption )을 할 수 있도록 해 줍니다. 특히 우리는 뎁스와 스텐실이 일시적인( transient ) 작업 데이터일 뿐이라는 것을 알고 있으며, 결코 메모리로 쓰여질 필요가 없다는 것을 알고 있습니다.

Off-screen Render Targets

오프 스크린 렌더 타깃들은 별로 엄격하게 정의되어 있지 않습니다.

먼저, 드라이버에게 애플리케이션이 FBO 를 렌더링하는 것을 끝냈고 렌더링을 위해 제출될 수 있다는 것을 알려주는 eglSwapBuffers() 와 같은 함수가 존재하지 않습니다; 렌더링 작업을 플러싱하는 것은 다른 API 활동들로부터 추론됩니다. 다음 섹션에서 Mali 드라이버의 지원하는 추론에 대해서 살펴 보겠습니다.

둘째로, 애플리케이션이 컬러, 뎁스, 스텐실 어태치먼트( attachment ) 지점에 부착된( attached ) 버퍼를 사용해 작업을 수행할 수 있는지 여부를 보장하지 않습니다. 애플리케이션은 이것들을 텍스쳐로서 사용하거나 다른 FBO 에다가 다시 부착할 것입니다. 예를 들어 이전 렌더 타깃으로부터 뎁스 값을 다시 로드해 다른 렌더 타깃을 위한 시작 뎁스 값으로 사용하는 것입니다. 애플리케이션이 glInvalidateFramebuffer() 를 호출해서 명시적으로 내용을 버리지 않는다면, OpenGL ES 의 기본 동작은 모든 어태치먼트를 보존합니다. 노트: 이것은 OpenGL ES 3.0 의 새로운 진입점( entry point )입니다; Open GL ES 2.0 에서는 Mali 드라이버가 지원하는 glDiscardFramebufferExt() 확장 진입점을 사용해서 동일한 기능에 접근할 수 있습니다.

Render Target Flush Inference

일반적인 상황에서 Mali 는 렌더 타깃이 "언바운드( unbound )"되었을 때 렌더링 작업을 플러싱하는데, 드라이버가 eglSwapBuffers() 호출을 발견하여 메인 위도우 서피스를 플러싱하는 경우는 예외입니다.

성능이 떨어지는 것을 막기 위해서는 개발자들은 최종 렌더링의 서브셋( sub-set )만을 포함하고 있는 불필요한 플러싱을 피할 필요가 있습니다. 그러므로 프레임 당 오프 스크린 FBO 를 한 번만 바인딩하고 그것을 끝까지 렌더링하는 것을 권장합니다.

잘 구조화된 렌더링 시퀀스( 거의 어쨌든 - 이게 왜 불완전한지는 다음 섹션에서 확인하세요 )는 다음과 같습니다:

#define ALL_BUFFERS COLOR_BUFFER_BIT | DEPTH_BUFFER_BIT | STENCIL_BUFFER_BIT glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 0 (window surface) glBindFramebuffer( 1 ) // Switch away from FBO 0, does not trigger rendering glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 1 ... // Draw FBO 1 to completion glBindFramebuffer(0) // Switch to FBO 0, unbind and flush FBO 1 for rendering glDraw...( ... ) // Draw something else to FBO 0 (window surface) glBindFramebuffer( 2 ) // Switch away from FBO 0, does not trigger rendering glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 2 ... // Draw FBO 2 to completion glBindFramebuffer(0) // Switch to FBO 0, unbind and flush FBO 2 for rendering glDraw...( ... ) // Draw something else to FBO 0 (window surface) eglSwapBuffers() // Tell EGL we have finished, flush FBO 0 for rendering

반대로 "나쁜" 동작은 다음과 같습니다:

#define ALL_BUFFERS COLOR_BUFFER_BIT | DEPTH_BUFFER_BIT | STENCIL_BUFFER_BIT glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 0 (window surface) glBindFramebuffer( 1 ) // Switch away from FBO 0, does not trigger rendering glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 1 glBindFramebuffer(0) // Switch to FBO 0, unbind and flush FBO 1 for rendering glDraw...( ... ) // Draw something else to FBO 0 (window surface) glBindFramebuffer( 1 ) // Rebind away from FBO 0, does not trigger rendering of FBO // However, rebinding FBO 1 requires us to reload old render // state from memory, and write over the top of it glDraw...( ... ) // Draw something to FBO 1 glBindFramebuffer(0) // Switch to FBO 0, unbind and flush FBO 1 (again) glDraw...( ... ) // Draw something else to FBO 0 (window surface) eglSwapBuffers() // Tell EGL we have finished, flush FBO 0 for rendering

이런 식의 행위는 증분 렌더러( incremental renderer )로 알려져 있으며 그것은 드라이버가 렌더 타깃을 두 번 처리하도록 만듭니다. 첫 번째 처리 패스는 중간( intermediate ) 렌더 스테이트를 메모리( 컬러, 뎁스, 스텐실 )에 모두 씁니다. 그리고 두 번째 패스는 그것을 다시 메모리로 읽어들입니다. 그러므로 그것은 오래된 스테이트의 최상위에 렌더링을 더 "추가"하게 됩니다.

위의 다이어그램에서 보이듯이, 증분 렌더링은 프레임 버퍼 대역폭 관점에서 잘 구조화된 단일 패스 렌더링과 비교했을 때 +400% 의 대역폭 페널티[ 32-bpp 컬러와 D24S8 로 패킹된 뎁스-스텐실이라 가정 ]를 가지고 있음을 알 수 있습니다. 잘 구조화된 렌더링은 중간 스테이트를 메모리에서 다시 읽는 것을 피하고 있습니다.

When to call glClear?

주의깊게 본 독자들은 네 개의 프레임 버퍼들을 위한 렌더링 시퀀스에다가 glClear() 라는 호출을 삽입한 것에 주목했을 것입니다. 이 애플리케이션은 각 렌더 타깃의 렌더링 시퀀스의 초기 부분에서 항상 모든 어태치먼트들에 대한 glClear() 를 호출해야 합니다. 물론 이전의 어태치먼트 칸텐트가 불필요함을 의미합니다. 이는 명시적으로 드라이버에게 이전의 스테이트가 필요하지 않다는 것을 전달하며, 즉 우리는 그것을 메모리로부터 다시 읽어들이는 것을 피할 수 있을 뿐만 아니라 정의되지 않은 버퍼 칸텐트들을 정의된 "clear color" 스테이트에 담습니다.

여기에서 볼 수 있는 일반적인 실수는 프레임버퍼의 일부만을 클리어하는 것입니다; 즉 시저( scissor ) 렉트( rectangle )가 일부 스크린 영역만을 포함한다든가 해서 렌더 타깃의 일부만이 활성화되었을 때 glClear() 를 호출하는 것. 그것이 전체 서피스에 적용될 때 렌더 스테이트가 완전히 버려질 수 있습니다. 그러므로 가능하다면 전체 렌더 타깃에 대한 클리어가 수행되어야 합니다.

When to call glInvalidateFramebuffer?

OpenGL ES API 에서 FBO 를 효율적으로 사용하기 위해서는 애플리케이션이 드라이버에게 컬러/뎁스/스텐실 어태치먼트들이 단지 일시적인 작업 버퍼임을 알려주는 것입니다. 그것들의 값이 현재 렌더 패스에 대한 렌더링 끝에서 버려질 수 있다는 것을 의미합니다. 예를 들어 모든 3D 렌더링은 컬러, 뎁스를 사용하지만, 거의 대부분의 애플리케이션에서는 뎁스 버퍼가 일시적이며 안전하게 무효화될 수 있습니다. 불필요한 버퍼들을 무효화하는 것이 실패하면 그것들에 메모리에 다시 작성되는 결과를 낳습니다. 그렇게 되면 메모리 대역폭을 낭비하게 되고 렌더링 처리에서 소비하는 에너지가 증가합니다.

이 시점에서 가장 일반적인 실수는 glInvalidateFramebuffer() 를 glClear() 와 동일하게 취급해서, 프레임 N 에 대한 무효화 호출을 프레임 N+1 의 FBO 를 처음 사용하는 시점에 하는 것입니다. 이건 너무 늦습니다! 무효화 호출의 목적은 드라이버에게 그 버퍼가 유지될 필요가 없음을 알려주는 것입니다. 그러므로 그런 버퍼들을 생성하는 프레임을 위해 GPU 에 작업 제출을 하도록 수정할 필요가 있습니다. 다음 프레임에 알려주는 것은 원래의 프레임이 처리된 후입니다. 애플리케이션은 드라이버에게 어떤 버퍼들이 프레임버퍼가 플러싱되기 전에 일시적인지 알려주는 것을 보장할 필요가 있습니다. 그러므로 프레임 N 에 있는 일시적인 버퍼들은 프레임 N 에서 FBO 가 언바인딩되기 전에 glInvalidateFramebuffer() 를 호출함으로써 식별될 수 있습니다. 예를 들면:

#define ALL_BUFFERS COLOR_BUFFER_BIT | DEPTH_BUFFER_BIT | STENCIL_BUFFER_BIT static const GLEnum invalid_ap[2] = { GL_DEPTH_ATTACHMENT, GL_STENCIL_ATTACHMENT }; glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 0 (window surface) glBindFramebuffer( 1 ) // Switch away from FBO 0, does not trigger rendering glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 1 ... // Draw FBO 1 to completion glInvalidateFramebuffer( GL_FRAMEBUFFER, 2, &invalid_ap[0] ); // Only keep color glBindFramebuffer(0) // Switch to FBO 0, unbind and flush FBO 1 for rendering glDraw...( ... ) // Draw something else to FBO 0 (window surface) glBindFramebuffer( 2 ) // Switch away from FBO 0, does not trigger rendering glClear( ALL_BUFFERS ) // Clear initial state glDraw...( ... ) // Draw something to FBO 2 ... // Draw FBO 2 to completion glInvalidateFramebuffer( GL_FRAMEBUFFER, 2, &invalid_ap[0] ); // Only keep color glBindFramebuffer(0) // Switch to FBO 0, unbind and flush FBO 2 for rendering glDraw...( ... ) // Draw something else to FBO 0 (window surface) eglSwapBuffers() // Tell EGL we have finished, flush FBO 0 for rendering

Summary

이 블로그에서 우리는 Mali 드라이버들이 렌더 패스들의 식별자를 다루는 방식, 일반적인 비효율적인 지점, 애플리케이션 개발자가 OpenGL ES API 를 비효율성을 피할 수 있도록 제어하는 방법 등에 대해서 살펴 보았습니다. 요약에서는 다음과 같이 추천합니다:

• 각 FBO( FBO 0 이 아닌 것 )를 프레임에서 정확하게 한 번만 바인딩하고 연속되는 API 호출 시퀀스에서 완료될 때까지 렌더링.
• 기존의 값이 필요로 하지 않는 모든 어태치먼트들에 대해 각 FBO 의 렌더링 시퀀스의 시작점에서 glClear() 를 호출.
• 중간 스테이트가 그냥 일시적인 작업 버퍼인 모든 어태치먼트들에 대해서 FBO 렌더링 시퀀스의 끝에서 다른 FBO 로 전환되기 전에 glInvalidateFramebuffer() 나 glDiscardFramebufferExt() 를 호출.

다음 시간에는 다음과 관련한 것을 살펴 보겠습니다 -- 윈도우 서피스 컬러를 한 프레임으로부터 다음 프레임을 위한 기본 입력으로서 유지하기 위한 EGL_BUFFER_PRESERVED 의 효율적인 사용과 그것이 성능과 대역폭에 미치는 영향.

Cheers,

Pete.

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-1-checking-the-pipeline

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

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

이 시리즈에서 처음 몇 개의 블로그 동안, ARM Mali "Midgard" GPU 패밀리가 사용하는 고수준 렌더링 모델에 대해서 설명해 왔습니다. 이 시리즈들의 나머지 부분에서는 ARM 의 시스템 레벨 프로우파일링 툴인 DS-5 Streamline 을 사용하는 방법에 대해서 설명하고, 애플리케이션이 Mali 기반 시스템의 외부에서 최적의 성능을 획득하지 못하는 영역을 식별할 것입니다.

이 블로그에서, 매크로-스케일( macro-scale ) 파이프라이닝과 관련한 이슈들에 대한 디버깅, 항상 GPU 를 바쁘게 만드는 수단, 그리고 프레임 레벨 파이프라인이 멈추는 일반적인 원인에 대해서 살펴 볼 것입니다. 만약 이 시리즈가 처음이라면 첫 번째 블로그를 읽을 것을 권장합니다. 왜햐나면 그것은 여기에서 더 세부적으로 다루게 될 개념에 대해서 소개하고 있기 때문입니다.

노트( note ): 여러분이 이미 DS-5 Streamline 을 가지고 있고 실행중이라고 가정합니다. 만약 아직 실행하지 않았다면, 다양한 Mali 기반 소비자 디바이스에서 설정하는 법에 대한 몇 개의 가이드가 있습니다:

• Google Nexus 10
• Samsung Galaxy Note 3, or Note 10.1

이 블로그의 예제들은 DS-5 v5.16 을 사용해서 수집되었습니다.

What does good content look like?

성능 문제를 분석하기 전에, 우리의 목표와 스트림라인에서 이것이 어떻게 보이는지를 이해하는 것이 좋습니다. 시스템의 성능과 칸텐트의 복잡도에 기반한 두 가지 "좋은" 행위( behavior )들이 존재합니다.

• GPU 가 병목( bottleneck )인 곳의 칸텐트를 위한 행위.
• 수직동기화( vsync )가 병목인 곳의 칸텐트를 위한 행위.

이 실험을 위해 필요한 카운터들은 다음과 같습니다:

• Mali Job Manager Cycles: GPU cycles
• 이 카운터는 GPU 가 뭔가를 수행하는 클락 사이클에 증가합니다.
• Mali Job Manager Cycles: JS0 cycles
• 이 카운터는 GPU 가 프래그먼트 셰이딩을 하는 클락 사이클에 증가합니다.
• Mali Job Manager Cycles: JS1 cycles
• 이 카운터는 GPU 가 버텍스 셰이딩을 하거나 타일링을 하는 사이클에 증가합니다.

The GPU is the bottleneck

만약 GPU 가 병목인 곳( 예를 들어 렌더링이 60 FPS 를 달성하기에는 너무 복잡함 )의 칸텐트를 위한 프레임 레벨 렌더링 파이프라인을 생성하고 유지하는 데 성공했다면, 우리는 GPU 워크로드( workload ) 유형( 버텍스나 프래그먼트 처리 )들인 작업들이 항상 전체 능력( capacity )을 이용해 실행되고 있기를 기대하게 됩니다.

거의 대부분의 칸텐트에서 프래그먼트 처리는 GPU 실행에 있어서 가장 지배적인 부분입니다; 애플리케이션들은 보통 버텍스다 한자리 혹은 두자리 수가 더 많은 프래그먼트를 가지고 있습니다. 그러므로 이 시나리오에서는 JS0 이 항상 활성화되어 있고 CPU 와 JS1 은 모든 프레임에서 적어도 일정 시간만큼 유휴상태가 될 것이라 예상할 수 있습니다.

스트림라인을 사용하여 이 카운터 집합들을 수집할 때, 세 가지 활동( activity ) 그래프들을 보게 될 것인데요, 이것들은 GPU 를 위한 날( raw ) 카운터 값들과 함께 툴에 의해 자동으로 생성됩니다. "GPU 프래그먼트" 처리가 완전하게 로드되어 있고, "CPU Activity" 와 "GPU Vertex-Tiling-Compute" 워크로드들은 각 프레임에서 일정시간 동안 유휴상태가 되는 것을 확인할 수 있습니다. 노트 -- 이를 보기 위해서는 1 ms 나 5 ms 의 줌( zoom ) 레벨에 가깝게 확대할 필요가 있습니다 -- 여기에서는 매우 짧은 기간에 대해서 이야기하고 있는 것입니다.

The vsync signal is the bottleneck

vsync 에 의해 조절( throttle )되는 시스템에서는 CPU 와 GPU 가 매 프레임 유휴상태가 되는 것을 기대할 수 있습니다. 왜냐하면 vsync 신호가 발생하고 윈도우 버퍼 교체( swap )이 발생하기 전까지는 다음 프레임을 렌더링하지 않기 때문입니다. 아래 그래프는 스트림 라인에서 이것이 어떻게 보이는지를 보여 줍니다:

만약 여러분이 애플리케이션 개발자가 아니라 플랫폼 통합자( integrator )라면, 60 FPS 로 실행하는 테스트 케이스들은 여러분의 시스템의 DVFS 주파수 선택의 효율성을 리뷰하는 데 있어 좋은 방법이 될 것입니다. 위의 예제에서는 활동들이 나타나는 위치 사이에 많은 시간 간격이 존재합니다. 이는 선택된 DVFS 주파수가 너무 높고 그 GPU 는 필요 이상으로 빠르게 실행중이라는 것을 의미합니다. 이는 플랫폼의 에너지 효율성을 전체적으로 감소시킵니다.

Content issue #1: Limited by vsync but not hitting 60 FPS

더블 버퍼링 시스템에서는 60 FPS 를 달성하지 못하지만 vsync 에는 여전히 제한되는 칸텐트가 존재할 수 있습니다. 이 칸텐트는 위의 그래프와 매우 유사해 보이는데요, 워크로드 사이의 시간 간격이 한 프레임의 길이의 몇 배가 될 것이며, 프레임율( frame rate )은 정확히 최대 스크린의 리프레시율( refresh rate )로 정확히 나눠질 것입니다( 예를 들어 60 PFS 패널은 30 PFS, 20 FPS, 15 FPS 등으로 실행될 수 있습니다 ).

60 FPS 로 실행중인 더블 버퍼링 시스템에서, GPU 는 vsync 버퍼 교체를 위한 시간 안쪽에서 성공적으로 프레임들을 생성하고 있습니다. 아래 그림에서는 두 개의 프레임버퍼( FB0, FB1 )들의 생명주기( lifetime )을 확인할 수 있습니다. 녹색으로 되어 있는 것은 on-screen 의 기간이며 파란색으로 되어 있는 것은 GPU 에 의해 렌더링되고 있는 기간입니다.

GPU 가 이를 수행할 수 있을 만큼 충분히 빠르게 실행되고 있지 않다면, 하나 이상의 vsync 데드라인( deadline )을 놓치게 될 것입니다. 그래서 현재의 프론트 버퍼( front-buffer ) 가 다른 vsync 기간 동안에 스크린상에 남아 있게 됩니다. 아래 다이어그램에서 오렌지 라인이 그어져 있는 곳에서는, 프론트 버퍼가 여전히 스크린에 렌덜이되고 있으며 백 버퍼( back-buffer )는 디스플레이를 위해 큐에 들어 가 있습니다. GPU 는 렌더링할 수 있는 버퍼를 가지고 있지 않기 때문에 대기상태에 빠집니다. GPU 가 45 FPS 이상으로 칸텐트를 실행할 수 있을만큼 충분히 빠름에도 불구하고, 성능은 30 FPS 로 떨어집니다.

안드로이드 윈도우 시스템은 보통 트리플 버퍼링( tripple buffering )을 사용합니다. 그래서 이 문제를 피합니다. 왜냐하면 GPU 가 렌더링하는 데 사용할 버퍼를 가지고 있기 때문입니다. 하지만 여전히 X11 기반 Mali 배포폰에서는 더블 버퍼링을 사용합니다. 만약 이런 이슈가 발생했다면, 성능 최적화를 수행하는 동안에는 vsync 를 끄는 것을 권장합니다; 발생하는 문제를 혼란스럽게 만드는 부차적인 요소들이 없는 상태에서 어떤 것을 최적화해야 할지 결정하는 것이 훨씬 쉽습니다.

Content issue #2: API Calls Break the Pipeline

여러분이 보게 될 두 번째 이슈는 파이프라인 휴식( break )입니다. 이 시나리오에서는 적어도 하나 이상의 CPU 처리 부분이나 GPU 처리 부분이 항상 바쁘지만 동시에 바쁘지는 않습니다; 일종의 직렬화( serialization ) 지점의 형식이 발생한 것입니다.

아래의 예제에서는, 칸텐트가 프래그먼트 중심( dominant )이며, 그래서 프래그먼트 처리가 항상 활성화되어 있을 것이라 기대하고 있지만, 활동이 진동하고 있음을 볼 수 있습니다. GPU 버텍스 처리와 프래그먼트 처리가 직렬화되고 있습니다.

이것의 가장 일반적인 원인은 API 의 동기화 행위를 강제하는 OpenGL ES API 함수를 사용하는 것이고, 이는 드라이버가 모든 대기중( pending )인 연산들을 플러싱( flushing )하게 강제하고, API 요구사항을 존중하기 위해서 렌더링 파이프라인을 비워( drain )버립니다. 가장 일반적인 범인들이 여기에 있습니다:

• glFinish(): 명시적으로 파이프라인 비우기를 요구합니다.
• glReadPixels(): 묵시적으로 현재 서피스를 위해 파이프라인 비우기를 요구합니다.
• glMapBufferRange(): GL_MAP_UNSYNCHRONIZED_BIT 가 설정되지 않았다면; 명시적으로 매핑되고 있는 데이터 리소스를 사용하고 있는 모든 대기중인 서피스들을 위해 파이프라인 비우기를 요구합니다.

이런 API 호출들은 파이프라인 비우기 때문에 빠르게 만들어 지는 것이 거의 불가능합니다. 그러므로 이런 함수들은 가능한 한 피할 것을 제안합니다. OpenGL ES 3.0 이 glReadPixels 함수가 픽셀 복사를 비동기적으로 수행할 수 있는 Pixel Buffer Object( PBO )를 타깃으로 한다는 것은 언급할 가지가 있습니다. 이것은 더 이상 파이프라인 플러싱을 발생시키지 않습니다. 하지만 여러분의 데이터가 도착할 때까지 잠시동안 기다려야만 하며, 메모리 전송은 여전히 상대적으로 비쌉니다.

Content issue #3: NOT GPU limited at all

오늘의 마지막 이슈는 GPU 가 전혀 병목이 아닌 사황입니다. 하지만 종종 형편없는 그래픽스 성능을 보여줄 때가 있습니다.

CPU 가 GPU 가 소비하는 것보다 더 빠르게 새로운 프레임을 생성할 수 있다면, 우리는 그냥 프레임 파이프라인을 유지하기만 할 수 있습니다. 만약 CPU 가 렌더링하는데 5 ms 를 소비하는 프레임을 20 ms 에 만들었다면, 파이프라인은 각 프레임에서 비어 있는 상태로 실행될 것입니다. 아래의 예제에서 GPU 는 매 프레임 유휴상태입니다. 하지만 CPU 는 항상 실행중이고, 이는 CPU 가 GPU 를 따라가지 못한다는 것을 내포하고 있습니다.

"꽉 잡아! CPU 가 단지 25 % 만 로드되었어". 스트림라인은 시스템의 전체 용량을 100% 로 보여 줍니다. 만약 여러분이 4 개의 CPU 코어를 가지고 있다면, 여러분의 시스템에서 단일 프로세서는 하나의 스레드가 최대이므로, 그것은 20 % 로드로 보여질 것입니다. 만약 "CPU Activity" 그래프의 타이틀 박스의 우상단에 있는 화살표를 클릭한다면, 그것은 확장될 것이고 여러분에게 시스템의 CPU 코어 당 개별적인 로드 그래픽스를 제공할 것입니다.

예상했던 대로, 한 코어가 100 % 로드를 사용하고 있습니다. 그러므로 이 스레드는 시스템에서 병목이 되는데요, 이는 전체 성능을 제한하게 됩니다. 이런 문제가 발생하는 여러 가지 원인이 있을 수 있는데요, 그래픽스 동작의 관점에서는 애플리케이션 비효율성보다는 두 가지 주요 원인이 있습니다:

• glDraw...() 호출이 과도하게 많음.
• 동적 데이터 업로드가 과도하게 많음.

모든 드로 호출( draw call )은 드라이버에 대한 비용을 가집니다. 컨트롤 구조체들을 만들고 그것들을 GPU 에 제출해야 합니다. 프레임 당 드로 호출의 개수는 유사한 렌더 스테이트( render state )를 가진 오브젝트의 드로잉을 배칭함으로써 최소화되어야 합니다. 배치를 크게 할 것인지 컬링을 고려할 것인지에 대한 균형 문제가 있기는 합니다. 타깃에 따라 다르기도 합니다: 모바일에서 대부분의 고사양 3D 칸텐트는 렌더 타깃 당 대략 100 개의 드로 호출을 사용하며, 많은 2D 게임들은 20-30 개의 드로 호출을 사용합니다( 역주 : 2014 년 이야기입니다 ).

동적 데이터 업로드의 관점에서, 클라이언트 메모리에서 그래픽스 서버로 업로드되는 모든 데이터 버퍼는 드라이버가 그 데이터들을 클라이언트 버퍼에서 서버 버퍼로 복제하는 것을 요구한다는 점에 주의하시기 바랍니다. 만약 서브 버퍼 업데이트보다는 새로운 리소스를 사용한다면, 드라이버가 그 버퍼를 위한 메모리를 할당해야만 합니다. 가장 일반적인 나쁜 짓은 클라이언트측 버텍스 애트리뷰트를 사용하는 것입니다. 정적인 Vertex Buffer Objects( VBOs )를 사용해 그래픽스 메모리에 영구적으로 저장할 수 있으며, 그 버퍼를 다른 일련의 렌더링을 위해서 참조로 사용할 수도 있습니다. 이는 업로드 비용을 한 번만 지불하게 해 주며 여러 렌더링 프레임 동안 그 비용을 분할( amortize )합니다.

Mali 그래픽스 스택이 성능을 전혀 제한하지 않는 경우가 존재합니다. 애플리케이션 로직 자체가 16.6 ms 이상 걸리는 경우에는 OpenGL ES 호출이 무한하게 빠르더라도 60 FPS 를 달성할 수 없습니다. DS-5 스트림라인은 매우 능력있는 소프트웨어 프로우파일러를 포함하고 있으며, 그것은 코드 내에서 병목이 어느 부분인지를 정확하게 식별할 수 있도록 도움을 줄 수 있습니다. 또한 다중 스레드를 사용해서 소프트웨어를 병령화하기 원한다면, 시스템의 다중 CPU 코어 사이에서 균형있는 워크로드를 로드할 수 있도록 도움을 줄 수 있습니다. 하지만 이것은 Mali 의 동작과 직접적으로 연관된 것은 아니기 때문에 여기에서는 다루지 않겠습니다.

Next Time ...

다음 시간에는 Mali 드라이버의 렌더 타깃 유지를 위한 접근법에 대해서 리뷰하겠습니다. 그리고 Frame Buffer Objects( FBOs )를 사용해 이 모델을 멋지게 실행하기 위해서 애플리케이션을 구조화하는 방법에 대해서 리뷰하겠습니다.

댓글과 의견을 환영합니다.

Cheers,

Pete.

주의 : 답이 틀릴 수도 있습니다. 그냥 정리하는 용도로 올립니다. 혹시라도 도움이 필요한 분이 있다면 도움이 되었으면 좋겠네요.

경고 : 숙제하려고 베끼는 데 사용하지 마십시오. 본인의 미래를 망칠 뿐입니다. 나중에 저를 원망하지 마세요.

부탁 : 문제 풀이가 잘못되었으면 지적해 주셨으면 좋겠습니다.

( a )

도르레로 연결해 놓았지만, 사실 이 두 물체는 일렬로 연결되어 있는 것과 같습니다.

아래에 있는 물체의 질량을 M 이라 하고 위에 있는 물체의 질량을 m 이라고 했을 때, 이것을 당기는 힘은 다음과 같이 정의됩니다.

식 1.

실제로 주어진 값을 대입해서 힘의 크기를 구하면 다음과 같습니다.

식 2.

( b )

힘의 일부는 질량 M 인 물체를 움직이는데 사용되고, 장력을 통해 질량 m 인 물체를 움직이게 됩니다.

그러므로 장력 T 는 다음과 같습니다.

식 3.

주의 : 답이 틀릴 수도 있습니다. 그냥 정리하는 용도로 올립니다. 혹시라도 도움이 필요한 분이 있다면 도움이 되었으면 좋겠네요.

경고 : 숙제하려고 베끼는 데 사용하지 마십시오. 본인의 미래를 망칠 뿐입니다. 나중에 저를 원망하지 마세요.

부탁 : 문제 풀이가 잘못되었으면 지적해 주셨으면 좋겠습니다.

그림 1.

그림 1 의 변수 및 상수들을 다음과 같이 정의합니다.

• M : 헬리콥터 질량.

• m : 물체 질량.

• F : 헬리콥터의 양력.

• G : 중력.

• g : 중력 가속도. 위쪽을 + 방향이라 할 때 중력 가속도는 - 방향. 9.8 m/s²

• F_n : 알짜힘.

• a_n : 상승 가속도( 알짜힘 가속도 ). 0.8 m/s².

• T_b :  물체를 매단 줄에 작용하는 장력의 세기.

• T_c : 줄이 헬리콥터를 당기는 장력의 세기.

( a )

위의 조건으로부터 알짜힘을 구할 수 있습니다. 중력과 양력을 더한 힘이 알짜힘입니다.

식 1.

질량과 가속도를 구해 봅시다.

식 2.

가속도를 알았으니 양력을 구할 수 있습니다.

식 3.

( b )( c )

물체와 헬리콥터가 함께 움직이고 있기 때문에, 두 물체가 받는 힘의 비는 질량의 비와 같습니다. 그러므로 줄에 작용하는 장력은 헬리콥터가 운동하는 데 필요한 힘만큼을 빼고 작용합니다.

식 4.

질량이 0 인 줄에서 양 끝에 작용하는 장력의 크기는 동일하므로 결과는 다음과 같습니다.

식 5.

주의 : 답이 틀릴 수도 있습니다. 그냥 정리하는 용도로 올립니다. 혹시라도 도움이 필요한 분이 있다면 도움이 되었으면 좋겠네요.

경고 : 숙제하려고 베끼는 데 사용하지 마십시오. 본인의 미래를 망칠 뿐입니다. 나중에 저를 원망하지 마세요.

부탁 : 문제 풀이가 잘못되었으면 지적해 주셨으면 좋겠습니다.

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/the-mali-gpu-an-abstract-machine-part-4---the-bifrost-shader-core

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

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

최근에 Mali Bifrost 아키텍쳐 패밀리인 Mali-G71 에 대해 발표했습니다. 그것의 전체적인 렌더링 모델은 이전의 Mali GPU 들과 유사한데요, - Bifrost 패밀리는 여전히 매우 파이프라인화되어 있는 타일 기반 렌더러입니다 - 원래의 "Abstract Machine" 블로그 시리즈를 따라가기 위해서 요구되는 프로그래머블( programmable ) 셰이더 코어에서 충분한 변화가 있었습니다.

이 블로그에서 필자는 전형적인 Bifrost 셰이더 코어의 블록 레벨 아키텍쳐를 소개하고, 애플리케이션 개발자가 그 하드웨어를 사용했을 때 기대할 수 있는 성능 향상에 대해서 설명할 것입니다. 그런 성능향상은 칸텐트를 최적화하고 DS-5 Streamline 과 같은 툴들을 통해서 노출되는 하드웨어 성능 카운터들을 이해할 때 올 수 있습니다. 이 블로그에서는 여러분이 이 시리즈의 처음 두 파트를 읽었다고 가정합니다. 만약 읽지 않았다면 읽고 오세요.

GPU Architecture

Bifrost GPU 의 탑레벨 아키텍쳐는 이전의 Midgard GPU 에서와 동일합니다.

The Shader Cores

Midgard 와 마찬가지로 Bifrost 도 통합 셰이더 코어 아키텍쳐입니다. 이는 단일 클래스의 셰이더 코어가 설계에 존재하는 모든 종류의 셰이더 프로그램과 컴퓨트 커널들을 실행하는 기능을 가졌다는 것을 의미합니다.

셰이더 코어의 개수는 특정 실리콘 칩마다 다릅니다; 우리 파트너들은 성능 요구와 실리콘 면적 제한에 기반해 셰이더 코어의 개수를 선택합니다. Mali-G71 GPU 는 저사양 디바이스를 위해 하나의 코어부터 고성능 설계를 위해 32 개의 코어까지 다양합니다.

Work Dispatch

GPU 를 위한 그래픽스 작업은 큐의 쌍으로 제출됩니다. 하나는 버텍스/타일링/컴퓨트 워크로드를 위한 것이며, 다른 하나는 프래그먼트 워크로드를 위한 것입니다. 모든 작업은 각 큐에 단일 서브미션( submission )으로서 제출된( submit ) 하나의 렌더타깃을 위한 것입니다.

각 큐의 워크로드는 더 작은 조각으로 쪼개져 GPU 안의 모든 셰이더 코어들에 분배됩니다. 타일링의 경우에는 고정 함수 타일링 유닛에 분배됩니다. 두 큐로부터의 워크로드들은 동시에 셰이더 코어에 의해 처리됩니다; 예를 들어, 서로 다른 렌더 타깃을 위한 버텍스 처리와 프래그먼트 처리가 병렬적으로 실행될 수 있습니다( 파이프라인 방법론에 대한 세부사항을 원한다면 첫 번째 블로그를 확인하세요 ).

Level 2 Cache and Memory Bandwidth

시스템 내의 처리 유닛들은 성능을 증진시키고 반복되는 데이터 페치( fetch )에 의해 발생하는 메모리 대역폭을 줄이기 위해 L2 캐시를 공유합니다. L2 캐시의 크기는 우리 실리콘 파트너들에 의해 그들의 요구에 맞게 구성됩니다. 하지만 일반적으로는 GPU 의 셰이더 코어당 64 KB 입니다.

메인 메모리에 대한 GPU 외부의 버스 포트의 개수는, 그리고 그에 의한 이용가능한 메모리 대역폭은 구현된 셰이더 코어의 개수에 의존합니다. 일반적으로, 우리는 클락 당 코어 당 32 비트 픽셀을 쓸 수 있도록 하는데, 클락 사이클 당 ( 읽기와 쓰기를 위해 ) 256 비트 메모리 대역폭을 가질 수 있도록 8 코어 설계를 하는 것이 합리적입니다. AXI 포트의 개수는 Midgard 보다 증가했으며, 다운스트림( downstream ) 메모리 시스템이 그것을 지원할 수 있다면, 클락 당 더 높은 최대 대역폭에 접근할 수 있도록 하기 위해 12 개가 넘는 코어들과 함께 더 크게 구성되었습니다.

이용가능한 메모리 대역폭은 GPU( 주파수, AXI 포트 폭 ) 와 다운스트림 메모리 시스템( 주파수, AXI 데이터 폭, AXI 지연 )에 모두 의존한다는 점에 주의하십시오. 많은 설계들에서 AXI 클락은 GPU 클락보다 더 낮을 겁니다. 그러므로 이론적인 GPU 대역폭을 실제로 이용할 수는 없습니다.

The Bifrost Shader Core

Mali 셰이더 코어는 프로그래머블 코어를 둘러싼 여러 개의 고정 함수 하드웨어 블록으로써 구조화되어 있습니다. 프로그래머블 코어는 Bifrost GPU 패밀리에서 가장 크게 변화된 영역입니다. 시리즈의 이전 블로그에서 언급한 Midgard "Tripipe" 설계에서 많은 변경이 있었습니다:

Bifrost 프로그래머블 실행( Execution ) 코어는 하나 이상의 실행 엔진들 -- Mali-G71 의 경우에는 세 개 -- 과 여러 개의 공유 데이터 처리 유닛들로 구성되는데, 이것들은 메시징 구조( messaging fabric )으로 연결되어 있습니다.

The Execution Engines

실행 엔진은 실제로 프로그래머블 셰이더 명령들을 실행할 책임이 있습니다. 각 명령은 단일 복합( composite ) 산술( arithmetic ) 처리 파이프라인과 실행 엔진이 처리 중인 스레드를 위해 요구되는 스레드 상태를 모두 포함합니다.

The Execution Engines: Arithemtic Processing

Bifrost 산술 유닛은 기능 유닛 활용도( functional unit utilization )를 향상시키기 위해 쿼드 벡터화 체계( quad-vectorization scheme )를 구현합니다. 스레드들은 4 개의 번들( bundle )로 그룹화되어 있으며, 이를 쿼드라 부르는데, 각 쿼드들은 128 비트 데이터 처리 유닛의 너비를 채웁니다. 단일 스레드의 관점으로에서 볼 때, 이 아키텍쳐는 스칼라 32 비트 연산의 스트림처럼 보입니다. 이는 셰이더 컴파일러를 위한 상대적으로 직관적인 forward task 의 높은 활용도를 성취할 수 있도록 만들어 줍니다. 아래의 예제는 vec3 산술 연산이 순수한 SIMD 유닛에 매핑되는 방식을 보여 줍니다( 파이프라인은 클락 당 한 스레드를 실행합니다 ):

쿼드 기반 유닛과 비교하면 다음과 같습니다( 파이프라인이 클랑 당 네 개의 스레드를 위해 스레드 당 한 레인( lane )을 실행합니다 ):

프로그램에서의 벡터 길이와는 무관하게 유용한 작업으로 하드웨어 유닛을들을 꽉 차게 유지하도록 만드는 기능의 이점들이 이들 다이어그램에서 명확하게 강조되어 있습니다. 데이터가 32 비트 타입보다 더 작아짐으로 인해서 제공되는 성능 향상과 전력 효율성은 모바일 디바이스에서 여전히 매우 중요합니다. 그러므로 Bifrost 는 int8, int16, fp16 데이터 타입들을 위한 네이티브 서포트( native support, 역주 : 애플리케이션 실행 환경에 이미 존재하는 기능 )를 유지합니다. 이 타입들은 데이터 유닛의 128 비트 데이터 너비를 채우기 위해서 패킹( packed )될 수 있습니다. 그러므로 단일 128 비트 수학 유닛은 8x fp16/int16 연산들을 클락 사이클 당 한 번 처리할 수 있으며 16x int8 연산들을 파이클 당 한 번 처리할 수 있습니다.

The Execution Engines: Thread State

복잡한 프로그램의 성능과 성능 확장성( scalability )을 향상시키기 위해서, Bifrost 는 셰이더 프로그램들이 사용하기 위한 다소 큰 범용 목적( general-purpose ) 레지스터( register ) 파일을 구현합니다. Mali-G71 은 64x32 비트 레지스터들을 제공하는데, GPU 가 스레드를 최대로 점유하는 것을 허용하며, [ ARM Mali Compute Architecture Fundamentals ] 에서 설명한 레지스터 파일 용례( usage ) 와 스레드 카운트 사이에 존재하던 이전의 트레이드 오프( trade off )를 제거했습니다.

OpenGL ES 유니폼( uniform ) 상수와 Vulkan 의 푸시( push ) 상수를 저장하기 위해서 사용되는 빠른 상수 저장소( constant storage )의 크기가 증가되었습니다. 이는 프로그램이 상수 저장소를 대량으로 사용할 때 발생하는 캐시 접근 부하를 줄여 줍니다.

Data Processing Unit: Load/Store Unit

로드/스토어 유닛은 ( 텍스쳐를 제외한 ) 모든 범용 목적 메모리 접근을 다룹니다. 버텍스 애트리뷰트( attribute ) 페치, 베어링( varying, 역주 : 버텍스 버퍼 출력이자 프래그먼트 버퍼 입력인 변수 ) 페치, 버퍼 접근, 스레드 스택 접근 등을 포함합니다. 이는 코어 당 16 KB L1 데이터 캐시를 포함하는데, L1 캐시는 공유 L2 캐시에 의해 뒷받침됩니다.

로드/스토어 캐시는 클락 사이클 당 단일 64 바이트 캐시 라인에 접근할 수 있으며, 스레드 쿼드 사이에서의 접근은 요구되는 고유( unique ) 캐시 접근 요청들을 줄이기 위해 최적화됩니다. 예를 들어, 네 개의 스레드가 같은 캐시라인의 데이터에 접근하고 있다고 할 때, 그 데이터는 단일 사이클에 반환될 수 있습니다.

이 로드/스토어 병합 기능은 일반적인 OpenCL 컴퓨트 커널들에서 찾아 볼 수 있는 데이터 접근 패턴들을 매우 가속화해 줄 수 있습니다. 이는 일반적으로 제한된 메모리 접근이며, 알고리즘 설계에서 그것의 활용을 최대화하는 것이 핵심적인 최적화 목표입니다. 또한 Mali 산술 유닛들이 스칼라임에도 불구하고, 데이터 접근 패턴은 잘 작성된 벡터 로드를 통해 여전히 이점을 얻을 수 있으며, 그래서 여전히 가능할 때마다 벡터화된 셰이더와 커널 코드를 작성하는 것이 좋습니다.

Data Processing Unit: Varying Unit

베어링 유닛은 전용 고정 함수 베어링 보간기( dedicated fixed-function varying interpolator )입니다. 그것은 프로그래머블 산술 유닛과 같은 최적화 전략을 구현합니다; 그것은 스레드 쿼드 사이의 보간값을 벡터화해서 기능 유닛 활용도를 보장하며, 더 빠른 fp16 최적화를 지원합니다.

이 유닛은 클락 당 쿼드 당 128 비트를 보간할 수 있습니다; 즉, mediump ( fp16 ) vec4 를 보간하는 데는 네 스레드 쿼드 당 2 사이클이 걸립니다. 베어링 변수 벡터 길이를 최소화하기 위한 최적화와 fp32 보다는 fp16 을 공격적으로 사용하면 결과적으로 애플리케이션 성능을 향상시킬 수 있습니다.

Data Processing Unit: ZS/Blend

ZS 와 블렌드 유닛은 모든 타일 메모리 접근을 다룰 책임이 있으며, 둘 다 뎁스/스텐실 테스트나 컬러 블렌딩과 같은 내장 OpenGL ES 연산들을 위한 것입니다. 또한 그 타일 버퍼에 프로그램이 접근하는데 필요한 기능들은 다음과 같습니다:

• https://www.khronos.org/registry/gles/extensions/EXT/EXT_shader_pixel_local_storage.txt
• https://www.khronos.org/registry/gles/extensions/ARM/ARM_shader_framebuffer_fetch.txt
• 그리고 Vulkan 의 병합된 서브패스 기능.

LS 파이프가 타일 버퍼 접근, 베어링 보간, 로드/스토어 캐시 접근을 제어하는 모놀리식( monolithic ) 파이프라인이었던 Midgard 의 설계와는 다르게, Bifrost 는 세 개의 더 작고 더 효율적인 병렬 데이터 유닛을 구현했습니다. 이는 그 타일 버퍼 접근이 베어링 보간을 위해 비동기적으로 실행될 수 있다는 것을 의미합니다. 예를 들면, 그래픽스 알고리즘이 프로그램에서 타일 버퍼 접근을 사용하고 있다면 처리중인 리소스들에 대한 경쟁이 줄어드는 것을 확인할 수 있을 것입니다. Midgard 에서는 LS 파이프라인이 매우 무거운 경향이 있었습니다.

Data Processing Unit: Texture Unit

텍스쳐 유닛은 모든 텍스쳐 접근을 구현합니다. 그것은 코어 당 16 KB L1 데이터 캐시를 포함하며, 공유 L2 캐시에 의해 뒷받침됩니다. Mali-G71 에서는 이 블록의 아키텍쳐 성능이 이전 Midgard GPU 에서와 동일합니다; 클락 당 하나의 바이리니어( bilinear ) 필터링된 텍셀( GL_LINEAR_MIPMAP_NEAREST )을 반환합니다. 예를 들어 바이리니어 텍스쳐 룩업( lookup )을 네 개의 스레드 쿼드의 각 스레드에서 보간하는 데는 4 사이클이 걸립니다.

어떤 텍스쳐 접근 모드들은 데이터를 생성하기 위해서 다중 사이클을 요구합니다:

• 트라이리니어( trilinear ) 필터링( GL_LINEAR_MIPMAP_LINEAR )은 텍셀당 두 개의 바이리니어 샘플들을 요구하며, 텍셀 당 2 사이클이 필요합니다.
• 볼륨( volumetric ) 3D 텍스쳐는 2D 텍스쳐보다 두 배의 사이클을 요구합니다; 즉, 트라이리니어 필터링된 3D 텍스쳐는 4 사이클을 요구합니다. 바이리니어 필터링된 3D 텍스쳐는 2 사이클을 요구합니다.
• 와이드( wide ) 유형의 텍스쳐 포맷( 컬러 채널 당 16 비트 이상 )은 픽셀 당 여러 개의 사이클을 요구할 수 있습니다.

Bifrost 에서 새롭게 최적화된 기능인데, 와이드 포맷 규칙의 예외는 뎁스 텍스쳐 샘플링입니다. 일반적으로 셰도우 매핑 기술이나 디퍼드 라이팅 알고리즘에 의해서 사용되는 DEPTH_COMPONENT16 이나 DEPTH_COMPONENT24 텍스쳐들로부터 샘플링하는 것은 최적화되었으며, 이제 단일 사이클 룩업입니다. 이는 Midgard 패밀리 GPU 에서보다 상대적으로 두 배의 성능을 달성합니다.

The Bifrost Geometry Flow

셰이더 코어 변경에 더해, Bifrost 는 새로운 인덱스 주도 버텍스 셰이딩( Index-Driven Vertex Shading, IDVS ) 지오메트리 처리 파이프라인을 소개합니다. 이전의 Mali GPU 들은 타일링 전에 버텍스 셰이딩을 모두 처리했고, 보통 이는 삼각형을 컬링( cull, 프러스텀 바깥인 경우나 면 방향( facing ) 테스트 실패했을 때 자름 )하기 위해서만 사용되는 베어링과 비교했을 때 계산과 대역폭을 낭비하는 결과를 낳았습니다.

IDVS 파이프라인은 버텍스 데이터를 절반으로 나눕니다; 하나는 위치를 처리하는데 사용되고, 다른 하나는 남은 베어링을 처리하는 데 사용됩니다:

이 플로우는 두 개의 중요한 최적화를 제공합니다:

• 인덱스 버퍼가 먼저 읽히고, 버텍스 셰이딩은 인덱스 버퍼에 의해서 참조되고 있는 버텍스가 하나 이상 존재하는 버텍스들의 배치( batch )만이 제출( submit )됩니다. 이는 인덱스 버퍼에 있는 공간적 공백( gap )을 버텍스 셰이딩이 스킵할 수 있도록 해 줍니다.
• 베어링 셰이딩은 clip-and-cull 단계에서 살아 남은 프리미티브들에 대해서만 제출됩니다; 이는 컬링된 삼각형에 대해서만 기여하고 있는 버텍스에 대한 중복 계산과 대역폭을 상당히 감소시켜 줍니다.

Bifrost 지오메트리 플로우를 최대한 활용하려면 패킹된 버텍스 버퍼들을 부분적으로 디인터리빙( deinterleave )하는 것이 좋습니다; 포지션( position )에 기여하는 애트리뷰트들을 하나의 패킹된 버퍼에 배치하고, 포지션 베어링에 기여하지 않는 애트리뷰트들은 다른 패킹된 버퍼에 배치합니다. 이는 화면에 기여하지 않거나 컬링된 버텍스들에 대해서는 비(non)-포지션 베어링들이 캐시에 올라가지 않는다는 것을 의미합니다. 필자의 동료인 stacysmith 는 이러한 유형의 지오메트리 처리 파이프라인을 이용하기 위해 버퍼 패킹을 최적화하는 것에 대한 블로그를 작성했습니다.

Performance Counters

이전의 Midgard GPU 와 마찬가지로, Bifrost 하드웨어도 수많은 성능 카운터들을 제공해 애플리케이션 개발자들이 애플리케이션을 프로우파일링하고 최적화할 수 있도록 하고 있습니다. Bifrost 아키텍쳐에 대해 애플리케이션 개발자들이 이용할 수 있는 성능 카운터에 대한 더 많은 내용을 확인하세요.

댓글과 의견을 항상 환영합니다.

Cheers,

Pete.

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/the-mali-gpu-an-abstract-machine-part-3---the-midgard-shader-core

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

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

( 역주 : 2016 년 4 분기에 나온 Mali-G51 부터는 Bifrost 셰이더 코어입니다. Mali-T 로 시작하는 것이 Midgard 이고, Mali-$(Number)-MP 가 Utgard 입니다. 이 시리즈의 Part 4 에서는 Bifrost 에 대해 다룹니다 )

시리즈의 처음 두 블로그들에서, 필자는 Mali GPU 들에 의해 사용되는 프레임 수준 파이프라이닝과 타일 기반 렌더링 아키텍쳐에 대해서 소개했습니다. 이는 애플리케이션의 성능을 최적화할 때 그래픽스 스택의 동작을 설명하기 위해서 사용될 수 있는 멘탈 모델을 개발자들에게 제공하려는 목적으로 작성되었습니다.

이 블로그에서, 필자는 이 추상 머신의 생성을 완료하고, 최종 요소를 형성할 것입니다: 틀에박힌( stereotypical ) Mali "Midgard" GPU programmable core. 이 블로그는 여러분이 처음 두 파트들을 읽고 왔다고 가정합니다. 그러므로 읽지 않았다면 먼저 읽고 오시기 바랍니다.

GPU Architecture

Mali GPU 의 "Midgard" 패밀리들( Mali-T600, Mali-T799, Mali-T800 )은 통합( unified ) 셰이더 코어 아키텍쳐를 사용합니다. 이는 설계상으로 단일 유형의 셰이더 코어만이 존재한다는 것을 의미합니다. 이 단일 코어는 모든 유형의 프로그래머블( programmable ) 셰이더 코어를 실행하는데, 버텍스 셰이더, 프래그먼트 셰이더, 컴퓨트 커널들을 포함합니다.

셰이더 코어의 정확한 개수는 특정 실리콘( silicon ) 칩( chip )마다 다릅니다; 실리콘 파트너들은 성능 요구사항과 실리콘 면적( area ) 제한에 기반해서 얼마나 많은 셰이더 코어를 구현할지를 선택할 수 있습니다. Mali-T760 GPU 는 저사양 장치들을 위해 단일 코어부터 고성능 설계를 위해 16 코어까지 달라질 수 있습니다. 하지만 거의 대부분의 구현에서는 4 코어나 8 코어 사이를 유지합니다.

GPU 를 위한 그래픽스 작업은 큐 쌍에 들어 가는데, 버텍스/타일링 워크로드( workload )를 위한 것이 하나이고 프레그먼트 워크로드를 위한 것이 다른 하나입니다. 그것들은 하나의 렌더 타깃을 위해서 동작하며, 각 큐에 단일 서브미션( submission )으로서 서밋( submit )됩니다. 두 큐로부터의 워크로드는 GPU 에 의해 동시에 처리될 수 있습니다. 그래서 서로 다른 렌더 타깃들을 위한 버텍스 처리와 프래그먼트 처리는 병렬적으로 실행될 수 있습니다( 파이프라인 방법론에 대한 세부사항을 원한다면 첫 번째 블로그를 확인하세요 ). 단일 렌더 타깃에 대한 워크로드는 작은 조각으로 나뉘어져서 GPU 에 있는 모든 셰이더 코어들 사이에서 분배됩니다. 타일링 워크로드의 경우에는 고정 함수( fixed-function ) 타일링 유닛에 분배됩니다( 타일링에 대한 개요를 원한다면 시리즈의 두 번째 블로그를 확인하세요 ).

시스템 내의 셰이더 코어들은 L2 캐시를 공유해서 성능을 증진시키며 반복적인 데이터 페치( fetch )에 의해 발생하는 메모리 대역폭을 감소시킵니다. 코어 개수와 마찬가지로, L2 캐시의 크기는 실리콘 파트너들에 의해서 구성됩니다. 하지만 일반적으로는 GPU 의 셰이더 코어 당 32 에서 64 KB 의 범위에 있습니다. 이 캐시가 외부 메모리에 대해 가지고 있는 메모리 포트( port ) 의 개수와 버스 폭( bus width )은 구성이 가능하며, 이 역시 실리콘 파트너가 성능, 전력, 면적 요구사항을 튜닝합니다. 보통 우리는 한 클락( clock ) 당 한 코어 당 32 비트 픽셀을 쓸 수 있도록 요구하며, 8 코어 설계로 클락 사이클( cycle ) 당 ( 읽기 및 쓰기 모두를 위해 ) 총 256 비트의 메모리 대역폭을 기대하는 것이 합리적일 겁니다.

The Midgard Shader Core

Mali 셰이더 코어는 여러 개의 고정 함수 하드웨어 블록으로서 구성되는데, 이는 프로그래머들 "트라이파이프( tripipe, 삼중 파이프 )" 실행( execution ) 코어를 감쌉니다. 고정 함수 유닛들은 셰이더 연산을 위한 설정을 수행하거나 - 삼각형 래스터화( rasterizing )이나 뎁스 테스트 - 셰이더 후처리( post-shader activity )를 제어합니다 - 블렌딩( blending )이나 전체 타일의 가치있는 데이터를 렌더링의 끝에서 메모리에 쓰기. 삼중 파이프 자체는 프로그래머블 파트이며, 셰이더 프로그램의 실행에 대한 책임이 있습니다.

The Tripipe

파이프라인 설계에는 세 가지 분류의 실행 파이프라인이 존재합니다: 하나는 산술( arithmetic ) 연산을 다루며, 하나는 메모리 로드/스토어( load/store ) 및 베어링 변수( varying, 역주 : 버텍스 셰이더 출력이자 프래그먼트 셰이더 입력으로 사용되는 변수 ) 접근을, 하나는 텍스쳐 접근을 다룹니다. 셰이더 코어 당 하나의 로드/스토어 와 하나의 텍스쳐 파이프가 존재합니다. 하지만 산술 파이프라인의 개수는 다양하며, GPU 마다 다릅니다; 오늘날의 대부분의 실리콘 제폼은 두 개의 산술 파이프라인을 가지고 있을 겁니다. 하지만 Mali-T880 은 세 개를 가지고 있습니다.

Massively Multi-threaded Machine

단일 코어에서 한 번에 하나의 스레드만을 실행하도록 하는 전통적인 CPU 아키텍쳐와는 다르게, 트라이파이프는 엄청난 다중 스레드 기반 처리 엔진입니다. 수 백개의 하드웨어 스레드가 트라이파이프 내부에서 동시에 실행될 수 있으며, 셰이딩되는 각 버텍스나 프래그먼트 당 하나의 스레드가 생성될 수 있습니다. 이 엄청난 개수의 스레드들은 메모리 지연( latency )를 감추기 위해 존재합니다; 어떤 스레드가 메모리 작업을 위해 대기하고 있다해도 중요하지 않습니다. 왜냐하면 적어도 한 스레드에서는 실행이 가능할 것이고, 효율적인 실행을 유지할 수 있습니다.

Arithmetic Pipeline: Vector Core

산술 파이프라인( A-pipe ) 는 SIMD( single instruction multiple data ) 벡터 프로세싱 유닛입니다. 이는 128 비트 쿼드-워드( quad-word ) 레지스터( register )들 상에서 수행되는 산술 유닛을 가지고 있습니다. 이 레지스터들은 2 x FP64, 4 x FP32, 8 x FP16, 2 x int64, 4 x int32, 8 x int16, 16 x int8 중의 하나로서 유연하게 접근될 수 있습니다. 그러므로 단일 산술 벡터 작업을 8 개의 "mediump" 값으로 단일 연산에서 수행할 수 있습니다. 그리고 OpenCL 커널들은 클락 사이클 당 SIMD 당 16 픽셀을 처리하기 위해서 8 비트 휘도( luminance ) 데이터 상에서 동작합니다.

아키텍쳐 파이프라인의 내부 아키텍쳐를 밝힐 수는 없지만, 각 GPU 를 위한 공용 성능 데이터를 사용해서 이용 가능한 수학 유닛의 개수에 대한 아이디어를 제공할 수는 있습니다. 예를 들어 16 코어를 가진 Mali-T760 은 600 MHz 로 326 FP32 GFLOPS 를 달성합니다. 이는 이 셰이더 코어의 경우에 클락 사이클 당 34 FP32 FLOPS 입니다; 그것이 두 개의 파이프라인을 가지므로 클락 사이클 당 파이프라인당 17 FP32 FLOPS 가 됩니다. 연산( operation )의 관점에서 이용가능한 성능은 FP16/int16/int8 데이터 타입에서는 증가하고 FP64/int64 데이터 타입에서는 감소할 것입니다.

Texture Pipeline

텍스쳐 파이프라인( T-pipe )은 텍스쳐를 사용하는 모든 메모리 접근에 대한 책임이 있습니다. 텍스쳐 파이프라인은 클락 당 바이리니어 필터링된( binlinear filterd ) 하나의 텍셀( texel )를 반환할 수 있습니다; 트라이리니어 필터링( trilinear filtering )은 메모리로에 있는 두 개의 서로 다른 밉맵( mipmap )로부터 샘플( sample )을 로드할 것을 요구하므로, 완료되려면 두 번째 클락 사이클이 요구됩니다.

Load/Store Pipeline

로드/스토어 파이프라인( LS-pipe )은 텍스쳐링과 관련이 없는 모든 메모리 접근에 대한 책임이 있습니다.

그래픽스 워크로드의 경우, 이는 버텍스 애트리뷰트 인풋( vertex attribute input ) 당 읽기, 버텍스 셰이딩 동안 계산된 버텍스 아웃풋( output ) 당 쓰기, 그리고 프래그먼트 셰이딩 동안 버텍스 셰이더에 의해 작성되고 베어링 변수로 보간될 수 있는 버텍스 아웃풋 값 당 읽기를 의미합니다.

일반적으로 모든 명령( instruction )들은 단일 메모리 접근 연산이며, 그것들은 벡터 연산임에도 불구하고 산술 연산처럼 단일 사이클에서 전체 "highp" vec4  베어링을 로드할 수 있습니다.

Early ZS Testing and Late ZS Testing

OpenGL ES 명세의 "fragment operations" 은 -- 그것은 뎁스 테스트와 스텐실 테스트를 포함합니다 -- 파이프라인의 끝에서 프래그먼트 세이딩이 완료된 후에 발생합니다. 이는 명세를 매우 단순하게 만들지만, 무엇인가를 셰이딩하는데 많은 시간을 소비해야 하고 그것이 ZS 테스트에 의해서 무효화( killed )된 것으로 밝혀진다면 프레임의 끝으로 던져져 버리기만 함을 내포합니다. 그것을 그냥 버려 버리는( discard ) 컬러링 프래그먼트들에서는 성능향상과 에너지 절약에 도움이 되므로, ZS 테스트를 미리 할 수가 있습니다( 예를 들어 프래그먼트 셰이딩 전에 ). 늦은 ZS 테스트는 ( 예를 들어 프래그먼트 셰이딩 이후에 ) 피할 수 없습니다( 즉, "discard" 를 호출할 수도 있는 프래그먼트에 대한 의존성같은 것들은 트라이파이프에 존재할 때까지는 비결정된 뎁스 상태를 가집니다 ).

전통적인 이른 Z 구조와 더불어, 우리는 프래그먼트를 중지시킬 수 있는 일부 오우버드로( overdraw ) 제거( removal ) 기능을 가지고 있습니다. 그것은 이미 래스터화되었지만 출력 화면에는 유용한 방식으로 기여하지 않는다면, 실제 렌더링을 막을 수 있습니다. 내 동료인 seanellis 는 이 기술에 대해 살펴 보는 훌륭한 블로그를 작성했습니다 - Killing Pixels - A New Optimization for Shading on Arm Mali GPUs - 그러므로 여기에서 깊게 살펴 보지는 않겠습니다.

Memory System

이 섹션은 나중에 추가되었습니다. 그래서 만약 이 블로그를 이전에 이미 읽었다면 이 섹션을 기억하지 못할 것입니다. 여러분이 이상하게 아니니까 걱정하지 마세요. 우리는 OpenCL 커널과 OpenGL ES 컴퓨트 셰이더를 작성하는 개발자들에게 GPU 캐시 구조에 대해서 더 많은 정보를 달라는 요청을 받아왔습니다. 캐시 지역성( locality )을 최적화하기 위해서는 데이터 구조체와 버퍼들을 깔고 가는게 실제로 이득이 되기 때문입니다. 사실들은 다음과 같습니다:

• 셰이더 코어 당 두 개의 16 KB L1 데이터 캐시; 하나는 텍스쳐 접근을 위해 하나는 범용 메모리 접근을 위해.
• 모든 셰이더 코어들에 의해 공유되는 단일 논리 L2 캐시. 이 캐시의 크기는 다양하며, 실리콘 통합자( integrator )에 의해서 구성됩니다. 하지만 일반적으로는 인스턴스화된( instantiated ) 셰이더 코어 당 32 KB 와 64 KB 의 사이입니다.
• 두 개의 캐시 레벨은 모두 64 byte 캐시 라인을 사용합니다.

GPU Limits

• 단순한 모델에 기반해, GPU 성능의 근본적인 속성들의 일부를 알아내는 것이 가능합니다:
• GPU 는 클락 당 셰이더 코어 당 하나의 버텍스를 제출합니다.
• GPU 는 클락 당 셰이더 코어 당 하나의 프래그먼트를 제출합니다.
• GPU 는 클락 당 셰이더 코어당 하나의 픽셀을 리타이어( retire, 역주 : 명령이 분기 예측 실패같은 것들 없이 실제로 완료되는 것을 의미 )합니다.
• 클락 당 파이프 당 하나의 명령을 제출할 수 있습니다. 그러므로 일반적인 셰이더 코어에 대해서는 만약 가능하다면 병렬적으로 4 개의 명령들을 제출할 수 있습니다:
• A-pipe 당 17 FP32 연산.
• LS-pipe 당 한 벡터 로드, 한 벡터 스토어, or one vector varying.
• T-pipe 당 한 바이리니어 필터 텍셀.
• 클라 당 코어 당 GPU 는 일반적으로 32 비트 DDR 접근( 읽기와 쓰기 )을 가지게 됩니다[ 구성 가능 ].

• Fill rate:
• 클락 당 8 픽셀 = 4.8 GPix/s.
• 완전한 1080p 에 대해 초 당 2314 프레임.
• Texture rate:
• 클락 당 8 개의 바이리니어 텍셀 = 4.8 GPix/s.
• 1080p @ 60 FPS 를 위해, 픽셀 당 38 바이리니어 텍스쳐 룩업( lookup ).
• Arithmetic reate:
• 코어 당 파이프 당 17 FLOPS = 163 FP32 GFLOPS.
• 1080p @ 60 FPS 를 위해, 픽셀 당 1311 FPLOPS.
• Bandwidth:
• 클락 당 256 비트 메모리 접근 = 19.2 GB/s 일기 및 쓰기 대역폭.
• 1080p @ 60 FPS 를 위해, 픽셀당 154 바이트.

OpenCL and Compute

주의깊은 독자들은 필자가 버텍스와 프래그먼트에 대해서 많이 이야기하고 있음을 눈치챘을 겁니다 - the staple of graphics work - 하지만 OpenCL 과 RenderScript 컴퓨트 스레드가 코어로 들어 오고 있는 과정에 대해서는 거의 언급하지 않았습니다. 이 두 가지 유형의 작업은 버텍스 스레드와 거의 유사하게 동작합니다 - 버텍스 셰이더를 실행하는 것을 1 차원 컴퓨트 문제로서의 버텍스 배열로 볼 수 있습니다. 그러므로 버텍스 스레드 생성자( creator )는 컴퓨트 스레드를 생성( spawn )하기도 합니다. 더 정확하게 이야기하자면, 컴퓨트 스레드 생성자가 버텍스도 생성하고 있는 것입니다.

Performance Counters

문서는 Midgard 패밀리 성능 카운터에 대해 설명하고 있습니다. 이 블로그에서 설명한 블록 아케텍쳐에 매핑되어 있으며, Midgard 패밀리에 대한 필자의 블로그에서 찾아 보실 수 있습니다.

Next Time ...

이 블로그는 시리즈의 첫 번째 챕터를 마무리하며, 추상 머진을 개발했습니다. 추상 머신은 기본 동작을 정의하는데, 애플리케이션 개발자가 Midgard 패밀리인 Mali GPU 를 이해할 수 있도록 합니다. 이 시리즈의 후반에서, 필자는 이 새로운 지식이 작동하도록 하기 시작할 것입니다. 그리고 일반적인 애플리케이션 개발 함정과 유용한 최적화 기술들에 대해서 조사할 것입니다. 이런 것들은 Arm DS-5 Streamline 프로우파일링 툴의 Mali integration 을 사용해 식별되고 디버깅될 수 있습니다.

댓글과 의견을 항상 환영합니다.

Pete

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/the-mali-gpu-an-abstract-machine-part-2---tile-based-rendering

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

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

이전 블로그에서 추상 머신을 정의하기 시작했으며, 그것은 Mali GPU 와 드라이버의 애플리케이션 단에서 볼 수 있는 동작들에 대해서 기술하는 데 사용될 수 있습니다. 이 머신의 목적은 개발자들에게 OpenGL ES API 의 기저에 깔린 흥미로운 동작들에 대한 멘탈 모델을 제공하는 것입니다. 이 모델은 애플리케이션의 성능에 영향을 주는 이슈들을 설명하는 데도 사용될 수 있습니다. 필자는 이 시리즈의 뒤쪽 블로그에서 이 모델을 사용해 개발자가 그래픽스 애플리케이션을 개발하는 동안 만날 수 있는 일반적인 성능 함정( pot-hole )들에 대해서 살펴 볼 것입니다.

이 블로그는 계속해서 추상 머신의 개발에 대해서 이야기하며, Mali GPU 패밀리의 타일 기반 렌더링에 대해 살펴 볼 것입니다. 여러분이 파이프라인에 관한 첫 번째 블로그를 읽어다고 가정합니다. 만약 읽지 않았다면 먼저 읽고 오시기 바랍니다.

The "Traditional" Approach

메인전원에 의해 전력을 공급받는 전통적인 데스크탑 GPU 아키텍쳐 -- 일반적으로 즉시 모드 아키텍쳐( immediate mode architecture )라 불립니다 -- 에서는 프래그먼트 셰이더( fragment shader )들이 각 드로 콜( draw call )에서 순차적으로 각 프리미티브( primitive ) 상에서 수행됩니다. 각 프리미티브들은 다음 프리미티브를 시작하기 전에 완료되기 위해 렌더링되는데, 대충 다음과 같은 알고리즘을 사용합니다:

foreach( primitive ) foreach( fragment ) render fragment

스트림 내의 어떤 삼각형은 화면 내의 일부 영역을 덮고 있기 때문에, 이들 렌더러에 의해서 유지되는 데이터 워킹 셋( working set of data )은 큽니다; 일반적으로는 적어도 전체 화면 크기의 컬러 버퍼( color buffer ), 뎁스( depth ) 버퍼, 그리고 스텐실( stencil ) 버퍼. 최신 장치들을 위한 일반적인 워킹 셋은 픽셀당 32 비트 컬러 버퍼, 그리고 32 비트로 패킹된( packed ) 뎁스/스텐실 버퍼입니다. 그러므로 1080p 디스플레이는 16 MB 의 워킹 셋을 가지며, 4k2k TV 는 64 MB 의 워킹 셋을 가집니다. 그것들의 크기 때문에, 이 워킹 버퍼들은 반드시 칩 바깥에 있는 DRAM 에 저장되어야 합니다.

모든 블렌딩( blending ), 뎁스 테스트, 스텐실 테스트 연산은 현재 프래그먼트의 픽셀 좌표를 위한 현재 데이터 값을 요구합니다. 이 값들은 이 워킹 셋으로부터 획득( fetch ) 니다. 셰이딩된 모든 프래그먼트들은 일반적으로 이 워킹 셋을 손대게 되며, 그래서 고해상도에서는 프래그먼트에 대해 읽기-수정-쓰기 연산을 하게 되면, 캐싱이 다소 완화해 준다고 하더라도, 이 메모리 상에서 예외적으로 높은 대역폭을 소비할 수 있습니다. 또한 높은 대역폭 접근에 대한 요구는 매우 많은 핀과 특별한 고주파수 메모리를 가진 넓은 메모리 인터페이스를 요구합니다. 둘 다 외부 메모리 접근을 필요로 하며, 이는 특히 에너지를 많이 사용하는 작업입니다.

The Mali Approach

Mali GPU 패밀리는 매우 다른 접근 방법을 사용하는데, 일반적으로 타일 기반 렌더링이라 불리며, 렌더링 동안 필요한 외부 메모리 접근과 전력( power ) 소비량을 최소화하기 위해서 설계되었습니다. 이 시리즈의 첫 번째 블로그에서 설명했듯이, Mali 는 각 렌더 타깃에 대해 구별되는 두 개의 패스 렌더링 알고리즘을 사용합니다. 그것은 먼저 지오메트리 처리를 모두 실행한 다음에 프래그먼트 처리를 실행합니다. 지오메트리 처리 스테이지 동안, Mali GPU 는 화면을 작은 16x16 픽셀 타일들로 쪼개고, 렌더링 중인 프리미티브들이 어떤 타일에 제출되고 있는지에 대한 리스트를 만듭니다. GPU 프래그먼트 셰이딩 단계가 실행될 때, 각 셰이더 코어는 한 번에 하나의 16x16 픽셀 타일을 처리합니다. 다음 타일을 렌더링하기 전에 렌더링이 끝납니다. 타일 기반 아키텍쳐에서 알고리즘은 다음과 같은 식입니다:

foreach( tile ) foreach( primitive in tile ) foreach( fragment in primitive in tile ) render fragment

16x16 픽셀 타일은 전체 화면 영역에 비해 작은 조각이므로, GPU 셰이더 코어와 강하게 결합되어 있는 빠른 RAM 에 전체 타일을 위한 전체 워킹 셋( 컬러, 뎁스, 스텐실 )을 유지하는 것이 가능합니다.

이 타일 기반 접근 방법은 여러 개의 이점을 가지고 있습니다. 그것들은 거의 개발자들에게 있어 투명하지만( transparent ) 알아 두면 가치가 있습니다. 특히 여러분의 칸텐트가 가지는 대역폭 비용을 이해하려고 할 때 그렇습니다:

• 워킹 셋에 대한 모든 접근들은 지역적( local ) 접근입니다. 그것은 빠르면서 전력을 덜 소비합니다. 외부 DRAM 에 대한 읽기나 쓰기에 필요한 전력은 시스템 설계에 따라 다양해지지만, 1 Gbyte/s 의 대역폭을 위해 120 mW 정도는 쉽게 소비됩니다. 내부 메모리 접근들은 대략 이 보다는 자리수가 다르게 낮습니다. 그러므로 이것이 매우 중요하다는 것을 이해할 수 있을 겁니다.
• 블렌딩은 빠르고 전력 효율이 높습니다. 왜냐하면 블렌드 연산들을 위해 요구되는 대상 컬러 데이터를 손쉽게 이용할 수 있기 때문입니다.
• 타일은 4x, 8x, 16x 멀티샘플 안티에일리어싱( multisample antialiasing ) 을 허용하기 위해 타일 메모리에 충분한 샘플들을 저장할 수 있을만큼 충분합니다. 이는 고품질이며 부하가 적은 안티 에일리어싱을 제공합니다. 하지만 관련 작업 셋의 크기 때문에 ( 일반적인 단일 샘플링 렌더 타깃의 4, 8, 16 배; 4k2k 디스플레이 패널의 16x MSAA 에는 1 GB 의 워킹 셋 데이터가 필요합니다 ), 개발자에게 MSAA 를 기능으로 제공하는 즉시 모드 렌더러는 드뭅니다. 왜냐하면 일반적으로 외부 메모리 공간과 대역폭이 너무 비싸기 때문입니다.
• Mali 는 타일 작업의 끝에서 메모리에다가 단일 타일을 위한 컬러 버퍼만을 써야만 합니다. 이 시점에 우리는 그것의 최종 상태를 알게 됩니다. CRC 체크를 통해 메인 메모리에 있는 현재 데이터와 블록의 컬러를 비교할 수 있습니다 -- Transaction Elimination 이라 불리는 처리입니다 -- 이때 타일 칸텐츠가 동일하다면 쓰기를 취소하며 SoC 의 전력을 절약하게 됩니다. 필자의 동료인 tomolson 은 이 기술에 대한 훌륭한 블로그를 작성했습니다. 그는 Transaction Elimination( Angry Birds 라 불리는 어떤 게임에서 이것에 대해 들어 봤을 겁니다 )에 실제 예제를 완성했습니다. 필자는 Tom 의 블로그에서 이 기술을 더욱 자세하게 설명할 것입니다만, 여기에서는 그 기술에 대해서 살짝 훔쳐 보기만 하겠습니다( "extra pink" 타일들만이 GPU 에 의해 쓰여진 것입니다 - 다른 것들은 성공적으로 취소된 것입니다 ).
  
• 빠르고, 손실없는 압축 기법을 사용해서 Transaction Elimination 을 실행하는 타일을 위해 컬러 데이터를 압축할 수 있습니다 -- ARM Frame Buffer Compression( AFBC ) -- 이는 대역폭과 전력을 더 줄여 줍니다. 이 압축은 오프스크린 FBO 렌더 타깃들에 대해서 수행될 수 있으며, 그것은 GPU 에 의해 일련의 렌더링 패스들에 텍스쳐로서 읽어들여질 수 있습니다. 또한 거기에 공급되는 메인 윈도우 서피스는 시스템의 Mali-DP500 과 같은 AFBC 호환 디스플레이 컨트롤러입니다.
  
• 대부분의 칸텐트는 뎁스 버퍼와 스텐실 버퍼를 가지고 있습니다. 하지만 그것들의 칸텐츠는 일단 프레임 렌더링이 끝낙 나면 유지될 필요가 없습니다. 만약 개발자가 Mali 드라이버에 뎁스 버퍼와 스텐실 버퍼를 유지할 필요가 없다고 알리면 -- 이상적으로는 glDiscardFramebufferEXT ( OpenGL ES 2.0 ) 이나 glInvalidateFramebuffer ( OpenGL ES 3.0 ) 에 대한 호출을 통해, 그리고 어떤 경우에는 드라이버에 의해서 추론될 수도 있지만 -- 타일의 뎁스 칸텐트와 스텐실 칸텐트는 결코 메인 메모리에 써지지 않을 것입니다. 대역폭과 전력을 크게 절약하는 또다른 방법입니다.

Summary

다음 시간에 튜닝을 하고 Mali 셰이더 코어 자체에 대한 간단한 블록 모델을 살펴 보면서 추상 머신에 대한 정의를 마칠 것입니다. Once we have that out of the way we can get on with the useful part of the series: putting this model to work and earning a living optimizing your applications running on Mali.

항상 댓글과 의견을 환영합니다.

Pete

원문 : https://community.arm.com/developer/tools-software/graphics/b/blog/posts/the-mali-gpu-an-abstract-machine-part-1---frame-pipelining

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

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

그래픽스 워크로드( workload )를 최적화하는 것은 보통 많은 현대 모바일 애플리케이션에서 필수입니다. 거의 대부분의 렌더링은 이제 렌더링 백엔드( back-end ) 에 기반한 OpenGL ES 에 의해 직접 혹은 간접적으로 다뤄집니다. 내 동료 중의 하나인 Michael McGeagh 는 최근에 Mali-T604 GPU 를 사용하는 그래피컬 애플리케이션들을 프로우파일링하고 최적화하기 위한 목적으로 Google Nexus 10 에서 동작하는 프로우파일링 툴인 Arm DS-5 Streamline 에 대한 작업 가이드를 포스팅했습니다. Streamline 은 강력한 도구이며, 전체 시스템의 동작에 대한 고해상도 가시화를 제공합니다. 하지만 그것은 엔지니어가 데이터를 해석( interpret )하고 문제 영역을 식별하고 수정할 점을 제안하는 데 시간을 쏟게 만듭니다.

그래픽스 최적화에 익숙하지 않은 개발자들에게는, 처음 시작할 때 공부할 것이 좀 있다고 할 수 있습니다. 그러므로 이 새로운 블로그 시리즈는 칸텐트 개발자들에게 필수적인 지식들을 제공해서 Mali GPUs 에서 성공적으로 최적화를 할 수 있도록 하기 위해 작성되었습니다. 이 시리즈의 코스 전반에서, 필자는 기본적인 macro-scale architectural structure 들과 동작들에 대해서 살펴 볼 것이므로, 개발자들은 이것을 어떻게 칸텐트에서 발생할 수 있는 가능한 문제로 해석할 것인지 그리고 Streamline 에서 그것들을 어떻게 확인할 것인지에 대해 걱정할 필요는 없습니다.

Abstract Rendering Machine

애플리케이션의 그래픽스 성능을 성공적으로 분석하기 위해서 필요한 가장 필수적인 조각은 OpenGL ES API 함수들을 밑바탕에 있는 시스템들에 대한 멘탈 모델( 역주 : 한글 링크 )입니다. 이는 엔지니어가 그들이 관찰하고 있는 동작들에 대해 추론할 수 있도록 합니다.

개발자들이 제어할 수 없고 결국에는 제한된 가치인 드라이버 소프트웨어와 하드웨어 서브시스템의 구현 세부사항 때문에 개발자들이 압도되지 않도록 하기 위해서는, 단순된 추상 머신을 정의하는 것이 유용합니다. 이는 관찰되는 동작들에 대해 설명하기 위한 기초로 사용될 수 있습니다. 이 머신에는 세 가지 주요 파트가 있으며, 그것들은 거의 직교적( orthogonal, 역주 : 서로 간섭하지 않고 독립적이어서 따로 따로 이해할 수 있다는 의미인듯 )입니다. 그래서 필자는 각각을 시리즈의 처음 몇 개의 블로그를 통해 순서대로 다루려고 합니다. 하지만 이 모델의 세가지 파트들에 대해 미리 살펴 보면 다음과 같습니다 :

1. The CPU-GPU rendering pipeline.
2. Tile-based rendering.
3. Shader core architecture.

이 블로그에서, 우리는 이들 중 첫 번째인 CPU-GPU rendering pipeline 에 대해서 살펴 보겠습니다.

Synchronous API, Asynchronous Execution

이를 이해하는 데 있어서 중요한 지식의 가장 근본적인 조각은 OpenGL ES API 에서 애플리케이션의 함수 호출과 그 API 호출들이 요구하는 렌더링 연산( operations )들의 실행 사이의 임시적 관계( temporal relationship )입니다. OpenGL ES API 는 애플리케이션의 관점에서는 동기적 API 로서 설계되었습니다( specified ). 애플리케이션은 일련의 함수 호출들을 만들어서 그것의 다음 드로잉 태스크에 필요한 상태( state )를 설정합니다. 그리고 나서 glDraw 함수를 호출해서 -- 보통 드로 콜이라 불립니다 - 실제 드로잉 연산을 발생시킵니다. API 는 동기적이므로, 드로 콜이 만들어진 후의 모든 순차적 API 동작은 렌더링 연산이 이미 실행된 것처럼 행동하도록 설계되어 있습니다. 하지만 거의 대부분의 하드웨어 가속 OpenGL ES 구현들에서는, 이는 드라이버 스택에 의해서 유지되는 정교한 환상입니다.

드로 콜에서도 이와 유사한 것이 있습니다. 드라이버에 의해서 유지되는 두 번째 환상은 프레임 버퍼 교체 완료( end-of-framebuffer flip )입니다. OpenGL ES 애플리케이션을 처음 작성하는 대부분의 개발자들은 eglSwapBuffers 호출이 프런트 버퍼와 백 버퍼를 교환( swap )한다고 말할 겁니다. 이것이 논리적으로는 사실이기는 하지만, 드라이버는 또 다시 동기화에 대한 환상을 유지하고 있는 것입니다; 거의 대부분의 플랫폼에서 물리 버퍼 교환은 한참 후에 발생합니다.

Pipelining

이러한 환상이 필요한 이유는, 여러분이 원하는 성능때문입니다. 만약 렌더링 연산을 실제로 동기적으로 수행하도록 강제한다면, CPU 가 다음 드로 연산을 위한 상태를 생성하느라 바쁠 때 GPU 가 놀게( idle ) 될 것입니다. 그리고 GPU 가 렌더링하고 있는 동안 CPU 가 놀 것입니다. 성능의 관점에서는 이런 유휴 시간( idle time )들은 허용될 수 없습니다.

이 유휴 시간을 제거하기 위해서, 우리는 OpenGL ES 드라이버를 사용해 동기적으로 렌더링되는 것처럼 환상을 유지했습니다. 하지만 실제로는 렌더링과 프레임 교환을 비동기적으로 처리하고 있습니다. 비동기로 실행하면 작은 백로그( backlog ) 작업을 빌드할 수 있으므로, GPU 가 파아프라인의 한쪽 끝에서 오래된 워크로드를 처리하는 곳에서 파이프라인을 만들 수 있고 CPU 는 새로운 작업을 다른 쪽에서 밀어 넣을 수 있습니다. 이 접근 방법의 장점은 파이프라인을 가득 채우면 GPU 에서 실행할 수 있는 작업이 항상 최고의 성능을 제공한다는 것입니다.

Mali GPU 파이프라인에서 작업 유닛( unit )들은 렌더 타깃( render target ) 기반( basis )으로 스케줄링됩니다. 여기에서 렌더 타깃은 윈도우 서피스( surface )이거나 오프스크린 렌더 버퍼일 수 있습니다. 단일 렌더 타깃은 두 단계의 절차로 처리됩니다. 먼저 GPU 는 렌더 타깃 내의 모든 드로 콜들에 대한 버텍스 셰이딩( vertex shading )을 처리합니다. 다음으로 전체 렌더 타깃을 위한 프래그먼트( fragment ) 셰이딩이 처리됩니다. 그러므로 Mali 를 위한 논리 렌더링 파이프라인은 세 가지 스테이지의 파이프라인으로 구별됩니다: CPU 프로세싱 스테이지, 지오메트리( geometry ) 프로세싱 스테이지, 프래그먼트 프로세싱 스테이지.

Pipeline Throttling

관찰력있는 독자들은 위의 그림에 있는 프래그먼트 작업이 CPU 및 지오메트리 처리 스테이지들보다 점점 더 느려지고 세 가지 연산 중에 가장 느리다는 것을 눈치챘을 것입니다. 이런 상황이 비정상적인 것은 아닙니다; 대부분의 칸텐트들은 셰이딩되는 버텍스보다는 프래그먼트를 더욱 많이 가지고 있으므로, 프래그먼트 셰이딩이 보통 주요 처리 연산입니다.

사실은 CPU 작업을 완료하는 것부터 프레임이 렌더링되는 것까지의 지연양( amount of latency )을 최소화하는 것이 바람직합니다 -- 최종 사용자 입장에서는 자신들이 터치 이벤트를 입력하고 있는 터치 스크린 디바이스와 상호작용( interacting )이 스크린의 데이터와 몇 백 밀리세컨드 정도 차이가 나는 상황이 가장 혼란스럽습니다 -- 그래서 우리는 프래그먼트 처리 스테이지를 위해 대기하는 밀린 작업이 너무 많아지는 것을 원하지 않습니다. 간단히 말해, CPU 스레드를 주기적으로 느리게 만드는 메커니즘( mechanism )이 필요합니다. 파이프라인이 이미 성능을 유지하기에 충분할 때 작업 대기열( queuing up )을 중단합니다.

이 조절( throttling ) 메커니즘은 보통 그래픽스 드라이버가 아니라 호스트 윈도우 시스템에 의해 제공됩니다. 예를 들어 안드로이드에서는 버퍼의 방향( orientation )을 알기 전까지는 프레임에서 어떠한 드로 연산도 처리할 수 없습니다. 왜냐하면 유저가 장치를 회전시켜서 프레임 크기를 변화시킬 수 있기 때문입니다. SurfaceFlinger -- 안드로이드 윈도우 서피스 관리자 -- 는 렌더링을 위해서 N 개의 이상의 버퍼가 이미 존재할 때 애플리케이션의 그래픽스 스택에 버퍼를 반환하는 것을 거절함으로써 파이프라인 깊이를 단순하게 제어합니다.

만약 이런 상황이 발생한다면, "N" 에 도달하자 마자 CPU 가 프레임당 한 번씩 유휴상태가 되어, EGL 이나 OpenGL ES API 함수들 내부에서 블락킹( blocking )이 발생하는데, 이는 디스플레이가 보류중인( pending ) 버퍼를 소비하고 새로운 렌더링 연산을 위해서 하나를 비워줄( freeing ) 때까지 유지됩니다.

그래픽스 스택이 디스플레이 리프레시 비율( rate )보다 더 빠르게 실행되고 있을 때 이와 동일한 방식으로 파이프라인 버퍼링에 제약이 가해집니다; 이 시나리오에서는 칸텐트는 디스플레이 컨트롤러에 다음 프론트 버퍼를 교체할 수 있다고 알려주는 수직 공백( vertical blank, vsync )를 기다리면서 "vsync limited" 됩니다. 만약 GPU 가 디스플레이가 그것을 보여줄 수 있는 것보다 빠르게 프레임을 생산한다면, SurfaceFlinger 는 렌더링이 완료되었지만 여전히 화면에 출력되어야 할 버퍼들의 개수를 누적할 것입니다; 심지어 이 버퍼들은 더 이상 Mali 파이프라인의 일부가 아님에도 불구하고, 그것들은 애플리케이션 처리를 위한 N 프레임 제약을 위해 카운트됩니다.

위의 파이프라인 다이어그램에서 보이듯이, 만약 칸텐트가 vsync 제한에 걸리면, CPU 와 GPU 가 완전히 유휴상태가 되는 주기를 가지는 것이 일반적입니다. 플랫폼 동적 전압( Platform dynamic voltage )과 주파수 스케일링( frequency scaling, DVFS )은 일반적으로 이런 시나리오에서 현재의 연산 주파수를 줄이려고 시도합니다. 이를 통해 전압과 에너지 소비가 줄어들지만, DVFS 주파수 선택은 보통 상대적으로 거칠기 때문에 일부 유휴 시간이 예상됩니다.

Summary

이 블로그에서 우리는 OpenGL ES API 에 의해 제공되는 동기화 환상과 API 뒤에서 비동기 렌더링 파이프라인이 실제로 실행되는 이유에 대해 살펴 보았습니다. 다음 시간에 필자는 계속해서 추상 머신 개발에 대해서 이야기할 것입니다. Mali GPU 의 타일 기반 렌더링 접근법에 대해서 살펴 보도록 하겠습니다.

댓글과 질문을 환영합니다.

Pete

주의 : 답이 틀릴 수도 있습니다. 그냥 정리하는 용도로 올립니다. 혹시라도 도움이 필요한 분이 있다면 도움이 되었으면 좋겠네요.

경고 : 숙제하려고 베끼는 데 사용하지 마십시오. 본인의 미래를 망칠 뿐입니다. 나중에 저를 원망하지 마세요.

부탁 : 문제 풀이가 잘못되었으면 지적해 주셨으면 좋겠습니다.

일단 문제에서는 등속 원운동을 가정하지 않았지만, 등속 원운동이라 생각하고 문제를 풀겠습니다.

일정한 속도로 등속 원운동을 한다면, 속도의 크기( 빠르기 )와 가속도의 크기는 다음과 같습니다. 증명은 [ 연습문제 5-5 ] 에서 확인하십시오.

식 1 에서 ω 는 각속도입니다.

식 1.

( a )

등속 원운동 시에 힘의 방향은 막대의 중심축을 향하게 됩니다. 

여기에서 헷갈리는 건, 알짜힘을 구하는 과정을 서술하라는 것인지, 아니면 중력에 의한 등속 원운동과 끈을 매달고 회전시켰을 때의 등속 원운동이 같은 개념이라는 가정을 깔고 문제를 풀라는 것인지 알 수가 없습니다.

이미 증명은 [ 연습문제 5-5 ] 에서 했으므로 따로 하지는 않겠습니다. 결국 중력이라는 가상의 끈으로 이어져 있든지 아니면 실제 끈으로 이어져 있든지 나타나는 결과는 같습니다.

( b )

식 1 을 통해 물체의 가속도를 알 수 있기 때문에, 알짜힘 크기는 다음과 같습니다.

식 2.

( c )

문제에서는 중력에 대해서 언급하고 있지 않지만 실제 해답에서는 중력을 고려하고 있습니다. 그래서 이 문제 풀이에서 오답이 나왔습니다. 만약 중력이 작용하지 않으면 T = F 가 되겠죠.

하지만 중력을 고려해야 하므로 물체에는 알짜힘과 중력의 합의 크기가 장력의 크기와 같습니다.

그림 1.

피타고라스 정리를 통해 문제를 풀어 보겠습니다.

식 3.

하지만 해답은 다음과 같습니다.

식 4.

해답이 오답인 것 같습니다.

원문 : Vulkan Debug Utilities.

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

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

Introduction

벌칸 API 는 이제 2 살이 되었습니다. 그리고 다른 것들처럼 개량할 영역이 있어 보입니다( and as with all things it is showing areas that require improvement ). 디버깅이 그런 영역 중의 하나인데요, 여기에서 우리는 벌칸 커뮤니티를 위해 큰 이득을 제공해줄 작은 변화를 줄 수 있습니다. IHV( 역주 : Independent Hardware Vendor ) 들과 몇몇 게임 회사들로부터의 입력을 요청하고 깃허브 유저들로부터 피드백을 받은 후에, 우리는 VK_EXT_debug_report 와 VK_EXT_debug_marker 에 의해 노출되는 디버깅 기능들을 개선하기로 했습니다. 우리가 연구한 결과, 현재 익스텐션( extension )에 다가 새로운 기능을 억지로 집어 넣으려고 시도하는 대신에, 익스텐션을 교체하는 것이 올바른 결정이라고 판단했습니다. 그 변화는 새로운 익스텐션인 VK_EXT_debug_utils 의 창조를 이끌었습니다.

Why the New Extension?

Vulkan Working Group 은 몇몇 소프트웨어 회사들에 근무하는 개발자들로부터 각각의 디버그 메시지들로부터 더 많은 정보를 받아 자신들의 코드에서 유발점( trigger )을 구별( isolate )할 수 있도록 해 달라는 피드백을 받았습니다. 애플리케이션은 다중의 벌칸 오브젝트들을 생성하고 그 중의 하나만이 잘못 다뤄질 수 있기 때문에, Validation messages created a special concern.

소프트웨어 개발자들이 더 효율적으로 이슈( issue )들을 구별하는 것을 돕기 위해, LunarG 는 VK_EXT_debug_report 와 VK_EXT_debug_marker 의 기능들을 병합해 더욱 유용한 디버그 메시지들을 생성하기로 했습니다. 그러나 이 두 가지 개별 익스텐션들 사이에서 협업을 시도하는 중에, 우리는 근본적인 문제가 있다는 것을 깨닫게 되었습니다. VK_EXT_debug_report 는 인스턴스( instance ) 익스텐션이지만 VK_EXT_debug_marker 는 디바이스( device ) 익스텐션이라는 겁니다. 디바이스 익스텐션에 대해 독립적인 인스턴스 익스텐션의 기능을 지정하기 위한 쉽고 깔끔한 방법이 존재하지 않습니다. 단순함을 위해, 그냥 새로운 익스텐션을 만들고, 한 곳에서 필수적인 모든 아이템들을 지원하기로 했습니다.

또한 유저의 디버그 콜백에 반환되는 정보를 확장하기도 했습니다. 이러한 변경은 예전의 익스텐션에도 적용될 수 있었지만, 대부분의 구조체들의 pNext 체인에 아이템들을 추가할 것을 요구했습니다. 그렇게 할 수는 있었지만, 우리가 생각한 것보다는 더 복잡했습니다. 왜냐하면 모든 디버그 콜백이 pNext 체인을 고려해야만 하기 때문이었습니다. 물론 우리는 여전히 나중에는 pNext 체인에 기능을 추가하긴 할 겁니다.

마지막으로 VK_EXT_debug_report 익스텐션은 VkDebugReportObjectTypeEXT 라는 특별한 내부 열거형을 사용해서 오브젝트 타입( type )을 추적( tracking )합니다. 이 열거형은 잠깐 동안 지원되었으며 심지어는 VK_EXT_debug_marker 익스텐션에서도 사용되었습니다. 하지만 벌칸 명세의 최신 버전들에서는 이 구조를 새로운 코어 오브젝트 타입 열거형으로 대체했습니다. 명세가 변경되었으므로, 크로노스는 VkDebugReportObjectTypeEXT 를 확장하는 것을 중지하고 대신에 VkObjectType 에다가만 새로운 열거을 추가하는 것을 지원하기로 결정했습니다. 결과적으로 VkDebugReportObjectTypeEXT 열거형은 시간이 흐르면 점점 더 곰팡내나게 될 것입니다.

이러한 사실들을 고려해서, LunarG 는 벌칸 디버그 유틸리티를 처음부터 새로 만들기로 했습니다.

Benefits of This New Extension

VK_EXT_debug_utils 는 VkDebugUtilsMessengerEXT 라는 디버그 메신저( messenger ) 개념을 소개합니다. 이를 생성하는 동안에, 애플리케이션은 어떤 디버그 메시지 타입들과 심각성( severity )들이 필요한지를 세부적으로 결정합니다. 추가적으로, 애플리케이션은 콜백 메시지 핸들러에 대한 함수 포인터를 제공하는데, 이는 메시지가 적절한 심각성과 타입을 만족시켰을 대 호출될 것입니다. VkDebugReportCallbackEXT 오브젝트 타입은 VK_EXT_debug_report 와 유사한 방식으로 동작합니다. 개선된 유용상은 새로운 콜백에 이제는 데이터가 공급된다는 데 있습니다. 이 콜백에서 공급된 데이터를 읽기 위해서는 "Creating a Debug Messenger Callback" 섹션을 참고하십시오.

VK_EXT_debug_marker 익스텐션과 마찬가지로, 새로운 익스텐션은 VkCommandBuffer 의 특정 위치를 식별할 수 있도록 해 줍니다. 이전에 VK_EXT_debug_marker 에서는, 실별된 위치가 "마커( marker )"라고 불렸습니다. 이제 VK_EXT_debug_utils 에서는, 그것들이 "레이블( label )"이라 불립니다. 또한 Vk_EXT_debug_utils 는 이 레이블들을 VkQueue 에다가 삽입해서 벌칸 큐( queue )에서 처리중인 runtime/driver/hardware 의 프로그레스를 식별할 수 있도록 하는 기능을 추가했습니다. 레이블에 대한 더 많은 정보를 원한다면 "Adding Labels" 섹션을 참고하십시오.

VK_EXT_debug_utils 익스텐션에 의해서 지원되는 VK_EXT_debug_marker 의 또 다른 기능은 애플리케이션이 정의한 데이터를 벌칸 핸들과 연관시키는 기능입니다. 이 기능의 거의 대부분의 용도는 각 벌칸 핸들을 쉽게 식별이 가능한 문자열 이름으로 만드는 것입니다. 벌칸 오브젝트의 핸들값은 로더( loader ), 레이어( layer ), ICD 를 포함한 모든 벌칸 컴포넌트에 대해서 내부적으로 변할 수 있습니다 -- 그러므로 핸들을 명명하지 않으면, 반환된 정보들이 맞는지 헷갈릴 겁니다. 예가 하나 있습니다:

그러나 애플리케이션이 자신의 벌칸 핸들에 대한 이름을 설정해 놓았다면, 그 이름들은 이 익스텐션을 지원하는 모든 컴포넌트들 내부에서 그 핸들들과 연관됩니다. 이는 오브젝트에 대한 핸들값이 변경되었더라도 올바로 동작합니다. 위의 경우에, VkCommandBuffer 가 "Primary Command Buffer in Thread B" 라고 명명되어 있었다면, 여러분은 특이한 핸들 값을 획득하게 되지만, 그것은 "Primary Command Buffer in Thread B" 라는 이름을 가지고 있을 것입니다. 이름에 대한 더 많은 정보를 원한다면, "Naming Objects" 섹션을 참고하십시오.

VK_EXT_debug_utils 는 태그를 사용하여 특정 오브젝트를 위한 바이너리( binary ) 칸텐트를 정의하는 기능을 계속해서 지원합니다. 이러한 태그가 걸린 칸텐트는 매우 복잡한 경향이 있으며, 거의 대부분 RenderDoc 같은 부가적인 칸텐트를 필요로 하는 디버깅 레이어를 위해서 사용됩니다. 태그들은 어떠한 validation 레이어 메시지에 의해서도 사용되지 않습니다. 그리고 디버그 메신저 콜백에서 유저가 획득할 수도 없습니다. 더 많은 정보를 원한다면 "Tagging Objects" 섹션을 참고하십시오.

위의 정보들을 일고 나면, 여러분은 새로운 익스텐션이 별로 새로운 것을 포함하고 있지 않다고 느낄 것입니다. 그러나 VK_EXT_debug_report 에 등록된 콜백에서 반환된 데이터를 살펴 본다면, 디버그 메시지가 콜백에 반환될 때 단지 하나의 오브젝트와 메시지만을 획득하게 된다는 것을 깨닫게 될 것입니다. 새로운 익스텐션을 사용하고 있다면, VK_EXT_debug_utils 는 여러분의 콜백 함수에 설정하고 넘김수 있는 모든 정보들을 결합합니다. 여기에 이전의 VK_EXT_debug_report 익스텐션이 반환한 콜백 메시지와 더불어 더 포함된 추가 정보들을 정리해 봤습니다:

• 각 디버그 메시지와 관련이 있는 오브젝트들의 리스트.
• ( 만약 이름이 설정되었다면 ) 각 오브젝트와 연관된 이름.
• 해당 시점까지 맞닥뜨린 커맨드 버퍼 레이블 리스트.
• 오브젝트 리스트에서 VkCommandBuffer 만이 존재하고 그것과 관련이 있는 레이블을 가지고 있을 때만...
• 해당 시점까지 맞닥뜨린 큐 레이블 리스트.
• 오브젝트 리스트에 VkQueue 만이 존재하고 그것과 관련된 이름을 가지고 있을 때만...

이 부가 정보들을 사용하면, 가장 복잡한 애플리케이션이라고 할지라도, 디버그 메시지의 위치를 쉽게 좁혀갈 수 있을 것입니다. 이는 VK_LAYER_LUNARG_standard_validation 을 활성화했을 때 특히 유용하며, 일련의 특별한 커맨드들에 대한 validation 메시지로부터 에러를 받게 될 것입니다.

How Do I Use It?

사용하기 전에, VkEnumerateInstanceExtensionProperties 를 사용해서 VK_EXT_debug_utils 익스텐션을 사용할 수 있는지 확인해야 합니다. 그러나 일단 익스텐션이 이용가능하다는 것을 확인했다면, 그것의 디버깅 기능들을 해제할 수 있습니다.

우리는 아래에서 VK_EXT_debug_utils 의 핵심 기능들에 대해서 다룰 겁니다. 하지만 이 새로운 익스텐션을 사용하는 방법은 벌칸 명세의 "Debugging" 섹션에서 자세하게 알아 볼 수 있을 것입니다.

이 익스텐션을 사용하는 것은 이전에 VK_EXT_debug_report 와 VK_EXT_debug_marker 를 사용하는 것과 유사합니다. 그러나 두 개의 익스텐션을 개별적으로 활성화하는 대신에( 하나는 인스턴스 익스텐션, 하나는 디바이스 익스텐션 ), 여럽분은 하나의 인스턴스 익스텐션만을 활성화하면 됩니다.

먼저 새로운 익스텐션을 사용해 디버그 메시지를 받는 것부터 살펴 보겠습니다. 만약 디버그 메시지가 필요하지 않다면, "Naming Objects" 섹션으로 바로 넘어 가십시오.

Creating a Debug Messenger Callback

디버그 메시지를 받겠다고 했으므로, 먼저 콜백 함수를 생성해야 합니다. 그것은 디버그 메시지를 받으며 PFN_vkDebugUtilsMessengerCallbackEXT 함수 포인터의 형태로 되어 있어야 합니다.

typedef VkBool32 (VKAPI_PTR *PFN_vkDebugUtilsMessengerCallbackEXT)( VkDebugUtilsMessageSeverityFlagBitsEXT messageSeverity, VkDebugUtilsMessageTypeFlagsEXT messageType, const VkDebugUtilsMessengerCallbackDataEXT* pCallbackData, void * pUserData);

새로운 콜백에서는 메시지 심각성( messageSeverity ) 가 메시지 타입( messageType )과 분리되었음을 알아채게 될 것입니다. 심각성은 메시지의 중요도를 지정합니다. 가능한 값들은 현재 다음과 같이 정의되어 있습니다:

typedef enum VkDebugUtilsMessageSeverityFlagBitsEXT { VK_DEBUG_UTILS_MESSAGE_SEVERITY_VERBOSE_BIT_EXT = 0x00000001 , VK_DEBUG_UTILS_MESSAGE_SEVERITY_INFO_BIT_EXT = 0x00000010 , VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT = 0x00000100 , VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT = 0x00001000 , } VkDebugUtilsMessageSeverityFlagBitsEXT;

메시지의 중요도가 올라갈수록, 열거형 값도 올라갑니다. In addition, we've left space for future types that could fit in between any of the existing values. 그런 이유로, 여러분은 콜백에서 항상 값들을 비교할 수 있습니다.

if (messageSeverity >= VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT) { // This means the message was either a warning or error of some kind. }

메시지 타입은 여러분이 받고 있는 메시지의 종류를 기술합니다. 현재 다음과 같은 메시지 타입들을 이용할 수 있습니다( 하지만 나중에 더 추가될 수 있습니다 ):

typedef enum VkDebugUtilsMessageTypeFlagBitsEXT { VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT = 0x00000001 , VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT = 0x00000002 , VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT = 0x00000004 , } VkDebugUtilsMessageTypeFlagBitsEXT;

범용( General ) 메시지는 일반적으로 벌칸 컴포넌트 자체에서 옵니다. Vadiation 비트는 애플리케이션의 행위를 명세에 대해 검증하는 과정과 관련이 있는 메시지를 가리킵니다. 이것들이 validation 레이어로부터 오는 가장 일반적인 메시지들입니다. 왜냐하면 거의 대부분의 validation 에러나 경고들은 벌칸 명세를 위해발 수 있음을 가리키기 때문입니다. 마지막으로, 애플리케이션의 성능을 개선할 것을 제안하는 성능( performance ) 메시지들이 있습니다.

pCallbackData 는 VkDebugUtilsMessengerCallbackDataEXT 구조체를 가리키는데요, 이는 메시지를 유발한 것이 무엇인지에 대한 정보를 포함하고 있으며, 메시지가 발생된 위치를 찾아내는 데 충분히 도움을 줍니다 : 

typedef struct VkDebugUtilsMessengerCallbackDataEXT { VkStructureType sType; const void * pNext; VkDebugUtilsMessengerCallbackDataFlagsEXT flags; const char * pMessageIdName; int32_t messageIdNumber; const char * pMessage; uint8_t queueLabelCount; VkDebugUtilsLabelEXT* pQueueLabels; uint8_t cmdBufLabelCount; VkDebugUtilsLabelEXT* pCmdBufLabels; uint8_t objectCount; VkDebugUtilsObjectNameInfoEXT* pObjects; } VkDebugUtilsMessengerCallbackDataEXT;

구조체의 처음 세 개의 파라미터( parameter )들은 대부분의 벌칸 구조체에서 동일합니다. 그래서 그것에 대해서 여기에서 다루지는 않겠습니다.

두 번째 세 개의 파라미터들은 특정 메시지에 대한 모든 세부사항을 제공합니다.

1.  pMessageIdName 은 문자열인데, 메시지를 유발한 것이 무엇인지를 가리킵니다. Validation 레이어의 경우, 이 문자열은 VUID( valid usage ID ) 문자열 식별자를 포함할 것입니다. 그것은 그 레이어가 위반했다고 생각하는 명세의 특정 위치를 식별하는 데 도움이 됩니다.
2. messageIdNumber 는 ( 0 이 아니라면 ) 이 메시지에 대한 고유 번호를 가리킵니다. 만약 메시지가 validation 레이어로부터 발생했다면, 그것은 발생한 경고나 에러를 위한 고유 숫자 VUID 를 포함할 것입니다. 이 숫자를 레이어가 위반이 발생했다고 생각하는 벌칸 명세의 위치를 찾기 위한 테이블의 색인으로 사용하십시오.
3. pMessage 는 ( null 종료 ) C 스타일 문자열입니다. 이는 메시지의 세부사항을 가리킵니다.

콜백은 메시지 ID 번호와 이름을 모두 반환합니다. Validation 레이어들은 현재 주어진 validation 메시지를 위해 messageIdNumber 를 반환합니다. 만약 messageIdNumber 가 제출되었다면, 여러분은 실제 Valid Usage ID 문자열을 vk_validation_error_messages.h 헤더 파일에 접근해서 검색할 수 있습니다. UNIQUE_VALIDATION_ERROR_CODE 열거형에서 값을 찾아서, VUID 를 명세 정보( spec snippet ) 매핑하는 테이블에서 값을 찾으면 됩니다. 명세 정보는 최종 VUID 문자열을 포함하는데요, 이는 명세에서 정확한 섹션을 찾아내기 위해서 사용될 수 있습니다. 우리는 이게 유저에게는 복잡한 작업이라는 것을 깨달았으며, 그래서 앞으로, Validation 레이어들은 새로운 pMessageIdName 필드를 사용해 실제 명세 VUID 문자열을 반환하도록 하는 것을 의도하고 있습니다.

일단 VUID 문자열을 획득했다면, 벌칸 명세를 열어서 해시 심볼( # ) 뒤에 VUID 문자열을 붙이면 그 섹션으로 바로 갈 수 있습니다.

이제 이 익스텐션에서 새로운 아이템들을 살펴 봅시다. queueLableCount 와 pQueueLables 는 애플리케이션이 VkQueue 에다가 적용한 레이블에 대한 정보를 포함합니다. 이 필드들은 VkQueue 오브젝트가 pObjects 리스트에 포함되었을 때만 활성화됩니다. pQueueLables 는 메시지가 발생한 시점까지 특정 VkQueuObject 에서 설정된 레이블들만을 포함합니다. 이 레이블들은 다음과 같은 정보를 포함합니다:

typedef struct VkDebugUtilsLabelEXT { VkStructureType sType; const void * pNext; const char * pLabelName; float color[ 4 ]; } VkDebugUtilsLabelEXT;

pLabelName 은 애플리케이션이 정의한 레이블의 이름이며 color 는 여러분이 설정한 부동소수점 색상입니다. Validation 레이어들과 디버그 메시지들이 색상을 사용하지는 않지만, 다른 레이어들이나 여러분의 애플리케이션은 이 정보를 사용할 수도 있습니다.

만약 VkQueue 오브젝트가 pObjects 리스트에 없다면, queueLabelCount 는 0 이고 pQueueLabels 는 null 이어야 합니다. pQueueLabels 배열의 아이템들은 정렬되어 있어서 가장 최근의 레이블이 낮은 인덱스 값에 들어 가 있습니다. 그러므로 0 번 인덱스에 있는 레이블이 VkQueue 와 연관된 가장 최근의 레이블입니다.

이와 유사하게 cmdBufLabelCount 와 pCmdBufLabels 는 pObjects 리스트에 있는 VkCommandBuffer 로부터의 모든 레이블들을 포함합니다. 레이블들은 세컨더리( Secondary ) 커맨드 버퍼에 의해 프라이머리( Primary ) 커맨드 버퍼로부터 상속될 수 있습니다. 그러나, 디버그 메시지의 경우에는, 거의 대부분의 레이어들과 로더는 단지 활성화된 커맨드 버퍼나 그것의 자식 오브젝트들에 대한 정보만을 알고 있습니다. 그러므로, VkCommandBuffer 가 pObjects 에 있고 VkCommandBuffer 가 연관된 레이블을 가지고 있다면, cmdBufLabelCount 는 0 이 아닌 값이며 pCmdBufLabels 는 null 이 아닌 값입니다.

VkDebuUtilsMessengerCallbackDataEXT 의 마지막 두 개의 요소는 objectCount 와 pObjects 입니다. pObjects 는 메시지와 쉽게 연관될 수 있는 모든 오브젝트들에 대한 정보를 포함합니다. 그 정보는 VkDebugUtilsObjectNameInfoEXT 구조체에 저장됩니다.

typedef struct VkDebugUtilsObjectNameInfoEXT { VkStructureType sType; const void * pNext; VkObjectType objectType; uint64_t objectHandle; const char * pObjectName; } VkDebugUtilsObjectNameInfoEXT;

pObjects 내의 각 오브젝트들은 오브젝트의 타입( objectType ) 과 오브젝트의 핸들( objectHandle ) 을 가지고 있습니다. 만약 ( "Naming Objects" 섹션에서 설명하는 것처럼 ) 오브젝트를 위한 이름을 지정한다면, 오브젝트의 이름( pObjectName ) 이 여러분이 제공한 이름을 포함하는 문자열에 대한 포인터로 설정될 것입니다 -- 여러분이 거의 대부분의 오브젝트들을 쉽게 식별할 수 있게 해 줍니다. pObjects 를 레이블과 함께 사용하면, 여러분은 메시지를 발생시킨 코드의 위치를 좁힐 수 있을 겁니다.

마지막으로, 콜백 함수는 유저가 제공한 데이터( pUserData ) 를 받을 수 있습니다. 그것은 메신저를 생성할 때 각 메신저에 제공한 것입니다.

Creating ( and Destroying ) a Debug Messenger

콜백을 설정하고 나면, 디버그 메신저를 생성할 필요가 있습니다. 그것은 메시지가 발생할 때 콜백을 호출하기 위해서 사용될 것입니다.

VkResult vkCreateDebugUtilsMessengerEXT ( VkInstance instance, const VkDebugUtilsMessengerCreateInfoEXT* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkDebugUtilsMessengerEXT* pMessenger);

이 역시 여러분이 벌칸 작업을 하면서 봤던 매우 표준적인 외형을 가졌습니다. 가장 중요한 컴포넌트는 2 번째 파라미터인 pCreateInfo 입니다. 이는 다음과 같은 구조체에 대한 포인터입니다:

typedef struct VkDebugUtilsMessengerCreateInfoEXT { VkStructureType sType; const void * pNext; VkDebugUtilsMessengerCreateFlagsEXT flags; VkDebugUtilsMessageSeverityFlagsEXT messageSeverity; VkDebugUtilsMessageTypeFlagsEXT messageType; PFN_vkDebugUtilsMessengerCallbackEXT pfnUserCallback; void * pUserData; } VkDebugUtilsMessengerCreateInfoEXT;

messageSeverity 파라미터는 콜백을 호출하기를 원하는 모든 메시지 심각성들을 지정하기 위한 것입니다. 여러분은 "플래그 비트( FlagBit )" 가 아니라 "플래그들( flags )"이 사용된다는 것을 알아차렸을 겁니다. 왜냐하면 이것은 하나 이상의 값들을 취하기 때문입니다. 예를 들어 다음과 같이 메시지 심각성들을 설정할 수 있습니다: 

messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT | VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT;

마찬가지로 messageType 은 여러분이 추적하고자 하는 모든 메시지 타입들의 조합입니다. 그리고 나서 pfnUserCallback 을 위에서 생성한 콜백 함수에 대한 포인터로 설정합니다.

여러분의 콜백에 반환되는 메시지들은 반드시 여러분이 활성화한 심각성과 vkCreateDebugUtilsMessengerEXT 호출 동안 활성화한 타입이어야만 합니다.

그렇지 않다면, 만약 신각성은 일치하는데 타입은 일치하지 않는다든가 한다면, 콜백이 호출되지 않을 것입니다.

마지막으로 여러분은 pUserData 를 사용해서 부가적인 데이터에 대한 포인터를 제공하거나 그것을 null 로 설정할 수 있습니다. 로그를 출력한다든가 하는 작업을 수행하기 위해서, 콜백이 호출되는 동안에 애플리케이션이 구조체나 클래스에 대한 포인터를 사용하는 경우가 많습니다.

모든 표준 벌칸 오브젝트들처럼, VkDebugUtilsMessengerEXT 를 vkDestroyDebugUtilsMessengerEXT 를 호출해서 파괴하게 됩니다.

void vkDestroyDebugUtilsMessengerEXT ( VkInstance instance, VkDebugUtilsMessengerEXT messenger, const VkAllocationCallbacks* pAllocator);

Naming Objects

네이밍은 애플리케이션이 특정 이름으로 오브젝트를 식별할 수 있도록 해 주며, 오브젝트 핸들 값이 로더, 레이어, 심지어는 런타임에 들어갈 때 변경될 수 있기 때문에 유용합니다. 만약 메시지가 특정 오브젝트를 위해 그런 레이어 중 하나에서 발생했다면, 그 핸들은 유저가 알지 못하는 값이 될 것이며 혼란스럽게 만들 것입니다. 그러므로 오브젝트를 네이밍하는 기능이 생겼습니다.

왜 네이밍이 유용한지 빠르게 살펴 봅시다. 여러분이 validation 레이어에 의해 검출된 잘못된 호출을 만드는 애플리케이션을 가지고 있다고 합시다. 또한 벌칸 로더는 오브젝트 자체를 래핑( wrapping )하고 있으며, 그래서 그것은 오브젝트와 연관된 다른 데이터를 유지할 수 있다고 합시다. 애플리케이션에서는 오브젝트에 대해  0xFEED 라는 핸들을 가지고 있습니다. 그러나 로더는 그 정보를 언랩( uwrap )해서 첫 번째 레이어에 0xF00D 라는 핸들을 넘기고 있습니다.  또한 그 레이어는 그것을 언랩해서 이제 0xBEEF 가 되었습니다. 최종적으로, validation 레이어는 버그를 발견하고 ( 여러분의 Debug Utils Messenger callback 을 사용해 ) 여러분에게 0xBEEF 가 잘못되었다고 알려 줍니다. 하지만 여러분은 0xBEEF 라는 오브젝트가 뭔지 궁금하겠죠?

자, 오브젝트에 어떤 유용한 이름을 부여했다면, 그것은 식별하기 쉬워질 겁니다. 위의 예제로 다시 돌아가 보죠. 여러분이 함수를 호출하기 전에, "Hamburger" 라는 이름을 0xFEED 와 연관된 오브젝트에 부여합니다. 만약 로더가 버그를 만나면, 여러분은 0xF00D 라는 것을 핸들로 받게 될 것입니다. 하지만 이름은 "Hamburger" 죠. 만약 레이어중 하나가 버그를 만나서, 여러분이 0xBEEF 를 받는 다고 해도 그것은 "Hamburger" 입니다. 명확하게도 네이밍이 훨씬 더 유용합니다.

VK_EXT_debug_utils 를 사용해 오브젝트를 네이밍하는 것은 VK_EXT_debug_marker 를 사용해서 오브젝트를 네이밍하는 것과 유사합니다. 그냥 다음 함수를 호출하기만 하면 됩니다 :

VkResult vkSetDebugUtilsObjectNameEXT( VkDevice device, const VkDebugUtilsObjectNameInfoEXT* pNameInfo);

그 구조체는 VK_EXT_debug_marker 익스텐션에 있는 VkDebugMarkerObjectNameInfoEXT 와 유사합니다. 중요한 차이는 단순히 멤버 이름이 다르다는 것과 새로운 VkDebugUtilsObjectNameInfoEXT 구조체에서의 타입은 VkDebugReportObjectTypeEXT 열거형이 아니라 VkObjectType 열거형을 사용한다는 사실입니다 이것은 "Creating ( and Destroying ) a Debug Messenger" 에서 설명했던 콜백에 반환되는 정확히 같은 구조체입니다. 하지만 포맷을 확인할 수 있게 여기에서 다시 언급하도록 하겠습니다 :

typedef struct VkDebugUtilsObjectNameInfoEXT { VkStructureType sType; const void* pNext; VkObjectType objectType; uint64_t objectHandle; const char* pObjectName; } VkDebugUtilsObjectNameInfoEXT;

Tagging Objects

태깅은 네이밍과 유사합니다. 하지만 매우 다른 목적을 가지고 있습니다. 네이밍의 경우에는 애플리케이션이 제공하는 문자열을 특정 오브젝트와 연관시킵니다. 하지만 태깅의 경우에는 정수 ID 와 바이너리 데이터를 오브젝트와 연관시킵니다. 태깅의 가장 잘 사용하려면, 애플리케이션과 레이어 혹은 런타임이 ID 및 데이터의 용례에 대해서 반드시 서로 동의하고 있어야 합니다.

태깅의 예는 다음과 같습니다:

• 셰이더 오브젝트를 인간이 인식할 수 있는 버텍스 및 프레그먼트 셰이더 칸텐츠로 태깅함.
• 버퍼를 그 칸텐츠에 대한 칸텐츠나 메타 데이터로 태깅함.

일반적으로, 거의 대부분의 디버그 레이어들과 툴들은 단순히 오브젝트를 이름으로 식별함으로써 그것들이 필요로 하는 필수 정보들을 획득합니다. Debug Utils Messenger 콜백들은 애플리케이션에 반환되기 때문에, 고유 오브젝트를 추적하기 위한 이름을 제외하고는 레이어들을 통해 넘길 필요가 있는 데이터들을 가지고 있지 않습니다. 애플리케이션은 이미 그것이 필요로 하는 모든 정보들에 대한 소유자( keeper )입니다. 그래서 Debug Utils Messenger 콜백을 통해 반환되는 태깅 정보는 존재하지 않습니다.

그러나, 여러분이 태깅을 필요로 한다면, VK_EXT_debug_utils 는 VK_EXT_debug_marker 와 비슷한 방식으로 구현을 합니다. 이 경우에, 여러분은 다음 함수를 호출하게 됩니다:

VkResult vkSetDebugUtilsObjectTagEXT( VkDevice device, const VkDebugUtilsObjectTagInfoEXT* pTagInfo);

그 구조체는 VK_EXT_debug_marker 익스텐션에 있는 VkDebugMarkerObjectTagInfoEXT 와 유사합니다. 두 개의 차이점이 존재합니다 : 1) 멤버 이름들이 다름 2) VkDebugUtilsObjectNameInfoEXT 구조체의 타입들이 VkDebugResportObjectTypeEXT 열거형 대신에 VkObjectType 열거형을 사용함:

typedef struct VkDebugUtilsObjectTagInfoEXT { VkStructureType sType; const void* pNext; VkObjectType objectType; uint64_t objectHandle; uint64_t tagName; size_t tagSize; const void* pTag; } VkDebugUtilsObjectTagInfoEXT;

여러분 중 일부는 이 구조체에 익숙하지 않을 것니다. 그래서 간단하게 다루도록 하겠습니다. objectType 과 objectHandle 은 네이밍의 경우와 정확히 동일합니다. tagName 은 이 태그를 위한 수치 이름이나 식별자이며, 태깅되는 데이터의 유형을 식별하는 데 사용됩니다. 만약 이 정보를 가로채기 위해서 레이어를 구현한다면, 이 값은 식별되는 오브젝트를 설정하려고 시도하는 특정 정보를 가리키고 있을 것입니다. pTag 는 tagSize 바이트의 데이터에 대한 포인터인데, 이는 이 오브젝트와 연관됩니다.

Adding Labels

가끔 어떤 오브젝트가 문제가 되는지를 알아내는 것으로도 부족한 경우가 있습니다. 보통 프레임 전반에서 유사한 방식으로 오브젝트를 여러 번 손댈 수 있습니다. 이런 경우에, 여러분이 어떤 프레임에서 ( 혹은 심지어는 여러 프레임들에서 ) 문제가 발생했는지 좁힐 수 있다면 훌륭할 것입니다 -- 고속도로의 옆쪽에 거리 표지판( mile-marker )이 여러분이 어디쯤 왔는지 알 수 있게 해주는 방법과 비슷합니다.

VK_EXT_debug_utils 를 사용하면, VkQueue 나 VkCommandBuffer 에다가 레이블을 삽입할 수 있습니다. VK_EXT_debug_marker 익스텐션에 의해서 처음 노출된 "markers" 와 유사합니다 -- 그것은 VkCommandBuffer 오브젝트에만 마커들을 추가할 수 있다는 차이는 있습니다.

레이블을 VkQueue 나 VkCommandBuffer 에다가 추가하는 두 가지 방법이 존재합니다:

• 레이블 영역( region )을 시작하고 끝내기.
• 그냥 레이블 삽입하기.

어떻게 사용하는지 이해하기 위해서 빠르게 예제를 살펴 봅시다.

여러분이 인간형 모양을 그리고 있다고 합시다. 다음과 같은 방식으로 그릴 겁니다:

DrawFigure() { UpdateMatrix(); DrawUpperBody(); DrawLowerbody(); } DrawUpperBody() { UpdateMatrix(); DrawChest(); DrawHeadNeck(); DrawLeftArm(); DrawRightArm(); } DrawLowerBody() { UpdateMatrix(); DrawWaist(); DrawLeftLeg(); DrawRightLeg(); }

Validation 을 실행할 때, 여러분은 드로( draw )에서 에러를 발견했다고 합시다. 하지만 어떤 드로가 문제인지 좁힐 수 있을까요? 레이블을 사용하면, 다음과 같이 할 수 있습니다.

DrawFigure() { BeginLabel("Draw Figure"); UpdateMatrix(); DrawUpperBody(); DrawLowerbody(); EndLabel(); // "Draw Figure" } DrawUpperBody() { BeginLabel("Draw Upper Body"); UpdateMatrix(); DrawChest(); InsertLabel("Draw head and neck"); DrawHeadNeck(); InsertLabel("Draw left arm"); DrawLeftArm(); InsertLabel("Draw right arm"); DrawRightArm(); EndLabel(); // "Draw Upper Body" } DrawLowerBody() { BeginLabel("Draw Lower Body"); UpdateMatrix(); InsertLabel("Draw waist"); DrawWaist(); InsertLabel("Draw left leg"); DrawLeftLeg(); InsertLabel("Draw right leg"); DrawRightLeg(); EndLabel(); // "Draw Lower Body" }

begin/end 와 insert 는 모두 특정 영역을 쉽게 식별할 수 있도록 하는 방시긍로 사용되고 있습니다. 이제, 에러나 경고가 "DrawLeftLeg" 루틴을 실행하는 중에 발생했다면, 여러분은 어떤 드로를 타게팅해야 할지 알 수 있을 겁니다.

레이블들은 커맨드 버퍼나 큐 기저상에 삽입될 수도 있습니다. 레이블 영역을 큐에서 시작하기 위해서는 다음과 같은 커맨드를 사용하게 됩니다:

void vkQueueBeginDebugUtilsLabelEXT( VkQueue queue, const VkDebugUtilsLabelEXT* pLabelInfo);

이 커맨드는 다음 구조체를 받아들입니다:

typedef struct VkDebugUtilsLabelEXT { VkStructureType sType; const void* pNext; const char* pLabelName; float color[4]; } VkDebugUtilsLabelEXT;

이것은 "Creating ( and Desetroying ) a Debug Messenger" 에서 기술한 콜백에 반환되는 것과 같은 구조체입니다. color 는 레이어나 툴에서 레이블 이름을 위한 색상있는 텍스트를 생성하기 위해 사용될 수 있습니다. 만약 색상에 신경을 안 쓴다면, 툴이 색상을 사용하는 경우에는 이 파라미터의 각 값들을 "1.0" 으로 설정하십시오.

레이블링된 섹션을 종료하려면, 다음 함수를 호출합니다:

void vkQueueEndDebugUtilsLabelEXT( VkQueue queue);

그것은 레이블을 취하지 않는다는 것에 주의하십시오. 이런 방식으로, end 는 "pop" 커맨드와 유사하게 작동합니다. 단지 특정 VkQueue 상에서 VkQueueBeginDebugUtilsLabelEXT 커맨드를 사용해 생성된 마지막 레이블을 종료시킵니다.

전체 영역을 정의하는 대신에, 단일 레이블을 특정 위치에 삽입할 수도 있습니다. 다음을 사용합니다:

void vkQueueInsertDebugUtilsLabelEXT( VkQueue queue, const VkDebugUtilsLabelEXT* pLabelInfo);

만약 VkQueue 와 연관되는 레이블들을 정의했고 메시지가 발생했고 오브젝트 리스트에 특정 VkQueue 가 포함되어 있었다면, 콜백의 queueLabelCount 와 pQueueLables 데이터 필드가 적절한 칸텐츠와 함께 생성되어 있을 것입니다. 이 경우에, 그 데이터는 스택과 유사하게 저장될 것입니다. 그러므로 첫 번째 요소는 가장 최근의 레이블이며, 두 번째 요소는 가장 오래된 레이블입니다.

위에서 VkQueue 커맨드에 대해서 했던 것처럼 레이블을 커맨드를 사용해서 커맨드 버퍼에 삽입할 수 있습니다 :

void vkCmdBeginDebugUtilsLabelEXT( VkCommandBuffer commandBuffer, const VkDebugUtilsLabelEXT* pLabelInfo); void vkCmdEndDebugUtilsLabelEXT( VkCommandBuffer commandBuffer); void vkCmdInsertDebugUtilsLabelEXT( VkCommandBuffer commandBuffer, const VkDebugUtilsLabelEXT* pLabelInfo);

얼마나 유사한지 확인해 보세요. 실제 차이는 VkQueue 대신에 VkCommandBuffer 를 요구한다는 것 뿐입니다. VkQueue 레이블처럼, 만약 pObjects 리스트에 VkCommandBuffer 오브젝트가 포함되어 있는 상태로 Debug Utils Messenger 콜백이 호출되었다면, 그리고 그 버퍼들이 레이블을 포함하고 있다면, 그 레이블들은 cmdBufLabelCount 와 pCmdBufLabels 필드에 추가될 것입니다. 또한, 큐 칸텐트와 마찬가지로, 데이터는 스택과 유사하게 반환되며, 첫 번째 레이블은 가장 최근이며 마지막 레이블은 가장 오래된 것입니다. 드로에 대한 예제를 살펴 보죠. 만약 버그가 DrawLeftLeg() 루틴에서 발생했다면, 에러가 반환될 때, cmdBufLableCount 와 pCmdBufLables 의 값들은 다음과 같은 식으로 보일 것입니다:

cmdBufLabelCount = 3; pCmdBufLabels[0] = "Draw left leg"; pCmdBufLabels[1] = "Draw Lower Body"; pCmdBufLabels[2] = "Draw Figure";

커맨드 버퍼 레이블의 특별한 특성( attribute )은 그것들이 커맨드 버퍼 경계를 넘어서서 활성화/비활성화 될 수 있다는 것입니다. 예를 들어, 프라이머리 커맨드 버퍼에서 레이블을 시작해서 세컨더리 커맨드 버퍼에서 레이블을 종료할 수 있습니다. 혹은 세컨더리 커맨드 버퍼에서 레이블을 시작해서 완전히 다른 세컨더리 커맨드 버퍼에서 레이블을 종료할 수 있습니다. 주의할 점이 있다면, 커맨드 버퍼 종속성 체인을 validation 메시지가 발생할 때 알 수 없다는 것입니다. Therefore, for those kind of messages you can only count on the contents of the one command buffer. However, for tools like RenderDoc, the spanning of command buffers should function correctly.

Application Usage Examples

Setting Up a Debug Utils Messenger and Callback

다음 코드 정보는 Debug Utils Messenger 콜백을 설정하고 그것을 사용하는 메신저를 생성하는 것을 보여 줍니다. 또한 이것이 익스텐션이기 때문에 vkGetInstanceProcAddr 를 사용해 VK_EXT_debug_utils 를 위한 벌칸 커맨드를 질의할 필요가 있음을 보여 줍니다 :

PFN_vkCreateDebugUtilsMessengerEXT CreateDebugUtilsMessengerEXT; PFN_vkDestroyDebugUtilsMessengerEXT DestroyDebugUtilsMessengerEXT; VkDebugUtilsMessengerEXT dbg_messenger; VkInstance instance; // Define a callback to capture the messages VKAPI_ATTR VkBool32 VKAPI_CALL debug_messenger_callback( VkDebugUtilsMessageSeverityFlagBitsEXT messageSeverity, VkDebugUtilsMessageTypeFlagsEXT messageType, const VkDebugUtilsMessengerCallbackDataEXT* callbackData, void* userData ) { char prefix[ 64 ]; char *message = ( char * )malloc( strlen( callbackData->pMessage ) + 500 ); assert( message ); if( messageSeverity & VK_DEBUG_UTILS_MESSAGE_SEVERITY_VERBOSE_BIT_EXT ) { strcpy( prefix, "VERBOSE : " ); } else if( messageSeverity & VK_DEBUG_UTILS_MESSAGE_SEVERITY_INFO_BIT_EXT ) { strcpy( prefix, "INFO : " ); } else if( messageSeverity & VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT ) { strcpy( prefix, "WARNING : " ); } else if( messageSeverity & VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT ) { strcpy( prefix, "ERROR : " ); } if( messageType & VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT ) { strcat( prefix, "GENERAL" ); } else { if( messageType & VK_DEBUG_UTILS_MESSAGE_TYPE_SPECIFICATION_BIT_EXT ) { strcat( prefix, "SPEC" ); validation_error = 1; } if( messageType & VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT ) { if( messageType & VK_DEBUG_UTILS_MESSAGE_TYPE_SPECIFICATION_BIT_EXT ) { strcat( prefix, "|" ); } strcat( prefix, "PERF" ); } } sprintf( message, "%s - Message ID Number %d, Message ID String :\n%s", prefix, callbackData->messageIdNumber, callbackData->pMessageIdName, callbackData->pMessage ); if( callbackData->objectCount > 0 ) { char tmp_message[ 500 ]; sprintf( tmp_message, "\n Objects - %d\n", callbackData->objectCount ); strcat( message, tmp_message ); for( uint32_t object = 0; object < callbackData->objectCount; ++object ) { sprintf( tmp_message, " Object[%d] - Type %s, Value %p, Name \"%s\"\n", Object, DebugAnnotObjectToString( callbackData->pObjects[ object ].objectType ), ( void* )( callbackData->pObjects[ object ].objectHandle ), callbackData->pObjects[ object ].pObjectName ); strcat( message, tmp_message ); } } if( callbackData->cmdBufLabelCount > 0 ) { char tmp_message[ 500 ]; sprintf( tmp_message, "\n Command Buffer Labels - %d\n", callbackData->cmdBufLabelCount ); strcat( message, tmp_message ); for( uint32_t label = 0; label < callbackData->cmdBufLabelCount; ++label ) { sprintf( tmp_message, " Label[%d] - %s { %f, %f, %f, %f}\n", Label, callbackData->pCmdBufLabels[ label ].pLabelName, callbackData->pCmdBufLabels[ label ].color[ 0 ], callbackData->pCmdBufLabels[ label ].color[ 1 ], callbackData->pCmdBufLabels[ label ].color[ 2 ], callbackData->pCmdBufLabels[ label ].color[ 3 ] ); strcat( message, tmp_message ); } } printf( "%s\n", message ); fflush( stdout ); free( message ); // Don't bail out, but keep going. return false; } // Setup our pointers to the VK_EXT_debug_utils commands CreateDebugUtilsMessengerEXT = ( PFN_vkCreateDebugUtilsMessengerEXT )vkGetInstanceProcAddr( instance, "vkCreateDebugUtilsMessengerEXT" ); DestroyDebugUtilsMessengerEXT = ( PFN_vkDestroyDebugUtilsMessengerEXT )vkGetInstanceProcAddr( instance, "vkDestroyDebugUtilsMessengerEXT" ); // Create a Debug Utils Messenger that will trigger our callback for any warning // or error. VkDebugUtilsMessengerCreateInfoEXT dbg_messenger_create_info; dbg_messenger_create_info.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT; dbg_messenger_create_info.pNext = NULL; dbg_messenger_create_info.flags = 0; dbg_messenger_create_info.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT | VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT; dbg_messenger_create_info.messageType = VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT | VK_DEBUG_UTILS_MESSAGE_TYPE_SPECIFICATION_BIT_EXT | VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT; dbg_messenger_create_info.pfnUserCallback = debug_messenger_callback; dbg_messenger_create_info.pUserData = NULL; VkResult result = CreateDebugUtilsMessengerEXT( instance, &dbg_messenger_create_info, NULL, &dbg_messenger ); // Do all your stuff // Destroy the Debug Utils Messenger DestroyDebugUtilsMessengerEXT( instance, dbg_messenger, NULL );

Using Object Names and Command Buffer Labels

다음 코드 정보는 레이블과 이름있는 오브젝트를 정의하는 방법을 보여 줍니다:

PFN_vkCmdBeginDebugUtilsLabelEXT CmdBeginDebugUtilsLabelEXT; PFN_vkCmdEndDebugUtilsLabelEXT CmdEndDebugUtilsLabelEXT; PFN_vkCmdInsertDebugUtilsLabelEXT CmdInsertDebugUtilsLabelEXT; PFN_vkSetDebugUtilsObjectNameEXT SetDebugUtilsObjectNameEXT; VkInstance instance; VkDevice device; VkCommandBuffer cmd_buf; VkDebugUtilsLabelEXT label; // Setup the function pointers CmdBeginDebugUtilsLabelEXT = ( PFN_vkCmdBeginDebugUtilsLabelEXT )vkGetInstanceProcAddr( instance, "vkCmdBeginDebugUtilsLabelEXT" ); CmdEndDebugUtilsLabelEXT = ( PFN_vkCmdEndDebugUtilsLabelEXT )vkGetInstanceProcAddr( instance, "vkCmdEndDebugUtilsLabelEXT" ); CmdInsertDebugUtilsLabelEXT = ( PFN_vkCmdInsertDebugUtilsLabelEXT )vkGetInstanceProcAddr( instance, "vkCmdInsertDebugUtilsLabelEXT" ); SetDebugUtilsObjectNameEXT = ( PFN_vkSetDebugUtilsObjectNameEXT )vkGetInstanceProcAddr( instance, "vkSetDebugUtilsObjectNameEXT" ); // ... vkBeginCommandBuffer( cmd_buf, &cmd_buf_info ); // Set a name for the command buffer VkDebugUtilsObjectNameInfoEXT cmd_buf_name = { .sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT, .pNext = NULL, .objectType = VK_OBJECT_TYPE_COMMAND_BUFFER, .objectHandle = ( uint64_t )cmd_buf, .pObjectName = "CubeDrawCommandBuf", }; SetDebugUtilsObjectNameEXT( device, &cmd_buf_name ); // Begin a label section indicating we're in a draw. label.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT; label.pNext = NULL; label.pLabelName = "Inside Draw"; label.color = { 0.4f, 0.3f, 0.2f, 0.1f }; CmdBeginDebugUtilsLabelEXT( cmd_buf, &label ); // Do other stuff // Insert a single label label.pLabelName = "Temp Label"; label.color = { 1.0f, 1.0f, 1.0f, 1.0f }; CmdInsertDebugUtilsLabelEXT( cmd_buf, &label ); // End the label (this rolls back to any label before "Inside Draw") // since that is the last one that was created with CmdBeginDebugUtilsLabelEXT CmdEndDebugUtilsLabelEXT( cmd_buf );

Updates to the Cube Demo

( 역주 : 그냥 VK_EXT_debug_report 에서 VK_EXT_debug_utils 로의 마이그레이션 샘플이므로 번역을 생략함 )

Future Validation Layer Improvements

이 튜토리얼을 발행하는 시점에, validation 레이어들은 VK_EXT_debug_report 익스텐션 콜백과 VK_EXT_debug_utils 익스텐션 콜백에 대해 거의 같은 정보를 반환할 것입니다. The extensions differ in that the VK_EXT_debug_report extension will also automatically add in VkCommandBuffer and VkQueue labels to the callback results and separate out some of the information so that the returned messages don’t seem as cluttered. 앞으로, 우리는 그런 에러 메시지들에 도움이 된다고 생각하는 부가적인 오브젝트 정보들을 추가할 계획입니다. validation 에러 메시지들이 부가적인 오브젝트 정보를 더 받아야 한다고 느낀다면, GitHub Issue 에 제출해 주십시오. 어떠한 메시지에 어떤 오브젝트 정보를 추가하기를 원하는지 명확하게 언급해 주세요. GitHub Pull Request 를 제공해 주실 수도 있습니다.

Conclusion

여러분도 보셨듯이, VK_EXT_debug_utils 익스텐션은 validation 레이어에 매우 많이 필요한 디버그 정보를 가지고 옵니다. 우리는 Vk_EXT_debug_utils 익스텐션을 Vulkan 1.1 을 이용할 수 있는 로더들에서부터 지원하기 시작했습니다. You don’t need to use Vulkan 1.1 to expose the extension functionality as the release of this extension and Vulkan 1.1 just happen to be timed together. 만약 이 익스텐션을 어떤 식으로든 사용하고자 한다면, 그냥 LunarG's Vulkan 1.1 SDK 를 시스템에 다운로드하시면 됩니다. VK_EXT_debug_utils 익스텐션을 찾아 봤으면 하는 바램입니다. 그것은 사용하기 편하고 유용하기 때문입니다.

Acknowlegements

이 아티클을 완료할 수 있도록 도움을 준 LunarG 의 Erika Johnson, Mark Lobodzinski, Mike Schuchardt 에게 감사드리고 싶습니다. 그리고 다시 한 번 검토해준 NVIDIA 의 Piers Daniel 에게도 감사드립니다.

주의 : 답이 틀릴 수도 있습니다. 그냥 정리하는 용도로 올립니다. 혹시라도 도움이 필요한 분이 있다면 도움이 되었으면 좋겠네요.

경고 : 숙제하려고 베끼는 데 사용하지 마십시오. 본인의 미래를 망칠 뿐입니다. 나중에 저를 원망하지 마세요.

부탁 : 문제 풀이가 잘못되었으면 지적해 주셨으면 좋겠습니다.

결국 지구와 같은 중력을 느끼기 위한 정거장의 분당 회전수를 구하라는 것입니다.

[ 연습문제 5-5 ] 에 의해서 등속원운동하는 물체의 속도와 구심 가속도의 크기는 다음과 같습니다. r 은 반지름, ω 는 각속도, T 는 주기입니다.

식 1.

중력 가속도와 구심 가속도는 같은 개념입니다. 그러므로 그러므로 중력 가속도는 다음과 같습니다.

식 2.

1 회전에 T 분 걸리기 때문에, 1/T 는 분당 회전수가 됩니다.

식 3.

해답은 1.36 [번/분] 이기는 하지만 대충 값이 비슷하므로 정답으로 취급하겠습니다.

주의 : 초심자 튜토리얼은 아닙니다. 그러므로, 실제 API 호출 용례를 알고자 한다면, 샘플이나 튜토리얼을 찾아서 확인해 보세요.

주의 : 완전히 이해하고 작성한 글이 아니므로 잘못된 내용이 포함되어 있을 수 있습니다.

주의 : 이상하면 참고자료를 확인하세요.

Interface Block

일단 HLSL 의 경우에는 일반 구조체를 사용해서 각 셰이더 스테이지( Shader Stage )의 입력과 출력을 정의할 수 있도록 하고 있습니다. 버텍스( Vertex ) 셰이더의 예를 하나 살펴 보죠.

// vertex input. struct VertexInput { float4 Position : POSITION0; float4 TexCoord : TEXCOORD0; float4 Normal : NORMAL0; float4 Tangent : TANGENT0; float4 Bitangent : BINORMAL0; float4 Color : COLOR0; }; // vertex output. struct VertexOutput { float4 Position : SV_Position; float4 TexCoord : TEXCOORD0; float4 Normal : TEXCOORD1; float4 Tangent : TEXCOORD2; float4 Bitangent : TEXCOORD3; float4 Color : TEXCOORD4; }; // constant buffer for global shader. cbuffer GlobalBuffer { float4x4 WorldViewProjectionMatrix; }; // common vertex shader. VertexOutput CommonVertexShader( VertexInput input ) { VertexOutput output = ( VertexOutput )0; output.Position = mul( WorldViewProjectionMatrix, float4( input.Position.xyz, 1.0 ) ); output.TexCoord = input.TexCoord; output.Normal = input.Normal; output.Tangent = input.Tangent; output.Bitangent = input.Bitangent; output.Color = input.Color; return output; }

VertexInput 과 VertexOutput 이라는 struct 와 GlobalBuffer 라는 cbuffer 가 정의되어 있습니다. 그리고 CommonVertexShader() 함수에서는 VertexInput 을 입력으로 받아 VertexOutput 을 산출합니다.

그리고 VertexInput 과 VertexOutput 의 각 필드)에는 시맨틱( Semantic ) 이 지정되어 있습니다. 언어에서 신택스( Syntax )는 우리말로는 "문법" 으로 표현될 수 있으며, 언어의 문법이 옳은지 판단할 때 사용될 수 있습니다. 시맨틱은 "의미" 로 표현될 수 있으며, 말 그대로 의미상 옳은 지를 판단할 때 사용될 수 있습니다. 시맨틱을 사용하는 것의 장점이라면, 변수 이름이 아니라 시맨틱으로 그 변수의 의미를 특정할 수 있다는 것입니다.

OpenGL 이나 Vulkan 같은 경우에는 셰이더의 입력이나 출력을 인터페이스( Interface )라 정의하고 있습니다. 두 개의 스테이지를 각각 노드라 생각하고 데이터가 인터페이스를 통해서 왔다갔다 한다고 생각하면 무리가 없는 설정인 것 같습니다.

그런데 그 인터페이스에 매우 많은 데이터가 왔다갔다 하면 관리하기가 힘드니까 그것을 인터페이스 블록( Block )이라는 것으로 묶을 수 있도록 하고 있습니다[ 3 ][ 4 ]. 

인터페이스 블록의 구문은 구조체를 선언하는 것과 유사합니다.

storage_qualifier 로는 uniform, in, out, buffer 등이 있습니다. 

• uniform : global shader variable.

• in : OpenGL 3.2 이상에서 지원되는 shader input.

• out : OpenGL 3.2 이상에서 지원되는 shader output.

• buffer : ARB_shader_storage_buffer_object 에 의해 지원되는 storage_buffer.

몇 개의 예를 [ 3 ] 에서 가져 와 보겠습니다.

// Vertex Shader out VertexData { vec3 color; vec2 texCoord; } outData; // Geometry Shader in VertexData { vec3 color; vec2 texCoord; } inData[]; // uniform buffer. uniform MatrixBlock { mat4 projection; mat4 modelview; };

Layout Qualifiers

그런데 storage_qualifier 들 중에서는 OpenGL 3.2 이상에서만 블록 형태로 지원되는 것들이 존재하기 때문에, 3.1 까지는 그냥 변수를 사용해서 입출력 데이터를 표현해야 했습니다. 이것 때문에 layout qualifier 라는 것이 필요했죠.

여러 개의 변수들을 만들어 놓은 다음에 그것에 순서와 특성을 부여합니다. layout 으로 묶여 있는 괄호 안 쪽에 한정자( qualifier )들을 삽입합니다.

이 한정자의 종류는 다음과 같습니다. 물론 더 많은 한정자들이 있기는 하지만, Vulkan Spec 에서 언급한 한정자들만 나열했습니다.

• location : 애트리뷰트( attribute ) 바인딩 순서를 지정합니다.

• component : 애트리뷰트의 컴포넌트 개수를 지정합니다.

다음과 같은 식이죠. 

layout(location = 0) in vec4 position; layout(location = 1) in vec2 texCoord; layout(location = 2) in vec3 normal;

이렇게 되어 있으면 프로그램에서 position, texCoord, normal 이 들어 있는 구조체를 한 번에 glBindVertexArray() 로 지정했을 때 하나의 버텍스 내부에서 순차적으로 위치가 지정된 것처럼 동작하게 됩니다. location 이 하나 증가하면 float 4 개만큼의 메모리 offset 을 가진다고 보면 됩니다. HLSL 로 치자면 layout 은 레지스터 인덱스라고 생각해도 무방할 것 같습니다.

그러므로 다음과 같이 배열을 가지고 있는 경우에는 일반적으로는 float 4 배열 요소 개수나 구조체의 크기만큼 증가하게 됩니다.

struct OutData { vec3 data1; dvec4 data2; float val[3]; }; layout(location = 0) out vec3 vals[4]; // Consumes 4 locations layout(location = 4) out OutData myOut; // Consumes 6 locations. dvec4 uses 2, and `val[3]` uses 3 total layout(location = 10) out vec2 texCoord; // Consumes 1 location

그런데 가끔 float 4 크기보다는 작은 변수들을 하나의 레지스터로 묶고 싶을 때까 있습니다. HLSL 로 치자면 packoffset 과 유사한 개념이겠네요. 이 때 component 라는 한정자를 사용하게 됩니다. 이 컴포넌트 한정자를 지정하지 않으면 기본값은 0 이라고 합니다. 그런데 component qualifier 는 OpenGL 3.2 부터 ARB_explicit_attrib_location 을 통해서 버텍스 셰이더와 프래그먼트( fragment ) 셰이더에서만 지원하는 개념입니다.

아래의 몇 가지 예가 있습니다.

layout(location = 0) out vec2 arr1[5]; layout(location = 0, component = 2) out vec2 arr2[4]; //Different sizes are fine. layout(location = 4, component = 2) out float val; //A non-array takes the last two fields from location 4.

어쨌든 매우 불편한 개념인데요, HLSL 을 사용하면 딱히 신경쓰실 필요는 없습니다. 왜냐하면 HLSL 은 이미 인터페이스 블록같은 개념을 구조체를 통해 지원하고 있을 뿐더러 DXC 로 컴파일하게 되면 레이아웃을 자동으로 지정해 주기 때문입니다. 게다가 DXC 에 실행인자로 "-fspv-reflect" 를 지정하면 시맨틱으로 애트리뷰트를 획득하는 것도 가능합니다.

제일 위쪽에 있는 HLSL 코드 중에 VertexInput 을 리플렉션( reflection )하는 소스 코드를 한 번 살펴 보겠습니다.

uint32_t numVariables = 0; SpvReflectResult spvResult = spvReflectEnumerateInputVariables( spvModule, &numVariables, nullptr ); if( SPV_REFLECT_RESULT_SUCCESS != spvResult ) { output = StringHelpers::Printf( "ReflectInputVariables() : Failed to call spvReflectEnumerateInputVariables() : %s.", SpvReflectResultStrings[ ( int )spvResult ] ); return false; } else { if( 0 == numVariables ) { output = "ReflectInputVariables() : There is no input variables."; return false; } } SpvReflectInterfaceVariable** spvVariables = new SpvReflectInterfaceVariable*[ numVariables ]; spvResult = spvReflectEnumerateInputVariables( spvModule, &numVariables, spvVariables ); if( SPV_REFLECT_RESULT_SUCCESS != spvResult ) { output = StringHelpers::Printf( "ReflectInputVariables() : Failed to call spvReflectEnumerateInputVariables() : %s.", SpvReflectResultStrings[ ( int )spvResult ] ); return false; } uint32_t offset = 0; for( uint32_t i = 0; i < numVariables; ++i ) { SpvReflectInterfaceVariable* spvVariable = spvVariables[ i ]; if( nullptr == spvVariable->semantic ) { output = "ReflectInputVariables() : All input variables must have semantic."; return false; } VkVertexInputAttributeDescription vkAttrDesc; vkAttrDesc.binding = 0; vkAttrDesc.format = ( VkFormat )spvVariable->format; vkAttrDesc.location = spvVariable->location; vkAttrDesc.offset = offset; _VertexInputAttributeDescriptionMap[ AnsiString( spvVariable->semantic ) ] = vkAttrDesc; offset += FormatElementSize( vkAttrDesc.format ); }

그러면 다음과 같은 결과를 얻을 수 있습니다. 저같은 경우에는 사용하기 편하게 일부러 VkVertexInputAttributeDescription 맵의 형태로 만들었습니다. 소스코드를 보면 대부분의 내용은 이해하실 수 있을 것 같네요.

그림 1.

그림 1 의 디버깅 정보에는 "TANGENT0" 시맨틱에 대한 정보가 나와 있습니다.

DXC layout

이 HLSL 에서 이 레이아웃을 강제로 지정하는 방법도 있는데요, [ 4 ] 에서는 [[vk::location(x)]] 애트리뷰트를 사용하도록 하고 있습니다. 실제로 순서를 맘대로 바꿔 보도록 하겠습니다.

// vertex input. struct VertexInput { [[vk::location(0)]] float4 Position : POSITION0; [[vk::location(3)]] float4 TexCoord : TEXCOORD0; [[vk::location(1)]] float4 Normal : NORMAL0; [[vk::location(5)]] float4 Tangent : TANGENT0; [[vk::location(2)]] float4 Bitangent : BINORMAL0; [[vk::location(4)]] float4 Color : COLOR0; };

그런데 vk 애트리뷰트를 사용해서 레이아웃을 결정하신다면 DXC 의 실행 인자로 "-fvk-use-dx-layout" 를 지정하시는 것을 잊으시면 안 됩니다. 안 그러면 에러가 발생합니다.

어쨌든 DXC 를 실행하면 다음과 같이 "TANGENT0" 시맨틱의 location 이 5 번으로 변경되어 있는 것을 확인하실 수 있습니다.

그림 2.

그런데, 그림 2 를 자세히 보신 분들은 알아 차렸겠지만, offset 이 변하지 않았습니다. 이것은 변수 순서가 변경되지 않았기 때문에 발생하는 문제( ? )입니다.

그러므로 이런 경우에는 offset 을 구할 때 location 순서대로 정렬한 다음에 구하는 것이 좋습니다. 물론 offset 은 구조체 내의 메모리 위치이고 location 은 GPU 레지스터에서의 인덱스와 같은 것이기 때문에 굳이 offset 을 순서와 맞출 필요는 없습니다. 하지만 헷갈릴 우려가 있고 이게 성능에 어떤 영향을 미치는 지는 잘 모르겠습니다. 그러므로 순서를 맞추는 것이 좋을 것 같습니다.

결론

Spirv-Reflect 에 대해서 분석하다가 보니, 굳이 레이아웃에 대한 분석을 하기는 했지만, 일반적으로는 아무것도 하지 말고 그냥 순서대로 레이아웃이 결정되도록 놔두는 것이 좋다는 생각이 듭니다.

참고자료

[ 1 ] Vulkan 1.1.122 Specification. Khronos Group.

[ 2 ] Layout Qualifier (GLSL), OpenGL Wiki. https://www.khronos.org/opengl/wiki/Layout_Qualifier_(GLSL).

[ 3 ] Interface Block (GLSL). https://www.khronos.org/opengl/wiki/Interface_Block_(GLSL).

[ 4 ] HLSL to SPIR-V Feature Mapping Manual. https://github.com/microsoft/DirectXShaderCompiler/blob/master/docs/SPIR-V.rst.

주의 : 답이 틀릴 수도 있습니다. 그냥 정리하는 용도로 올립니다. 혹시라도 도움이 필요한 분이 있다면 도움이 되었으면 좋겠네요.

주의 : 특별한 경우가 아니라면, 귀찮아서 문제는 안 옮깁니다.

경고 : 숙제하려고 베끼는 데 사용하지 마십시오. 본인의 미래를 망칠 뿐입니다. 나중에 저를 원망하지 마세요.

부탁 : 문제 풀이가 잘못되었으면 지적해 주셨으면 좋겠습니다.

문제에서는 "위성의 빠르기와 주기 사이에 T² ∝ r³  관계가 있음을 보여라" 인데 문제가 약간 이상합니다. 아마도 주기와 반지름의 관계겠죠. 

일단 익히 알고 있는 식으로부터 시작하겠습니다. 위성의 가속도 a 는 다음과 같습니다. 여기에서 r 을 벡터로 표기하고 있는데요, 이건 지구 중심으로부터 위성까지의 벡터입니다.

식 1.

중력 F ( 중력가속도가 아니라 중력입니다 )는 다음과 같이 정의됩니다. G 는 중력상수, M 은 지구의 질량, m 은 위성의 질량입니다.

식 2.

이 경우에 위성의 가속도를 a 라했을 때 다음과 같은 관계가 성립합니다.

식 3.

식 1 에서 위성의 가속도를 알고 있기 때문에 식 3 에 대입하면 다음과 같습니다.

식 4.

식 4 를 정리하면 다음과 같습니다.

식 5.

식 5 를 통해 반지름의 세제곱은 주기의 제곱과 비례관계에 있음을 알 수 있습니다.

그런데 실제 케플러 3 법칙을 검색해 보니 비례식의 결론은 유사한데, 정확한 식이 다르게 나오는군요. 아마도 장축과 단축을 고려하지 않은 데서 차이가 발생하지 않나 싶네요...