OpenCL与OpenGL互操作的优势

Question

由于OpenGL使用纹理内存和许多内置的图形函数（混合、MipMap等），因此我们可以获得良好的速度。

为什么我们需要OpenCL（由于OpenCL缓冲区而变慢）与OpenGL的互操作性，只是因为我们可以将渲染与计算相结合，还是有其他好处，如性能。

我只想知道这样做的主要优势，是否有任何已发表的论文显示他们通过使用OpenGL与OpenCL的互操作性增加了性能或任何证明显示在速度和质量方面提高了性能。

- Megharaj

---

可能是OpenCL比OpenGL慢的重复问题。 - talonmies

我不是这个领域的专家，但我怀疑使用OGL + OCL可以提高一些性能。当一个人想要使用OCL时，需要切换上下文，这可能会影响性能。另一方面，有些算法使用通用的“着色器”（如OpenCL）编写更容易。 - fen

@talonmies 我正在寻找证明为什么Khronos添加了互操作性的证据，之前的问题我并不满意，我只想知道他们在哪里发表了一些论文，证明他们获得了质量或速度。 - Megharaj

@fen 我不认为在切换上下文时会有额外开销，因为它们共享上下文和缓冲区。请问是否有任何相关论文？ - Megharaj

@Megharaj：这些都很好（虽然我怀疑你在与风车搏斗）。但是你现在已经两次提出了几乎相同的问题，这并不好。 - talonmies

Answer 1

OpenGL专注于实时光栅图形。由于其范围有限，可以更加优化该任务，并且大多数硬件也是为此而设计的。

OpenCL则涉及通用计算。折叠蛋白质、天气预报、高频交易、模拟神经元、机器学习、SETI、信号处理、比特币挖掘等。

但在两者之间也有许多重叠领域。

首先，许多这些东西都具有视觉组件。例如，科学家可能希望能够看到/与折叠的蛋白质进行交互，而无需将所有数据从GPU RAM复制到CPU内存，对其进行处理以使其成为可视格式，然后将其发送回GPU。

此外，游戏也可以使用OpenCL。以Minecraft为例。如果您正在使用现代OpenGL（而不是Minecraft实际使用的OpenGL 1.3）制作Minecraft，则希望只将原始地图数据上传到GPU中。使用几何/镶嵌着色器的单个传递将该数据转换为立方体和其他形状，然后使用变换反馈来捕获结果（您只需要运行一次）。

但Minecraft也有各种关于如何更新地图的规则。计算照明，生长树木，使水流动，引爆TNT等等。这些是你用着色器（或者可能不止一个通道）无法做到的事情。你可以在CPU上进行（Minecraft就是这样做的），但如果你看过那些同时引爆数千个TNT的视频，你会发现这会导致严重的延迟。而水流动可能会对大型服务器上的所有人造成延迟。你可以使用OpenCL来发送给OpenGL，但如果它们链接在一起，效率会更高。

您可以使用OpenCL来模拟新的OpenGL技术。例如，如果您拥有OpenCL但没有几何/细分着色器，则可以在OpenCL中执行此操作（当然，在现实中目前并不那么有用，因为大多数具有过时OpenGL实现的系统也将缺乏OpenCL支持）。是否存在像细分着色器这样有用但不存在的东西？

有很多视觉效果在OpenGL管道内无法实现（至少不高效）。一个例子是实时光线追踪。另一个是粒子模拟。过程/分形地形生成也是如此。

还有其他一些对游戏/实时图形有用的东西。例如，物理模拟可以移动到CPU外。此外，如果渲染管道/场景图本身可以移动到GPU上，这将显著减少CPU和GPU之间的调用次数，并使其更加并行。还有许多其他的事情，如射线投射、AI、路径查找等等。基本上，任何你只计算以便于视觉呈现的东西。

最后，我确定还有很多其他的东西，以前没有人想到过，但现在是可能的。随着硬件朝着这个方向发展，我们越来越推崇并行算法。

- David C. Bishop

---

非常感谢您的回答，我正在寻找这种类型的答案。是否有任何已发表的论文或文章，在任何应用中都取得了优势？再次感谢您的回答。 - Megharaj

@Megharaj 我不知道有没有任何论文展示直接集成OpenCL->OpenGL与OpenCL->CPU->OpenGL相比的优势（我相信有很多关于OpenCL+OpenGL的论文，但并非特定于集成）。这只是会提高性能。除了在一些可能的例外情况下开销太大（例如从GPU->CPU->GPU传递所有场景图调用可能比仅在CPU上执行更慢）需要额外的无用工作之外，应该可以完成所有事情而不需要直接集成。 - David C. Bishop