■後藤弘茂のWeekly海外ニュース■
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(ララビー)」のような高スループットCPUがグラフィックス処理に進出する余地を増やす。また、プログラマブル化を進めるGPUの次の発展の可能性も示している。
さらに、3DグラフィックスAPIが、GPUのアーキテクチャの変化を引っ張るという流れ自体も、変わりつつある。DirectXとGPUアーキテクチャの変化は連動し続けるだろうが、支配的ではなくなる。DirectXに定義されない部分での拡張が、GPUのアーキテクチャ変化の多くを占めるようになるからだ。
実際、NVIDIA GPUのG80でのアーキテクチャ拡張は、グラフィックスAPIに直接関係ない部分が大半を占めていた。また、GPUがグラフィックスAPIとは関係ない部分で拡張した機能を、DirectX Compute Shaderで取り込むといった逆転現象も起きている。Larrabeeのように、高スループットCPUの上にグラフィックスパイプを載せるアプローチも登場している。
●DirectX の移行で進んできたGPUの肥大化GPUはこれまで、DirectX の世代が進む毎にアーキテクチャを変化させ、その度にチップを肥大化させてきた。
 |
| GPUのダイサイズ図 |
チップの肥大化は2つの要因による。1つは、パフォーマンスを倍増させたため。演算性能を伸ばすには、より多くのリソースが必要になり、GPUのトランジスタ数を押し上げた。もう1つは、プログラマブル化を進めたため。個別に処理を行なっていた固定機能ハードを、単一のプログラマブルプロセッサに集約させると、必要なトランジスタ数は減る。しかし、そのままでは性能が大幅に落ちてしまうため、同じ性能を保つだけでも演算リソースを大幅に増やす必要が生じる。結果として、GPUの場合は、固定ハードからプログラマブルハードへの切り替えで、トランジスタ数とダイサイズ(半導体本体の面積)を増大させきた。
過去数回の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に定義されているグラフィックスパイプラインをハードウェアとして実装する方向にあった。頂点処理→ラスタライズ→ピクセル処理&テクスチャリング→フレームバッファプロセッシングという、一連のグラフィックスパイプラインに沿った実装は、プログラマブル化が進んだDirectX 9世代でも変わらなかった。頂点シェーダ(Vertex Shader)プロセッサとピクセルシェーダ(Pixel Shader)プロセッサは、それぞれ別な実装だった。
 |
| DirectX 8 APIとGPU実装 |
 |
| DirectX 9 APIとGPU実装 |
だが、DirectX 10では、API側で定義される各シェーダステージが、ほぼ共通した仕様となった。また、パイプラインの途中でもメモリへのアウトプットができる「Stream Out」などが加わった。そのため、シェーダを実行するプロセッサを共通化した「ユニファイドシェーダ(Unified-Shader)」化する方が合理的となった。
結果として標準的なDirectX 10世代GPUでは、1種類のシェーダプロセッサが全てのシェーダステージを実行。その回りに、テクスチャフィルタリングユニットやラスタライザといった固定ハードウェアが付帯するアーキテクチャに変わった。これは、GPUの構造の根本的な転換で、GPUにとっては最大規模のアーキテクチャ改革となった。シェーダプロセッサを拡張するだけでなく、1種類のシェーダプロセッサでさまざまなシェーダを走らせるためのスケジューリングなど、見えない部分でハードウェアが肥大化した。
当時ATI TechnologiesのPC向けGPUユニットを率いていたRick Bergman(リック・バーグマン)氏(現Senior Vice President, AMD)は、DirectX 10当時に「DirectX 10をサポートするためには、(DirectX 9世代GPUより)30～40%程度のロジック(回路)が余計に必要だ」と説明した。そして、実際にはパフォーマンスアップ分も含めると、トランジスタ数は倍増した。
 |
| DirectX 10 APIとGPU実装 |
●図で明瞭になるGPUアーキテクチャの変化
上のチャート群は、DirectX の各世代の論理上のパイプラインと、それに対応する典型的なGPUアーキテクチャ実装の概念図だ。名称の混乱を避けるため、若干、ステージやユニットの名前をモディファイしてある。論理図の構成も、データフローをより明確にするため、若干手を加えてある。
例えば、パイプライン最終段のビデオメモリ上でのピクセル等のプロセッシングについては、DirectX 9までの図で示した比較的汎用の表現である「フレームバッファプロセッシング(Framebuffer Processing)」と、DirectX 10以降につけられた名称「アウトプットマージャ(Output Merger)」の共通性を示すために、アウトプットマージャの後に「フレームバッファプロセッシング」と加えた。また、ピクセルシェーダプロセッサからビデオメモリへのダイレクトな出力(アウトプットマージャステージでサポートされる)を明瞭にするため、ピクセルシェーダプロセッサとアウトプットマージャの間に、メモリへの出力ラインを加えた。
簡略化のために省いたものもある。例えば、ジオメトリシェーダ(Geometry Shader)でサポートするプリミティブのプロセッシングは、概念的にはDirectX 9世代ではセットアップ/ラスタライザ(Setup/Rasterizer)のステージに固定機能として含められると考えられるが、図中では外した。DirectX 10でのDirectX Compute Shaderは、DirectX 11と従来DirectX 10との違いを明確にするために示さなかった。
必須項目ではないが重要な機能は破線で示した。例えば、DirectX 9世代での頂点シェーダでのテクスチャフェッチは、DirectX 9の基本仕様では必須でなくNVIDIAなどは対応しなかったため破線とした。
実装アーキテクチャ図の方では、論理図との相対的な関係を示すために、特殊な名称を加えた。例えば、ユニファイドシェーダプロセッサからメモリへのダイレクトな書き出しは、DirectX 10の論理パイプライン上での名称であるストリームアウトで示した。
完全に正確な図というわけではないが、概念は掴むことができると考えている。
●専用ハードウェアを最小に抑えプログラマブルGPUに適応図を見ると、DirectX 10でガラリとGPUの構造が変わったことがよくわかる。DirectX 9までは、論理パイプラインが、ほぼ反映された形で実装されていた。しかし、DirectX 10では、論理パイプと、実際のGPUのユニットとデータフローは全く異なっている。DirectX 10がGPUアーキテクチャにとって最大の転換だったことがよくわかる。
この転換の結果、2つの方向が有効になった。(1)1つは、グラフィックスパイプラインで、論理上のプログラマブルステージを増やすこと。論理上のプログラマブルシェーダを増やしても、ハードウェア自体に別設計のプロセッサを加える必要がないため、簡単に増やすことができる。(2)もう1つは、専用ハードウェアを持たないかほとんど持たない汎用的なプロセッサでサポートすること。Intelが試みる「Larrabee」のように、テクスチャユニット以外の専用ハードを持たないアーキテクチャでも容易だ。
DirectX 11は、こうしたDirectX 10で敷いた流れに乗っている。まず、シェーダステージ数が増えた。「テッセレーション(平面分割:Tessellation)」のサポートのために、固定機能のテッセレーションステージ以外に、シェーダステージが追加されたからだ。固定機能は最小限で済むように定義されている。そのため、Larrabeeのようなより汎用のCPUは、新たに加わる要素も全てプロセッサ上のソフトウェアとして実装することができそうだ。
 |
| DirectX 11 APIとGPU実装 |
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のダイサイズ(半導体本体の面積)を抑えることに使う余裕が産まれる。つまり、コストを抑える方向に向かうことができる。
 |
| TSMCのプロセスロードマップ |
また、このアプローチは、Larrabee型の高スループットCPUとも親和性が高い。Larrabeeは、GPUが必ず固定機能で実装しているラスタライザまで、プログラマブルなプロセッサコアで実現する。そのため、テッセレータ専用ハードウェアも、プロセッサコアの上にソフトウェアで実装するのが自然な流れとなるだろう。つまり、テッセレータをハードで載せるのなら、その前に、より必要性の高いラスタライザをハードで載せるだろう。
テッセレータハードが行なうのは頂点の生成だけなので、特殊な演算ユニットが必要なわけではない。生成される頂点数は膨大になる可能性があるが、プロセッサコアに内部メモリを持つため、この問題も解決できると推測される。
ここで重要な点は、DirectXではどんどんシェーダステージが積み重なり複雑になって行くが、ハードウェアは一定のシンプル性を保つことができることだ。これがユニファイド型のシェーダプロセッサの利点で、DirectX 10がその扉を開いた。今後、API上で定義されるパイプラインステージがいかに複雑になろうとも、この路線に乗っている限り、ハードウェアの複雑化は抑えられる。
しかし、皮肉なことに、このことはグラフィックスAPIのハードウェアに対する影響力の低下を招くだろう。ハードウェアは、固定的なパイプラインをいかに速く処理するか、ではなく、柔軟なプロセッサの上でいかに上手にプログラマブルなステージを走らせるか、に向かう。グラフィックスの機能は、固定ハードウェアとしてではなく、プロセッサ上のシェーダプログラムとして実現される。つまり、GPUとグラフィックスAPIの関係は、汎用CPUとOSのような関係になって行く。OSがCPUを完全に支配はできないように、グラフィックスAPIもGPUを支配できないようになる。