opengl - 在OpenGL中使用间接渲染有什么好处?

标签 opengl opengl-es shader

我读到类似 glDrawElementsIndirect 的 API , glDrawArraysIndirect帮助我们进行间接渲染。间接渲染与直接渲染的不同之处在于,诸如“顶点属性数量”、“要绘制的实例数量”、“缓冲区对象的起始顶点属性”等渲染参数是由 GPU 本身在缓冲区对象中提供的,而不是直接渲染。由 CPU 在绘制调用中提供。

我明白了。 它还解释说,优点是渲染速度更快,因为不涉及 CPU 交互。但是等等,实际执行渲染调用的不是 CPU 吗?它仍然指定渲染模式(GL_TRIANGLES 等)。它还可能加载顶点属性。

间接渲染中的所有性能增益是否都是通过不必传递这些微小变量来实现的:“计数”、“基元计数”、“第一个顶点属性”、“实例计数” “? 这对我来说没有多大意义。 (它也没有改变任何状态)

最佳答案

性能增益通常不是由于传递一些小变量(例如“计数”或“实例计数”)而带来的,而是由于了解这些变量。为了知道这些值,您必须与 CPU 进行一次往返,这只有在结果可用后才可能,即在服务器同步之后(加上它会增加总线的延迟)。

假设您正在使用几何着色器的变换反馈。这意味着无论您输入什么,您都不真正知道另一端会输出什么,无论如何,在批处理完成并且您查询了计数之前都不知道。
间接渲染解决了这个问题,你不需要知道,实际上你也不想知道。信息进入缓冲区对象,GPU 无需您的干预即可访问它。

这类似于条件渲染。实际上你可以跳过条件渲染的整个过程,不是吗?您可以运行遮挡查询并查看它是否通过,然后决定是否提交您想要绘制的那些对象,而不是向命令队列提交可能不会执行的命令(多么低效!)。
但这意味着您必须等到查询(以及前一批)完成、同步并执行 PCIe 传输才能做出此决定。在此期间,GPU 可能会停止运行,然后您仍然没有设置正确的缓冲区/纹理并提交命令。因此,实际上,推测性地提交命令并让驱动程序/GPU 决定是否丢弃它们或是否绘制它们会更有效。

这也是 ARB_query_buffer_object 背后的想法,它允许您将查询结果读入缓冲区对象。

编辑:
此外,间接渲染允许更有效地提交渲染命令批(特别是与持久映射结合使用),这可以避免通常存在的大部分或全部服务器/客户端和 CPU/GPU 同步,并且可能来自另一个处理器核心,并节省每次绘制调用固定开销。参见第 62 页起 in Cass Everitt's talk .

关于opengl - 在OpenGL中使用间接渲染有什么好处?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19534284/

相关文章:

unity3d - 统一的 360 查看器,纹理出现在顶部和底部扭曲

javascript - 我们可以动态地将自定义着色器应用于 Three.js 对象吗

opengl-es - 带有柏林噪声的 GLSL 阴影

c++ - GLFW - 用鼠标旋转相机的 View 矩阵使其旋转

android opengl 纹理重叠

java - 如何在Android OpenGL中正确绘制不透明的纹理?

ios - GLKit 移动相机时一个物体移动奇怪

c++ - 与基本逻辑代码相比,OpenGL glDrawElements() 调用有多繁重?

Java 游戏网络与 Kryonet : Bare-bones packet transfering

c++ - Visual Studio 2019 找不到很多头文件