AMD、GPGPU向けの取り組み「ボルツマンイニシアチブ」を発表。CUDAとの互換性も提供 15
ついにAMDがCUDAにすり寄る？ 部門より
HPC分野の国際会議SC15において、AMDが「ボルツマンイニシアティブ」を発表した（AnandTech）。内容は外部GPUとクラスタに対応したHSA+、CPU/GPU両対応のC++14コンパイラ、CUDAとソースコードレベルで互換性を取るインターフェースの3点だ。ボルツマンの名前は流体解析の格子ボルツマン法や機械学習モデルのボルツマンマシンでGPUが利用されていることから取られたようだ。
HSA+はこれまでのHSAを拡張して外部GPUやHPCクラスタ向けのプログラミングモデルに対応したもの。64bit Linux向けのディスプレイ出力なしのドライバとランタイムが提供され、広帯域インターコネクト経由のノード内/ノード間リモートDMAをサポートする。
Heterogenous Compute Compiler（HCC）と名付けられた新しいコンパイラはLLVM ClangベースでC++11/14や/C11、OpenMP4.0、そしてC++17で採用予定のParallel STLに対応。1つのコンパイラでCPUとGPUのどちらにも使える。そのためGPU用のカーネルを別のソースに記述する必要はなく、ラムダ式でSTL互換のアルゴリズムに述語引数として渡せばよい。
Heterogeneous-compute Interface for Portability（HIP）はHCCで利用できるCUDA風のAPI。HIPで書かれたソースコードはHCCだけでなく、ヘッダーファイルを加えることでNVIDIAのCUDA向けコンパイラであるNVCCでもコンパイル可能となる。従来のCUDAコードをHIPコードに変換するためのツールも用意されており、これによってHSA環境はソースコードレベルでCUDAとの互換性を有することになる。
さすがにバイナリレベルでの互換性は実現されなかったようだが、CUDAで開発されたGPGPUプログラムをAMD GPU向けに移植することが容易になったのはありがたい。
一本化しないの？ (スコア:1)
OpenCLあたりでまとめて欲しい
どのGPUでもFPGAでも同じコードが動く時代はいつ来るんでしょ？
-- 風は東京に吹いているか
Re:一本化しないの？ (スコア:1)
結局、nVidiaが強情を張り続けたのでOpenCLでは一本化出来なかったということでしょう。
GPUを沢山使う現場…例えばCG映像の制作会社…では、OpenCLよりも先行してたCUDAの方が優勢な状況がずっと続いてて、CUDAが使えないからnVidia以外の製品を導入出来ないという顧客が結構いた感じですし、
そういう現場に対する対策でしょうね。
Re: (スコア:0)
OpenCLがいつまでたってもイケてないままパフォーマンスが悪く、CUDAしか選択肢がない状況が続いていたようですね。
Re:一本化しないの？ (スコア:1)
CUDAはさわりの部分しか扱ったことがないので多少いい加減ですが(^_^;、CUDAってCっぽい文法のアセンブラという感じがするんですよね。
要は、文法はCっぽいけどハードウェアを直接叩く感じで、組み込みのチップでも今時ようやらんわ。と言うレベルの事をやる必要がある感じが。
で、OpenCLは、抽象化がかなりされてて、余程のことがなければチップ毎にコードを書く必要がないのですが、その反面、パフォーマンスが今ひとつ（多分、バッファを通じた、CPUとチップの間のデータのやり取り部分にボトルネックがありそう）。
# とはいえ、最近は結構OpenCLのパフォーマンスが良くなってきてるとは思いますが…
そこら辺でnVidia製品を使う人が昔から多くて、しかも、例えばAMDとかその他のベンダが消費電力や演算性能で大きく勝る製品を出したとしても、CUDA文法やCUDAの作法にそってコードを書くインフラが無いから移行できない。と言う状況になってる感じがあるんですよね。
それこそ、ゲームなんかだとGLのシェーダでは出来ないか困難な処理をCUDAでやってる場合が多いのですが、これをOpenCLに移植となるといろいろ厄介なので…
Re: (スコア:0)
特別詳しくないのですが、CUDAという先例を無視してOpenCLを策定したが使われなかった、とも読めるのですがどうなんでしょうか？
Intelは結構OpenCLを押していたという印象があるのですが、それでも覆せなかったということなのでしょうか？
Re:一本化しないの？ (スコア:1)
intelの本命はXeon PhiであっちはあんまりopenCLを押していない気がする。
ついでにCUDAはnVidia独自かつ専用の規格なので無視するほかないでしょうな。
Re: (スコア:0)
IntelもOpenCLを押していなくて、NVIDIAはCUDA推し。
ということでOpenCLはいまいち使われていないという理解でいいですか？
Re: (スコア:0)
IntelはOpenMP推し（Phiがホモジアスだから）
最近の一般向けアプリではOpenCL対応をうたったものが多いと思います
おそらくOpenCLの完成度が上がったのと、つぶしの効かないnvidia CUDAよりアピールしやすいせいでしょう
白旗ってことね。 (スコア:1)
結局自前でなーんも提供できないからCUDAの成果に寄生しよう！、っていういつものAMDで安心です。
OpenCLはどうするのだろうか (スコア:0)
OpenCLは低水準すぎるから、メインに据えるのをやめて新しいAPI作るということか。
OpenCLとは全く独立したもののように読み取れるんだけど。
OpenCL2.1とSPIR-Vが策定されたから、それをベースに高級言語用のフレームワークも
作れそうなものなのに。
CUDAの対抗となると、今更な感じがするなぁ。
Re:OpenCLはどうするのだろうか (スコア:2, 参考になる)
公式のプレスリリースによるとOpenCLのサポートは続けていくみたいです(AMD [amd.com])。
HIPはCUDA対抗というよりはGPGPUにおいてぼくのかんがえたさいきょうのしーぷらぷらこんぱいらを作ったから互換性だって取れちゃうんだぞーって趣旨かと。
HCCの実装についてC++標準化委員会に報告してるみたいですし(本の虫 [blogspot.jp])、その中でアクセラレータ向けのC++サブセットなんていらんかったんや！って息巻いてるそうです。
"full open source HSA programming suite and HIP porting tools"なんて言ってるんで、コンパイラ自体もソース出すつもりなんでしょうかね。
Re:OpenCLはどうするのだろうか (スコア:1)
と言うか、OpenCLってCL側はいいんですが、CL側をコンパイルしてデータのやり取りをするバッファを定義して、コードを動かして…という一連の流れがものすごく煩雑な手続きがいる気がするんですけどね。
最近GLSL使ってみて、あのグチャグチャで難解なホスト側のAPIには閉口しましたが、それでもOpenCLよりはずっと楽にホスト側のコードを書ける。というくらいの状況ですし。
ラムダ式で渡して云々とか、コード書く側が何処で動かすかを意識するのを最低限にできるように言語側でサポートしよう。というアプローチは確かに正解だと思いますよ。
今までなかったのが不思議な機能がいっぱい。 (スコア:0)
外部GPUも使えないクラスタにも非対応でよく今まで持ったな。
Re: (スコア:0)
あくまで「HSAを拡張」なので、外部GPUでRDMAが使えて統合アドレス空間なしの非HSAなクラスタは作れましたよ。