Android用のOpenCLを使用できるかどうか疑問に思っていましたが、それが不可能であることがわかり、件名を完全に削除しました。しかし、公式のAndroid Developerブログ（http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html）の1月14日のブログ投稿のおかげで、並列プログラミングが可能であることがわかりました。 Android 4.0以降、RenderScriptに感謝します！OpenCLとの共通機能がかなりあるAPI。
私が今疑問に思っているのは、なぜGoogleがOpenCL（現在Khronosグループによって処理されているオープン仕様）を推進するのではなく、この新しいソリューションを実装することを選択したのかということです。
つまり、あるものから別のものに変換するのはそれほど難しいことではありませんが、それでも...
とにかく、本当の説明があれば教えてください！
AppleはOpenCLの商標を保持しています。GoogleはAppleと競合しています。おそらくそれは本当に簡単です。
Androidを使用したOpenCLの作業を完了しました（ここを参照）。Intel、Imagination、およびその他のチップメーカーの作業のおかげで、OpenCLが前進することを嬉しく思います。グーグルはすぐに好転するでしょう。
答えは、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コード生成をさらに改善する計画の大きな部分を占めています。高速コードの記述をさらに簡単にする多くの新しい改善もあります。