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

북미 시간 2013년 11월 11 ~ 12 일에 AMD는 미국 캘리포니아 산호세에서 개발자 이벤트 " AMD De ve lo per Summit 2013 "(약칭, APU13. 다음 약어 표기)을 개최. 그 속에서 "Graphics Core Next"(이하, GCN) 기반의 Radeon 시리즈 전용으로 개발된 그래픽 API " Mantle "(맨틀)에 대한 자세한 세션" Mantle : Empowering 3D Gra ph I CS Innovation "을 실시했다.
 
　Mantle의 존재가 밝혀진 2013년 9월 시점에서는 "Mantle이 어떤 구조로 애플리케이션 가속화를 실현하는 것인가?"라는, 중요한 부분은 설명되지 않았다. APU13 간신히 그 부분이 밝혀져, 본고에서는 세션의 내용을 바탕으로 Mantle의 실태를 밝히고 싶다.

GPU의 기능을 직접 조작하는 Mantle. 단, 이용은 계획적으로?

Guennadi Riguer 씨 (Mantle Chief Architect , AMD). 구 ATI Technologies 시대에 게임 그래픽 개발 경험이 있고, 옛날에는 " Neverwinter Nights"시리즈와 "FEAR" 시리즈 등으로 그 이름이 신뢰되고 있다.

  세션 담당은, AMD에서 Mantle의 수석 아키텍트를 역임하는 Guennadi Riguer 씨다. 그는 우선 Mantle을 "PC 환경에서 게임 개발 등의 실시간 그래픽 응용 프로그램을 개발하는 사람들이 직면하고 있는 장애물을 배제하기 위해"개발한 것이라고 평가했다.

 현재의 Mantle은 PlayStation 4 (이하 PS4)와 ​​Xbox one과 같은 차세대 게임기에 채용 된 GCN 아키텍처를 대상으로하여 현재의 GPU가 가진 기능을 정확하고 직접적으로 조작하는 그래픽 프로그래밍 API (GPU 프로그래밍 API)로 설계되어 있다고 한다.

　응용 프로그램이 GPU를 거의 직접이라고 말해도 좋은 레벨로 구동 시키거나 각종 자원 관리도 담당 하는 것이므로 현재의 DirectX 또는 OpenGL에 비하면 매우 낮은 수준 API 인 셈이다.

　그러나 "하드웨어 추상화 계층이 없어지는 것은 아니다" 라고 Riguer 씨는 말한다. 따라서 NVIDIA 등의 경쟁 GPU 메이커가 "Mantle의 구조"에 참여 하는 것은 "기술적으로 가능" (Riguer 씨)이라고 한다. 이것은 꽤 놀라운 발언이다.

　하드웨어를 추상화 한 GPU 프로그래밍 API 가 된다," 라면, DirectX 및 OpenGL과 무엇이 다른가?" 라는 의문은 당연히 솟아 온다. 이 점에 그는 Mantle이 DirectX 나 OpenGL을 전면적 대체가 아니라고 한 후 "특정 3D 그래픽 프로그래밍 장면에만 사용 할 것" 이라고 했다. 그러면 Mantle은 어떤 장면에서 사용되는 것인가. Riguer 씨는 세 가지 예를 들어 설명했다.

Mantle의 활용에는 그래픽 파이프 라인에 대한 깊은 이해가 필요하므로,

만인을 위한 솔루션은 아니라는 슬라이드

 첫번째는 "압도적인 성능이 필요한 어플리케이션"을 개발하는 경우이다. 물론, 게임은 그 필두로 들수 있을 것이다. 반대로 말하면, 리얼 타임성을 게임 정도로 중시하지 않는 3D 그래픽 도구와 뷰어 어플리케이션 이라면 일부러 Mantle을 사용할 필요가 없다.

 두번째는 "그래픽 프로그래밍과 관련된 모든 요소를 애플리케이션 측에서 직접 관리하고 싶은" 경우이다. 자세한 내용은 후술 하지만, Mantle에서는 GPU의 명령 버퍼도 애플리케이션 측에서 관리할 필요가 있으며 " 렌더링에 필요한 데이터와 파라미터를 준비하고 API를 호출하면 한방에 렌더링" 이라는 건 아니다. Mantle의 활용은 3D 그래픽 파이프 라인에 대한 깊은 이해가 필요한 것이다.

 마지막 세번째는 "그 애플리케이션을 GCN 기반 GPU 환경에서 멀티 플랫폼 전개하고 싶은" 경우가 된다. 즉, GCN 기반의 GPU를 채용하는 PS4와 Xbox one 용 게임을, 같은 GCN 기반의 다른 기종이나 PC에 이식하고 싶다고 하는 상황이다. NVIDIA 제 GPU와 Intel의 통합 그래픽 기능에도 대응해야 한다면 두번 수고가 될 뿐이므로, Mantle은 사용하지 않는 편이 좋다.

"Small Batch 문제"를 예로 하는 Mantle에 의한 고속화의 사례

Mantle이 가져 오는 성능 향상 점으로, "Small Batch 문제"가 예로 다루어 졌다.

 Riguer 씨는 Mantle의 개발에 있어서 "GPU를 철저하게 효율적으로 활용하는 것"을 목표로 내건라고 말한다. DirectX 나 OpenGL을 통해 실현이 어려웠던 수준의 성능을 제공하기 때문이다. 그러면, 어떤 사례에 Mantle를 활용하면 애플리케이션의 성능 향상이 실현 될 수 있을까?

 Riguer 씨는 "1 시간 미만의 세션으로는 말을 다 할수 없다"고 웃으며 알기 쉬운 사례로 "Small Batch 문제 해결"을 예로 들어 해설했다. 예를 들어, 초원 장면을 그리는데, 풀 모델 1만개 묘화할 필요가 있다고 생각하자. 이 경우 "풀 모델의 렌더링을 1만 번 실행한다 '는 것이 보통의 발상이다. 그러나 이를 기존의 DirectX 또는 OpenGL에서 처리하려고 하면 최악의 경우 GPU에 대해 다음과 같이 대량의 처리가 발생 될 가능성이 있다.

1. 1만 회분의 풀 모델을 GPU로 전송한다.
2. 1만 회분의 묘화(그리기) 명령을 생성한다.

3. 그래픽 드라이버 묘화 명령을 GPU 고유의 명령으로 1만회 번역 명령을 발행한다

 대량의 처리가 발생하면 거기에 오버 헤드가 발생, 전체 성능에 부정적 영향을 미치게되는데, 이러한 "소규모 묘화의 대량 처리" 에 의한 문제를 전문 용어로 "Small Batch"(스몰 배치) 문제라고 한다.

 GPU와 DirectX를 정통한 사람이라면 "그것은, 지오메트리 인스턴스로 해결 가능한거 아닌가?" 라고 생각할 수 있다. 분명히, DirectX 9.0c에서 도입된 지오메트리 인스턴스 라는 기능을 사용하면 위의 1. 에서 언급한 "1 만 회분의 풀 모델 전송"은 1회로 끝낼 수 있다.  하지만 2와 3은 해결할 수 없다.

 DirectX를 사용하는 게임 타이틀은 따라서 "풀 모델을 1 만회 묘화"하는 것이 아니라 "1 만개의 풀을 1번 묘화"하도록 처리 형태를 바꿔서, 대책하고 있다. 이러한 처리를 "지오메트리 통합 (Geometric Consolidation)" 등으로 부르기도 하지만, 실제로는 게임 로직과의 균형도 있기에, 언제나 이 수법이 잘된다고는 할 수 없다. 원래 이러한 묘화의 최적화에 번뇌하지 않으면 안되는 것은 게임 개발자로서는 본래 의도가 아니다.

  Riguer 씨에 따르면 근래 평균 PC 게임의 경우, 지오메트리 통합의 최적화를 실시하고 있었다고 해도, 1 프레임 당 3000 ~ 5000 개의 Small Batch가 생기고 있다 한다. 특히 그래픽이 무거운 게임이 되면 1 프레임 당 1 만개 안팎에 달하는 경우도 있다고 한다. 하지만 Mantle을 활용하는 게임에서는 1 프레임 당 10 만개의 Small Batch에 해당하는 처리가 있어도 성능면에서 영향은 나오지 않는다고 한다.

그래픽이 무거운 DirectX 기반 게임에서 1 프레임 당 1 만 여개의 Small Batch가 생기고있다 (왼쪽) 하지만 Mantle를 사용한다면, 10 만 개 분의 처리에서도 성능 저하를 발생하지 않는다 (오른쪽)

현재 GPU 프로그래밍 모델을 이미지 한 슬라이드. "Queues"라고 쓰여져있는 것이 명령 버퍼이다

 그것을 실현하는 요소의 하나는 명령 버퍼의 처리 방법에 있다. 현재 GPU 프로그래밍 모델은 GPU의 각종 기능을 응용 프로그램이 사용하는 경우 응용 프로그램 측이 명령을 실행하면 그것이 명령 버퍼에 일단 축적된다. 그리고 모아진 명령은 GPU에 순차적으로 발행된다. 그것을 받아 GPU가 처리하는 흐름이다. Mantle에서도 그것은 변하지 않는다.

　DirectX 나 OpenGL의 경우,이 명령 버퍼의 생성과 묘화 명령의 축적, 그 실행 관리를 담당하는 것은, DirectX 및 OpenGL, 그리고 GPU 장치 드라이버이며, 응용 프로그램이 직접 손대는 작업은 없었다. 예를 들어 멀티 코어 CPU 환경에서 "각 명령 버퍼에 대한 조작이 어떤 CPU가 처리하는 스레드에 할당되는지 응용 프로그램에서 알 수 없다" 라는 블랙 박스가 된다.

 

그러나 Mantle 이라면, Mantle 대응 응용 프로그램의 경우는 지금 예를 든 커맨드 버퍼의 생성 및 묘화 명령의 축적, 그 실행 관리의 모든 것을 응용 프로그램에서 담당 할 수 있게 된다. 응용 프로그램 측이 명령 버퍼를 자유롭게 할 수 있기에 "어떤 커맨드 버퍼 제어는 임의의 CPU 스레드를 할당" 이라는 것도 할 수 있다. 이런 용도로 응용 프로그램이 하드웨어 자원을 보다 효율적으로 사용할 수 있게 되기 때문에 성능을 낼 수 있다는 것이 Mantle의 이점이 있는 의미다.

Mantle에서 응용 프로그램은 명령 버퍼 및 명령의 실행을 "직접"관리

 다만, Mantle 에서는 커맨드 버퍼 관련 조작을 모두 응용 프로그램 측에서 하는 이상, 커맨드 버퍼 사이의 상태 관리 및 커맨드 버퍼 간의 동기화 취득 같은 것도 어플리케이션 측에서 실시 할 필요가 있다. 따라서 개발자의 수고가 나름대로 늘어날 가능성은 있는 것이다.


Mantle은 어플리케이션이 그래픽 메모리를 관리

왼쪽이 DirectX 나 OpenGL의 메모리 이용 형태, API가 메모리를 할당한다. 한편 Mantle은 응용 프로그램 측이 메모리를 확보하여 어떻게 사용 할까를 신고하는 형태

  Mantle는 커맨드 버퍼뿐만 아니라 응용 프로그램 측이 그래픽 메모리를 자유롭게 관리 할 수 있게 된 것도 큰 차이가 있다. DirectX 및 OpenGL에서 응용 프로그램은 API를 통해 그래픽 메모리를 확보한다. 게다가 정점 버퍼나 텍스처 배열, 상수 버퍼 같은 용도 별로 응용 프로그램이 "O O에 사용하는 메모리를 주세요"라고 요청하면 API를 경유해, GPU 드라이버가" 그러면 이것을 사용하라 " 고 메모리를 할당하는 구조로 되어 있다. 뭔가 할때마다 일일이 메모리를 확보하지 않으면 안되는 것으로, 처리와 그래픽 메모리 이용 효율이 나빠지는 것도 자명한 것이다.

 거기에서 Mantle은 "응용 프로그램에서 적절한 양의 그래픽 메모리를 확보 한 후, API를 통해 "이것은 OO 에 사용합니다 "라고 신고하는 '형태로 바뀐다. 이 구조라면 그래픽 메모리 이용 효율이 향상되고 응용 프로그램 내에서 그래픽 메모리의 재사용도 쉽다. 예를 들어, 어떤 렌더링 스테이트에서 "쉐도우 맵 용으로 생성한 버퍼 "를,"상수 버퍼 "에 재사용하는 것이 가능해진다. 용도별로 일일이 메모리를 확보하지 않아도 되기에 API 오버 헤드는 줄어들고 메모리 절약으로 이어지는 것이다.

Mantle의 그래픽 메모리 관리 방식의 장점을 보인 2 장의 슬라이드. Mantle은 용도마다 세세하게 그래픽 메모리를 확보하지 않아도 된다.(왼쪽), 게다가, 확보한 메모리를 어떻게 사용할 것인가는 응용 프로그램에서 자유롭게 결정할 수 있다 (오른쪽)

Brian Bennett (Mantle Architect, AMD)

 Mantle의 그래픽 메모리 활용에 대해 설명한 Mantle Architect의 Brian Bennett 씨는 "이 메모리 이용 형태에 가장 직접적으로 혜택을 얻는 것은 그래픽 가상 메모리의 활용"이라고 주장했다.

 그래픽 가상 메모리는 CPU의 가상 메모리와 같은 이치 기능이다. 처음에 실제 그래픽 메모리보다 큰 메모리 영역을 정의하고, 그것에 가상 주소를 내어 주고, 응용 프로그램 측은 가상 주소를 사용해 메모리를 이용한다. 그리고 실제 그래픽 메모리에 들어 있지 않은 부분은 외부 스토리지에 스왑 아웃된다.

 그래픽 가상 메모리 자체는 새로운 개념은 아니지만, Mantle에서는 실제 메모리와 가상 메모리의 할당을 가르키는 리매핑 테이블을 조작 할 수 있게 된다. 그에 따라 응용 프로그램이 필요한 시간에 가상 메모리의 내용을 실제 메모리에 로드 할 수있게 되는 것이다. 이것을 잘 활용하면 예를 들어 오픈 월드 타입의 게임에서, 지역 이동중에 로딩 화면을 출력으로 게임의 진행을 멈추지 않고, 백그라운드에서 필요한 3D 모델과 텍스처 데이터를 읽어 두는 따위의 것이, 지금까지 보다 쉽게 할 수 있게 된다.

Mantle의 그래픽 가상 메모리의 사용 방법을 보인 슬라이드

게임 기용 개발에 활용 기술을 Mantle에 사용 가능하다는 슬라이드

 또한 세션 외에도 DirectX나 OpenGL에서는 예측 불능인 타이밍에 행하는 쉐이더 컴파일을 사전에 끝마치거나 앤티엘리어싱을 임의로 구성되는 것으로, 각 쉐이더 스테이지를 자유자재로 조합해 렌더링 흐름을 형성하는 등의 것이 Mantle 에서는 가능하다고 소개했다.

 Mantle에서 가능하게 되는 이러한 요소는 하드웨어를 추상화한 DirectX 나 OpenGL에 의한 PC 게임의 개발과 확실히 지금까지 되지 않던 것으로 있었지만, 사실 PlayStation 3 나 Xbox 360 세대 게임 개발에서는 드물지 않았다. 당연히 게임 개발자는 PS4와 Xbox one 용 게임 개발에서도 같은 수법을 쓰기에, 그 개발에서 키운 기술을 PC 환경에 그대로 가지고 갈 수 있다는 것이 Mantle의 큰 이점인 것이다 .




Mantle에서는 멀티 GPU 환경을 유연하게 활용할 수 있게

　세션의 마지막에는 PC만 이라는 Mantle의 이점이 소개되었다. 그것은 다중 GPU에 대한 대응이다. Mantle 에서는 PC에 탑재된 여러 Mantle 지원 GPU 및 APU의 모두를 응용 프로그램이 자유롭게 다룰수 있게 했다. 지금까지 AMD의 GPU가 탑재된 멀티 GPU 환경에서는 단일 GPU끼리 협조 동작시키는 "CrossFire"나, 독립 GPU와 APU를 결합 'AMD Dual Graphics Technology "라는 기능이 제공되고 있었다. 그러나 이들은 기본적으로 d완전히 동일하거나 가까운 스펙의 GPU를 조합할 필요가 있다....... 라는 것은 경험으로 알고있는 독자도 많을 것이다.

 그것이 Mantle는 GCN 세대라는 제약은 있지만 다른 스펙의 GPU를 조합한 멀티 GPU 환경에서도 각각의 GPU를 풀 활용할 수 있다는 것이다. 예를들면 CrossFire 환경에서는 그래픽 렌더링을 GPU 마다 오버랩시켜 렌더링 하는 것으로 렌더링 성능을 향상시키는 "Alternate Frame Rendering"(AFR)이 기본적인 사용법이다. 그것이 Mantle 에서는 "APU 및 독립 GPU를 조합해, APU 측의 GPU 코어를 포스트 이펙트 처리 전용으로 사용" 등의 유연한 활용이 가능하게 되는 것이다.

Mantle 환경에서 다중 GPU 활용 이미지 슬라이드 (왼쪽)와 그 활용법의 장점을 꼽았던 슬라이드 (오른쪽). Mantle는 멀티 GPU 방식을 바꿀지도 모른다?

게임 개발자를 주목 시키는 Mantle. NVIDIA의 대응책은 어떻게?

　2013년 9월에 발표된 이후 Mantle은 게임 개발자의 세계에서 매우 주목을 받고 있으며, "세계 게임 스튜디오들이 속속 채용 또는 채용의 검토를 시작하고 있다"고 AMD는 주장한다. 발표 시점에서 " Battlefield 4 "가 Mantle에 대응한다고 발표해 주목 시켰다. 또 최근에는 " TOMB RAIDER " " HITMAN ABSOLUTION "을 다루고 현재는" Thief "의 PC 버전을 개발하고 있는 Nixxes Software가 Mantle의 채용을 결정하고, Thief의 PC 판에서는 Mantle 버전이 제공 될 전망이라는 것이다. 

 " CryENGINE 3" 으로 유명한 Crytek도 Mantle의 채용을 검토하고 있는 것이 세션에서 발표되고 있어 (※ 채용이 결정된 것은 아니다) Mantle의 채용 동향은 PC 게임 팬이라면 주목 해 둘 필요가 있다. PS4와 Xbox one을 만든 여세를 몰아, Mantle로 PC 게임 시장도 제패하려고 노리는 AMD. 하지만 경쟁에 있는 NVIDIA도 그 움직임을 가만히 보고 있지는 않을 것이다. Mantle 대해 NVIDIA는 어떤 대응책을 준비해 오는가? 당분간은 거기에서 눈을 뗄 수 없다.


2013년 11월 15일 기사 입니다.

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

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

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

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