HIPはCUDA対抗というよりはGPGPUにおいてぼくのかんがえたさいきょうのしーぷらぷらこんぱいらを作ったから互換性だって取れちゃうんだぞーって趣旨かと。 HCCの実装についてC++標準化委員会に報告してるみたいですし(本の虫 [blogspot.jp])、その中でアクセラレータ向けのC++サブセットなんていらんかったんや！って息巻いてるそうです。 "full open source HSA programming suite and HIP porting tools"なんて言ってるんで、コンパイラ自体もソース出すつもりなんでしょうかね。
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よりはずっと楽にホスト側のコードを書ける。というくらいの状況ですし。
ラムダ式で渡して云々とか、コード書く側が何処で動かすかを意識するのを最低限にできるように言語側でサポートしよう。というアプローチは確かに正解だと思いますよ。