なぜGoogleはOpenCLの代わりにRenderScriptを選択したのですか

Question

Android用OpenCLを使用できるかどうか、それが不可能であることを知り、件名を完全に削除したのですか？ 1月14日の正式なAndroidデベロッパーブログ（http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html）のブログ記事のおかげで、私は並列プログラミングがAndroid 4.0以降、RenderScriptのおかげで可能！ OpenCLでよく使われる機能を持つAPIです。

私は今、なぜOpenCLをプッシュするのではなく、この新しいソリューションの実装を選択したのだろうと考えています（現在、Khronosグループが扱っているオープンな仕様です）。

私が意味する、私が知っている、それは一方から他方へ変換するのは本当に難しいことではありませんが、とにかく、まだ...

、実際の説明のように誰もがあれば、私に知らせてください！

Answer 1

答えは、AndroidのニーズはOpenCLが提供しようとしているものと大きく異なることです。

OpenCLは、CUDAで初めて導入された実行モデルを使用します。このモデルでは、カーネルは1つまたは複数のワーカーグループで構成され、各グループはそのグループ内で高速共有メモリと同期プリミティブを備えています。これは、グループのサイズを決定し、そのグループ内で同期するタイミングを決定するため、特定のアーキテクチャでアルゴリズムをスケジュールする方法とアルゴリズムの記述が混在する原因となります。

これは、1つのアーキテクチャ用に作成したもので、絶対的なピークパフォーマンスが必要な場合に最適ですが、パフォーマンスの可搬性を犠牲にしてピークパフォーマンスが得られます。あなたのアーキテクチャでは、最高のパフォーマンスを得るためにグループあたり256人の作業者を実行するのに十分なレジスタと共有メモリがあるかもしれませんが、別のアーキテクチャでは、1グループあたり128人以上の作業者による大量のレジスタ流出が発生し、80％ 。一方、コードはグループごとに256人の作業者に対して明示的に記述されているため、ランタイムは別のアーキテクチャの状況を改善するために何もできません。この種の状況は、GPU計算のデスクトップ/ HPC側のアーキテクチャーからアーキテクチャーに移行するときによく起こります。

Androidでは、アーキテクチャが非常に異なるさまざまなGPUとCPUベンダー間でパフォーマンスの移植性が必要です。 AndroidがCUDAスタイルの実行モデルに依存する場合、単一のカーネルを作成し、それを一定の範囲のデバイスで受け入れられるようにすることはほとんど不可能です。

RenderScriptは、ピークパフォーマンスを犠牲にして、開発者からのスケジューリングを制御します。しかし、RenderScriptの可能性については、常にギャップを埋めるようになっています。たとえば、Android 4.2で導入されたAPIであるScriptGroupは、GPUコードの生成をさらに改善するための計画の大きな部分を占めています。高速なコードを書くことさえさらに簡単にする新しい改良がたくさんあります。

Answer 2

AppleはOpenCLで商標を保持しています。 GoogleはAppleと競争している。多分それは本当に簡単です。

私たちはAndroid（see here）でOpenCLの作業を行っており、Intel、Imagination、および他のチップメーカーの仕事のおかげで、それが前進しています。間もなく、Googleは順調に回復するだろう。