计算着色器不是常规渲染管道的一部分。因此，在执行绘图命令时，不涉及链接到当前程序或管道的计算着色器。
所以我希望它的调用速度比glDrawArrays快。任何人都可以提供有关开销的更多细节吗？
glDispatchComputeIndirect是否更快，因为它会跳过错误检查？
答案 0 :(得分：1)
这个问题基本上是无关紧要的。
计算着色器用于计算数据。渲染管道用于渲染内容。你不需要用一个来完成你需要另一个任务的任务。
如果您正在尝试构建间接渲染命令，为什么要努力使这些计算看起来像绘图操作而不仅仅是制作一个简单的CS？如果您正在尝试实际绘制内容，那么计算操作将无法访问大多数可以在90％的情况下快速渲染的内容。
因此，如果一个人比另一个人更快或更慢，那并不重要，因为你不会将一个用于与另一个相同的任务。由于他们做了两件完全不同的事情，所以无法衡量一个人相对于另一个人的表现。
这就像询问sin是否比sqrt更快。它并不重要，因为你不能用另一个取而代之。如果您需要sin，sqrt无法提供帮助。反之亦然。
它会跳过错误检查吗？
谁说它＆＃34;跳过错误检查＆＃34;？
调度操作仍然必须确保CS所需的任何纹理/图像/缓冲区实际上都是绑定的并且适合于CS。
答案 1 :(得分：1)
任何人都可以提供有关开销的更多详细信息吗？
当你为每次调用绘制足够的基元时，glDrawArrays开销很小，所有绘图命令都是如此：较少的绘制调用=更高的性能。
glDispatchComputeIndirect是更快的替代方案，因为它会跳过错误检查吗？
不，正如Nicol Bolas所说，当你需要一个顶点片段着色器时，你通常不会使用计算着色器，尽管有时候这种情况并不那么清楚。
glDrawArraysIndirect存在。此函数类似于glDrawArrays，但从GPU上的缓冲区获取渲染命令信息。如果在GPU上生成渲染命令信息，这是非常有用的，以避免读取它（避免昂贵的GPU到CPU复制）。但是，这是一个特例。
当你用低原始数量调用它时，glDrawArrays开销很大。通过分组多个对象和网格来避免这种情况。然后glMultiDrawArrays非常有用：https://www.khronos.org/opengl/wiki/Vertex_Rendering#Multi-Draw