●パイプライン並列化がこれまでの流れ GeForce FX 6800(NV40)の登場で、GPUは新しい世代に入った。特に重要なのは、GPUの処理の並列度と効率を上げるためのアプローチが重要になったことをNV40が示していることだ。
GPUもCPUと同様に、その性能はラフに言うと、動作周波数×並列度×効率で決まる。そしてCPUと同様に、このうち周波数は引き上げることが徐々に難しくなっている。それは、消費電力が向上しているためと、チップ自体の複雑度が増しているからだ。そのため、いかに効率よく多くの命令を並列実行できるかが、GPUの性能のカギになりつつある。 伝統的にはGPUはパイプライン数を増やすことで処理性能を向上させてきた。これは、今のスーパースカラになる前のCPUが、シングルパイプ(486)からデュアルパイプ(Pentium)へとパイプラインを増やして性能を上げたことと同じ意味を持つ。CPUと違ってGPUはストリーム処理なので、パイプラインを増やすことで簡単に性能を上げることができた。その基本自体は、現在のようにProgrammable Shader中心のアーキテクチャになっても変わらない。 GPUにとってパイプライン(現在はShader数)数を増やすことは、CPUにとってプロセッサコアを増やすのと多少似た意味がある。それは、「スレッドレベルパラレリズム(TLP:Thread-Level Parallelism)」の向上ができるからだ。GPUの場合、Shaderの観点から見ると、1頂点(Vertex)が1スレッド、または1ピクセルが1スレッドと考えることができる。 従来の固定機能パイプラインの場合、話は簡単だった。単純な命令ストリームをいかに速く実行するかだけを考えればよかったからだ。「GPUはストリーミングプロセッサとして進化してきた。スループットオリエンテッドの設計だった」とIntelで3Dグラフィックスを担当するKim Pallister氏(Senior Technical Marketing Engineer, 3D Graphics)は言う。 そのため、固定機能のGPUは約200ステージ(NVIDIAの場合)と非常に深いパイプラインを持ち、レイテンシは長いがスループットを高い構造を取っていた。分岐のない命令ストリームを処理するだけなので、こうしたパイプラインを複数化することで、容易に並列化ができたわけだ。 ●CPU同様にメモリと分岐が性能向上の壁に だが、NV40世代になると、話はそう単純ではなくなる。モダンCPUのパフォーマンス向上の2大障壁である、メモリアクセスと動的分岐によるペナルティが、GPUでも壁になり始めたからだ。 実際には、NV3x/R3xx世代からすでに単純なパイプラインの拡張のストーリは通じなくなり始めていたのだが、NV40ではますます問題はクリティカルになり始めた。それは、NV40がDirectX 9 Programmable Shader 3.0をハードウェアサポートするからだ。 Shader 3.0では、Vertex Shaderにテクスチャフェッチ(取り込み)機能が加わり、Pixel Shaderにダイナミック分岐が加わった。これらは、いずれもShaderの効率を下げる可能性を秘めている。テクスチャフェッチはメモリアクセスレイテンシを生じさせる可能性があり、動的な分岐はShaderの処理する命令ストリームを乱すからだ。もちろん、テクスチャのレイテンシはピクセル側では以前からあった問題だし、Vertex Shader側はNV3xでもダイナミックフロー制御をサポートしていた。しかし、よりクリティカルになり始めたのは確かだ。 そのため、NVIDIAではいくつかの工夫をNV40アーキテクチャに施している。 1つは、階層キャッシングによるメモリレイテンシの隠蔽だ。NVIDIAのテクスチャユニットは、Vertex ShaderもPixel ShaderともにL1キャッシュを内蔵する。さらに、共有の大容量のL2キャッシュを備え、テクスチャをキャッシュする。CPUで言えば、各CPUコアがそれぞれL1を内蔵、さらに共有のL2データキャッシュを備えるのと同じような構造を持ち始めたわけだ。 もう1つの工夫は、テクスチャフェッチをしてテクスチャ待ちをしている間に、他の依存性のない命令を実行すること。ここでNVIDIAはスレッディングという言葉を使っているのだが、これは異なる頂点に対するシェーダを同時に走らせることができるという意味ではないらしい。 ただ、長い目で見ると、もしShaderの効率を高めて、メモリアクセス待ちをもっと隠蔽しようと思ったら、GPUのShaderもCPUと同様に、ある程度のTLP(スレッディング技術)をShader内部に実装するようになるのかもしれない。ただし、CPUのようにHyper-Threadingのような「サイマルテニアス マルチスレッディング(Simultaneous Multithreading:SMT)」は必要がないだろう。メモリ待ちなどをトリガにしてスレッドを切り替える、「Coarse-Grain Multi-threading」などが向いているかもしれない。 分岐については、NVIDIAも「Pixel Shaderの分岐は(処理が)重いことを顧客にきちんと説明している」という。ただ、長い目で見るとPixel Shaderのこうした新機能も、GPUの性能にとってプラスに働く。 例えば、NVIDIAがNV40世代のデモプログラムで新たに登場させたキャラクタ人魚の“Nalu”では、皮膚と鱗を、単一のシェーダプログラムでシェーディングしている。Pixel Shader 3.0の動的分岐を使い、シェーダプログラムを、スキンシェーダとクロスシェーダそれぞれに分岐させている。 これによって、まずシェーダの管理は容易になる。そして、GPUハード側で、例えばシェーダプログラムをキャッシュできれば、シェーダの切り替えが高速になる。 ●命令レベルの並列性も高める方向へ
また、NV40では、命令レベルの並列度を高める仕組みも備え始めた。例えば、Pixel Shader内部には2つのShader演算ユニットを備える。また、4wayのSIMDユニットであるPixel Shaderの演算ユニットを、3コンポーネント対1コンポーネント、あるいは2コンポーネント対2コンポーネントに分割して異なる命令を実行できる。つまり最大で4命令をPixel Shader内で並列実行できる。つまり、Shader内では命令レベルの並列化へと向かっているわけだ。 しかし、どうやってNVIDIAは、16個ものPixel Shaderにそれぞれ2基づつのShader演算ユニットを搭載できたのだろう。浮動小数点演算ユニットは膨大なトランジスタを消費すると言うのに。 そこにはマジックがある。というのは、NV40のPixel Shaderでは両Shaderは完全に同じ演算を実行できるわけではなく、片方のShaderは実際にはテクスチャユニットと排他利用、つまり一部のロジックを共有しているからだ。 そのため、Pixel Shaderへのトランジスタの付加は最小にとどめて、2並列を実現できたと推測される。もっとも、その結果として、2つのShaderユニットでは、完全に同じ演算を並列できるわけでもないし、2つのShaderでの演算とテクスチャプロセッシングを並列に行われるわけでもない。 例えば、NVIDIAの示したシェーダコードサンプルを見ると、積和算命令は下のShaderユニット(Shader 2)にしか発行されていない。積算命令は上のShaderユニット(Shader 1)に対しても発行されているのに。そのことから積和算ユニットを備えるのはShader 2だけだと推定できる。これは、浮動小数点演算ユニットの設計では常套的な手段の1つで、コストの大きい(トランジスタを食う)積和算ユニットは最小限にとどめるわけだ。 また、NV40では、こうしたマルチイシューアーキテクチャで通常必要となるハードウェアも、簡略化していると推定される。それはスケジューラだ。 x86などのCPUでは、マルチイシューのスーパースカラ構造の場合、ハードウェアスケジューラで命令をスケジューリングする。それに対して、NV40の場合はハードウェア側での最適化サポートはあるものの、基本的にはデバイスドライバ内のランタイムと、さらに静的コンパイラでスケジューリングを行なう。スケジューリングしやすいように、静的コンパイラでNV4x向けのオプションを使ってコンパイルしないと、完全な最適化はできないとNVIDIAは言う。 Shader内で命令を並列実行できるとはいえ、前後の命令に依存性がある場合にはもちろん並列化はできない。さらに、コンパイル時の最適化も必要となるため、実際にどこまで命令レベルの並列化ができるのかはまだわらかない。しかし、GPUがShader内での命令レベルの並列化を強化する方向へと向かい始めたことは確実だ。 こうして見ると、NV40は6 Vertex Shader+16 Pixel Shader+16ピクセルエンジン構成によってスレッドの並列性を高めただけでなく、各Shader内部の並列性や効率を高めることにも注力していることがよくわかる。 そして、おそらくこれはNVIDIAだけのトレンドではない。ATI Technologiesの次世代アーキテクチャR420も、間違いなくShader内部の並列性と実行効率の向上を図ってくるだろう。そうなると、ますますGPUの性能はパイプライン数(この数え方自体が無意味になりつつあるが)では比較できなくなって行くだろう。 □関連記事 (2004年4月26日) [Reported by 後藤 弘茂(Hiroshige Goto)]
【PC Watchホームページ】
|
|