DirectX 11에서 GPU 아키텍쳐 방향성

● DirectX 10을 확장판 DirectX 11

　DirectX 11의 서포트는, 어느 정도, GPU에 있어서 무거운 짐인가. 아마 설계상은, 그만큼 무거운 짐은 아니다. 적어도, DirectX 10에의 점프와는 비교가 되지 않는 만큼, 설계상의 노력이나 코스트는 작을 것이다. 왜냐하면, GPU 벤더는, 
이전 DirectX 10에의 이행시에, GPU의 구조적인 혁신을 끝마쳤기 때문이다. DirectX 11은, DirectX 10의 구조에 소폭적인 확장이 될 것이다.

　 또, DirectX 11은, DirectX 10과 같게, 범용적인 프로세서 프렌들리인 방향을 향하고 있다. DirectX 10에서는, 그래픽스 파이프라인이 높은 유연성을 가지게 되어, GPU가 갖추는 프로세서가 범용성을 강하게 했다. 그 결과적으로, GPU와는 달리, 그래픽스 전용 하드웨어를 거의 가지지 않는, 보다 범용적인 프로세서로의 서포트가 용이하게 되었다. DirectX 11에서도, 새롭게 더해지는 전용 하드웨어를 최소에 억제하고 있어 기본적으로는 같은 방향을 향하고 있다.

　이것은, Intel의「Larrabee(라라비)」과 같은 throughput CPU가 그래픽스 처리에 진출하는 여지를 늘린다. 또, 프로그래머블화를 진행시키는 GPU의 다음의 발전의 가능성도 나타내 보이고 있다.

　 게다가 3D그래픽스 API가, GPU의 아키텍쳐의 변화를 이끈다고 하는 흐름 자체도, 바뀌고 있다. DirectX와 GPU 아키텍쳐의 변화는 계속 연동하겠지만 , 지배적은 아니게 된다. DirectX에 정의되지 않는 부분에서의 확장이, GPU의 아키텍쳐 변화의 대부분을 차지하게 되기 때문이다.

　 실제, NVIDIA GPU의 G80로의 아키텍쳐 확장은, 그래픽스 API에 직접 관계없는 부분이 대부분을 차지하고 있었다. 또, GPU가 그래픽스 API와는 관계없는 부분에서 확장한 기능을, DirectX Compute Shader로 수중에 넣는다고 하는 역전 현상도 일어나고 있다. Larrabee와 같이, 고throughput CPU 위에 그래픽스 파이프를 싣는 어프로치도 등장하고 있다.

● DirectX의 이행으로 진행되어 온 GPU의 비대화

　GPU는 지금까지, DirectX의 세대가 진행될 때마다 아키텍쳐를 변화시켜, 그 번에 칩을 비대화 시켜 왔다.

　 칩의 비대화는 2개의 요인에 의한다.
하나는, 퍼포먼스를 배증시켰기 때문에. 연산 성능을 늘리려면 , 보다 많은 자원이 필요하게 되어, GPU의 트랜지스터 카운트를 밀어 올렸다. 하나는, 프로그래머블화를 진행시켰기 때문에. 개별적으로 처리를 행하고 있던 고정 기능 하드를, 단일의 프로그래머블 프로세서에 집약시키면, 필요한 트랜지스터 카운트는 줄어 든다. 그러나, 그대로는 성능이 큰폭으로 떨어져 버리기 위해, 같은 성능을 유지하는 것만으로도 연산 자원을 큰폭으로 늘릴 필요가 생긴다. 결과적으로, GPU의 경우는, 고정 하드로부터 프로그래머블 하드에의 변환으로, 트랜지스터 카운트와 die size(반도체 본체의 면적)를 증대시켜 왔다.

　과거 몇차례의 DirectX의 메이저 업데이트, 즉, DirectX 7→DirectX 8→DirectX 9→DirectX 10에서는, 이러한 이유로 GPU 하드웨어가 비대화 했다.
DirectX 8에의 이행에서는 프로그래머블인 하드가 들어간 파이프라인이 2중구조가 되었다.
DirectX 9에의 이행에서는 정점 처리와 픽셀 처리가, 본격적인 프로그래머블 프로세서로 옮겨졌다.
그리고 DirectX 10에의 이행에서는, 보다 유연한 프로그래머블성을 위해서, GPU 아키텍쳐의 근본적인 개혁이 필요하게 되었다.

　 어느 세대에의 이행도, GPU를 어떻게 만드는가 하는, 본질적인 부분과 관계되는 개혁이었다.
특히, DirectX 10세대로의 아키텍쳐 개혁은, GPU의 본질을 바꾸는 근본적인 물건이었다.
DirectX 8으로부터 DirectX 9로 API의 개혁으로 견인해 온 GPU 아키텍쳐의 개혁이, 정점을 맞이한 분기점이 DirectX 10이다. DirectX 11에의 이행은, 이러한, GPU의 마이크로 아키텍쳐의 근본적인 개혁을 수반한 과거의 메이저 업데이트와 비교하면 마이너다.

● API상의 그래픽스 파이프라인과 GPU의 실장의 괴리

　DirectX 10세대의 GPU 아키텍쳐의 개혁이 전환점이 되는 것은, GPU의 물리적인 파이프라인을, 논리상의 그래픽스 API의 파이프라인과 떼어냈기 때문이다. DirectX 9세대까지의 GPU는, 그래픽스 API에 정의되고 있는 그래픽스 파이프라인을 하드웨어로서 실장할 방향에 있었다. 정점 처리→rasterize→픽셀 처리&texture 링→frame buffer 프로세싱이라고 하는, 일련의 그래픽스 파이프라인에 따른 실장은, 프로그래머블화가 진행된 DirectX 9세대라도 변하지 않았다. Vertex Shader 프로세서와 Pixel Shader 프로세서는, 각각 별도인 실장이었다.

　 하지만, DirectX 10에서는, API측에서 정의되는 각 쉐이더스테이지가, 거의 공통된 사양이 되었다. 또, 파이프라인의 도중에도 메모리에의 아웃풋을 할 수 있는「Stream Out」등이 더해졌다. 그 때문에, 쉐이더를 실행하는 프로세서를 공통화한「유니파이드쉐이더(Unified-Shader)」화하는 것이 합리적이 되었다.

　 결과적으로 표준적인 DirectX 10세대 GPU에서는, 1 종류의 쉐이더프로세서가 모든 쉐이더스테이지를 실행. 그 회전에, texture 필터링 유닛이나 래스터라이저라고 하는 고정 하드웨어가 부대하는 아키텍쳐로 바뀌었다. 이것은, GPU의 구조의 근본적인 전환으로, GPU에 있어서는 최대 규모의 아키텍쳐 개혁이 되었다. 쉐이더프로세서를 확장할 뿐만 아니라, 1 종류의 쉐이더프로세서로 다양한 쉐이더를 달리게 하기 위한 스케줄링 등, 안보이는 부분에서 하드웨어가 비대화 했다.

　 당시 ATI Technologies의 PC를 위한 GPU 유닛을 인솔하고 있던 Rick Bergman(릭크·바 구먼) 씨(현Senior Vice President, AMD)는, DirectX 10 당시에「DirectX 10을 서포트하기 위해서는, (DirectX 9세대 GPU로부터 30~40% 정도의 논리(회로)가 불필요하게 필요하다」라고 설명했다. 그리고, 실제로는 퍼포먼스 업분도 포함하면, 트랜지스터 카운트는 배증했다.

●  GPU 아키텍쳐의 변화

　 위의 차트군은, DirectX의 각 세대의 논리상의 파이프라인과 거기에 대응하는 전형적인 GPU 아키텍쳐 실장의 개념도다. 명칭의 혼란을 피하기 위해, 약간, 스테이지나 유닛의 이름을 완화하다 되어 있다. 논리도의 구성도, 데이터 플로우를 보다 명확하게 하기 위해, 약간 손봤다

　 예를 들면, 파이프라인 최종단의 비디오메모리상에서의 픽셀등의 프로세싱에 대해서는, DirectX 9까지의 그림으로 나타내 보인 비교적 범용의 표현인「frame buffer 프로세싱(Framebuffer Processing)」이라고, DirectX 10이후에 붙여진 명칭 Output Merger의 공통성을 나타내기 위해서, Output Merger 의 뒤에「frame buffer 프로세싱」이라고 더했다. 또, 픽셀쉐이더프로세서로부터 비디오메모리에의 다이렉트인 출력(Output Merger스테이지로 서포트된다)을 명료하게 하기 위해, 픽셀쉐이더프로세서와 Output Merger의 사이에, 메모리에의 출력 라인을 더했다.

　 간략화를 위해서 생략한 것도 있다. 예를 들면, 지오메트리쉐이더(Geometry Shader)로 서포트하는 원시적의 프로세싱은, 개념적으로는 DirectX 9세대로는 셋업/래스터라이저(Setup/Rasterizer)의 스테이지에 고정 기능으로서 포함할 수 있다고 생각할 수 있지만, 그림중에서는 제외했다. DirectX 10으로의 DirectX Compute Shader는, DirectX 11으로 종래 DirectX 10과의 차이를 명확하게 하기 위해서 나타내 보이지 않았다.

　 필수 항목은 아니지만 중요한 기능은 파선으로 나타내 보였다. 예를 들면, DirectX 9세대로의 정점 쉐이더로의 texture 페치는, DirectX 9의 기본 사양에서는 필수가 아니고 NVIDIA 등은 대응하지 않았기 때문에 파선으로 했다.

　 실장 아키텍쳐도의 분에서는, 논리도와의 상대적인 관계를 나타내기 위해서, 특수한 명칭을 더했다. 예를 들면, 유니파이드쉐이더프로세서로부터 메모리에의 다이렉트인 서두는, DirectX 10의 논리 파이프라인상에서의 명칭인 스트림 아웃으로 나타내 보였다.

　완전하게 정확한 그림이라고 하는 것은 아니지만, 개념은 잡을 수 있다고 생각하고 있다.

● 전용 하드웨어를 최소에 억제 프로그래머블 GPU에 적응

　 그림을 보면, DirectX 10으로 GPU의 구조가 바뀌었던 것이 잘 안다. DirectX 9까지는, 논리 파이프라인이, 거의 반영된 형태로 실장되고 있었다. 그러나, DirectX 10에서는, 논리 파이프와 실제의 GPU의 유닛과 데이터 플로우는 완전히 차이가 난다. DirectX 10이 GPU 아키텍쳐에 있어서 최대의 전환(이었)였던 일을 잘 안다.

　 이 전환의 결과, 2개의 방향이 유효하게 되었다. (1)하나는, 그래픽스 파이프라인으로, 논리상의 프로그래머블 스테이지를 늘리는 것. 논리상의 프로그램쉐이더를 늘려도, 하드웨어 자체에 별설계의 프로세서를 더할 필요가 없기 때문에, 간단하게 늘릴 수 있다. (2)이제(벌써) 하나는, 전용 하드웨어를 가지지 않는가 거의 가지지 않는 범용적인 프로세서로 서포트하는 것. Intel가 시도하는「Larrabee」과 같이, texture 유닛 이외의 전용 하드를 가지지 않는 아키텍쳐에서도 용이하다.

　DirectX 11은, 이러한 DirectX 10으로 깐 흐름을 타고 있다. 우선, 쉐이더스테이지수가 증가했다. 「테셀레이션(평면 분할: Tessellation)」의 서포트를 위해서, 고정 기능의 테셀레이션스테이지 이외에, 쉐이더스테이지가 추가되었기 때문이다. 고정 기능은 최소한으로 끝나도록 정의되고 있다. 그 때문에, Larrabee와 같은 보다 범용의 CPU는, 새롭게 더해지는 요소도 모두 프로세서상의 소프트웨어로서 실장할 수 있을 것 같다.

　DirectX 11의 테셀레이션스테이지군은, 유니파이드쉐이더 GPU에 잘 적합하도록 정의되고 있다. 테셀레이션의 제어는 전단의(Hull Shader에,테셀레이트된 정점의 변이는 Domain Shader이 맡는다. 그 때문에, 테셀레이터하드가 하는 것은, 단순하게 패치에 대해서의 정점 데이터의 생성만된다.

　 즉, DirectX 11의 테셀레이터는 컨피규러블로 유연성이 높은 복잡한 것이지만, 이전과 같이 그 모두를 전용 하드웨어로서 실장하려고는 하고 있지 않다. 쉐이더프로세서에 실장 가능한 쉐이더스테이지로 프로그래머블에 처리하는 것을 전제로서 전용 하드웨어의 증가를 최소에 억제하고 있다.

　 이러한 어프로치로부터, 하드웨어로서 필요한 자원도, 그만큼 큰 것으로는 없을 것이다. 물론, 그 만큼, 쉐이더프로세서의 실행 시간은 테셀레이션에 놓친다. 그러나, 그곳에서는 다른 처리와의 로드 밸런스를 취할 수 있다. 구체적으로는, 연산 자원이 많은 고급 지향 GPU는, 보다 디테일의 섬세한 텟세레이션을 실행해, 자원의 적은 GPU에서는, 디테일을 달게 한다고 하는 조정이 가능하다.

　DirectX 11에는 이 외 하드웨어적인 확장이 다수 포함되어 있지만, 모두, GPU의 구조의 변혁이나 대규모 전용 하드웨어의 실장을 필요로 하지 않는다고 추측되는 것 뿐이다. 그 때문에, DirectX 11세대의 GPU의 실장의 기본은, 위의 추정도와 같이 매우 DirectX 10과 닮아 다닌 것이 된다고 추정된다.

　물론, GPU 벤더 각사는, 성능을 향상시키기 위해서 DirectX 11세대라도 다양한 아키텍쳐의 확장을 더해 온다고 추측된다. 그러나, API의 정의에 영향을 받는 부분에서는, 큰 확장은 필요가 없다고 볼 수 있다.

● GPU에 있어서 비교적 어려움이 낮은 DirectX 11

　 이러한 사정으로부터, DirectX 11의 서포트는, GPU에 있어서 DirectX 10때 정도 무거운 짐은 되지 않는다. 이행 자체는 비교적 순조롭게 진행될 것이다. 신API에의 대응의 실장이 너무 무거워서, 로앤드의 GPU로 성능을 떨어뜨리지 않고 이행 하는 것이 어렵다고 한 문제도, 거의 발생하지 않는다고 추측된다. 과거의 이행에서는, 이것이 큰 문제(이었)였다.

　 신API 서포트를 위해서 필요한 트랜지스터 카운트의 증가가 이전 정도는 아니기 때문에, DirectX 11세대에의 이행에서는, 신프로세스에의 이행의 필요성이 약간 줄어든다. 역을 말하면, 프로세스 기술의 진보를, GPU의 die size(반도체 본체의 면적)를 억제하는 것에 사용할 여유가 출생한다. 즉, 코스트를 억제할 방향을 향할 수 있다.

　 또, 이 어프로치는, Larrabee형의 throughput CPU와도 친화성이 높다. Larrabee는, GPU가 반드시 고정 기능으로 실장하고 있는 래스터라이저까지, 프로그래머블인 프로세서 코어로 실현된다. 그 때문에, 테셀레이터 전용 하드웨어도, 프로세서 코어 위에 소프트웨어로 실장하는 것이 자연스러운 흐름이 될 것이다. 즉, 텟세레이타를 하드하고 싣는다면, 그 전에, 보다 필요성의 높은 래스터라이저를 하드하고 실을 것이다.

　테셀레이터 하드가 행하는 것은 정점의 생성 뿐이므로, 특수한 연산 유닛이 필요한 것은 아니다. 생성되는 정점수는 방대하게 될 가능성이 있지만, 프로세서 코어에 내부 메모리를 가지기 위해, 이 문제도 해결할 수 있다고 추측된다.

　 여기서 중요한 점은, DirectX에서는 자꾸자꾸 쉐이더스테이지가 겹겹이 쌓여 복잡하게 되어 가지만, 하드웨어는 일정한 심플성을 유지할 수 있는 것이다. 이것이 유니파이드형의 쉐이더프로세서의 이점으로, DirectX 10이 그 문을 열었다. 향후, API상에서 정의되는 파이프라인 스테이지가 얼마나 복잡하게 되어도, 이 노선을 타고 있는 한, 하드웨어의 복잡화는 억제된다.

　 그러나, 짓궂은 일로, 이것은 그래픽스 API의 하드웨어에 대한 영향력의 저하를 부를 것이다. 하드웨어는, 고정적인 파이프라인을 얼마나 빠르게 처리하는지, 그게 아니라, 유연한 프로세서 위에서 얼마나 능숙하게 프로그래머블인 스테이지를 달리게 하는지, 로 향한다. 그래픽스의 기능은, 고정 하드웨어로서가 아니고, 프로세서상의 쉐이더프로그람으로서 실현된다. 즉, GPU와 그래픽스 API의 관계는, 범용 CPU와 OS와 같은 관계가 되어 간다. OS가 CPU를 완전하게 지배는 할 수 없게, 그래픽스 API도 GPU를 지배할 수 없게 된다.