※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.
CPU 부하가 낮은 새 3D API
(원문 : CPU 負荷が低い 新しい 3D API)
작년 AMD Mantle을 시작으로 DirectX 12가 발표되고, 얼마전에는 Apple로부터 Metal도 등장했습니다. DirectX 11 이후 정체 혹은 안정되어 있던 상태가 일변, 새로운 GPU용 API로의 흐름이 가속되고 있습니다. 모두가 DirectX11, OpenGL과는 호환성이 없는 새로운 API 집합입니다.
지금까지와 느낌이 크게 다른 건 CPU를 위한 쇄신이라는 점입니다. 새로운 묘화기능에 대한 대응은 없고 딱히 GPU의 하드웨어 성능 추가를 목적으로 한 것도 아닙니다. 목적은 CPU 부하의 경감입니다.
API Platform Beta SDK GPUs ------------------------------------------------------------- Mantle Windows 2014/5 RADEON GCN Direct3D 12 Windows ? GCN,Fermi,Kepler,Maxwell Metal iOS 8 2014/6 PowerVR G6430
그만큼 높아진 CPU의 부하가 문제가 되고 있다는 말이 되겠습니다.
지금까지는 공통 API의 호환성을 댓가로 두터운 드라이버 레이어가 존재했고, 성능이 향상됨에 따라 CPU가 전송하는 커맨드의 규모도 커졌습니다. Multi Core CPU의 사용이 일반화되었음에도 불구하고, 구태의연한 OpenGL은 스레드를 통한 최적화를 가로막고 있었습니다.
드라이버의 오버헤드는 게임 전용기(Game Console)과 범용기 PC/Smartphone의 큰 차이 중 하나입니다.
간단하게
고정기능은 단계적으로 줄어들어, 3D 묘화에 필요한 알고리즘의 대부분이 애플리케이션 측의 소프트웨어로 구현되게 되었습니다. 범용화가 진행되고 GPU의 용도가 넓어지면서, 기존의 고도의 기능이나 드라이버의 두터운 보호가 오히려 프로그래밍의 자유도를 막기도 합니다.
원래 GPU는 진화속도가 빨라, 기능도 성능도 사용방법도 단기간에 변화해왔습니다. Desktop에서 Mobile로 바뀌어도 마찬가지입니다. 하이레벨에서 통합된 API로는 큰 변화에 따라가기가 힘듭니다. 뭐든지 해주는 명령은 편리하지만, 사양을 정하기 위해서는 어느 정도 쓰임새가 결정되어야 하기 때문입니다. 변경이 빈번해질수록 설계는 보다 심플해지고, 의존을 줄이는 방향으로 진행됩니다.
Direct3D 10에서는 Shader의 통합과 리소스의 Buffer화 같은 개혁이 이루어졌습니다. 실제로 사용해보면 리소스 관리는 생각했던 것처럼 간단하지 않다는 것을 알게 됩니다. Resource View에는 자잘한 플래그 설정이 필요하고, 익숙해질때까지는 조합의 제한으로 고민했습니다. 정말로 자유롭다고 느낀 것은 Direct3D 11의 ComputeShader부터입니다. 용도도 데이터의 사용도 모두 프로그래머가 정할 수 있습니다.
Texture Atlas는 복수의 텍스처를 거대한 텍스처에 통합합니다. 안쪽 배치는 프로그래머가 스스로 관리해야 합니다만, 그 대신 셰이더는 uv만으로 필요한 텍스처를 읽어들일 수 있습니다. 만약 GPU의 메모리 전부를 거대한 한장의 텍스처로 볼 수 있다면 uv는 포인터와 거의 같다고 볼 수 있겠습니다. 현재 리소스 관리는 프로그래머에게 개방되어 있지 않지만, Texture Atlas는 그 제한을 넘기 위한 수법의 하나로 볼 수 있습니다.
OpenGL의 Shader 명령은 DirectX보다도 상당히 나중에 디자인된지라, Uniform의 배치나 셰이더 사이의 바인드도 자동화되어 있습니다. OpenGL 3.x 이후는 메모리 배치를 프로그래머가 정할 수 있게 되었고, 4.x 이후는 심볼의 바인드도 단순한 번호지정으로 바뀌었습니다. Direct3D의 로우레벨 명령에 가까워지고 있습니다.
GPU는 범용성을 늘리고 있습니다만, 호환성 유지를 위한 래핑은 필요 이상으로 복잡해진 감이 있습니다. 새로운 API에서는 CPU 부하의 저감과 동시에 보다 간단하고 쓰기 쉬운 API로의 복귀도 기대할 수 있습니다.
Command Buffer
묘화시에 CPU가 처리하는 것은 Command Buffer의 구축입니다. 말하자면 GPU(Command Processor)가 실행하는 프로그램 그 자체로, 애플리케이션은 프레임마다 동적으로 프로그램을 생성하는 것이라 할 수 있습니다.
드라이버는 GPU의 성능을 최대한 뽑아내게 만들어져있어, 쓸데없는 Command를 생략하는 등의 최적화 처리를 합니다. 하드웨어별로 구조가 다르므로, GPU Native한 형식으로 변환하는 작업도 필요합니다. GPU Command의 생성과 발행은 나름대로 비용이 들어가는 일입니다.
상태값은 Draw 타이밍에 필요하므로, Command의 생성은 묘화명령까지 지연됩니다. Draw 명령에 부하가 집중되어보이는 것은 그 때문입니다.
각종 Buffer화는 Command 부하경감수단의 하나입니다. 파이프라인 상태라면 묘화할때마다 Command Buffer에 쓰여지지만, Buffer에서는 미리 전송시켜둔 리소스를 어사인하는 것만으로 끝나기 때문입니다.
게임 전용기(Console)
게임 전용기는 PC와 사정이 크게 다릅니다.
- 호환성의 족쇄가 없음
- 하드웨어 호환성이 불필요(단일 하드)
- 소프트웨어 호환성을 가지지 않음(SDK의 상위호환성을 가지지 않음)
- 필요에 따라 더 로우레벨의 최적화수단이 준비됨
- 하드 내부의 정보가 어느 정도 공개되어 있음
게임 전용기는 수년 사이클로 리프레시되고, 호환성 확보에는 전용 하드웨어 또는 소프트웨어 에뮬레이션이 이용됩니다. 그렇기에 소프트웨어(SDK) 호환성은 그다지 중요하지 않습니다.
처음부터 GPU Native한 형식을 사용할 수 있는 경우도 있고, CPU의 오버헤드도 PC와 비교하면 상당히 낮습니다.
필요에 따라 보다 로우레벨의 최적화가 가능한 것도 전용기의 특징입니다.
최근에는 그런 경우가 적어진 듯 하지만, 예를 들자면 GPU Command를 직접 조작할수 있는 경우 사전에 모델 데이터를 GPU Native한 Command 형식으로 변환해둘 수 있습니다. 메모리에 Buffer Data와 Command Buffer를 로드하는 것 만으로 묘화가 가능해집니다. 동적인 Command 생성과 비교하여 CPU 부하는 거의 생기지 않습니다. (다만 몇가지 트레이드 오프가 발생하므로 항상 최선의 방법이라고는 할 수 없음)
하드의 내부구조가 어느 정도 공개되어 있다는 점도 프로그래머의 부담을 줄여줍니다. 묘화 알고리즘의 설계시에 내부의 구조를 알고 있으면 어떤 방법이 효율이 좋은지 어느 정도 판단할 수 있어, 고민할 필요가 줄어듭니다.
호환성과 앞으로의 전망
- 게임 전용기와의 차이가 적어진다
- API의 분열
새 API는 현재의 CPU/GPU 성능과 사용법에 맞춰 재설계되었습니다. 전체적인 동작효율이 올라가고, CPU 오버헤드가 경감되는 등 퍼포먼스 특성이 보다 게임 전용기에 가까워져갈 것입니다. 그 반면, 현재는 플랫폼별로 사양이 분단되어 있어, 호환성이라는 새로운 과제가 남겨집니다.
OpenGL ES 2.0는 모바일에서 브라우저까지 플랫폼의 벽을 넘어 이용되고 있고, 통일된 API로서 큰 의미를 갖고 있습니다. 마찬가지로 앞으로도 OpenGL ES 3.0/3.1이 널리 이용될것인가하면 반드시 그럴 것 같지도 않습니다. 특히 iOS의 경우에는 Metal 대응기기와 일치하기에, 성능이나 기능을 위해 OpenGL ES 3.0을 선택할 메리트가 사라집니다.
ES2.0 ES3.0 Metal ---------------------------------------------------------- Apple A5/A6 PowerVR SGX543/554 Y - - Apple A7 PowreVR G6430 Y Y Y
Android의 ES 3.0이나 Desktop의 OpenGL 4.x와 호환성을 가지기 위해서는 필요합니다만, 성능이나 쉬운 사용을 우선한다면 Metal이 선택될 가능성이 높습니다. 용도에 따라 적절하게 사용될 듯 합니다.
그렇다고는 해도 각종 플랫폼에 개별적으로 대응하는 건 큰일입니다. OpenGL의 Low Overhead Profile이나 Multi thread Extension처럼, 플랫폼을 넘어선 새로운 사양의 등장을 기대합니다.