我们已经问before这个问题略有不同，但我想知道Android开发人员认为Google的决定背后的真正含义，而不是谷歌官方的答案。
OpenCL是一种开放标准，适用于各种设备，如CPU，台式机GPU，ARM处理器，FPGA和DSP。它为我们的开发人员提供了创建高性能软件和库的便利，适用于所有设备。
RenderScript是一种更高级别的语言，主要侧重于媒体操作，可在CPU和GPU上运行。它适用于所有新的Android手机和平板电脑，但不适用于其他操作系统。与OpenCL的一个重大区别是RenderScript总是处理调度，而不是软件。
Google的官方回答在OpenCL上实际上是不正确的，这对OpenCL社区中的许多人感到沮丧，并在逻辑上做出了一些重大反应。所以请务必关注RenderScript和OpenCL - 我不希望这个问题被关闭，因为我们被告知废话。
答案 0 :(得分：11)
首先，让我们来处理Tim Murray对this问题的回答。
他声称OpenCL / CUDA执行模型与其执行模型的各种因素相关联，如寄存器计数，本地存储器和其他此类细节。虽然这可能部分正确，但OpenCL执行模型是专门开发的，允许聪明的开发人员以仍然可以产生最大性能的方式抽象这些差异。
例如：为了处理微架构的差异，如果内核开发人员需要知道这些细节，OpenCL运行时API会提供clGetDeviceInfo，它会暴露大量信息（请注意，扩展信息也可以在这里检索。）
矢量（SIMD风格）执行的细节也不能幸免。大多数OpenCL实现指南state应该在没有显式向量化的情况下编写内核 - 实现将向量化相邻工作项的执行。这也是CUDA遵循的模型（它甚至不再提供矢量类型，但这是另一回事）。
来到工作项目;确实可以将constrain工作维度扩展到特定大小。但实际上，reqd_work_group_size属性几乎不会被使用，除非它是一些已知的维度（为了计算而不是性能）。
此外，clEnqueueNDRangeKernel的OpenCL文档明确指出
“ local_work_size 也可以是NULL值，在这种情况下是OpenCL 实施将决定如何打破全球工作项目 进入适当的工作组实例。“
Intel和AMD实施都是如此。
现在让我们转到Stephen Hines在here上的Android错误页面上提出的观点。
“不是谷歌，但硬件供应商为RenderScript制作了驱动程序 计算。 ARM选择在OpenCL之上构建RSC编译器，因为 他们已经选择了OpenCL。
See - 硬件供应商没有创建驱动程序，因为 谷歌或Khronos集团也问过他们，因为他们创建了他们 想要。 OpenGL和WebCL是一些原因，也是 对新桌面的竞争。“
最后，作为一名从注册合并器（在GeForce 2上）开始使用GPGPU的开发人员，我认为没有理由认为OpenCL对Android生态系统更具破坏性，或者为什么它应该优先于{ {3}}回答陈述
Apple拥有OpenCL的商标权。谷歌与苹果竞争。 也许真的很简单。我们已经使用Android（this）完成了OpenCL的工作，并且很高兴 由于英特尔，Imagination和。的工作，看到它向前发展 其他芯片制造商。谷歌很快就会转身。
也许真的很简单。