c++ - glGetError 和性能

Question

背景

在工作中，我们开发了两种产品，它们都具有 OpenGL 3.x+ 和 GLES 2.0/3.0+ 后端。团队是独立的，但确实有一些重叠，我们最近讨论了 glGetError 的性能。

在这两种产品中，设计都是这样的，即任何 GL 调用都不应生成由 glGetError 记录的错误代码。为了检测此类错误，在调试中我们有一个宏，它在每次 GL 调用后添加一个 glGetError，如果检测到任何错误，它就会断言，因为这意味着存在错误。在我的产品上，这是默认启用的，在另一个产品上，它必须明确启用。

这些已经存在于我工作多年的产品代码库中，我们看到它们会导致性能下降，在许多平台上通常在 25% 左右。我们认为这是为及早发现错误而付出的合理代价。另一个团队声称在某些情况下，添加这些检查会减慢他们以 60FPS 运行的产品的执行速度至 < 1FPS，从而使产品无法使用，这就是默认情况下未启用它们的原因。这两款产品都可以在许多 OpenGL/GLES 平台(PC、OSX、Linux、iOS 和 Android)上运行。

问题

我理解 glGetError 降低性能的原因；您(可能)需要 CPU/GPU 同步以使先前操作的状态正确。根据我的理解，这应该将预期的帧时间从“MAX(CPU time, GPU time)”(假设没有其他同步点，也没有排队的帧)更改为“CPU time + GPU time + 同步堆”(假设每个 glGetError 调用都会产生一个同步点)。这是不正确的推理，还是存在使用 glGetError 降低性能的其他原因？

我一直认为在调试中每次调用 glGetError 是一件合理的事情(至少在 GL 调用之后应该不会出现错误)。不是这种情况还是不被认为是“最佳实践”？是否有某些情况会导致极端的性能问题，例如其他团队所描述的(例如，使用一组特定的 GL 调用和/或平台)？

Answer 1

glGetError() 实际上不必等待来自 GPU 的任何内容。它报告的所有错误都来自检查 API 调用的参数，以及驱动程序管理的内部状态。所以 CPU/GPU 同步在这里没有发挥作用。

唯一可能出现延迟的错误是 GL_OUT_OF_MEMORY，但规范对此相当开放(“可能会生成”)，因此它也不是同步的真正原因。

我能想到在每次 API 调用后调用 glGetError() 可能会显着降低性能的两个原因:

• 您进行了两倍的 OpenGL 调用。调用本身以及检查和返回错误状态都有开销。虽然调用一次 glGetError() 可能不会很昂贵，但如果您调用它数百万次，成本就会加起来。
• 一些驱动程序在驱动程序内部使用多线程。在这种情况下，glGetError() 将导致驱动程序中线程之间的同步，如果这种情况频繁发生，可能会对性能产生非常大的影响。

至于你应该做什么，你真的必须找出什么是有效的。一些想法/建议:

• 我绝对不会在发布版本中调用 glGetError()。它在调试期间非常有用，但在完成测试/QA 后会产生不必要的开销。

• 错误很棘手。所以如果你只是想知道是否有任何错误，你不必在每次调用后调用 glGetError()。例如，您可以在每帧结束时只调用一次。当然，如果你得到一个错误，并且想知道是哪个调用引起的，你需要更频繁的调用。因此，您可以拥有多种构建类型。

  • 发布没有 glGetError() 调用的版本。
  • 在每帧结束时调用 glGetError() 进行测试/QA 构建。
  • 在每次 OpenGL 调用后使用 glGetError() 调用调试构建。