ios - EAGLContext_presentRenderBuffer 在 OpenGLES 压力测试中占用了大部分时间

Question

我正在使用仪器为我的引擎捕获有关 OpenGL 压力测试的信息。

经过很长一段时间后，前 3 个函数(使用来自 OpenGL ES Analyzer Instrument 的 API 统计信息)是:

1. EAGLContext_presentRenderBuffer (654,827,246)
2. glBufferData (16,128,155)
3. glDrawElements (11,555,768)

为什么EAGLContext_presentRenderBuffer这么高？我的猜测是，由于 CPU 利用率非常低，所以这个计时还包括 CPU 停顿等待 vsync 所花费的时间。

这样对吗？如果不是，还有什么可以解释此功能的高成本？

Answer 1

根据我的经验，其中很大一部分来自 iOS 设备中使用的基于图 block 的延迟渲染器的“延迟”部分。设置场景渲染时，GPU 会推迟大量绘制调用，直到需要它们之前。

在许多情况下，这可能意味着 OpenGL ES 绘制调用在 CPU 上计时时看起来非常快，但从场景中读取或显示场景的最后一个元素似乎要花费很多时间。最后一次调用将阻塞，直到所有渲染完成，因为它需要为真才能在屏幕上显示完成的图像。

不幸的是，这会导致难以分析您的渲染，因为您无法准确评估 OpenGL ES 场景中哪些阶段最慢。在这里，我依靠 OpenGL ES 驱动程序工具来告诉我我是否受几何或填充率限制，然后将虚拟元素放入我的管道中以尝试定位瓶颈。

我们还没有真正的 Time Profiler for OpenGL ES 的良好对应物，如果您希望看到它，我建议您提交一个功能请求。我知道我会的。