OpenGL状态冗余消除树，渲染状态优先级

Question

我正在我的游戏引擎中使用自动 OpenGL 批处理方法，以减少绘制调用和冗余调用。

我的批处理树设计从最昂贵的状态开始，并为每个较便宜的状态添加叶子。

例子:
树根:着色器/程序
sibling :混合状态...
顺便说一句

所以我的问题是最有可能最昂贵的电话，在这个列表中:

绑定(bind)程序

绑定(bind)纹理

绑定(bind)缓冲区

缓冲纹理、顶点数据

绑定(bind)渲染目标

glEnable/glDisable

混合状态方程、颜色、函数、colorWriteMask

深度模板状态 depthFunc, stencilOperations, stencilFunction, writeMasks

还想知道哪种方法会更快:
- 将所有可批处理的绘图命令收集到单个顶点缓冲区并仅调用 1 个绘图调用(此方法还将强制更新 cpu 端每个顶点的矩阵变换)
- 根本不进行批处理并渲染许多小的绘制调用，只有批处理粒子系统......

PS:根据使用情况，渲染目标将始终更改为 Pre 或 Post。

目前进展:

Andon M. Coleman:最便宜的统一和顶点阵列绑定(bind)、昂贵的 FBO、纹理绑定(bind)

datenwolf:程序使状态缓存无效

1:帧缓冲状态
2:程序
3:纹理绑定(bind)
...
N:顶点数组绑定(bind)，统一绑定(bind)

WebGL 中的当前执行树:

程序

属性指针

质感

混合状态

深度状态

钢网前/后状态

光栅化状态

采样状态

绑定(bind)缓冲区

绘制数组

每个步骤都是一个兄弟哈希树，以避免再次检查主渲染队列中的状态缓存

加载纹理/程序/着色器/缓冲区在渲染之前发生在额外的队列中，以用于 future 的多线程，并确保在对其进行任何操作之前初始化上下文。

自渲染对象的最大问题是您无法控制何时发生某些事情，例如如果开发人员在 gl 初始化之前调用这些方法，他不会知道为什么但他会遇到一些错误或问题......

Answer 1

此类操作的相对成本当然取决于使用模式和您的一般情况。但是你可能会发现 Nvidia's "Beoynd Porting" presentation slides作为有用的指南。让我在这里特别复制第 48 张幻灯片:

Relative Cost of state changes

• In decreasing cost...
• Render Target ~60K/s
• Program ~300K/s
• ROP
• Texture Bindings ~1.5M/s
• Vertex Format
• UBO Bindings
• Uniform Updates ~10M/s

这并不直接匹配您列表中的所有要点。例如。 glEnable/glDisable可能会影响任何事情。 GL 的缓冲区绑定(bind)也不是 GPU 直接看到的。当然，缓冲区绑定(bind)主要是客户端状态，具体取决于目标。混合状态的变化将是一个 ROP 状态变化，依此类推。