LoginSignup
12
6

More than 5 years have passed since last update.

何故GPUでSIMTが流行ったか (仮)

Last updated at Posted at 2018-01-15

とりあえず、拙い知識で書いてみます。色々簡略化していたり、理解が怪しかったりしますが、ご勘弁を。

4-way SIMD時代

初期のGPUは、色処理のRGBA及び座標処理のXYZWを意識して、4-way SIMDユニットで構成されていました。

しかし、RGBやXYZだけの処理が多かったり、RGBAやXYZWの処理でもA (透明度) 要素やクォータニオンのW要素だけ別処理の必要なことが多々あり、非効率でした。

3-way SIMD + スカラ時代

4-way SIMDの4番目の要素が例外的に扱われやすいなら、4番目の要素を独立させてスカラ扱いしちゃえば良いと考えたのが、この3-way SIMDユニット + スカラユニットです。

これで問題が解決されたかに見えましたが、高度なシェーダーがスカラ演算を多用するようになり、スカラ演算の連続で3-way SIMDユニットが無駄になり非効率でした。

VLIW時代 (Radeon R600/2007年~)

スカラ演算の連続もCPUのように複数の演算ユニットに流し込みたいが、CPUのように命令スケジューラを大きくしないで演算ユニットを詰め込みたいと考えたのが、このVLIW方式です。

しかし、VLIWは命令の静的スケジューリングしかできないため、レイテンシ不定の命令で演算ユニットが活かせない状態になり非効率でした。

アウトオブオーダー+SIMT時代 (NVIDIA G80/2006年~)

命令の静的スケジューリングが動的レイテンシ変化に弱いなら、アウトオブオーダー方式で命令の動的スケジューリングすれば良いのですが、それだけでは命令スケジューラが大きすぎます。それなら、一つの命令スケジューラで複数のスレッドを制御すれば良いじゃないと考えたのがSIMT方式です。

それでも、やっぱり命令スケジューラは大きくて非効率でした。

アウトオブオーダー+制御コード+SIMT時代 (NVIDIA Kepler/2012年~)

巨大な命令スケジューラが非効率なら、動的スケジューリングの一部を事前計算して静的に与えれば良いじゃないと考えたのが、制御コード方式です。最新です。

アウトオブオーダー+512-bit SIMD時代 (Xeon Phi KNL/2016年~)

巨大な命令スケジューラを幾つも持つのが非効率なら、SIMDの要素数を増やして同時処理すれば良いと考えたのが512-bit SIMD方式です。そもそもSIMDの効率が悪かったのは、rgbaやxyzwを同一視して扱うからでした。それならば、 Packedデータ ([xyzw, xyzw, ...]) を転置してPlanerデータ ([[x, x, ...], [y, y, ...], [z, z, ...], [w, w, ...]]) で処理しちゃえば、要素数の多いSIMDでも効率的に扱えるはずです。アウトオブオーダーでスカラー演算もばっちり? # XXX: MesaのOpenSWRのコード未読

後書き

メモリ周りを無視しすぎ、ハイパースレッドもどきについて無視してるなど、色々問題ある記事ですが、何かの参考になれば幸いです。

Xeon PhiよりNVIDIA GPUの方が汎用に思えますね。特にPlaner処理は、グラフ処理やテーブルルックアップの多い3Dでどれだけ役立つやら…。

(追記) 後書きに少し追加。

参考文献

https://pc.watch.impress.co.jp/docs/2007/0518/kaigai359.htm
https://pc.watch.impress.co.jp/docs/column/kaigai/383968.html
https://github.com/NervanaSystems/maxas/wiki/Control-Codes
https://news.mynavi.jp/article/20160830-bifrost/

12
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
6