Opengl 当有OpenCL时，GLSL有什么意义？

将此视为标题中问题的完整形式：既然OpenCL可能是未来严肃GPU编程（以及其他设备编程）的通用标准，为什么不在OpenGL编程时——以一种未来证明的方式——利用OpenCL上的所有GPU操作？通过这种方式，您可以获得GLSL的优势，而不受其编程限制。

GLSL是。它最初用于控制图形管道

另一方面，OpenCL是最重要的。它不控制图形，而是控制计算

这两种技术针对不同的能力和功能

---

这就是说，向前看，它们可能不是使用GLSL进行计算的理由。然而，到目前为止，完全支持GLSL的供应商比支持OpenCL的供应商更多，因此它在计算方面仍然很有用，尽管它受到限制，因为这不是它的核心用途，至少现在是这样。

将来OpenCL可能会取代GLSL。与此同时，OpenGL互操作仍然存在一些问题，至少在最重要的（NVidia/ATI）实现中是如此

---

不过，OpenCL不会完全取代OpenGL。OpenGL在光栅图形方面做得更多。OpenCL中唯一的光栅图形原语是纹理/图像，它根本无法渲染图形。

@diter:让我来教你吧！CL/GL互操作性可能会严重损害整体性能，特别是在处理大量对象缓冲区（例如，大于100）时。改变上下文的开销以及对缓冲区结构或缓冲区指针的缺乏支持将扼杀我的应用程序，我正在认真考虑使用几何体着色器来替换我的opencl代码。不要自欺欺人，用opencl完全替换整个opengl需要一个完整的重新编码过程，这不仅需要很长时间，而且也没有什么优势。此外，正如这里的人们所说，opengl不仅仅是管道计算。我想说，如果您打算使用CL/GL iterop，请尽可能在顶点/几何体着色器上重写代码。

GLSL是一种“着色语言”。它用于3D渲染，并具有特别有用的特殊数据类型（例如，长度为4的向量和秩为4x4的矩阵）。顶点着色器和片段着色器位于渲染管道内定义良好的位置，它们会在通过该管道的数据流中自动触发。着色器还可以直接访问三维管道的变换和投影矩阵

OpenCL是一种“计算语言”。它不是专门为我们在3D渲染中看到的计算任务设计的，而是C的一个子集。OpenCL的数据类型与GLSL中的向量和矩阵（float4，float16）类似，但使用起来不太方便。此外，您没有图形上下文（这可能是一个优点，也可能是一个缺点），并且OpenCL内核不驻留在3D渲染管道中

如果要将计算模块插入三维渲染管道并由渲染管道触发，请使用GLSL。如果希望在3D渲染管道之外的GPU上进行常规计算，请使用OpenCL

---

这并不意味着OpenCL不能用于渲染3D图形。它可以。事实上，您可以在OpenCL中单独实现自己的管道，然后将图形复制到帧缓冲区。但如果你只想画一些3D图形，复制SGI、Nvidia、Intel和AMD工程师的所有工作可能不值得这么麻烦。然后，只需使用GLSL并将着色器插入一个随时可用且性能充分的OpenGL管道就更容易了。只是认为编写Masa是开源的OpenGL实现的一个主要任务。

这有点像问“当有Chrome时，Safari有什么意义？”：重点是OpenCL不仅仅是GLSL的变体；OpenGL 4.3管道中仍然有大量固定的功能，可编程性只涉及在该管道上连接在一起的特定着色器。OpenCL允许在程序代码中表达整个功能，但——我想——这里的问题真的变成了：这样会更慢吗？是的，我的意思是，在不考虑GLSL和OpenCL目标的情况下，OpenCL似乎在更强大的接口中提供了GLSL的优势。是否有OpenCL做不到的事情，而GLSL做不到的事情，以及OpenCL会做得更糟的事情？@Lela：就纯计算而言，目前唯一的真正优势（据我所知）是部署和供应商支持——GLSL在野外得到更好的支持（因此我的最后一段）。另外，对于纯计算，OpenCL确实比GLSL IMO好。是的。我应该更强调我提到的“未来证明”。这个问题的主要思想是围绕着未来的编程，而大多数迹象表明OpenCL将成为一个广泛支持的标准。我认为性能在很大程度上取决于你做什么，以及如何做。通常，您不会共享数百个缓冲区，但最多只能共享少量缓冲区。您所说的“无法渲染”是什么意思？据我所知，除了帧缓冲区（在屏幕上显示内容）之外，您可以使用OpenCL实现所有OpenGL管道。这并不意味着你仍然不能渲染到纹理，或者仅仅使用OpenGL来分配一个帧缓冲区，然后可以在OpenCL中使用。是的，你可以这样做，但是速度会非常慢。GPU拥有专用的高度优化的硬件，用于布点、光栅化、混合、镶嵌和其他各种典型的图形操作。OpenCL不提供对此硬件的任何支持。这就是我的意思。