vik*_*eid 19 opengl shader opengl-es
我读过API之类的glDrawElementsIndirect,glDrawArraysIndirect帮助我们进行间接渲染.间接渲染不同于直接渲染参数,如"顶点属性数","绘制实例数","从缓冲区对象开始顶点属性"等由GPU本身在缓冲区对象中提供而不是直接渲染由绘图调用中的CPU提供.
我明白.它还解释了它的优点是它可以更快地渲染,因为不涉及CPU交互.但是等等,是不是实际进行渲染调用的CPU？它仍然指定了渲染模式(GL_TRIANGLES等).它也可能加载了顶点属性.
那么,间接渲染中的所有穿孔增益都是通过不必传递这些微小变量来解释的:"计数","原始计数","第一顶点属性","实例计数"？这对我来说没什么意义.(它也没有改变任何状态)
Dam*_*mon 22
性能增益通常不是由于传递一些小变量,如"计数"或"实例计数",而是由于知道这些.为了了解这些值,您必须往返CPU,这只有在结果可用之后才可能,即在服务器同步之后(加上它会增加总线的延迟).
假设您正在使用带有几何着色器的变换反馈.这意味着,无论你给什么,你不真的知道什么是对的另一端出来,而不是之前的批次已完成,你查询的次数,反正.
间接渲染解决了这个问题,你不需要知道,实际上你不想知道.信息进入缓冲区对象,GPU可以在没有您干预的情况下访问它.
这类似于条件渲染.实际上你可以跳过条件渲染的全部内容,不是吗.您可以运行遮挡查询并查看是否通过,然后决定是否提交要绘制的对象,而不是将命令提交到可能无法执行的命令队列(效率低下!).
除此之外,您必须等到查询(以及上一批)完成,同步,并在做出此决定之前进行PCIe传输.在此期间,GPU可能会停止,然后您仍然没有设置正确的缓冲区/纹理和提交的命令.实际上,推测性地提交命令并让驱动程序/ GPU决定是丢弃它们还是绘制它们是更有效的.
这也是背后的想法ARB_query_buffer_object,它允许您将查询结果读入缓冲区对象.
编辑:
此外,间接渲染允许更有效地提交渲染命令批次(特别是与持久映射相结合),这可以避免通常存在的大部分或全部服务器/客户端和CPU/GPU同步,并且可能来自另一个处理器核心和保存每个drawcall固定开销.请参阅Cass Everitt的演讲中的第62页.
在直接渲染中,CPU占用了准备并将索引数据从其自己的存储器中流出,通过具有有限带宽的总线到GPU.它必须检查GPU状态并与之同步.每个步骤都很耗时.
使用间接渲染,所有CPU都会发送一个简短的命令,从而启动大量的绘图操作.这节省了总线带宽.而且因为GPU可以在更长的时间内工作,所以中断的次数更少,迫使CPU停止正在进行的任何操作(上下文切换),这意味着复杂的数字任务,如物理模拟将执行更高性能.