SIGGRAPH 2008 - IntelのCPU・GPUハイブリッドプロセッサ「Larrabee」の正体

グラフィックスプロセッサとしてLarrabeeを活用した場合

Larrabeeは自由度が高く、GPU以上のことが出来そうだということは何となく伝わってきた。とはいっても、一般ユーザーとしてはLarrabeeは通常のグラフィックスプロセッサとして使いたいと思うはずだ。

結論から言うと、LarrabeeはOpenGLやDirectXからGPU的に使うことができる。しかし、前述したようにGPU的な専用ロジックがテクスチャユニットだけであり、それ以外はソフトウェアとして実装する必要がある。

ここまで徹底したソフトウェア実装のグラフィックスパイプラインにはどのようなメリットがあるのだろうか。

下の図は「F.E.A.R.」「GEARS OF WAR」「HALFLIFE2-EPISODE2」というベンチマーク素材に選ばれることの多いPC-3Dゲーム達を実行した際のグラフィックスパイプラインにかかる負荷を割合で示したグラフだ。

たとえばF.E.A.R.では他の2タイトルに比べてラスタライズ処理とアルファブレンド処理への負荷が大きいことがわかる。最新のDirectX 10世代のGPUでは、頂点シェーダとピクセルシェーダの個数を動的に変動できる統合型シェーダアーキテクチャを採用するが、これをもってしてもラスタライズ処理とアルファブレンド処理の負荷を低減させる方策はない。しかし、Larrabeeの場合、ラスタライズ処理とアルファブレンド処理までがソフトウェアであり、x86コアがその処理に従事しているので、一時的に、これらに従事するx86コアを増やすことは出来る。「これはレンダリングパイプラインがフルソフトウェア実装であるLarrabeeの特長である」とSeiler博士は強調する。

それでは、Larrabeeのソフトウェアレンダリングパイプラインの実装はどのようになっているのだろうか。

これを簡単に表現したのが次の図である。なお、この図は頂点シェーダとピクセルシェーダのタスクだけを切り出して見せたものだ。

まず、プリミティブ(ポリゴンや線分)単位で頂点データを処理していくが、ここでラスタライズ処理までを実行する(FrontEnd)。ここでは頂点処理スレッドとラスタライズ処理スレッドが複数走ることになり、この負荷バランスに応じて複数のx86コアが動的に従事する。

ラスタライズ処理が終わるとこれはピクセルタスクに分解されるが、これは64×64ピクセル(あるいは128×128ピクセル)のような適当なタイル(Bin Set)としてメモリに出力される。

この後、ピクセル単位の処理に従事するx86コアはメモリからひとかたまりのピクセルタスク(Bin Set)を取り出して、実際のピクセルシェーダー的な処理と、さらに後段のアルファブレンディング処理などまでを行う(BackEnd)。

Backend部分についてさらに詳しく見ていこう。

各x86コアは独立した4スレッドを処理できると述べたが、ピクセル単位の処理に従事するx86コアは、うち1スレッドをセットアップスレッドに割り当てている。ここではメモリから取り出したひとかたまりのピクセルタスク(Bin Set)を、実際のピクセルタスクとして発注する処理を行う。

残った3スレッドが実際のそのピクセルタスクを取り出して前Z処理(カリング)を行い、ピクセル陰影計算をして、後Z処理(Z更新)を行い、必要であればブレンディング計算を行う。

ここで注目したいのはピクセルの入出力先がL2キャッシュになっているという点だ。

3つのピクセル処理スレッドはピクセルの書き出し、Z処理、アルファブレンディング処理で3つのピクセルに対して入出力を行うことになるが、セットアップスレッドの方で事前に3つのピクセル処理スレッドに必要なデータはL2キャッシュに読み出しておくので、実際の3つのピクセル処理スレッドの入出力はL2キャッシュに対して行われるのだ。一般的なGPUでは入力に関してはキャッシュが効くが出力に関しては実際にメモリアクセスが発生する。「局所的なメモリに対する入出力はL2キャッシュ上ですませられるLarrabeeアーキテクチャでは大幅なメモリバス消費の低減に結びつく」とSeiler博士は述べる。

これを調べた結果が以下のグラフになる。

オレンジがLarrabeeのL2キャッシュを利用したときのメモリバス消費の推移で、紫が出力結果をメモリに直に書き出したときのものになる。その違いは明白だ。