My life as an APE

Intelの戦略的GPUキラー、Larrabeeの概要がSigraphで発表になるとのことで、Paperが公開された。ライスタライザが手書きできる時代がまた来るとは、目頭があつくなる。

●HW概要
Core2Duo程度のダイ面積（65nmで212平方mm程度)に、Pentium相当のインオーダー・コアを10個集積。各コアには16wayのSIMD-VPUが搭載される。VPU 1エントリあたり最大2flop/サイクルとされる（mad処理）。また、１コアあたり4HWTread。それぞれのHWT毎に独立したレジスタページが用意され、L1キャッシュもおなじくHWT毎に分割される。

それぞれのコアはリングバスで接続され、各コアあたりに256KBのローカルキャッシュが接続される。他コアのローカルキャッシュにはリングバスを経由してアクセスする必要があり、キャッシュ内でのコヒーレンシはHW実装で保たれる。

グラフィクス処理の支援機能として、テクスチャフェッチユニットが搭載され、コプロセッサとして動作する。なお、テクスチャフェッチユニットはL２キャッシュを通して各コアと通信する。テクスチャフェッチの手助けとしてMMUによるPageFault例外がやや唐突にあげられているが、EPICが提唱するMegaTextureとの関連性が伺えて面白い。

と仕様的には、どこのCELL Broadband Engineかと見間違えてしまうような類似性だが、一定のダイ面積にVPUを詰め込むとしたらどうしても似たような設計になってしまうのだろう。私的予想ではPS3のGPUはCELLで来ると思っていたのだけれど、それが実現しなかった（それらしき研究成果は一部に見て取れるが）現在、CELL GPUのあだ花として、是非Larrabeeには花を咲かせてもらいたい。

●コアアーキテクチャについて
基本的にはCBEと同じく良い筋なのでは、と思う。ただこうしたハイパフォーマンスを追求するチップの場合、一点のボトルネックが大きな足かせになることもままあるため、幾つか気になる点を記しておきたい。

基本VPUアーキテクチャについては、Pentium相当のコアを利用するとのこと。この辺はもっと割り切って、Z80移植戦略時代のへその緒のような仕様は切ってしまってもよかったのではないかという気はする。Paper上想定クロックサイクルが1GHzとされているのも、なんとなくPentiumアーキテクチャの所為ではないか、と邪推される。CBEは(多くのものを犠牲にしながらも)3Ghz前後で駆動し、SPUの仕様自体は割り切っていて中々良い。
Larrabeeについても、IA32をベースに大胆にリアーキテクトしてしまうのが清々しい。

VPUが16wayとされているの点は見かけ上のFLOPS値は上昇するが実用上はやや不安だ。HWTが4スレッドとなっている点からも、VPU命令レイテンシが長大であることがみてとれる。HWT数が増えた分、レジスタ数、L1キャッシュエントリが減少するなどの副作用も懸念されるところだ。実運用上、インオーダーコアで複数のHWTが動作しても実行効率はそれほど向上しないのでは、という点も気になる。
追記：Paperでは1コアの理論ピーク値が1GHz駆動時で32GFLOPS（madd換算）とされている。VPU命令は４サイクルに一度しか発行できない、という仕様だろうか？

VPU命令が１エントリあたりmad相当の2flop/cycleというのも、dp3、dp4や...dp16命令が無さそうなことが示唆される。IntelのSIMD系命令セットは代々デベロッパの意見をあえて無視したような実装が多いような印象もあるが、Larrabeeではどうだろうか。

ローカルストアのサイズが256KBというのも実用としては少ない。512KBのローカルストアであれば、アプリケーションの自由度も大幅に上がるのでは、とおもわれる。個人的にはコヒーレンシの管理はなしにして、アドレッシング幅が増えるほうがうれしい。
コヒーレンシの管理にしても、キャッシュアローケーション時にリングバス上でパケットを一周させる必要があり、パケットの流れはEven/Oddサイクルで切り替わるとのことで、バスを一周させるめだけに20サイクル程度のレイテンシがかかってしまうような気もする。また、倍精度処理については「遅くならないとは書いていない」点もみそだ。
なおVPUのアドレッシングについて、レジスタのほかに、L１、L2がアドレッシングできるほか、Scatter.Gather、型変換なども可能で便利にできていそうだ。

●グラフィクス・エンジンについて
Paper後半は、Larrabee上でのグラフィクス・エンジンのリファレンス実装の解説に割かれている。この実装ではタイルベースの描画エンジンで、トライアングル・セットアップの結果をいったんBINに戻して、後のラスタライズパスでBIN毎に描画処理するという実質2パス構成になっている。

この実装による一番のメリットは、通常は描画時に最も帯域を消費する深度バッファとカラーバッファをローカルストアに保持しておける点だろう。通常アプリケーションではバス帯域とシンクロナイゼーションがパフォーマンスを規定するのだが、特にゲームアプリケーションでは帯域がボトルネックになることが多い。このため、バス上の流れを追うことがパフォーマンス向上の第一歩となる。

タイリング処理のメリットによって、アプリケーションで帯域をもっとも消費するのはテクスチャフェッチのアクセスとなる。Paper上ではテクスチャフェッチのレイテンシ（数百サイクルと表記されている）はソフトウェア実装によるファイバのコンテキストスイッチによって補うとされている。気になる点はファイバのコンテキストをローカルストア上におく必要があるため、無尽蔵にコンテキスト保持が行えない、という点だ。

またソフトウェア実装により、パイプライン上のボトルネックやストールをできるだけ減らせている点は非常に好ましい。多くのGPUではトライアングルセットアップやインターポレーションが実用上のボトルネックになるケースもままあるが、そうしたケースを最適化できるというのは心強い。

タイルベースの実装によるデメリットとして、複数タイルにまたがるプリミティブに対して冗長なDataReadが行われる、という点がある。が、Paperによる実装ではタイルサイズが128x128と比較的大きく、またモダンなアプリケーションではプリミティブサイズが細かくなることもあり、タイル分割によるロスは5％前後との計測結果とのことだ。
また、タイルをまたぐMSAA/FSAA処理、フィルタ処理は単一パスで行えない、という点もデメリットとして考えられるが、その辺は実装でどうにでもなる範囲かとは思う。

●実パフォーマンスについて
気になる実パフォーマンスについてだが、シミュレータ上ではほぼ実用的なパフォーマンスが達成され、同程度のダイサイズのHW実装GPUとほぼ同程度と考えてよい雰囲気が醸し出されている。メリットとしては動的にパイプラインを組み替えられるフレキシビリティと、ソフトウェア最適化の余地が大いにあることだろう。

が、前者としてはUnifiedShaderモデルと比較しての優位性はやや立証が難しく、後者に関してはHW実装GPUとのソフトウェア互換性の兼ね合いからあまりに変態的な処理は行えないような気もする。なかなかむずかしいところだ。

●Mike Abrashのこと
ここまでとは全く関係ないが、Paperの執筆者に現RadGameToolsのMike Abrashの名を見て多いに納得してしまった。
Mikeには前職でのチームメイトとして数年お世話になった。当時すでにゲームプログラマ界の大御所でありながら、更に高みを目指し続けるという点で、多いに勉強させてもらったものだ。その後チームを離れてRadGameToolsにうつり、何をしているかというと、７年越しでソフトウェア・レンダリング・パイプラインを実装していると聞いていた。

当時はついにMikeも隠居して趣味のレンダラを書いているのか、と少し寂しく思ったのだが、どうやら全然違ったらしい。お見それしました、申し訳ありません。
なお、彼の他にもLarrabeeのソフトウェア・スタックには界隈のメンバーが続々集結している。この点もありLarrabeeは今後用注目かと思う。

７年越しで物事を遂行できる意思は多いに見習いたい。拙作のスクリプト言語も、７年後には全ての商業ゲームはスクリプト言語でコーディングされることを読んで実装してみた。絶えることなく、細々と続けていきたいものだ。