我一直在想，如果有可能使用OpenCL的针对Android，发现这是不可能的，而完全放弃的主题。 但由于从1月14日的博客文章在官方Android开发者博客（http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html），我发现，并行编程是可能的由于Android 4.0，感谢的renderScript！ 具有与OpenCL的不少共同特征的API。
我现在想知道的是：为什么谷歌选择实现这一新的解决方案，而不是推的OpenCL向前（一种开放的规范，现在由Khronos Group处理）。
我的意思是，我知道，这不是真的很难从一个转换到另一个，但仍...
无论如何，如果有人因为真正的解释，请让我知道！
答案是，Android的需求比OpenCL的尝试提供很大的不同。
OpenCL的使用CUDA中首先介绍了执行模型。 在这个模型中，内核由一个或工人的许多组，并且每个组具有快速的共享该组内的存储器和同步原语。 这样做是什么引起的算法的描述与如何该算法应在特定的架构安排间杂（因为你决定一个组的大小，当该组内同步）。
当你正在编写一个架构是伟大的，你想绝对峰值性能，但它在性能便携性为代价获得峰值性能。 也许在你的建筑，你有足够的寄存器和共享内存来运行每组256名工人为获得最佳性能，但在另一种架构，你最终与上述每组职工128人任何大规模的寄存器溢出，致使80％的性能回归。 同时，由于你的代码是明确写出每组256名工人，运行时不能做任何事情来试图改善的另一种架构的情况 - 它必须服从你写什么。 从架构迁移到架构的GPU计算的台式机/ HPC的一面，当这种情况是常见的。
在移动设备上的Android需要许多不同的GPU和CPU厂商之间的性能与便携性非常不同的架构。 如果Android的是依靠CUDA式的执行模型，这将是几乎不可能写一个内核，让它在各种设备的运行可以接受。
的renderScript摘要超过调度从在一些峰值性能为代价的显影剂远离控制; 然而，我们在不断缩小差距在什么是可能用的renderScript条款。 例如，ScriptGroup，在Android 4.2中引入了一个API，是我们的计划，以进一步提高GPU的代码生成的重要组成部分。 有很多的到来，让写快的代码更容易新的改进了。
苹果持有的OpenCL商标。 谷歌与苹果竞争。 也许这就是这么简单。
我们所做的工作，对OpenCL的与Android（ 见这里 ），并很高兴地看到它前进得益于英特尔，想象力，和其他芯片制造商的工作。 谷歌将掉头很快。
