我一直想知道是否可以使用OpenCL for Android，发现它不可能，并完全放弃了主题。 但感谢1月14日在官方Android开发者博客（http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html）上发布的博客文章，我发现并行编程是可能的自Android 4.0以来，感谢RenderScript！与OpenCL具有相当多功能的API。
我现在想知道的是：为什么谷歌选择实施这个新的解决方案，而不是推动OpenCL向前推进（现在由Khronos集团处理的开放式规范）。
我的意思是，我知道，从一个转换到另一个并不是很难，但仍然......
无论如何，如果有人作为真正的解释，请告诉我！
答案 0 :(得分：39)
我们已经使用Android（see here）完成了OpenCL的工作，并且很高兴看到它在英特尔，Imagination和其他芯片制造商的工作中取得了进展。谷歌很快就会转身。
答案 1 :(得分：32)
答案是Android的需求与OpenCL尝试提供的需求非常不同。
OpenCL使用CUDA中首次引入的执行模型。在此模型中，内核由一个或多个工作组组成，每个组在该组中具有快速共享内存和同步原语。这样做是因为算法的描述与应该如何在特定体系结构上调度该算法相混合（因为您决定了组的大小以及何时在该组内进行同步）。
当您为一个架构编写并希望获得绝对峰值性能时，这非常棒，但它会以性能可移植性为代价获得最佳性能。也许在您的体系结构上，您有足够的寄存器和共享内存来为每组运行256个工作程序以获得最佳性能，但在另一个体系结构中，您最终会发生大量寄存器溢出，每组最多128个工作者，导致80％的性能回归。同时，因为你的代码是为每组256个工作者显式编写的，所以运行时无法做任何事情来尝试改善另一个体系结构的情况 - 它必须服从你所写的内容。在GPU计算的桌面/ HPC端从架构迁移到架构时，这种情况很常见。
在移动设备上，Android需要具有截然不同架构的许多不同GPU和CPU供应商之间的性能可移植性。如果Android依赖于CUDA风格的执行模型，则几乎不可能编写单个内核并使其在一系列设备上运行可接受。
RenderScript以一些峰值性能为代价，从开发人员那里抽象出对日程安排的控制;但是，我们不断缩小与RenderScript相关的差距。例如，在Android 4.2中引入的ScriptGroup是我们进一步改进GPU代码生成计划的重要组成部分。有很多新的改进，使得编写快速代码变得更加容易。