● GPU에 있어서 비교적 허들이 낮은 DirectX 11


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


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


TSMC의 프로세스 로드맵


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

 

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

 

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

 

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


 

출처 : http://pc.watch.impress.co.jp/docs/column/kaigai/20090804_306876.html



저작자 표시
신고
by 흥배 2009.11.15 08:30

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


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

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

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

DirectX 11 APIGPU 구현



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

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

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

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

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




나머지는 다음에.... ^^


DirectX 11세대의GPU마이크로 아키텍쳐의 방향성 - 1

DirectX 11세대의GPU마이크로 아키텍쳐의 방향성 - 2



출처 : http://pc.watch.impress.co.jp/docs/column/kaigai/20090804_306876.html



저작자 표시
신고
by 흥배 2009.11.13 09:00

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


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


DirectX 8 APIGPU 구현


DirectX 9 APIGPU 구현


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


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


당시 ATI  TechnologiesPCGPU 유닛을 인솔하고 있었던 Rick Bergman(Senior Vice President, AMD)DirectX 10당시에 「DirectX 10을 지원하기 위해서는 (DirectX 9세대 GPU보다)30~40%정도의 논리(회로)가 필요하다」라고 설명했다. 그리고 실제로는 퍼포먼스 상승 부분도 포함하면 트랜지스터 수는 배증했다.


DirectX 10 APIGPU 구현




그림으로 명료하게 된 GPU 아키텍쳐의 변화


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


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


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


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

 

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

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




나머지는 다음에....

DirectX 11세대의GPU마이크로 아키텍쳐의 방향성 - 1

출처 : http://pc.watch.impress.co.jp/docs/column/kaigai/20090804_306876.html

저작자 표시
신고
by 흥배 2009.11.11 08:30

● DirectX 10에서 구조 개혁의 위를 탄 DirectX 11


DirectX 11의 지원은 GPU에 있어서 어느 정도 무거운 짐인가. 아마 설계상으로는 그다지 무거운 짐은 아니다. 적어도 DirectX 10에서의 점프와는 비교가 되지 않을 만큼 설계상의 노력이나 비용은 작을 것이다. 왜냐하면 GPU 벤더는 전회의 DirectX 10에서 이행 시에 GPU의 구조적인 변혁을 끝마쳐 버리고 있기 때문이다. DirectX 11DirectX 10의 구조 뒤를 탄 소폭적인 확장이 될 것이다.


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


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


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


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



 

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


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


GPU의 die size 그림


칩의 비대화는 두 개의 요인에 의한다. 하나는 퍼포먼스를 배증시켰기 때문에 연산 성능을 늘리려면 보다 많은 자원이 필요하게 되어 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 9API의 개혁으로 견인해 온 GPU 아키텍쳐 개혁이 정점을 맞이한 분기점이 DirectX 10 이다.  DirectX 11로의 이행은 이러한 GPU의 마이크로 아키텍쳐의 근본적인 개혁을 수반한 과거의 메이저 업데이트와 비교하면 마이너.




나머지는 다음에....^^



출처 : http://pc.watch.impress.co.jp/docs/column/kaigai/20090804_306876.html

저작자 표시
신고
by 흥배 2009.11.09 08:30
Windows 7이 성공을 거둔다면 자동적으로 DirectX 11을 사용한 게임이 많이 만들어지리라 생각합니다.
DirectX 11은 10에서 발전한 형태이며 10은 현재 한국에서 가장 많이 사용하고 있는 9와 구조가 좀 다르다고 합니다.

10월20일이면 Window 7이 정식 출시하고, 곧 ATI에서 DirectX 11 지원 그래픽 카드가 나온다고 하니 지금부터 조금씩 DiretctX 11을 공부하면 좋으리라 생각합니다.

아직 한국에서 DirectX 10 이나 11과 관련된 글이 거의 없는데 'VSTS 2010 스터디'에서는 현재 두 분이 관련 글을 연재하고 있습니다.
DirectX 11을 처음 공부하시는 분들은 여기 글을 보면서 공부하시면 훨씬 더 쉽게 할 수 있으리라 생각합니다.
http://vsts2010.tistory.com/category/DirectX%2011

저작자 표시
신고
by 흥배 2009.09.23 14:02
| 1 |