谷歌选择RenderScript而不是OpenCL的真正原因是什么？

Question

我们已经问before这个问题略有不同，但我想知道Android开发人员认为Google的决定背后的真正含义，而不是谷歌官方的答案。

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

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

Google的官方回答在OpenCL上实际上是不正确的，这对OpenCL社区中的许多人感到沮丧，并在逻辑上做出了一些重大反应。所以请务必关注RenderScript和OpenCL - 我不希望这个问题被关闭，因为我们被告知废话。

Answer 1

首先，让我们来处理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错误页面上提出的观点。

• “OpenCL不符合Android开发人员的需求” - 我不相信有任何形式的民意调查。我没有看到斯蒂芬获得这些无可争议的信息。我不能辩论这个。
• “并积极参与平台碎片化” - Google really going to argue的开发人员是否认为NDK不包含特定于硬件的功能？好像NDK主页上的warning listed还不够。
• “OpenCL不符合Android的需求/目标，因此我们不会发布支持它的Google设备”。如果这是真的，那些Android设备将不会附带OpenCL支持。我不能比文森特更好地陈述here。

  

“不是谷歌，但硬件供应商为RenderScript制作了驱动程序   计算。 ARM选择在OpenCL之上构建RSC编译器，因为   他们已经选择了OpenCL。

     

See - 硬件供应商没有创建驱动程序，因为   谷歌或Khronos集团也问过他们，因为他们创建了他们   想要。 OpenGL和WebCL是一些原因，也是   对新桌面的竞争。“

最后，作为一名从注册合并器（在GeForce 2上）开始使用GPGPU的开发人员，我认为没有理由认为OpenCL对Android生态系统更具破坏性，或者为什么它应该优先于{ {3}}回答陈述

  Apple拥有OpenCL的商标权。谷歌与苹果竞争。   也许真的很简单。

     

我们已经使用Android（this）完成了OpenCL的工作，并且很高兴   由于英特尔，Imagination和。的工作，看到它向前发展   其他芯片制造商。谷歌很快就会转身。

也许真的很简单。