为啥 Google 选择 RenderScript 而不是 OpenCL [关闭]

Posted 2023-03-16

【中文标题】为啥 Google 选择 RenderScript 而不是 OpenCL [关闭]

【英文标题】：Why did Google choose RenderScript instead of OpenCL [closed]为什么 Google 选择 RenderScript 而不是 OpenCL [关闭]

【发布时间】：2013-01-01 09:23:27

【问题描述】：

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

我现在想知道的是：为什么 Google 选择实施这个新解决方案，而不是推动 OpenCL（现在由 Khronos 小组处理的开放规范）。

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

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

【问题讨论】：

LinkedIn 上继续讨论：linkedin.com/groups/…

【参考方案1】：

Apple 拥有 OpenCL 的商标。谷歌与苹果竞争。或许真的就这么简单。

我们已经在 Android (see here) 上完成了 OpenCL 的工作，并且很高兴看到它在英特尔、Imagination 和其他芯片制造商的努力下取得进展。 Google 很快就会好转。

【讨论】：

为什么这个答案没有更高？

@UtkarshSinha：接受的答案总是第一位的，这是如此的政策。即使另一个答案的票数是原来的 100 倍。只有两个答案。这是它所能达到的最高水平。

【参考方案2】：

答案是 Android 的需求与 OpenCL 试图提供的完全不同。

OpenCL 使用 CUDA 中首次引入的执行模型。在这个模型中，一个内核由一组或多组worker组成，每个组在该组内都有快速共享内存和同步原语。这样做会导致算法的描述与应该如何在特定架构上调度该算法（因为您正在决定组的大小以及何时在该组内同步）混合在一起。

当您为一种架构编写代码并希望获得绝对的峰值性能时，这非常棒，但它以牺牲性能可移植性为代价获得了峰值性能。也许在您的架构上，您有足够的寄存器和共享内存来每组运行 256 个工作程序以获得最佳性能，但在另一种架构上，您最终会出现大量寄存器溢出，每组超过 128 个工作程序，导致 80% 的性能回归.同时，由于您的代码是为每组 256 个工作人员明确编写的，因此运行时无法尝试改善另一个架构上的情况——它必须遵守您所编写的内容。在 GPU 计算的桌面/HPC 端从架构迁移到架构时，这种情况很常见。

在移动设备上，Android 需要在具有非常不同架构的许多不同 GPU 和 CPU 供应商之间实现性能可移植性。如果 Android 依赖于 CUDA 风格的执行模型，几乎不可能编写一个内核并让它在一系列设备上可接受地运行。

RenderScript 以牺牲一些峰值性能为代价，将调度控制权从开发人员手中抽离出来；但是，我们在 RenderScript 的可能性方面不断缩小差距。例如，在 Android 4.2 中引入的 API ScriptGroup 是我们进一步改进 GPU 代码生成计划的重要组成部分。还有很多新的改进，让编写快速代码变得更加容易。

【讨论】：

OpenCL 有一个“让运行时决定组大小”的特性——只需在 clEnqueueNDRangeKernel 中为组大小传递 NULL。

伟大的 OpenCL 库已经考虑了这些最佳参数调整。让您的代码根据运行时硬件类型自动更改参数非常简单。

请注意，Tim Murray 在 Google 的 Renderscript 团队工作，并且对 Renderscript 的成功有着既得利益。他在这里陈述了不正确的信息，“因为您正在决定一个组的大小以及何时在该组内同步”。如上所述，您可以让运行时决定组大小。

对于那些标记这个答案的人，请停止。虽然您可能不同意这里提出的论点，但这是一个询问 Google 为什么选择使用 Renderscript 的问题，并且 Google 员工已经提供了他们的立场。这是对所提出问题的可行答案。如果您想反驳此答案中的断言，请改用 cmets 来解释为什么它们可能不正确。

@BradLarson，由于 OpenCL 社区对 Google 对这个开放标准的非发明性处理感到非常沮丧，你建议我们应该怎么做？谷歌试图避免与我们进行任何讨论，但不断在 OpenCL 上提供上述虚假信息。