为什么Google会选择RenderScript而不是OpenCL

Question

为什么Google会选择RenderScript而不是OpenCL

Red*_*arp 43 android opencl renderscript

我一直想知道是否有可能使用OpenCL for Android,发现它是不可能的,并完全放弃了主题.但感谢1月14日在官方Android开发者博客(http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html)上发布的博客文章,我发现并行编程是可能的自Android 4.0以来,感谢RenderScript!一个与OpenCL有很多共同特征的API.

我现在想知道的是:为什么谷歌选择实施这个新的解决方案,而不是推动OpenCL向前推进(现在由Khronos集团处理的开放规范).

我的意思是,我知道,从一个转换到另一个并不是很难,但仍然......

无论如何,如果有人作为真正的解释,请告诉我!

Answer 1

arr*_*ire 43

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

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

Answer 2

Tim*_*ray 32

答案是Android的需求与OpenCL尝试提供的需求非常不同.

OpenCL使用CUDA中首次引入的执行模型.在此模型中,内核由一个或多个工作组组成,每个组在该组中具有快速共享内存和同步原语.这样做是因为算法的描述与应该如何在特定体系结构上调度该算法相混合(因为您决定了组的大小以及何时在该组内进行同步).

当你为一个架构编写并希望获得绝对峰值性能时,这非常棒,但它会以性能可移植性为代价获得最佳性能.也许在您的体系结构上,您有足够的寄存器和共享内存来为每组运行256个工作程序以获得最佳性能,但在另一个体系结构中,您最终会发生大量的寄存器溢出,每组最多128个工作者,导致80%的性能回归.同时,因为你的代码是为每组256个工作者显式编写的,所以运行时无法做任何事情来尝试改善另一个体系结构的情况 - 它必须服从你所写的内容.在GPU计算的桌面/ HPC端从架构迁移到架构时,这种情况很常见.

在移动设备上,Android需要具有不同架构的许多不同GPU和CPU供应商之间的性能可移植性.如果Android依赖于CUDA风格的执行模型,则几乎不可能编写单个内核并使其在一系列设备上运行可接受.

RenderScript以一些峰值性能为代价,从开发人员那里抽象出对调度的控制; 但是,我们不断缩小与RenderScript相关的差距.例如,在Android 4.2中引入的ScriptGroup是我们进一步改进GPU代码生成计划的重要组成部分.有很多新的改进,使得编写快速代码变得更加容易.

请注意,Tim Murray在Google的Renderscript团队工作,对Renderscript的成功有着既得利益.他在这里陈述不正确的信息"因为你决定一个组的大小以及何时在该组内进行同步".如上所述,您可以让运行时决定组大小. (37认同)
OpenCL有一个"让运行时决定组大小"功能 - 只需在clEnqueueNDRangeKernel中为组大小传递NULL. (30认同)
@BradLarson,因为OpenCL社区对谷歌未发明的处理这个开放标准感到非常沮丧,你有什么建议我们应该做什么？谷歌试图避免与我们进行任何讨论,但一直在告诉OpenCL上面的虚假信息. (19认同)
对于那些标记这个答案的人,请停止.虽然你可能不同意这里提出的论点,但这是一个问题,为什么谷歌选择使用Renderscript,而谷歌的一名员工已经提出了他们的立场.这是对所提问题的可行答案.如果您希望反驳此答案中的断言,请使用注释来解释它们可能不正确的原因. (13认同)
伟大的OpenCL库已经考虑了这些最佳参数适应性.让代码根据运行时硬件类型自动更改参数非常简单. (7认同)
如先前的评论所述，该答案实际上是错误的。 (3认同)
我会告诫不要在 RS Compute 中走得太远（尽管肯定会探索您的选择）。谷歌做了一个类似的项目，用于称为 RS 图形的图形。开发人员反击并希望使用 OpenGL 和 Google 弃用的 RS 图形。讨论在这里：https://groups.google.com/forum/#!topic/android-developers/m194NFf_ZqA 正如您在上面提到的 Brad 帖子中看到的那样，大多数开发人员对这个决定不满意，更喜欢开放标准这给了他们更多像 OpenCL 一样的控制权。甚至约翰卡马克最近也说这是一个“WTF？” 决定。很有可能再次发生 (2认同)
@BradLarson,在您的链接开发者表达了他们的意见,然后Google拒绝了它没有讨论.然后,当开发人员推迟时,他们再次表示强硬不使用Android.然后Devs再次推回,他们说不,你没关系.然后Devs再次推迟,他们只是关闭了评论.这不是一个只是在谈论隔离墙的讨论. (2认同)
@JimV--他们都被标记为使用人身攻击,并被其他主持人删除.我已经恢复了一个,没有不必要的严厉语言.关于您的评论,Stack Overflow不是推动开发人员更改策略的地方.如果你想反驳他们在这里所做的技术论证,那很好,但我不希望这种情况转变为火焰战争. (2认同)
即使他们出售,我也反对供应商锁定.Google仍然可以使用OpenCL实现Renderscript并公开这两个API,这将是一个实用的解决方案.你下一步怎么做？Google会尝试阻止其他Java绑定到OpenGL ES API吗？Renderscript不是跨平台处理API,它适合不同的需求,我不会在桌面和嵌入式环境中使用特定于平台的API.理想情况下,Google应该为OpenCL做出贡献,以帮助改善它.最终用户应该选择Android,因为它符合他们的需求,而不是因为缺乏OpenCL支持. (2认同)

归档时间：	12 年，7 月前
查看次数：	15697 次
最近记录：	10 年，9 月前