c++ - 与基本逻辑代码相比，OpenGL glDrawElements() 调用有多费力？

Question

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

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

Answer 1

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

This video on OpenGL performance显示在绘制时哪些状态更改比其他状态更改成本更高。真正精彩的部分从 31 分钟左右开始。

如果您在绘制调用之间没有更改任何 OpenGL 状态，则绘制调用相对较快。不同的状态片段对绘制调用有不同的影响。从最快到最慢(根据 NVIDIA 上面的介绍，所以要有所保留):

• 非 UBO 统一更新
• Vertex buffer bindings (不改变格式)
• UBO binding
• Vertex format变化
• 纹理绑定(bind)
• 片段 post-processing状态变化
• 着色器程序更改
• Render target开关

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