●Sandy BridgeのAVXユニットはフルパイプライン化されている?

　Intelは、次世代のCPU「Sandy Bridge(サンディブリッジ)」に新しいベクトル演算命令である「AVX(Advanced Vector Extensions)」を実装する。AVXの最大のポイントは256-bit幅のSIMD(Single Instruction, Multiple Data)命令をサポートすることで、32-bitの単精度浮動小数点演算なら8-wayでSIMD型並列処理ができる。現在のSSE系命令は128-bit幅で4-wayの32-bit単精度演算なので、フルスピードなら2倍の演算パフォーマンスを達成できることになる。FLOPS値は2倍になるはずだ。Sandy Bridgeの実行パイプラインは、AVX命令のために拡張され、演算ユニットとロード/ストアユニットが256-bit演算サポートに備えて拡張されることが明らかになっている。

Sandy Bridgeの実行パイプライン(PDF版はこちら)

　ここで出てくる疑問は、Sandy Bridgeの演算パイプが256-bit SIMD演算について完全にパイプライン化されており、1サイクルスループットで256-bitを演算できるのかどうかという点だ。Intelは128-bit幅ずつローとハイに分けて、2サイクルで演算を行なうといった実装を選択することもできる。実際、128-bit幅のSSE演算ユニットについては、Intelは当初は64-bit幅での実装を採っていた。もし、IntelがAVXでも同じダブルパンプ型の設計を取ったとすれば、Sandy BridgeでのAVX命令は、SSEの2倍のピークパフォーマンスは達成できないことになる。

　Intelは、まだSandy Bridgeのパフォーマンスについて、具体的な比較数値を明らかにしてない。しかし、4月に開催されたIntelの技術カンファレンス「Intel Developer Forum(IDF) 2010 Beijing」では、その手がかりが公開された。AVX命令を使ったアプリケーションのパフォーマンス比較を、キーノートスピーチの中でデモしたからだ。このデモでは、動画の中の画像トラッキングをAVX命令を使って行なった。デモではAVXを使った場合の処理が14秒で終わったのに対して、AVXを使わなかった場合は35秒かかったと示された。

AVX命令のデモ

●256-bit FPUの実装コストをNehalemでも検討

　このパフォーマンス比較だけを見るとAVX化によって2倍以上のパフォーマンスが出ているように見える。また、Intelは、昨年(2009年)秋のAVX命令についての技術セッションの中で、命令セットの実装による2倍のスピードアップについて、コードアナライザの出力をベースに説明している。論理上のパイプラインがきちんと実装されているなら、AVXでフルスピードを出せるはずだ。IDF Beijingでのデモは、AVXがフルパイプラインで実装されている可能性を高めた。

　もっとも、Intelが256-bitのSIMD演算ユニットを実装したにしては、妙な点もある。それはCPUコアのダイ専有面積だ。Sandy BridgeのCPUコアは、現在のNehalem(ネヘイレム)系CPUコアと比べて、同じ32nmプロセス同士で比較しても10%台程度しかサイズが増えていない。サイズが比較的大きな浮動小数点演算ユニットを倍増させたにしては、ダイの増加は控えめだ。

　そもそも、Intelが現Nehalem世代でAVXのようなワイドSIMDを採用しなかったのは、CPUコアの大型化による汎用性能の効率低下を抑えるためだったので、これは不可解だ。ダイエリアの増加が少ないのなら、AVXを後回しにした理由が薄くなるからだ。この問題について、2月に米スタンフォード大学の公開講義EE380で、IntelのアーキテクトGlenn J. Hinton氏(Intel Fellow, Intel Architecture Group, Director, IA-32 Microarchitecture Development, Intel)が詳しく説明している。それによると、Nehalemのアーキテクチャ検討の段階では、ベクトル命令を拡張した場合は搭載できるCPUコア数が少なくなると判断、パフォーマンス効率を比較した結果、ベクトル命令を拡張しないマルチコア化を選んだという。

Nehalemのマイクロアーキテクチャ(PDF版はこちら)

●CPUコアとGPUコアでL3キャッシュを共有

　Sandy Bridgeは、IntelのメインストリームPC向けCPUとしては初めてGPUコアをCPUに内蔵する。Intelは、Sandy Bridgeの共有L3キャッシュが、CPUコアとGPUコアの両方から共有されることを明らかにした。これは、Sandy Bridge世代ではGPUのキャッシュとバス回りのアーキテクチャが変わる可能性を示唆している。

　伝統的なGPUでは、キャッシュはCPUとは異なる制御をしている。下の図は、旧来のGPUのキャッシュ構造を大まかに示した図だ。グラフィックスパイプラインでは、リードモディファイライト、つまり、読み込んだデータを変更して書き戻すケースが少ない(ピクセル処理などはこれが発生する)。そのため、GPUのキャッシュのほとんどはリードオンリのバッファで、テクスチャ、頂点、命令などは、それぞれ専用のリードオンリキャッシュに格納される。中でもデータ量が多いのはテクスチャで、そのため通常はテクスチャキャッシュは階層構造を取っており、テクスチャL2キャッシュは数百KBクラスの大容量となっている。

GPUのメモリ階層(PDF版はこちら)

　伝統的なGPUでは、内部データパスも、こうしたGPU独特のアーキテクチャに合わせて構成されている。データバス自体が、リードオンリの上りのパスと、ライトオンリの下りのパスに分離されている。テクスチャや頂点はそれぞれ、外部メモリからプロセッサへと「メモリ→キャッシュ→プロセッサコア」という一方向のバスで読み込まれる。通常、このパスでは、クロスバスイッチで複数のメモリコントローラと複数のプロセッサコアが結ばれている。

　こうした上り方向のデータパスとキャッシュメモリ以外に、GPUはプロセッサからメモリへの下り方向のデータパスを持っている。旧来のGPUでは、ピクセルデータがこのパスを通っていた。そのため、伝統的にはこのパスは「ROP(Rendering Output Pipeline)ユニット」を経てメモリに書き込んでいた。

　ROPでの処理の際には、外部メモリ上にあるピクセルのZ値のカラーデータの参照やブレンディングなどの処理が必要になる。そのため、ここにもキャッシュが噛まされている。トランスペアレンシなどの処理では読み込んだピクセルを変更して書き戻すため、このキャッシュとメモリの間はリード&ライトとなっている。

　Intelのグラフィックスコアのメモリ構造も、ほぼこうした伝統型のGPUアーキテクチャに沿っているものと思われる。

●変わりつつあるGPUのキャッシュアーキテクチャ

　Sandy Bridgeでは、GPUコアがCPUコアと大きなL3キャッシュを共有する。そこで出てくる疑問は、GPUコアに対してはL3はどのように振る舞うのかという点と、GPUコア内部のキャッシュとバスの階層をどう構成するかという点。この2点は、CPUも含めたキャッシュの効率と、GPUコアに何をやらせるかという基本的なコンピューティングモデルに深く関わる。

　後者の方から考えると、まずGPUコアの内部のバスを、組み替えるかどうかがポイントとなる。

　例えば、NVIDIAの「Fermi(フェルミ)」アーキテクチャでは、GPUのメモリ階層はCPU型のリード&ライトのキャッシュとなり、メモリ－キャッシュ－プロセッサの間はリード&ライトの双方向バスで結ばれている。これは、GPUに汎用的な処理を行なわせるGPUコンピューティングに最適化したためだ。バスとキャッシュが一元化されたため、メモリに対する「RAW(Read After Write)」ハザードを回避できる。つまり、特定アドレスにデータを書き込んだあとに読み出さなければならないはずが、書き込む前に読み出してしまう危険を回避できる。NVIDIAは、通常のデータパスは一元化しながらも、リードオンリのデータが多いテクスチャだけは別パスにしている。

Fermiのメモリ階層(PDF版はこちら)

　これが、汎用コンピューティングに完全に合わせたIntelの「Larrabee(ララビ)」になると、完全にCPU的なキャッシュ階層となる。Larrabeeは各CPUコアに256KBのリード&ライトのL2キャッシュを備えており、ピクセルも全てL2キャッシュ上に置きタイリング処理することを想定していた。

Larrabeeのメモリ階層(PDF版はこちら)

　Sandy Bridgeでは、L3キャッシュのレベルではリード&ライトにできると見られるため、こうした汎用コンピューティング指向のキャッシュ&バスアーキテクチャにフィットする。そのため、Sandy Bridge GPUコアの内部のキャッシュとデータパスをこうした構造に変えるのかどうかがポイントの1つとなる。

●GPUコアの汎用アプリケーションへの応用にそれほど熱心ではないIntel

　もし、IntelがGPUコアで汎用アプリケーションを積極的に走らせようと考えているなら、当然のことながらキャッシュとパスをFermiやLarrabeeのように組み替えた方がいい。しかし、それはGPUコアのトランジスタ数を増やして、通常のグラフィックスタスクの効率を下げることに結びつきかねない。また、それは、CPUコア側のデータ並列コンピューティングの性能を上げる方向性と、ある程度競合してしまう。

　現状では、IntelはSandy BridgeでGPUコアを大きく変えるとは言っていない。また、AVX命令を組み込むSandy Bridgeでは、データ並列性の高い汎用のワークロードはCPU側で処理するという方向にあるようだ。そのため、GPUコア内部キャッシュとパスは従来のままだと推定される。

IntelのGPUコアのブロックダイアグラム(PDF版はこちら)

　そうなると、Sandy Bridge GPUコアにとってL3の共有はどういう意味があるのか。当然推測できる利点は、より大きなキャッシュによって、キャッシュ効率を高めて統合グラフィックスの弱点であるメモリ帯域の不足をカバーすること。CPUとGPU間でのデータの転送を、オンチップメモリでキャッシュすることで高速化すること。どちらかと言えば当たり前のポイントに落ち着きそうだ。

　GPUコアとのキャッシュ共有では、キャッシュの制御を工夫する必要がありそうだ。現在の3Dグラフィックスアーキテクチャの性質上、GPUコアは大量のテクスチャデータを読み込むケースが発生する可能性がある。そのため、テクスチャの多いゲームなどのアプリでテクスチャをキャッシュしていると、CPUコアと共有するキャッシュが圧迫されてしまう。また、テクスチャデータは、基本的にはリードモディファイライトが発生しない。そのため、テクスチャなどのデータタイプを考慮したキャッシュの制御、例えばテクスチャのキャッシュラインのプライオリティを下げたり、スヌーピングを行なわないといった制御が必要になると推測される。

IDFで示されたSandy Bridgeのアーキテクチャ