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 设备中使用的基于 tile 的延迟渲染器的“延迟”部分。在设置场景渲染时，GPU 会推迟很多绘制调用，直到需要它们之前。

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

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

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