Larrabee paper review

by syoyo

http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

読みました.
結論. 性能は微妙. レイトレアクセラレータロジックはなしのよう. 開発は楽なのが唯一の救いか.

Larrabee 構成概要

なんとも普通. そりゃ CPU メニーコアなので普通になりますね.

gather/scatter

VPU のインストラクションは L1 のアドレスをソースオペランドに取ることができる.

非連続アドレスからのロード(gather)と非連続アドレスへのストア(scatter)をサポートしている。
ただしキャッシュの速度に制限されるので、たとえばすべての要素が異なる場所を示していれば(データが L1 にキャッシュされているとして)最悪 16 サイクルはかかることになる。
ただし実際はそれなりにコヒーレンスがあるのでそれより少なくなるとのこと.

大域アドレス(仮想アドレス)に対する gather/scatter はできそうな記述ですが、atomic 操作とか考えるととても複雑になって実装が難しい気がしていますがどうでしょうか.

ベクトル演算命令は masked 実行あり。まあこれは普通ですね。ベクトルデータの load/store 命令でもベクトル要素ごとに mask をかけることができて, mask された要素はアップデートされないようにすることができるよう.こちらはたしかにあると便利.

GFLOPS

コア数は可変みたいだけど、たぶん製品として最初に出てくるのを考えると 16 コアの構成あたりが妥当そうでしょうか.
16 cores、1GHz, madd が 1cycle でできるとして、 

16(cores) * 16(vector width) * 1(GHz) * 2(madd) = 512 gflops

微妙なところですね(スカラ ALU の flops は dominant でないのでカウントしていません).

HWラスタライザ撤廃

この判断はいいと思うというか自然な流れですね。いまや HW ラスタライザ(とそれがあるためにレンダリングパイプラインが分断されてしまっている状況)は GPU の最大のネックですから。
ゲームなどは GPU レンダリングのパフォーマンスを出すために CPU で軽く
レンダリングしてから visibile なポリゴンを投入とか、deferred shading したりとラスタライザをなるべく経由しないようになっていますしね.

さらにポリゴンの密度がピクセルに近くなってきているのもラスタライザがネックになっている原因です. そろそろピクセルセントリックで処理したほうが効率的になりつつあります(その流れでレイトレ化という風にもなっています).

テクスチャは HW

テクスチャ処理は機能が決まっているわりに演算量が多い処理なので HW で提供というのは正しい判断です。Aniso filtering とか SW でやったらベラボーに時間がかかるしね.
 
ただ、演算コアから HW テクスチャユニットを使うには L2 を介して texturing コマンド(か特殊メモりアドレスへのアクセス?)を発行しないといけないので、テクスチャリングのレイテンシがでかそうなのが気になりますね。スレッディングとかで隠蔽はできますが、テクスチャリングのパフォーマンスを出すにはそのようなプログラミングが明示的に必要になりそうです.
テクスチャキャッシュは L1 相当の 32KB でその先はいきなり DRAM なのかな?
それだとマルチテクスチャリングしたときにキツいので、4MB のシェアードメモリの一部を L2 テクスチャキャッシュとして使えたりするのだろうか. でもそれだと 16 コア/4MB L2 の構成ができないから(256 KB x 16 = 4MB)、やはり 10 コア/4MB で一セットの構成になるんでしょうか.

半透明

フレキシブルな演算パイプライン構成だから半透明とかやりやすくなるとありますが、
帯域を考えるとよほど制約を与えないと使い物にはならない気がしています.

とはいえ、いずれにせよこれからのグラフィックスでは半透明、屈折, アンチエイリアスなどのなめらかで潤いのあるグラフィックス効果が重要になってくるはずなので、その流れを実現する一歩としてはいいかのかもしれません. 

レイトレ

1k x 1k, 4 Mray(eye ray + reflection) が、16 コアで 40 fps.
同じシーンを octa core CPU だと 12 fps.

レイトレ専用の HW ロジックも搭載しないみたいですし、
16 コア版で 4 倍程度(Larrabee 8 core なら 2 倍しかない)ということで
思ったほど Larrabee でレイトレというのはアドバンテージはないですね.

これだと普通に Larrabee 製品化時期の次世代の CPU で達成できなくもないレベルです.

Larrabee のレイトレ性能を理論値から計算してみますと、

512 Gflps / (41.16[fps] * 4 [Mray]) = 3,000 flops/ray

とレイあたり 3,000 flops. まあ RTRT の普通の CPU 実装だとだいたい数千 flops くらいでできると期待されますから(トラバース込みで)、flops レベルでは CPU 実装とあまり変わらないことになります。CPU が演算コアなので同等になるのは当然といえば当然でしょうか.

視覚的にリッチなリアルタイムレイトレを実現するためには 3T flops が必要と 10 年前にすでに予測されていますが[1]、私も [1] との計算方法は異なりますが 3T flops くらいが必要だと思っています.

たとえば 2k x 1k pixels, 60 fps 実現するとして, 120 Mpixels/sec 処理する必要があり,

3 [Tflops] / 120 [Mpixels] = 25,000 flops/sec

これだと 1 レイの処理に 2,500 flops をかけたとして, レイを pixel あたり 10 本処理することができます. これだけ処理できれば既存のラスタライズグラフィックス品質+αをレイトレで実現できるでしょう.

そんなわけで、3T flops を実現してレイトレプロセッサを謳うには Larrabee は 48 cores @ 2 GHz の構成にする必要があります. 第一世代でここまでの構成は、どうでしょうかね、なんとか実現可能かもしれませんが難しいところだと思います.

金融

たとえば単純な BlackScholes option pricing だと算術関数が一番のネックなので、これがアクセラレートされないとベクタ長やコア数のスケール以外ではさほど CPU との違いはない気がしています.

開発環境

既存の C/C++ 開発スタイルで開発できます. Larrabee Native というプログラミングモデルと呼ばれています.
それ以外でも、DX の compute shader とか Ct, SPMD スタイルも利用可能.
プログラマブルパイプラインの利点ですね.
また、演算コアでの printf とかもサポートするようなのでデバッグが楽にできます
(ただし printf などは host と通信する必要があるのでベラボーに遅くなるはず.
使うとしてもデバッグ用途だけにするのがよさそうです)

まとめ

性能は微妙ですが、開発が既存のモデルをそのまま大体使えそうという利点は大きい.

Larrabee がいきなり既存の GPU を置き換えるとかリアルタイムレイトレプロセッサとして使えるほどにはなれそうにありませんが(しかも実際に製品として出てくるにはあと 1,2 年かかることを考えると、さらに性能に疑問があります)、
たとえばオフラインレンダラの高速化などの、単なるプログラミングしやすい演算アクセラレータとして使うにはいいかもしれ
ません。

MUDA や lucille で Larrabee をサポートするのはどうするかなぁ… Intel の SDK の出来次第でしょうか. ’08 末あたりにはシミュレータが提供されはじめるみたいなので、それから考えることにします.

おまけ

しかし、論文はいかにもやっつけな感じですねぇ、、、特に図が.

Refernces

[1] 並列画像処理
http://www.amazon.co.jp/dp/4339025933

Advertisements