CODEWITHSUNDEEP
iosperformanceoptimizationopengl-es
Oliver Hume
Oliver Hume

Reputation: 479

EAGLContext_presentRenderBuffer taking the majority of time in a OpenGLES stress test

I'm using instruments to capture information on a OpenGL stress test for my engine.

After a long period, the top 3 Functions (using API Statistics from the OpenGL ES Analyzer Instrument) are :

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

Why is EAGLContext_presentRenderBuffer so high? My guess is, because CPU utilization is so low, that this timing also includes the time spent stalling on the CPU waiting for vsync.

Is that correct? If not, what else could explain the high cost of this function?

Upvotes: 1

Views: 507

Answers (1)

Brad Larson
Brad Larson

Reputation: 170319

In my experience, a large part of this comes from the "deferred" part of the tile-based deferred renderers used in iOS devices. When setting up the rendering of your scene, the GPU puts off a lot of the draw calls until just before they are needed.

In many cases, that can mean that the OpenGL ES draw calls appear to be very quick when timed on the CPU, but the last element that reads from or displays the scene seems to take a lot of time. That last call will block until all rendering is completed, because it needs for that to be true in order to display the completed image onscreen.

Unfortunately, this can make it hard to profile your rendering because you can't get an accurate assessment of what stages in your OpenGL ES scene are the slowest. This is where I've relied on the OpenGL ES Driver instrument to tell me whether I'm geometry or fill rate limited and then put dummy elements in my pipeline to try to localize bottlenecks.

We don't really have a good counterpart to Time Profiler for OpenGL ES yet, and I recommend filing a feature request for one if you'd like to see that. I know I would.

Upvotes: 2

Related Questions