Intelは「Larrabee(ララビ)」をグラフィックス製品として投入することを諦めた。なぜか。

　IntelはLarrabeeの製品計画を大きく変えた。グラフィックス用途としては、45nmプロセス版のLarrabeeも、そして、おそらく32nmプロセスのLarrabee 2と呼ばれていた製品も出て来ることはなさそうだ。HPC(High Performance Computing)など一部の顧客にはLarrabeeを提供するが、ボリュームが出るグラフィックス向けとしての発売をIntelは諦めたようだ。アーキテクチャを変更したLarrabee 3の動向はまだ見えないが、事実上、Larrabee戦略の仕切り直しと言っていい。

　この変化は、何を意味するのか。何が変わるのか、そして、何が変わらないのか。

　もちろん、変わるのは単体製品としてのLarrabeeと、そして、おそらくは、ディスクリートグラフィックス製品としてLarrabeeを普及させる戦略自体。一方、変わらないのはIntelがCPUに統合するための、データ並列重視型プロセッサコアのアーキテクチャを緊急に必要としている点だ。

　Intelにとってマイナスなのは、開発費をかけたLarrabeeチップが、結局製品にならないで終わること。それによる、汎用データ並列コアの浸透計画の後退。逆にプラスなのは、Larrabeeを大々的に市場に出して、結果としてセールス的に大失敗をする可能性がなくなったこと。汎用データ並列アーキテクチャ自体がダメというマイナスイメージを植え付けてしまうリスクをなくした。

　今後の展開として、非常に可能性が高いのは、データ並列コアを、まずディスクリートグラフィックスとして普及させるという戦略の仕切り直し。また、IntelがLarrabeeのISA(Instruction Set Architecture)とマイクロアーキテクチャを改良する可能性も高い。後述する理由から、よりコンピュート効率を重視した方向へと向かうと推測される。

　その反面、可能性が低いと推測されるのは、従来型グラフィックスに最適化したチップとして仕切り直すこと。ラスタライザのようなコストの低い機能は加える可能性はあるが、汎用性の高いデータ並列コアであるという、根本的なアーキテクチャを変更する可能性は低いだろう。なぜなら、Larrabeeの真の目的は、グラフィックスに最適なディスクリートチップを作り、ディスクリートGPU市場を取ることではないからだ。

　製品としてのLarrabeeが本来的な目的としているのは、CPUに統合するデータ並列コアのテストビークルであること。どうやれば、フレキシブルで高効率かつ、プログラムしやすいアーキテクチャにできるのか、それを追求することにある。そして、最終的には、統合グラフィックスコアのように、CPU(今はまだチップセット)へと統合すると見られる。

　この方向性は、x86命令セットの延長で実装したLarrabeeの命令セットを見れば一目瞭然だ。CPUに統合することを考えないなら、CPUの命令セットのスペースにマップする必然性は薄い。Intelは、Larrabee New Instruction(LNI)をx86の拡張として実装したことで、どんなx86コアとも組み合わせることができる。

　その意味では、Larrabeeの実体は、製品自体ではなく、命令セット拡張であるLNIだ。また、Intelの幹部達も、Larrabeeのような汎用データ並列コアをCPUへと統合することを展望している。多くの人がLarrabee=グラフィックスと見るが、グラフィックスは汎用データ並列コアの普及戦略として持ち出された、極端な言い方をすれば“方便”に過ぎない。

　ではなぜ、Intelはそこまで汎用データ並列コアにこだわるのか。それは、CPUアーキテクチャの発展の方向性がそこにあるからだ。CPUメーカーは、サーバー以外では、大型のスーパースカラCPUコアをCPUダイ(半導体本体)にたくさん積む方向は望んでいない。クライアントでは、ホモジニアス(同種)なマルチコア構成では、ワークロードに対して得られるパフォーマンス効率が高くならないからだ。

　効率性で言えば、大型のスーパースカラコアと、小型のデータ並列特化型コアの組み合わせのヘテロジニアス(異種混合)構成が望ましい。なぜなら、これからパフォーマンスを伸ばしたいのは、データ並列で浮動小数点演算中心のワークロードだからだ。シングルスレッドの整数演算の性能をどんどん高めることではない。しかし、アムダールの法則は依然として生きているため、Intelは大型のスーパースカラコアを捨て去ることもできない。必然的にヘテロジニアスになる。

　そして、IntelやAMDなどx86系CPUメーカーは、その場合、データ並列コアをスーパースカラCPUコアとより密接に連携できるアーキテクチャに持って行きたい。GPUのような、ダウンロードモデルではプログラミング上、適用できるアプリケーションに限界があると考えているからだ(この点は議論もある)。そして、命令セットを拡張できるというx86 CISCの利点を活かすことができる。

　こうした背景があるため、Intelは、製品としてのLarrabeeを仕切り直ししても、基本的には同じ方向でデータ並列コアを開発して行くだろう。本質的な部分では、Larrabeeの背後の技術方向性は変わっていないと見られる。

Intelの将来のCPUの予測

Intel命令セットアーキテクチャの進化

　Intelは、かなり早い時期から、一部の顧客に対してLarrabeeのサンプルを配布。評価を行なってもらい、フィードバックを得ていた。IntelがLarrabee戦略の仕切り直しをすることになった大きな原因の1つは、グラフィックスでのフィードバックの結果が非常に悪かったことにあると推測される。

　実際、漏れ伝えられるLarrabeeのグラフィックス系での評価はかなり悪かった。特に、既存のグラフィックスタスクでは、パフォーマンス効率が極めて悪かったという。DirectXのような既存のグラフィックスAPIベースでは、性能はハイエンドGPUの「半分行くか行かないか」とある業界関係者は語っていた。もちろん、性能評価はアプリケーションによって大きくブレがあるため、一概には言えないが、効率に問題があったのは確かなようだ。

　特に、GPUと比較した場合に、消費電力当たりのパフォーマンスがかなり低く、そのためGPUとしては競争力は持てないと言われていた。「パフォーマンス/電力が悪すぎる」という声があった。

　こうした評価は、アーキテクチャ上からも容易に想像がつく。

　Larrabeeは、テクスチャフィルタリング以外には、全てをソフトウェア処理している。そのため、既存のグラフィックスAPIに最適化した固定機能ハードウェアも備えたGPUに効率で勝つことが難しい。データパスもATI R6xx系とNVIDIA Fermi以外のGPUは、グラフィックスタスクに最適化した上下非対称の内部バス構造を持っていたが、Larrabeeは汎用のリングバスで全てを流す構造だ。そのため、バスの電力効率も悪く、テクスチャ転送の多いワークロードではバスネックがあると推定される。実際、リングバスを使っていたR600では、効率の問題があった。

RV770の内部バス構造

　GPUでは、内部バスに負担をかけないように、グラフィックスパイプのROP(Rendering Output Pipeline)はメモリコントローラに直結するハードウェアで行なっていた。ROPはメモリ上の深度(Z)やアルファ(α)などのデータの参照が頻発してデータ帯域を食うからだ。対してLarrabeeはROPもCPUコアによるソフトウェア処理だ。そのため、バスへの負担を避けるために、基本はオンチップメモリ上で行なう。オンチップメモリは各コア256KBと制約されているため、コア単位でのタイリングベースのグラフィックス処理を基本としていた。しかし、レンダリング面を区切って処理するタイリングは、グラフィックスでは制約となる。

　スレッドと命令の制御も大きく異なる。おおざっぱに言うと、既存のGPUは伝統的グラフィックスAPIに最適化した制御を行なっているのに対して、LarrabeeはCPU的な自由度の高い制御を行なっている。例えば、Fermi以前のGPUは、GPU全体で1つのカーネルプログラムを走らせる構造だが、Larrabeeは16個のコアそれぞれが異なるプログラムを走らせることができる。これは、命令とスレッドの制御を各コア単位で行なうことを意味しており、その分、制御機構が複雑になる。

　こうして見ると、Larrabeeは自由度の高さのために、効率性を犠牲にしていることがわかる。Larrabeeはアーキテクチャ上の必然として、伝統的なグラフィックスAPIベースの処理では、電力効率がGPUより悪くなる。加えて、最初のLarrabeeのシリコンは、ほとんど省電力機構を持っておらず、アイドル時でも電力の消費が大きかったという。Intel自慢の省電力機構のスキルが活かされていないことになる。

Larrabeeのテクスチャサンプラの構造(推測)

Larrabee全体の構造

　Larrabeeの強味は、既存グラフィックスAPIを外して、ソフトウェアで自由にレンダラを書く場合に活かされる。既存GPUは、グラフィックスAPIに最適化されていため、自由度が制限されている部分があるからだ。また、固定ハードウェアがボトルネックあるいはオーバーヘッドとなっている部分がある。そのため、GPUより自由度がずっと高いLarrabeeの方が、有利に働くグラフィックス処理もある。

　例えば、Intelが『IEEE Visualization 2009』で発表した共同論文「Mapping High-Fidelity Volume Rendering for Medical Imaging to CPU, GPU and Many-Core Architectures」では、既存グラフィックスAPIを使わない医療向けボリューメトリックレンダリングをテストしている。それによると、NVIDIAのGeForce GTX 280(GT200)に対して16コアのLarrabeeは、スペック上のピークパフォーマンスでは半分であるにも関わらず、ボリューメトリックレンダリングでは1.5倍の性能を達成すると言う。

　そのため、Larrabee登場を受けてグラフィックスソフトウェア業界が、こぞって既存グラフィックスAPIを捨て、ソフトウェアレンダラに移るなら、Larrabeeの状況は変わる。その場合は、おそらく、Larrabeeが最強で、NVIDIA Fermiがその次、AMD R800系が3番手となるだろう。しかし、ソフトウェア側がそこまでラディカルには移行できないため、Larrabeeは強味を発揮しきれない。

　ちなみに、AMDの現在のGPUアーキテクチャは、既存APIへの最適化にかなり寄っている。それに対して、NVIDIA Fermiが狙うのは既存グラフィックスAPIに新手法を織り込んだハイブリッドグラフィックス。NVIDIAは、IntelとAMDの、ちょうど中間地点にいる。つまり、AMDはグラフィックスソフトウェアが急激には変わらないと見ており、NVIDIAはある程度変わると考えており、Intelは急激に変化すると期待していた。

　ソフトウェア業界の動きは、Larrabeeが発表された当初は、ソフトウェアレンダラへの期待で盛り上がっていた。例えば、米国のトップ開発者の1人Tim Sweeney氏(CEO, Founder, Epic Games)が、2008年のCEDECで「グラフィックスAPIを介さない新しい時代が来る」とぶち上げた。しかし、今年(2009年)のCEDECでのトップ開発者のパネルディスカッションなどを見ると、それには時間がかかるという見方の方が多かった。Larrabee熱が冷めたあとでは、おそらく、それが業界の一般通念だろう。

　こうして見ると、そもそも、Intelが組み立てたLarrabeeを取り巻くグラフィックスソフトウェアのビジョン自体にも無理があったと言えそうだ。では、Larrabeeを仕切り直すとしたら、Intelは、戦略やアーキテクチャをどのように組み替えるのだろう。次回はそれを考えてみたい。

グラフィックスレンダリングパイプラインの変遷