AMDがCPUとGPUのメモリ空間を統一する「hUMA」を発表




参考URL


CPUとGPUのメモリ空間が同じになる様子。



最近のGPUはシェーダパフォーマンス向上やグラフィック以外の処理能力（俗に言うGPGPU）向上で細粒度化が進んでるので、メモリ空間を統一化するメリットが出てきた、ということかな？



これ、かなり前から計画されてて、ずっと注目してたけどようやく実装される目処がついたみたいですね。



最初に聞いたのはbulldozerとかSSE5の計画が出た頃だったと思うので、AMD内では10年くらい前から計画してたんじゃないかなぁ？



というわけでとりあえず気になる点を列挙してみます。

※私は半導体やCPUの専門家ではないので、間違いはご指摘いただけると助かります



■実装に時間がかかった理由

メモリのコヒーレンシの実装が大変だった、というのもあるだろうけど、苦労して実装するだけのメリットが無かった、というのもあると思います。

・コヒーレンシ

　複数のプロセッサがメモリに同時読み書きを行うとデータの整合性が取れなくなってグチャグチャなデータになります。

　そうならないように整合性を取ることをコヒーレンシと言います。

　プロセッサ数が増えるとデータのやり取り（トラフィック）が増えるので大変になります。

　CPUはせいぜい４〜１６コアくらいですが、GPUは1000コア以上あるので、、、大変です。



・実装するメリット

　約7年前、初めてユニファイドシェーダのGPU（Xbox360ですね）が登場した当時は現在よりもシェーダの制約が多く、まだ固定パイプライン向けに作られたシェーダを使わないゲームが主流でした。

　なので当時はGPUをCPUのように使おうとメモリ空間を統一しても、活かすソフトがありませんでした。

　そこからだんだんシェーダの制約が取り払われ、GPGPUという言葉も生まれて、DirectX11のようにシェーダをフルに生かしたAPIも登場し、対応したゲームも増え始めました。

　それでもまだフル活用しているのは一部のハイエンドゲームやHPCなどに限られいますが、メモリ空間を統一するメリットが整ったのはここ最近だと思います。



■わかりやすいメリットは高速化、省電力化

CPU-GPUでデータをコピーする必要がなくなるので、その分高速化されるし、電力も食わなくなる。

コヒーレンシのトラフィック増が気になりますがハードウェアでやってくれるので上手くやってくれるんでしょう。



■わかりにくいメリットは「GPUでCPUのプログラムが動く」

実際にGPUのプログラムしたことある人ならわかるけど、GPUはCPUの命令動きません。

シェーダっていう文字列をボコスカ突っ込んで、「動け！」ってやると動くんです。

なのでシェーダってCPUからすると単なる文字列なんです。

インタプリタみたいなものなので、もちろんコンパイルも入ります。

そしてCPU側のメモリ空間は見えません。javascriptがメモリアドレス見えないのと似ています。



なのでGPU使うにはGPUにデータや命令を転送してやる必要があります。

「コピーするくらい簡単だろ」と思うかも知れません。

そうではなくて、それでは意味が無いんです。



例えばApacheのようなWEBサーバでGPUを使おうとしたら、Apache本体だけでなく、大量のプラグイン全部に修正が必要です。

それをセキュリティアップデートやら機能拡張やらしながら更新するなんて、無理。

Apacheは普通に100以上のスレッドを使うので、GPUみたいな超並列プロセッサ向きだとは思いますが、修正多すぎて使えないってことになります。



しかしこれが「ソフトウェアの変更なしに動きます。」となると話は別です。

命令の変換やコンテキストスイッチとかも必要だから、hUMAだけじゃ無理なんだろうけどね

ただ、hUMAであともう少しってところまで来るのは確かです。

コンテキストスイッチはOS向けの機能なので、プログラミングとあまり関係がなく、開発者がHSAアプリケーションを作ることはできるだろうからね。





■Jaguarコア(PS4/Xbox∞)ではhUMAはサポートされない？

どうもこちらのロードマップ見てると今回hUMAの発表があったSteamrollerコアよりもJaguarコアの方が先に出ることになってるので、Jaguarコア(PS4/Xbox∞で採用予定)ではhUMAはサポートされないように見えます。

ただ、改めてJaguar関連の情報を探してみると、Jaguarについては詳しい情報何もないんだよね。GPUはGCN使うってことと、2〜4コアだってことくらいで。

GCN使うのはSteamrollerと一緒。



製造面から考えると、ハイパフォーマンス向けのSteamroller、モバイル向けのJaguarで若干状況が違います。

AMDのファウンダリというとGF(GlobalFoundries)とTSMCですが、GFは製造が遅れており、TSMCはハイパフォーマンス向けプロセスの優先度が低くなっています。

仮にSteamroller／Jaguarを似たようなアーキテクチャで同時開発していたらTSMCからJaguarが先に出てくるのが自然な気もします。

秘密にする理由がわかりませんが。



新しい技術ってのは常にリスクを伴うものなので、今後５年以上にわたって両社のゲームプラットフォームを支えるCPUに新技術（hUMA）がある方がいいとは限りません。

当然エラッタはあるでしょうし、CELLのように生パフォーマンスばかりで実性能が出しにくいなど調整不足も考えられます。

それにhUMAはゲームのようにアセンブラでガリガリプログラムしてしまうプログラマ向けというよりは、既存ソフトウェア資産の有効活用を念頭に置いたパフォーマンスアップが目的だと思いますし。

ゲームプログラマにとっては「コピーするくらい簡単だろ」で済んでしまう問題だと思います。



もちろんhUMAに対応している方がプログラミングの自由度は格段に上がりますし、GPU特有の問題でハマることも減るでしょうからプログラムも楽になると思います。

ただhUMAに対応したAPUが出て、それに対応した開発環境ができて、開発環境のチューニングが終わって、、、って、していると２〜３年は簡単にすぎてしまいそうな気もします。

仮にCPUの命令をGPU向けに変換するとしても、それに掛かるオーバーヘッドもゼロではないと思いますし、ガリガリにチューニングするゲームには向かない気がしますね。





なんかダラダラ書いてみて締りがなくなってきたのでこのへんで。



ツッコミ歓迎。



気が向いたら追記／修正するかも。





参考URL