我计划对我的 OpenGL 程序进行一些优化(它不需要优化，但我是为了优化而这样做)。出于好奇，OpenGL 绘图函数与基本逻辑代码相比有多昂贵？目前，我正在开始一个游戏，屏幕上充满了方 block ，以代表 2D block 状景观。这意味着正方形(两个三角形)的绘制调用被调用多次。目前，我计划添加一些代码来查看当前帧中 block 的位置，并将它们分组在一起。例如，如果有一列有 7 个 block 高，我可以调用一个函数来绘制一个 1 x 7 的矩形，而不是执行 7 个单独的 drawBlock() 函数(其中包含 glDrawElements() 调用)，等等打开，整个屏幕。
如果计算绘制内容的代码实际上比单独绘制 block 占用更多的 CPU，我就不会费心这样做。
最佳答案
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 进行分组是个好主意。
关于c++ - 与基本逻辑代码相比，OpenGL glDrawElements() 调用有多繁重？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34486197/