GoogleがOpenCLではなくRenderScriptを選択した理由
OpenCL for Androidを使用することが可能であるか、それが不可能であることを確認して、件名を完全に削除したのかと思っていました。しかし、公式Android開発者ブログ（http://Android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html）に関する1月14日のブログ投稿に感謝します。 ）、Android 4.0、RenderScriptのおかげで4.0以降、並列プログラミングが可能であることを発見しました！OpenCLでかなり多くの共通機能を持つAPI。
私が今疑問に思っているのは、GoogleがOpenCLを推進する代わりにこの新しいソリューションを実装することを選択した理由です（現在、Khronosグループによって処理されているオープン仕様）。
つまり、一方から他方に変換するのはそれほど難しいことではありませんが、それでも...
とにかく、本当の説明として誰かがいたら教えてください！
その答えは、AndroidのニーズはOpenCLが提供しようとしているものとは大きく異なるということです。
OpenCLは、CUDAで最初に導入された実行モデルを使用します。このモデルでは、カーネルは1つまたは複数のワーカーグループで構成され、各グループにはそのグループ内で高速共有メモリと同期プリミティブがあります。これにより、特定のアーキテクチャでアルゴリズムをスケジュールする方法とアルゴリズムの説明が混在します（グループのサイズとそのグループ内で同期するタイミングを決定しているため）。
これは、1つのアーキテクチャ用に作成していて、絶対的なピークパフォーマンスが必要な場合に最適ですが、パフォーマンスの移植性を犠牲にしてピークパフォーマンスを実現します。たぶんあなたのアーキテクチャでは、最高のパフォーマンスを得るためにグループあたり256ワーカーを実行するのに十分なレジスタと共有メモリがありますが、別のアーキテクチャでは、グループあたり128ワーカーを超える大量のレジスタ流出が発生し、80％のパフォーマンス低下を引き起こします。 。一方、コードはグループごとに256ワーカー用に明示的に記述されているため、ランタイムは別のアーキテクチャの状況を改善しようとすることはできません。このような状況は、GPUコンピューティングのデスクトップ/ HPC側でアーキテクチャーからアーキテクチャーに移行するときによく見られます。
モバイルでは、Androidは、非常に異なるアーキテクチャを持つ多くの異なるGPUとCPUベンダー間のパフォーマンスの移植性を必要とします。AndroidがCUDAスタイルの実行モデルに依存する場合、単一のカーネルを作成して、さまざまなデバイス上で許容範囲内で実行させることはほとんど不可能です。
RenderScriptは、一部のピークパフォーマンスを犠牲にして、開発者から離れたスケジュールの制御を抽象化します。ただし、RenderScriptで何ができるかという点では、常にギャップを埋めています。たとえば、Android 4.2で導入されたAPIであるScriptGroupは、GPUコード生成をさらに改善するための私たちの計画の大部分です。高速コードをさらに簡単に作成できるようにする多くの新しい改善が来ています。あまりにも。
AppleはOpenCLの商標を保持しています。 GoogleはAppleと競合しています。おそらく、それは本当にそれほど単純なことです。
OpenCLでAndroid（ ここを参照 ）を使用して作業を行いました。Intel、Imagination、およびその他のチップメーカーの作業のおかげで、それが前進していることを嬉しく思います。Googleはすぐに好転します。