与基本逻辑代码相比，OpenGL glDrawElements() 调用有多繁重？

Question

我计划对我的 OpenGL 程序进行一些优化（它不需要优化，但我是为了优化而这样做）。出于好奇，OpenGL 绘图函数与基本逻辑代码相比有多昂贵？目前，我正在开始一个游戏，屏幕上充满了方块，以代表 2D 块状景观。这意味着正方形（两个三角形）的绘制调用被调用多次。目前，我计划添加一些代码来查看当前帧中块的位置，并将它们分组在一起。例如，如果有一列有 7 个块高，我可以调用一个函数来绘制一个 1 x 7 的矩形，而不是执行 7 个单独的 drawBlock() 函数（其中包含 glDrawElements() 调用），等等开，整个屏幕。

如果计算绘制内容的代码实际上比单独绘制块占用更多的 CPU，我就不会费心这样做。

Answer 1

glDrawElements（或任何其他OpenGL 渲染命令）的成本无法真正估计。这是因为它的成本很大程度上取决于您在绘制调用之间更改的 OpenGL 状态。调用 OpenGL 状态更改函数（基本上，任何不是某种形式的 glGet 或某种形式的 glDraw 的 OpenGL 函数）的成本将相对较快。但这会使下一次绘制调用变慢。

这个关于 OpenGL 性能的视频显示了绘制时哪些状态更改比其他状态更改成本更高。真正精彩的部分从 31 分钟左右开始。

如果您在绘制调用之间没有更改任何 OpenGL 状态，则绘制调用相对较快。不同的状态对绘制调用有不同的影响。从最快到最慢（根据上面 NVIDIA 的演示，因此请持保留态度）：

• 非 UBO 制服更新
• 顶点缓冲区绑定（不更改格式）
• UBO绑定
• 顶点格式更改
• 纹理绑定
• 片段后处理状态变化
• 着色器程序更改
• 渲染目标开关

现在，绘制调用将比“基本逻辑”更昂贵。即使它们之间没有状态变化，它们也不便宜。如果效率对您的代码很重要，那么对方块进行分组是一个好主意。