opencl - Google 选择 RenderScript 而不是 OpenCL 的真正原因是什么？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

8年前关闭。




Improve this question




该问题已被问到 before形式略有不同，但我想知道 Android 开发人员认为 Google 决定背后的真正原因是什么，而不是 Google 的官方答案是什么。

OpenCL 是一种开放标准，适用于各种设备，例如 CPU、桌面 GPU、ARM 处理器、FPGA 和 DSP。它为我们开发人员提供了创建适用于所有设备的高性能软件和库的便利。

RenderScript 是一种高级语言，主要关注媒体操作并在 CPU 和 GPU 上运行。它适用于所有新的 Android 手机和平板电脑，但不适用于其他操作系统。与 OpenCL 的一个很大区别是 RenderScript 总是处理调度，而不是软件。

谷歌的官方回答在 OpenCL 上实际上是不正确的，这让 OpenCL 社区中的许多人感到沮丧，并在逻辑上给出了一些强烈的 react 。所以请对 RenderScript 和 OpenCL 保持事实——我不希望这个问题被关闭，因为有人在胡说八道。

Answer 1

首先，让我们来处理this的答案。蒂姆·默里的问题。

他指出，OpenCL/CUDA 执行模型与其执行模型的各种因素有关，例如寄存器计数、本地内存和其他此类细节。虽然这可能部分正确，但 OpenCL 执行模型是专门开发的，允许聪明的开发人员以仍然可以产生最大性能的方式抽象这些差异。

例如:为了处理微架构的差异，内核开发人员需要了解这些细节，OpenCL 运行时 API 提供了 clGetDeviceInfo它暴露了过多的信息(请注意，扩展信息也可以在此处检索)。

矢量(SIMD 风格)执行的细节也不能幸免。大多数 OpenCL 实现指南 state内核应该在没有显式矢量化的情况下编写 - 实现将矢量化相邻工作项的执行。这也是 CUDA 遵循的模型(它甚至不再提供向量类型，但这是另一回事)。

来到工作项目的地步；确实可以constrain特定尺寸的工作尺寸。然而在实践中，reqd_work_group_size除非它是某个已知维度(为了计算，而不是性能)，否则几乎不会使用属性。

此外，clEnqueueNDRangeKernel 的 OpenCL 文档明确指出

"local_work_size can also be a NULL value in which case the OpenCL implementation will determine how to be break the global work-items into appropriate work-group instances."

Intel 的情况确实如此。和 AMD 实现。

现在让我们继续讨论 Stephen Hines 在 Android 错误页面上提出的观点 here .

“OpenCL 不符合 Android 开发人员的需求”——我不相信有任何形式的民意调查。我不知道斯蒂芬从哪里得到这些无可争议的信息。我不能辩论这个。

“并积极促成平台碎片化” - 是 Google 的开发人员 really going to argue NDK 不包含特定于硬件的功能？好像 warning listed在 NDK 主页上还不够。

“OpenCL 不符合 Android 的需求/目标，因此我们不会发布支持它的 Google 设备”。如果这是真的，那么那些 Android 设备就不会附带 OpenCL 支持。我不能比文森特更好地说明 here .

"Not Google but the hardware vendors made the drivers for RenderScript Compute. ARM chose to build the RSC-compiler on top of OpenCL, because they already chose for OpenCL.

See - the hardware vendors did not create the drivers because Google or Khronos Group asked them too, they created them because they wanted to. OpenGL and WebCL are some of the reasons, but also the competition over the new desktop."

最后，作为一名从寄存器组合器时代(在 GeForce 2 上)就开始使用 GPGPU 的开发人员，我认为 OpenCL 没有理由对 Android 生态系统造成更大的破坏，或者为什么它应该比 this 更受青睐。回答说

Apple holds the trademark on OpenCL. Google competes with Apple. Perhaps it's really that simple.

We've done work on OpenCL with Android (see here) and are happy to see it moving forward thanks to the work of Intel, Imagination, and other chip makers. Google will turn around soon enough.

或许真的就这么简单。