以前曾以稍微不同的形式提出过这个问题，但我想知道 Android 开发人员认为谷歌决定背后的真正原因是什么，而不是谷歌的官方答案是什么。
OpenCL 是一种开放标准，适用于各种设备，例如 CPU、桌面 GPU、ARM 处理器、FPGA 和 DSP。它为我们开发人员提供了创建适用于所有设备的高性能软件和库的便利。
RenderScript 是一种高级语言，主要关注媒体操作并在 CPU 和 GPU 上运行。它适用于所有新的 Android 手机和平板电脑，但不适用于其他操作系统。与 OpenCL 的一个很大区别是 RenderScript 总是处理调度，而不是软件。
Google 的官方回答在 OpenCL 上实际上是不正确的，这让 OpenCL 社区中的许多人感到沮丧，并在逻辑上给出了一些强烈的反应。所以请对 RenderScript 和 OpenCL 保持事实——我不希望这个问题被关闭，因为有人在胡说八道。
首先，让我们处理蒂姆·默里对这个问题的回答。
他指出，OpenCL/CUDA 执行模型与其执行模型的各种因素有关，例如寄存器计数、本地内存和其他此类细节。虽然这可能部分正确，但 OpenCL 执行模型是专门开发的，允许聪明的开发人员以仍然可以产生最大性能的方式抽象这些差异。
例如：为了处理微架构的差异，内核开发人员需要了解这些细节，OpenCL 运行时 API 提供了clGetDeviceInfo，它公开了大量信息（注意扩展信息也可以在此处检索）。
矢量（SIMD 风格）执行的细节也不能幸免。大多数 OpenCL 实现指南声明内核应该在没有显式矢量化的情况下编写 - 实现将矢量化相邻工作项的执行。这也是 CUDA 遵循的模型（它甚至不再提供向量类型，但这是另一回事）。
来到工作项目的地步；确实可以将工作尺寸限制为特定大小。然而在实践中，reqd_work_group_size除非它是某个已知维度（为了计算，而不是性能），否则几乎不会使用该属性。
此外，clEnqueueNDRangeKernel的 OpenCL 文档明确指出
“ local_work_size也可以是 NULL 值，在这种情况下，OpenCL 实现将确定如何将全局工作项分解为适当的工作组实例。”
Intel和 AMD的实现也是如此。
现在让我们继续讨论 Stephen Hines 在此处的 Android 错误页面上提出的观点。
“不是 Google，而是硬件供应商为 RenderScript Compute 制作了驱动程序。ARM 选择在 OpenCL 之上构建 RSC 编译器，因为他们已经选择了 OpenCL。
看- 硬件供应商没有创建驱动程序，因为谷歌或 Khronos Group 也要求他们，他们创建它们是因为他们想要。OpenGL 和 WebCL 是部分原因，也是新桌面的竞争。”
最后，作为一名从寄存器组合器时代（在 GeForce 2 上）就开始使用 GPGPU 的开发人员，我认为没有任何理由说明 OpenCL 对 Android 生态系统有更大的破坏性，或者为什么它应该比这个答案更受欢迎
Apple 拥有 OpenCL 上的商标。谷歌与苹果竞争。或许真的就这么简单。
我们已经在 Android 上完成了 OpenCL 的工作（请参阅此处），并且很高兴看到它在英特尔、Imagination 和其他芯片制造商的努力下取得进展。谷歌很快就会好转。
或许真的就这么简单。