Android 为什么谷歌选择RenderScript而不是OpenCL

我一直在想，是否有可能在Android上使用OpenCL，但我发现这是不可能的，于是干脆放弃了这个话题。 但多亏了1月14日在Android开发者官方博客上发布的博文(http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html)，我发现自从Android 4.0以来，由于RenderScript，并行编程是可能的！一个API，它与OpenCL有很多共同的特性

我现在想知道的是：为什么谷歌选择实施这个新的解决方案，而不是推进OpenCL（一个现在由Khronos集团处理的开放规范）

我的意思是，我知道，从一个转换到另一个并不难，但是

---

不管怎么说，如果有人能说出真实的解释，请让我知道

苹果拥有OpenCL的商标。谷歌与苹果竞争。也许真的就这么简单

---

我们已经用Android（）完成了OpenCL的工作，很高兴看到它在Intel、Imagination和其他芯片制造商的努力下向前发展。谷歌很快就会扭转局面。

答案是Android的需求与OpenCL试图提供的截然不同

OpenCL使用最早在CUDA中引入的执行模型。在这个模型中，内核由一个或多个工作组组成，每个工作组在该组中都有快速共享内存和同步原语。这会导致算法的描述与该算法在特定体系结构上的调度方式混杂在一起（因为您正在决定组的大小以及何时在该组中进行同步）

当您为一种体系结构编写代码时，您希望获得绝对的峰值性能，但它以牺牲性能可移植性为代价获得了峰值性能，这一点非常好。也许在您的体系结构上，您有足够的寄存器和共享内存来运行每个组256个工作线程以获得最佳性能，但在另一个体系结构上，您最终会出现大量寄存器溢出，每个组超过128个工作线程，导致80%的性能下降。同时，因为您的代码是为每个组256个工作人员显式编写的，所以运行时无法尝试在另一个体系结构上改善这种情况——它必须遵守您编写的内容。这种情况在GPU计算机的桌面/HPC端从一个体系结构移动到另一个体系结构时很常见

在移动设备上，Android需要在许多不同的GPU和CPU供应商之间具有非常不同的体系结构，以实现性能可移植性。如果Android依赖CUDA风格的执行模型，那么几乎不可能编写一个内核并在一系列设备上运行

---

RenderScript从开发人员那里抽象出对调度的控制，以牺牲一些峰值性能为代价；然而，我们一直在缩小RenderScript的差距。例如，Android 4.2中引入的API ScriptGroup是我们进一步改进GPU代码生成计划的重要组成部分。还有很多新的改进使得编写快速代码变得更加容易。

OpenCL有一个“让运行时决定组大小”的功能——只需在clEnqueueNDRangeKernel中为组大小传递NULL。优秀的OpenCL库已经考虑到了这些最佳参数自适应。让您的代码根据运行时硬件类型自动更改参数非常简单。请注意，Tim Murray在Google的Renderscript团队工作，对Renderscript的成功感兴趣。他在这里陈述了不正确的信息，“因为您决定了一个组的大小以及何时在该组中进行同步”。如上所述，您可以让运行时决定组大小。对于标记此答案的用户，请停止。虽然您可能不同意这里提出的论点，但这是一个问题，询问谷歌为什么选择使用Renderscript，一名谷歌员工已经提供了他们对Renderscript的立场。这是对所提问题的可行答案。如果你想反驳这个答案中的断言，请使用注释来解释它们可能不正确的原因。@BradLarson，由于OpenCL社区对Google没有发明处理这个开放标准感到非常失望，你建议我们应该怎么做？谷歌试图避免与我们进行任何讨论，但在OpenCL上不断透露上述虚假信息。LinkedIn上的讨论仍在继续：为什么这个答案不更高？@Utkarshssinha：这是一项政策，公认的答案总是排在第一位。即使另一个答案有100倍的选票。只有两个答案。这是它能达到的最高点。