Intelは、現世代のNehalem(ネヘイレム)マイクロアーキテクチャはパフォーマンスデスクトップとサーバー向けCPUから投入した。しかし、次世代CPUアーキテクチャ「Sandy Bridge(サンディブリッジ)」では、メインストリームデスクトップとノートPC向けCPUから投入する。そのため、Sandy Bridge系CPUの浸透するペースは、Nehalem系CPUと較べると格段に速いペースになると予想される。Intelは、今週、北京で開催する「Intel Developer Forum(IDF)」でも、Sandy Bridgeについて何らかの情報を公開すると見られている。

Intel CPU移行図 PDF版はこちら

　Sandy BridgeのCPUコアの、実行パイプラインの基本構造そのものはNehalemとそれほど変わらない。命令発行ポートは合計6つで、1サイクルで最大6個のuOPsの発行が可能だ。3ポートが演算で3ポートがロード/ストアに割り当てられている点もNehalemと同じだ。このことは、命令のフェッチから実行までの効率が、Nehalem世代とほぼ変わらないことを示唆している。

　ただし、Sandy Bridgeで大きく変わった点もある。まず、演算パイプに256-bit幅のSIMD(Single Instruction, Multiple Data)命令を含むAVX命令の実行ユニットが加えられること。また、ロード/ストアポート群のうちロードとストアアドレスのポートが、それぞれロード/ストア両用のパイプになる。それによって、1サイクルで2ロードが可能となる(ただしL1データキャッシュからの帯域は48Bytes/サイクル)。

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

　AVXでは256-bit幅のSIMD演算が可能で、32-bitデータなら8個を並列に演算できる。従来のSSEの128-bit幅の2倍の演算効率だ。AVXのために、新たに256-bitレジスタYMMが加えられる。また、単純にSIMDの幅を2倍にしただけでなく、レジスタをマスクレジスタとして使うことでレジスタの各スロットに値を選択的に書き込む(あるいは逆にメモリに書き出す)ことも可能になる。

ベクタ命令の拡張 PDF版はこちら

　また、AVXでは、命令エンコーディングフォーマットも大きく変える。x86(IA-32/Intel 64)アーキテクチャでは、これまで命令の頭に「プリフィックス(Prefix)」を加えることで、新命令を実現してきた。しかし、プリフィックスによって命令フォーマットは複雑になり命令長が長くなった。その結果、CPU側での命令のフェッチ&プリデコード&デコードが難しくなってしまった。

　そこで、AVXでは、より効率的で将来の拡張も容易な命令エンコーディングフォーマットシステム「VEX(Vector Extension)」を導入する。これによって、将来的な命令拡張が容易になり、CPUハードウェアでの命令のデコードの負担も減らすことができる。そのため、IntelはVEXベースのAVXへとアプリケーションを誘導しようとしている。AVXは128-bit幅でも使える仕様となっており、128-bit SSEアプリをポートしやすい作りとなっている。

AVXの命令フォーマット PDF版はこちら

　Sandy Bridgeの大きな特徴は、GPUコアがCPUダイに統合されたこと。Sandy BridgeのGPUコアは、ダイレイアウト上ではかなり大きい。CPUコアプラスL2キャッシュと較べると、約2倍の大きさがある。しかし、従来のGMCH(Graphics Memory Controller Hub)のサイズから考えれば、特に肥大化しているわけではない。もともと、GPUコアは、同プロセス換算のCPUコアよりサイズが大きい。

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

　Sandy BridgeのGPUコアの内部アーキテクチャ自体は、現在のIntelのグラフィックス統合チップセットとほぼ変わらない。DirectX 10世代で、テッセレーションはサポートしない。しかし、アーキテクチャ的には大きな特徴が1つある。それはデュアルGPU構造になっていることだ。具体的にはGPUコアが1個の製品と2個の製品の両方がある。

　Sandy BridgeのGPUコアは、シェーダプログラムを実行する実行ユニット(Execution Unit:EU)を12個備えている。現在わかっている範囲では、12個のEUが6個ずつ1個のGPUコアに含まれている。つまり、1個のGPUコアで6個のEUを持つ製品と、2個のGPUコアで12個のEUを持つ製品がある。

　EUは、SIMD(Single Instruction, Multiple Data)型の実行ユニットでハードウェアマルチスレッディングをサポートする。Intelは、EUの数や動作周波数、マルチスレッド数を増やすことで、GPUコアの性能を上げてきた。EUの数は2007年のG35系などに載っていた「Intel GMA Series 3」では8個、2008年のG45などの「Intel GMA Series 4」で10個。Sandy Bridgeではそれが12個となり、しかも2グループのGPUコアに分けられる。

　ここでの疑問は2個のGPUコアが実際にどんな構成になっており、どのように働くのかだ。想定される2GPUコアの構成方法は、大きく3つに分けられる。(1)単純にフル機能のGPUコアを2つ備えた構成、(2)演算ユニットであるEU部分だけが、2グループに分割可能で2つのプログラムを並列に走らせることができる構成、(3)GPUのステージのうちジオメトリパイプラインとピクセルシェーディングは2つに分割されているが、ROP(Rendering Output Pipeline)やスレッド管理は共有されている構成。

Sandy Bridge システムアーキテクチャ PDF版はこちら

　3種類の方法のうち、GPUコアを2重化する(1)が一番実装が重く、EUの実行管理だけを分割する(2)が軽い。ROPは分割しない(3)はその中間だ。

　(1)2個のフル機能のGPUコア構成の場合はSLIライクな構成となり、ROPまで全てを2重化する。この構成は、コアが別ダイ(半導体本体)に分かれていて、異なる物理メモリにアクセスする場合には有効だ。メモリアクセスがクリティカルなROPまで個別に持つからだ。しかし、Sandy BridgeのGPUコア群のように、同じ物理メモリを使う場合には意味が薄い。特に2GPUコアで、1画面だけをレンダリングする場合には、無意味なロスが生じてしまう。

　(3)ROP以外のGPUユニットを分割する方法は、NVIDIAがFermiアーキテクチャの「GF100(GTX 480)」で採用した。GF100は、小さなGPUコアである「GPC (Graphics Processing Cluster)」を4個備え、各GPCは頂点フェッチからシェーダプロセッサ群、ラスタライザ、テッセレータなど、GPUの基本的な機能は全て備える。しかし、ROPとメモリコントローラは共有となっており、GPU全体のカーネルプログラムの実行管理も一元化されている。

　この手法は、ジオメトリパイプラインのボトルネックを解消するのに向いている。ジオメトリパイプラインの負担が重いDirectX 11では、特に有効だ。DirectX 11に対応するAMDも、「ATI Radeon HD 5800(Cypress)」で似たような手法を採っている。しかし、DirectX 11に対応しないSandy Bridgeで意味があるかどうかは、疑問だ。もっともジオメトリパイプも含めたGPU構成をスケーラブルに調整できる利点があり、その点はSandy Bridgeでも意味がある。

　(2)EUが2グループに分割され、2つのプログラムを並列に走らせることができる構成は、最も単純だ。これはGPUの1つのトレンドで、例えば、NVIDIAのFermiアーキテクチャでは個々の「SM(Streaming Multiprocessor)」が、コンテクストを共有する個別のカーネルプログラム(それぞれの間に依存性がない場合のみ)を走らせることができる。

　また、IntelのLarrabeeになると、16個のコアがそれぞれ別のコンテクストを走らせることができる。別コンテクストを走らせることができると、グラフィックスを描画している間に、物理シミュレーションのプログラムを走らせるといったことが可能になる。Intelの目的が、統合GPUコアの汎用的な活用にあるとすれば、この手法も考えられる。しかし、Intelはこれまで統合GPUコアについては汎用アプリケーションを走らせる方向へ進めては来なかった。

　こうした事情から、現時点ではSandy Bridgeの“デュアルGPUコア”がどのような仕様になっているのかわかっていない。明瞭な点は、GPUコアを内蔵するSandy Bridgeでは、グラフィックスパフォーマンスでも差別化がされていることだ。

Intel CPUデスクトップロードマップ PDF版はこちら