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

时间:2012-12-17 22:34:12

标签: ios performance optimization opengl-es

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

经过很长一段时间,前3个函数(使用OpenGL ES Analyzer仪器的API统计数据)是:

  1. EAGLContext_presentRenderBuffer(654,827,246)
  2. glBufferData(16,128,155)
  3. glDrawElements(11,555,768)
  4. 为什么EAGLContext_presentRenderBuffer如此之高?我的猜测是,因为CPU利用率很低,所以这个时间还包括在等待vsync的CPU停滞所花费的时间。

    这是对的吗?如果没有,还有什么可以解释这个功能的高成本?

1 个答案:

答案 0 :(得分:2)

根据我的经验,其中很大一部分来自iOS设备中使用的基于图块的延迟渲染器的“延迟”部分。在设置场景渲染时,GPU会在需要之前释放大量的绘制调用。

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

不幸的是,这可能会使您难以分析渲染,因为您无法准确评估OpenGL ES场景中哪些阶段最慢。这是我依靠OpenGL ES Driver仪器告诉我是否几何或填​​充率有限,然后在我的管道中放置虚拟元素以尝试本地化瓶颈。

我们还没有真正与OpenGL ES的Time Profiler相提并论,如果你想看到它,我建议你提交一个功能请求。我知道我愿意。