[분석정보] GDC 2014 OpenGL 드라이버 오버헤드는 맨틀과 싸울 수준

Tom Olson 씨 (Director of Graphics Research, ARM)

"Game Developers Conference 2014"에 맞춰 개방형 그래픽 API "OpenGL "또는"OpenGL ES"등을 책정하는 업계 단체로 있는 Khronos Group (크로노스 그룹, 이하 Khronos)이 보도 관계자 전용 설명회를 개최하고 OpenGL ES의 최신 버전인 "OpenGL ES 3.1"을 발표했다.

 그 개요는 3월 18일 기사에 게재했지만, 여기에서는 설명회에서 공개된 OpenGL ES 3.1의 요점과 AMD의 "Mantle" 등장으로 주목 받게된 드라이버 오버 헤드가 OpenGL에서 어떻게 되어 있는지 등 화제를 리포트하고 싶다.
　OpenGL ES 3.1의 설명을 담당한 것은 ARM 에서 그래픽 연구 부문의 이사인 Tom Olson (톰 올슨) 씨 이다.


OpenGL ES 3.1은 기존의 OpenGL ES 3.0 대응 하드에서 동작

　OpenGL ES 3.1에서 Khronos는 OpenGL 4.x 계의 기능에서 개발자들의 요청이 가장 많았던 기능을 픽업해 채용했다고 한다. 그 중에서도 특히 뜨거운 주제는 " Compute Shader" 와 "Draw-Indirect"(Indirect draw commands)의 도입이다.

OpenGL ES 3.1의 핫 토픽은 Compute Shader와 Draw-Indirect의 도입

 우선 Compute Shader 도입의 의의를 설명하자. 지금까지 OpenGL ES는 GPGPU를 취급하는 솔루션이 없어, OpenCL을 활용하는 수밖에 없었다. 본가 OpenGL도 "OpenGL 4.2" 까지 같은 상황이었지만, 개발자의 요청을 받아 "OpenGL 4.3" 에서 Compute Shader를 도입했다. 이 부분의 경위는 SIGGRAPH 2012의 보고 기사로 소개했는데, OpenGL ES 3.1의 Compute Shader의 채용도 같은 맥락 위에 있는 것이라 이해하면 좋을 것이다.

 "GPGPU 용 API 에는 OpenCL이 있는데, 왜 개발자는 Compute Shader를 요구하는가?"라고 말하면, 그래픽 렌더링용으로 GPGPU를 활용한다면, OpenCL 보다 OpenGL 틀안에 Compute Shader를 사용하는 편이 형편이 좋기 때문이다.  독립된 영상 처리 및 필터링 처리를 한다면, OpenCL도 좋을 것이다. 그러나 불필요한 광원을 제거하는 "라이트 컬링 "(Light Culling) 같은 렌더링 지원 처리, 렌더링 결과에 모션 블러와 같은 포스트 이펙트를 적용하는 경우 동일한 그래픽 파이프 라인에서 처리 할 수있는 Compute Shader 쪽이 번잡하지 않아 형편이 좋다.

 이 위에 1개의 팟픽스로 있는 Draw-Indirect는 메모리상에 둔 지오메트리 데이터 등을 CPU를 거치지 않고 GPU 측에서 취득해 렌더링에 돌릴 수 있는 구조이다. 원래 OpenGL ARB (Architecture Review Board)가 책정한 ARB 확장 사양에 있어 OpenGL 3.1에 도입 된 것이 OpenGL ES로 온 것이다. Compute Shader는 그래픽 메모리에 임의의 데이터, 예를들면 원시적인 (= 폴리곤)을 비롯한 지오메트리 데이터를 써낼수 있다. 즉, Compute Shader와 Draw-Indirect을 조합하면 묘화할 3D 그래픽 데이터의 준비에서 묘화까지 GPU 측에서 수행 할 수 있게 되는 것이다.

 "생성된 파티클이나 시뮬레이션한 결과를 그래픽 데이터로 변환하고 그것을 바탕으로 묘화를 행한다"라는 것이 GPU 내에서 완결 하게 된다. CPU의 도움은 불필요 하기에 응용 프로그램의 CPU 부하를 줄이고, CPU와 비동기이며 병렬 그래픽 묘화를 할 수 있게 된다. 이것은 성능의 향상뿐만 아니라 모바일 기기에 있어서 가장 중요한 과제인 소비 전력 절감 효율화에도 유효한 것이다. 여기에, OpenGL ES 3.1은 기본적으로 OpenGL ES 3.0 세대의 하드웨어에서 그대로 동작한다. 새로운 기능은 모두 드라이버 수준에서 실현할 수 있다는 것이다. 또, "OpenGL 4.4"에서 OpenGL ES 3.1 기반 응용 프로그램을 움직이기 위한 수단도 조만간 제공될 것이다.

OpenGL에서 OpenGL ES의 흐름뿐만 아니라 OpenGL ES 3.1으로 만든

응용 프로그램을 OpenGL 4.4 로 움직이는 수단도 향후 제공된다

"최신 OpenGL은 Mantle 수준으로 오버 헤드가 적다"

Neil Trevett 씨 (Vice President Mobile Ecosystem : NVIDIA, President, Khronos)

　자, 여기까지의 화제는 속보와 같지만, 설명회에서는 지금 유명해진 AMD의 " Mantle "과 같은 "낮은 오버 헤드의 그래픽 API"를 밟아간다. OpenGL의 설계 및 실행 기능에 대한 설명도 행했다. 이 화제를 담당한 것은 Khronos의 대표도 맡는 NVIDIA의 Neil Trevett  씨다. 여기서 드라이버의 오버 헤드는 GPU를 구동하기 까지의 전 단계로, 주로 CPU 측에서 실행되는 프로그램 부분에서 발생하는 시간적인 손실을 가리킨다.

 GPU를 구동하기 위한 커맨드나 파라메터를 준비하고 드라이버에 넘겨 처리가 필요하지만, 이것은 기본적으로 순차적인 동작이므로 필연적으로 싱글 스레드로 실행된다. 멀티 코어 CPU 환경에서도 GPU를 구동하기 위해 동작하는 CPU는 통상 1 코어 뿐이므로, 이것으로는 효율성을 올리지 못하고 오버 헤드가 생겨 버린다.

 한쪽의 GPU 측도 커맨드나 파라메터가 갖추어지지 않으면 처리를 시작할 수 없기에 이것들이 드라이버로 부터 주어지는 것을 기다리지 않으면 안된다. 이것도 오버 헤드를 생기게 하는 원인이 된다. 그점 OpenGL은 어떻게 되는 것인가? Trevett 씨는 " OpenGL은 기초 설계가 낡고 느리다"고 말해지지만, OpenGL 3.x 이후는 DirectX보다 현대적인 아키텍처로 되어 있기 때문에 큰 변경을 필요로 하지 않는다 "고 주장한다.

드라이버의 오버 헤드는 다양한 요인으로 발생하지만,

현재의 OpenGL에서는 이것을 제로에 가깝게 된다는 Trevett 씨

　프로그래머블 셰이더에 처음으로 대응한 OpenGL 2.x 시대는 고정 파이프 라인 기반의 설계로 오버 헤드가 생기기 쉬운 구조로 되어 있었다. 그러나 Trevett 씨는 "OpenGL 2.x 이전 API로 제작된 애플리케이션은 오버 헤드가 컸지만, OpenGL 3.x 이상을 잘 활용하면 CPU와 GPU가 병렬로 동작 할 수 있게 된다"고 말한다. 오버 헤드를 줄여 하드웨어 성능을 끌어내기 쉽게 개량을 거듭하고 있다는 것이다.

위는 "OpenGL에 대해 흔하게 있는 오해" 이들은 과거의 인상에 끌려간 것이며,

앞의 문제는 최신 OpenGL 에서 해결되어 있다고 한다.

　OpenGL 3.x 이후는 클래식한 아키텍처를 고쳐 커맨드나 파라매터를 기술하는 버퍼 자체를 API를 통하지 않고 GPU에 직접 전송할 수 있는 구조가 구현 되었다. 이것에 의해 CPU 측이 멀티 쓰레드로 커맨드나 파라미터를 정리한 버퍼를 형성하는 버퍼를 계속 GPU로 전송할 수 있게 된다. GPU 측은 CPU의 사정을 신경 쓰지 않고 전송된 버퍼를 사용하여 비동기로 묘화를 실행 할 수 있게 된 것이다. 호환성을 유지를 위해 고정 파이프 라인 기능은 남아 있지만, OpenGL 3.x 이상을 사용한다면 오버 헤드는 이미 충분히 작아져 있다. 이것이 Khronos의 입장이다.

위의 슬라이드는 과거 OpenGL 에서의 처리 흐름을 보여준 것. CPU가 명령을 쌓아서 GPU를 구동 시킨는 DirectX 적인 아키텍처였다.아래의 슬라이드는 최신의 OpenGL에서의 처리 흐름으로 CPU와 GPU가 병렬로 동작할 수 있는 아키텍처가 채용되고 있다

 또한 Trevett 씨는 "Draw-Indirect을 활용하면" GPU 자체가 GPU를 구동해 "동작을 효과적으로 프로그램 할 수 있다" 고 말했고, 응용 프로그램이 하드웨어의 성능을 더욱 끌어낼수 있도록 OpenGL ES 측에서도 진화가 계속되고 있는 것을 어필했다.

과거 OpenGL 기반 프로그램도 최신의 OpenGL 기반으로 고쳐쓰면

5 ~ 15 배의 속도 업을 기대할 수 있다고 Trevett 씨는 호소했다

　무엇보다 모바일 장치용으로 진화한 OpenGL ES는 어찌됐든, PC에서 실행하는 OpenGL의 경우 과거의 소프트웨어 자산을 간단하게 잘를수 없는 사정도 있다. 어쩌면 Khronos는 "소형 경량의 스마트한 OpenGL"을 실현하는 것은 OpenGL 대신 OpenGL ES의 쪽 이라고 생각하고, 그쪽을 앞으로 키워 가려고 생각하고 있는지도 모른다. Trevett 씨의 강연을 들은 필자는 그렇게 느끼고 있다.

2014년 3월 21일 기사 입니다.

[분석정보] AMD 독자 그래픽스 API Mantle

[분석정보] GDC 2014 미국 MS DirectX 12를 발표

[분석정보] GPU의 진화에 대응한 Microsoft의 차세대 API DirectX 12의 배경

[분석정보] 그래픽 및 DirectX 로드맵을 정리

[분석정보] GDC 2016 Unreal Engine 4를 통합형 그래픽 기능으로 움직이다