［CEDEC 2008＃05］インテル，日本のゲーム開発者にLarrabeeを紹介

　新たなGPUとして開発が進むインテルのLarrabee（開発コードネーム）。2008年8月に開催されたSIGGRAPH 2008とIDFで以前より踏み込んだ発表が行われ，その姿が徐々に明らかになりつつある。
　今回のCEDECにおいては，インテル ソフトウェア技術部アプリケーション・エンジニア久保寺陽子氏と，同部アプリケーション・スペシャリスト太田仁彦氏による「今後のインテル Visual Computingの方向性」と題するセッションが開催され，その中でLarrabeeの紹介が行われた。内容そのものは先のSIGGRAPHおよびIDFで公開されたものがベースだったが，国内の開発者に向けては初のお披露目（といっても実物があるわけではないが）となった。会場に集まったゲーム開発者達の反応を含めてセッションの内容をリポートしよう。

多数のPentiumデザインのコアを使い
並列処理を重視したアーキテクチャLarrabee

　インテルのセッションは，マルチコアでのグラフィックスプログラミングのポイント解説，そしてLarrabeeの紹介という二つのパートに分かれ，前半を久保寺陽子氏が，後半を太田仁彦氏が担当する形で進められた。前半のセッションはゲームプログラマ向けの比較的，実践的な内容だったので，本稿では太田氏が担当した後半の内容を中心に紹介したい。
　「4年前にS3 Graphicsからインテルに移籍した」という太田氏。「過去10年間，さまざまなグラフィックスハードウェアが存在し乱立して淘汰されてきた。その経緯を振り返りながらLarrabeeの可能性を皆さんと共有したい」と述べ，Larrabeeの登場にいたる経過から解説を始めた。
　ご存じのように，グラフィックスハードウェアは当初，プログラム機能を持たない「固定ハードウェア」としてスタートしている。その最終形がDirectX 7で，それは，データを流し込んでやれば3Dグラフィックスを自動的に描く機械のようなものだった。固定的なハードウェアはパフォーマンスを上げやすい反面，自由度は低い。簡単にいって，どのゲームも似たようなグラフィックスしか描けず，ゲームベンダーのオリジナリティを発揮させる余地が少ないところが欠点だ。
　そこで，DirectX 8以降，プログラム機能を取り込む方向へと進化の舵を大きく切り換えることになった。そうした過去を踏まえ，太田氏によるとLarrabeeは「グラフィックスハードウェアに対するインテルの回答」なのだという。

2001年に最終形を見た固定ハードウェア（スライド左側）から，よりプログラマブルな機能を取り込む方向性でグラフィックスハードウェアは進化してきた。右側の雲のように描かれているステージがグラフィックスパイプライン中のプログラマブルな部分である

10個のPentiumデザインコアとCore2 Duoの比較。命令発効（Instructions per issue）の能力はCore 2 Duoに及ばないが，ベクタ演算はCore 2 Duoの20倍の性能が得られたのだという

　Larrabeeを開発するきっかけになったのは，いまから数年前にインテル社内で行われた実験にさかのぼるという。それは「シングルスレッドの性能を追求するのではなく，並列化を追求したらどうなるのだろうか」（太田氏）というもの。「Core2 Duoの半導体面積と消費電力の枠の中で，Pentiumデザインにベクタユニットを合体させたコアをいくつ並べられるか試したところ，10個並べられた」ため，Pentiumベースのコア×10個とCore2 Duoの特性の違いを調べたのだそうだ。
　ここでいう「Pentiumデザイン」は初代Pentium（いわゆるP5）のことで，In-Orderで命令を実行するCPUである。ただし，Pentiumとまったく同じものではなく，「32ビット×16のベクタユニット」が統合されている。ベクタユニットとは，Pentium IIIから導入されたSSEのようなもので，32ビットの値ならば最大16個を同時に処理できる演算ユニットである。

　この実験では上のスライドに示されているように，ベクタ演算に関しては10個のPentiumデザインコアを集積させたプロセッサのほうが高速という結果が得られ，これがLarrabeeの原型になったわけだ。

Larrabeeのアーキテクチャ。複数のPentiumデザインコアとメモリコントローラが1024ビット（双方向）のバスで接続されている

　右のスライドがLarrabeeのブロック図だ。図中「Multi-Threaded Wide SIMD」と描かれた黄色い枠がPentiumデザインのコアで，それぞれのコアが256KBのL2キャッシュを持ち，キャッシュ間が片方向512ビット，双方向1024ビットの高速なリング状のバスで接続される。メモリコントローラやディスプレイコントローラも，このリングバスで接続される。
　なお，現時点でLarrabeeのコア数は正式には発表されておらず，先の10個という数字はインテル社内の実験で使用されたコア数であり，実機が必ずしもそうなるとはアナウンスされていない点に注意して欲しい。ただ，現行の「Core 2 Duoと同じ集積度なら10個」という情報はLarrabeeの姿を予想する上で貴重といえるだろう。

　「Fixed Function」や「Texture Logic」とされているユニットは固定ハードウェアとなる。ほとんどのレンダリング処理をソフトウェアで行おうというLarrabeeだが，テクスチャユニットを固定ハードウェアとして残した理由としては，「テクスチャユニットは特殊で，プログラマブルなハードウェアに比べて固定ハードウェアの方が圧倒的に有利」（太田氏）だからだという。
　各コアのスカラユニットはPentium相当だが，ベクタユニットは現行のSSEとは，やや異なるものが使用されているようだ。

高いスケーラビリティが得られるLarrabee

32ビット×16の処理が可能なベクタユニット。完全なベクタ命令を備えるユニットだという

　Larrabeeのベクタユニットは，メモリ中に散在するデータを取り込むことができる「Scatter/Gather」（ロード/ストア）ユニットを備えている。メモリ中でわざわざデータを整列させずとも一気にレジスタに取り込めるわけだ。また，16個のデータのうち命令の適用をマスクする「Mask Register」を備えるという。

　以上がLarrabeeの概要だが，簡単にまとめるなら，Pentiumデザイン＋ベクタユニットという汎用CPUに近いコアを複数並べたGPU，ということになる。わずかな固定ハードウェアを残すものの，ほとんどのレンダリング処理をソフトウェアで行う点が特徴といえるだろう。

Larrabeeと現行GPUとの違い。それぞれのコアがIAアーキテクチャなので特別なコンパイラは必要ない，という点を太田氏は強調していた

　右のスライドは，セッションで示されたLarrabeeと現行GPUの比較だが，その中で太田氏は，Larrabeeのコアが完全なIntelプロセッサであるため，「細かな制限があるコンパイラではなくフルセットのC，C++が使える」という点を強調していた。
　「細かい制限があるコンパイラ」とは，暗にNVIDIAのCUDAを指しているのだろう。CUDAではGPU向けの開発言語としてCgを用いるが，これはC言語をベースにGPUのためのカスタマイズが加えられており，あくまで“Cライク”な言語である。開発者にとって使い慣れた言語が使えるという点を太田氏はアピールしたかったのだろう。
　さらに太田氏は，Larrabeeが現行GPUが持ついくつかの問題点を解決すると述べる。

　下のスライド（左）は「F.E.A.R.」プレイしている間，各レンダリングステージで生じる負荷の変化を表したもの。ゲームのシーンに応じてステージごとの負荷がダイナミックに変化する。現行のGPUでは，たとえばピクセルシェーダの負荷が増大してもシェーダに割り当てることが出来るリソースが固定されているため，変動に対応できないが，ソフトウェアでレンダリングを行うLarrabeeなら柔軟に対応できるという。

F.E.A.Rプレイ中，各レンダリングステージの負荷は図のようにダイナミックに変化するという。固定ハードウェアを大きく残す現行のGPUでは，このような負荷の変動に対応しづらいと太田氏

現行のGPUはプログラマブルなステージの間に固定ハードウェアを残す。固定ハードウェアにデータを渡すためのシリアライズ（直列化）が必要で，その部分がボトルネックになるが，Larrabeeにはそれがない

　また，現行のGPUでは大まかにピクセルシェーダとバーテックスシェーダという二つのプログラマブルなステージの間に固定ハードウェアがはさまる形のパイプラインを採用する。この固定ハードウェアにデータを渡すためにデータをシリアル化する必要があり，その部分がボトルネックになりがちだが，Larrabeeにはそれがなく，そこも利点だという。
　現状ではLarrabeeを搭載するグラフィックスハードウェアがないだけに性能の評価は出来ないが，Larrabeeによるソフトウェアレンダリングはコア数に比例した高いスケーラビリティが得られるという主張は興味深い。

開発者達はLarrabeeにやや懐疑的？

ライドに示されたようなスケーラビリティが得られるなら，Larrabeeの将来は有望だが，製品がない段階での即断は禁物かもしれない

　最後に短時間ながらQ&Aセッションが設けられたが，会場に詰めかけた開発者達からは順当に（?）いつくかの懐疑的な質問が寄せられていた。
　例えば，「SSEの4×32ビットでさえ効率的に使うのは難しいのに16×32ビットのベクタ演算の効率が上げられるのか？」という質問について太田氏は「良質なツールの提供が重要になってくる」と答えていたが，質問者は納得できない様子だった。実際にプログラムを作成している側からすれば当然の疑問かもしれない。
　ただ，LarrabeeもDirectXのもとでシェーダー言語を使って操る限り，現行のGPUと（パフォーマンスを除いて）ほとんど違いはないはずで，3Dの性能に関してはLarrabeeのソフトウェアレンダラーを提供するインテルの技量次第だろう。Larrabeeのベクタユニットを意識せざるを得ないのは，現在でいうGPGPU的な使い方をしたときに限られるはずだ。

　また，「プログラマにはSPMDモデルの方が使いやすいのではないか」という質問もあった。
　この質問は少し解説が必要かもしれない。現行のGPUでは，一つのデータに対する処理を記述するだけで，あとはGPUが勝手に複数データに対して処理を行ってくれる仕組みを提供している。たとえば，A+1という処理を書いておけば，数百のデータに対して一気に1を足してくれるのだ。このとき，GPU内部でどのように複数データがベクタ化されているかは意識する必要がない。これをSPMD（Single Program，Multiple Data）と呼ぶ。
　一方，Larrabeeはベクタユニットをプログラマが操る必要があると予想される。これは自由度が高いことを意味する一方，プログラマの負担が増えることを意味する。「面倒じゃないか」というわけだ。
　実働する製品がないだけに，太田氏も質問には答えづらそうだったが，いずれにしてもLarrabeeは未だに不明な部分が残るハードウェアでもある。そもそも，プログラマブルなハードウェアでは性能が上げられないという理由で固定ハードウェアが導入された3Dのレンダリングの歴史を，一気にソフトウェアオンリーに戻そうというのだから，パフォーマンスやプログラマビリティに疑問の声が上がるのは無理もない。
　2009年の登場が予定されているLarrabeeだが，「非常に興味深いものになるだろう」とだけは言えそうだ。