IntelはSandy Bridgeでグラフィックスコアを従来より大幅に強化した。その強化の方向を、大まかな言葉で表現すると、“今どきのGPUコア”化だ。つまり、NVIDIAやAMDのGPUコアが向かっている方向と、同じ方向へとIntelコアも向かい始めた。これまでの独自のアーキテクチャから、他社との共通項の多いアーキテクチャへと変わりつつある。

　簡単に言えば、低コスト化を特に重視し、CPU屋的な発想で作っていたのが、これまでのIntelグラフィックスコアだ。そのため、パフォーマンスと効率、そして汎用的なプログラム性では弱かった。それに対して、Sandy Bridgeグラフィックスコアは、GPU的な発想でコストよりパフォーマンスと電力効率を重視し、さらに汎用性を考慮して作られている。

　Sandy Bridgeグラフィックスコアが目指すのは、相対的に性能の高い3Dグラフィックスと、汎用コンピューティング向け機能、効率的なメディアプロセッシングの組み合わせだ。具体的には、(1)プロセッサに固定機能ユニットを組み合わせることによる効率的な3Dグラフィックスの実現、(2)プロセッサへの汎用コンピューティングやメディア処理向け命令や機能の付加、(3)メディア処理のための固定機能ユニットの強化、これらの改良をSandy Bridge世代からスタートさせた。

　こうした改良の多くは、他社のGPUコアがやって来たことを追いかけるものだ。Intel独特の部分もあるが、他社GPUコアとのギャップを埋める技術が多い。Intelはその概要を9月のIntel Developer Forum(IDF)で説明しているが、その説明からは、従来のIntelグラフィックスの弱点がどこにあったかが明瞭に見えてくる。また、NVIDIAやAMD GPUの強味がどこにあるのかも見えてくる。

Sandy Bridgeのグラフィックスコア

　Sandy Bridgeのグラフィックスコアの全体の構造は、Intelコアの従来の構造を踏襲している。下の図は、Intelの説明をベースに、スタンダードなGPUのブロック図に合わせて起こした図だ。Intelは大枠の構造は維持しながら、その中身を取り替えるという手法を取った。

Sandy Bridgeのグラフィックスコアの全体の構造 PDF版はこちら

　図の上側に並ぶのは、3Dパイプラインのセットアップや制御のためのユニット群。これらのユニットがグラフィックスパイプライン中の頂点やトライアングル、ピクセルなどの処理に必要なセットアップやアーリーZテストなどハンドルする。

　中央部分はプログラマブルなシェーダプロセッサアレイ。いわゆるユニファイドシェーダアーキテクチャ型で、シェーダプロセッシングはこのアレイで行なう。Intelアーキテクチャでは、個々のプロセッサを「EU(Execution Unit)」と呼んでいる。Intelグラフィックスでプロセッサ数を数える場合は、このEUを数えている。EUの実態はSIMD(Single Instruction, Multiple Data)型の演算プロセッサだ。

　EUアレイの右上はメディアスタック。固定機能のビデオデコーダのほか、EUアレイでメディアプロセッシングを実行するための制御ユニットなどがある。

　EUアレイの右に並ぶのはメモリからデータを読み込んで加工するサンプラ系ユニット群。テクスチャサンプラは、メモリからフェッチしたテクスチャを、3Dグラフィックスパイプライン向けにフィルタする。テクスチャサンプラは各EUの共有ユニットとなっている。

　　テクスチャサンプラはメモリインターフェイス(Sandy Bridgeの場合は内部リングバス)に直結するシステムメモリインターフェイスからのバスを持つ。従来のIntelグラフィックスコアでは、テクスチャ読み込みはキャッシュされている。おそらく、Sandy Bridgeのグラフィックスコアも同様の構造になっていると推定して図を起こした。もしかすると、コア内部のメモリ階層は変わっているかもしれない。

　もう1つのメディアサンプラは、メディアプロセッシング専用のフィルタだ。こちらもシステムメモリインターフェイスに接続されているはずで、テクスチャサンプラとパスを共有している可能性がある。

　このほか、通常のGPUと同様にピクセルオペレーション(ROP)を行なうユニットがある。ピクセルオペレーションはメモリインターフェイス(Sandy Bridgeの場合は内部リングバス)に直結するシステムメモリインターフェイスに接続されており、レンダーキャッシュが付属している。

　このように、Sandy Bridgeグラフィックスコアは、一般的なGPUのユニットを揃えている。その点は、同じIntelのアーキテクチャでも固定処理機能ブロックをほとんど持たず、ソフトウェア処理中心だったLarrabee(ララビー)とは大きく異なる。LarrabeeはラスタライザやROPユニットのような、GPUなら必須と言われる機能ブロックすら持たなかった。

　Sandy Bridgeグラフィックスコアは、基本構成は従来のIntelグラフィックスコアを踏襲している。しかし、3Dグラフィックスとメディア処理においては、従来と大きな違いがある。それは、プロセッサでのソフトウェア処理から固定機能ユニットでのハードウェア処理への移行だ。

　これまでの世代のIntel内蔵グラフィックスの設計では、3Dグラフィックスパイプライン中の固定処理の多くを、プロセッサであるEUで実行するカーネルプログラムでエミュレートしていたという。グラフィックスコアのダイ面積を小さくするためだったとIntelは説明している。ダイ面積を食う固定ユニットを持たず、プログラマブルユニットで実行するなら、コアを小さくできる。

　この手法では、ダイ面積当たりのパフォーマンスは高くなるが、電力については不利になる。電力では、通常、固定機能ユニットが最も低消費電力で、プログラマブルプロセッサは電力を食うからだ。そのため、従来のIntelグラフィックスでは、電力当たりのパフォーマンスは決して高くなかったという。そこで、Sandy Bridgeでは、3Dグラフィックスパイプラインの固定機能は、基本的に固定ハードウェアで実装した。

　「従来は、パイプラインの各部分を、プログラムで実行できるかどうか考え、可能な場合はプログラムで実行するように設計していた。しかし、 Sandy Bridgeではプログラムで実行する必要があるのかどうかを考え、必要がなかったら、固定機能ハードウェアで実装している」とThomas Piazza氏(Intel Fellow, Director, Graphics Architecture)は説明する。

ソフトウェア処理とハードウェア処理の比較 PDF版はこちら

　できる限りプロセッサで実行していたのを、できる限り固定機能ユニットへオフロードする。これは、電力効率とスループットを第一に考えた場合は、常道の手段だ。その結果、グラフィックス処理の電力効率が上がり、レイテンシは短縮され、スループットも向上したという。シェーダプロセッサは、本来の仕事であるシェーダの実行に、より多くのサイクルを割くことができるようになった。

　「シェーダにはシェーダの仕事をさせる。それ以上のことはさせない」(Piazza氏)。

Sandy Bridgeのシェーダ

　こうした改良の結果、Sandy Bridgeグラフィックスコアでは、原理的に電力当たりのパフォーマンスが上がるだけでなく、ドライバソフトウェアも軽くなったという。固定機能のAPIを、プロセッサプログラムにJITコンパイラが変換する必要がなくなったからだ。「ドライバはこれまでの世代に較べて、劇的にランタイムが減った」(Piazza氏)と言う。

　ドライバに必要なCPUパフォーマンスが減ったことで、その分、CPUコア側の消費電力も減ったとIntelは説明する。つまり、グラフィックス処理時の、グラフィックスコアの電力効率だけでなく、CPUコア側のドライブランタイムの電力効率も改善されたという。

　固定機能ハードウェア化による効率の向上は、Intelグラフィックスでは新しいが、一般的なGPUコアでは当たり前の話だ。Intel以外のメーカーにとっては、全然、新しい話ではない。重要な点は、Intelの設計ポリシーが180度転換して“GPUらしいグラフィックスコア”を作ろうとしていることだ。

　これは、Larrabeeの時の“CPUらしいグラフィックスコア”を作ろうという方向とは完全に逆だ。LarrabeeではIntelは、できる限り固定ハードウェアを排除して、プロセッサで処理しようとした。

　3Dグラフィックスパイプラインの中の固定的な処理を、固定ハードウェアユニットで実行することで、効率的な3Dグラフィックスを実現する。EUは、固定機能のエミュレーションから解放された分だけ、本来のシェーダプロセッシングに集中する。Sandy Bridgeアーキテクチャでは、こうした改革が始められた。

　それに合わせて、Sandy Bridgeでは、プロセッサであるEUを、より汎用に使いやすくするための改革もスタートした。より複雑なシェーダプログラムや、非グラフィックスの汎用コンピューティングプログラム、メディア処理プログラムなどを走らせやすくするためのプロセッサの改良だ。

　具体的には、レジスタファイルの拡張、ベクタのコントロールフロー制御の強化、CISC(Complex Instruction Set Computer)的な命令の複合化による命令ステップ数の削減、固定ポイント整数演算の強化、データフォーマット変換やシャッフルなどの命令の追加、ベクタ粒度の変換、超越関数のスループットの向上、マルチカーネルランニングなどが公式にIDFで明らかにされている。これらの改良によって、Sandy BridgeのEUは、アーキテクチャの上ではスループットが向上するだけでなく、効率的に走らせることができるプログラムの幅が広がった。

Sandy Bridgeの改良点

　まず、EUではレジスタファイルのサイズが大きくなった。これまで、Intelのグラフィックスコアではレジスタファイルが限られており、レジスタが足りなくなるケースがあった。そのため、EUはレジスタ溢れを処理する機能を備えており、レジスタから溢れたデータをキャッシュやメモリに待避させていたという。

　しかし、こうしたレジスタ溢れの処理は、スループットを下げる可能性があり、また、データ移動によって無駄な電力を消費する。そこで、IntelはSandy Bridgeではレジスタファイルを拡張、ほとんどのケースで、全てを物理レジスタに格納できるようにしたとPiazza氏は説明する。ただし、依然として一部のワークロードのためにレジスタを待避させる機能は残しているという。Intelが機能と言っているからには、レジスタ溢れはハードウェアで処理していると推定される。

　GPUでは一般にスレッド当たりの物理的なレジスタ数が固定されておらず、グラフィックスなどではランタイムがシェーダプログラムをネイティブ命令に変換する際に割り当てる。通常のグラフィックスは必要レジスタ数が少ない(かつては4～8本だった)場合が多いが、汎用プログラムでは32レジスタやそれ以上が望ましい場合がある。しかし、一定数のスレッドを立ち上げようとすると、スレッド当たりのレジスタ割り当てを減らさなければならない。

　GPUはマルチスレッディングでメモリレイテンシを隠蔽する度合いが強いため、立ち上げるスレッド数が多く、必要とするレジスタの量も多い。立ち上げられるスレッド数が制限されると、メモリレイテンシによってストールする確率が高くなってしまう。CPUはキャッシュメモリでレイテンシを隠蔽するが、GPUはレジスタでレイテンシを隠蔽している。

　汎用プログラムや複雑なシェーダプログラムは、レジスタを多く必要とするため、レジスタファイルを圧迫する。その状況で一定数のスレッドを立ち上げるためには、物理レジスタに収まりきらないデータを内外のメモリにいったん待避させるしかなくなる。それが、今までのIntelグラフィックスの状況だったと推定される。

　レジスタファイルを拡張すれば、この問題は解決できる。もちろん、レジスタを増やした分だけ、ダイエリアを食う。実際、NVIDIAやAMDのGPUは、ダイのある程度の部分はレジスタで占められている。Intelグラフィックスも、それに近づきつつある。

Sandy Bridgeのダイレイアウト PDF版はこちら