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

Question

之前已经提出了一个稍微不同的问题,但我想知道Android开发人员认为谷歌的决定背后的真正含义,而不是谷歌官方的答案.

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

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

谷歌的官方回答在OpenCL上实际上是不正确的,这使OpenCL社区中的许多人感到沮丧,并在逻辑上做出了一些重大反应.因此,请务必关注RenderScript和OpenCL - 我不希望这个问题被关闭,因为无意中被告知.

Answer 1

首先,让我们来谈谈Tim Murray 对这个问题的回答.

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

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

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

• 来到工作项目; 确实可以将工作维度约束到特定大小.然而在实践中,reqd_work_group_size除非是一些已知的尺寸(为了计算而不是性能),否则几乎不使用该属性.

• 此外,clEnqueueNDRangeKernel的OpenCL文档清楚地说明了这一点

" local_work_size也可以是NULL值,在这种情况下,OpenCL实现将确定如何将全局工作项分解为适当的工作组实例."

英特尔和AMD的实施也是如此.

现在让我们走上由斯蒂芬·海因斯在Android的错误页面上超募过点这里.

• "OpenCL不符合Android开发人员的需求" - 我不相信有任何类型的民意调查.我没有看到斯蒂芬获得这些无可争议的信息.我不能辩论这个.
• "并积极促进平台碎片化" - Google的开发人员是否真的会争辩说NDK不包含特定于硬件的功能？好像NDK主页上列出的警告不够.
• "OpenCL不符合Android的需求/目标,因此我们不会发布支持它的Google设备".如果这是真的,那些Android设备将不会附带OpenCL支持.在这里,我不能比文森特更好地说明这一点.

"不是Google,而是硬件供应商为RenderScript Compute制作了驱动程序.ARM选择在OpenCL之上构建RSC编译器,因为他们已经选择了OpenCL.

请参阅 - 硬件供应商没有创建驱动程序,因为Google或Khronos Group也提出了这些驱动程序,因为他们想要创建驱动程序.OpenGL和WebCL是一些原因,也是新桌面的竞争."

最后,作为一名从注册合并器(在GeForce 2上)开始与GPGPU合作的开发人员,我认为没有理由说OpenCL对Android生态系统更具破坏性,或者为什么它应该优先于这个答案.

Apple在OpenCL上持有该商标.谷歌与苹果竞争.也许真的很简单.

我们已经完成了使用Android的OpenCL工作(见这里),并且很高兴看到由于英特尔,Imagination和其他芯片制造商的工作而向前推进.谷歌很快就会转身.

也许真的很简单.