SDL_GL_SwapWindow slow

SDL_GL_SwapWindow takes about 18% of my total CPU usage (iOS 6.1 on iPad, OpenGL ES 2.0) according to instruments. Is this normal? It seems rather a lot. In addition, the OpenGL ES analysis reports that the glDiscardFramebufferEXT should be used. I tried doing that after swap window but it doesn’t seem to have any effect at all… Why doesnt this work?

Also (sorry for asking multiple questions in one thread) - is APPLE_framebuffer_multisample somewhat integrated? I’m a bit confused about the workings with buffers, since SDL made this so easy I don’t know all the details.

2013/11/18 cboe <christoph.boehler at antiloop.com>

SDL_GL_SwapWindow takes about 18% of my total CPU usage (iOS 6.1 on
iPad, OpenGL ES 2.0) according to instruments. Is this normal? It seems
rather a lot. In addition, the OpenGL ES analysis reports that the
glDiscardFramebufferEXT should be used. I tried doing that after swap
window but it doesn’t seem to have any effect at all… Why doesnt this
work?

Also (sorry for asking multiple questions in one thread) - is
APPLE_framebuffer_multisample somewhat integrated? I’m a bit confused about
the workings with buffers, since SDL made this so easy I don’t know all the
details.

I bet it’s probably related to vsync being enabled. I’ve seen this reported
on Android quite a few times, and it looks like the exact same situation, a
mystery delay in SDL_GL_SwapWindow which happens while the OpenGL machinery
"waits" for the vertical retrace (whatever that means in a device with an
integrated LCD display).–
Gabriel.

2013/11/19, Gabriel Jacobo :

“waits” for the vertical retrace (whatever that means in a device with an
integrated LCD display).

Just because they aren’t rastering beams doesn’t mean they don’t have
to cope with vsync :stuck_out_tongue: (they can’t update the entire screen at once,
there’s latency regarding how fast pixels can update, and sending the
new data takes time as well in the first place).

We really need a FAQ for this that we can point someone to the next time someone asks this exact same question again…

2013/11/18 cboe <christoph.boehler at antiloop.com>

SDL_GL_SwapWindow takes about 18% of my total CPU usage (iOS 6.1 on iPad, OpenGL ES 2.0) according to instruments. Is this normal? It seems rather a lot. In addition, the OpenGL ES analysis reports that the glDiscardFramebufferEXT should be used. I tried doing that after swap window but it doesn’t seem to have any effect at all… Why doesnt this work?

Also (sorry for asking multiple questions in one thread) - is APPLE_framebuffer_multisample somewhat integrated? I’m a bit confused about the workings with buffers, since SDL made this so easy I don’t know all the details.

I bet it’s probably related to vsync being enabled. I’ve seen this reported on Android quite a few times, and it looks like the exact same situation, a mystery delay in SDL_GL_SwapWindow which happens while the OpenGL machinery “waits” for the vertical retrace (whatever that means in a device with an integrated LCD display).
?–
Gabriel.On Tuesday, November 19, 2013 3:02 AM, Gabriel Jacobo wrote:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I bet it’s probably related to vsync being enabled. I’ve seen this
reported on Android quite a few times, and it looks like the exact same
situation, a mystery delay in SDL_GL_SwapWindow which happens while the
OpenGL machinery “waits” for the vertical retrace (whatever that means
in a device with an integrated LCD display).

A good way to determine this on iOS is to see if Instruments thinks the
game is running at exactly 60fps.

In which case, even if vsync isn’t the culprit, who cares if you are
losing 18% of the CPU there? :slight_smile:

As for buffer discard: it’s not making a difference because making your
rendering faster just means more time waiting for vsync, which is a good
problem to have. But if it were to make a difference, you can discard to
avoid an extra copy operation inside the GL.

Calling glClear() on your color and depth buffers right after swapping
achieves the same effect, at least on Apple platforms: the GL realizes
you don’t need the last frame’s data so it doesn’t copy it around after
displaying it…but if you were just going to redraw the entire frame
anyhow, discarding is slightly faster than glClear(), since it doesn’t
explicitly reinitialize the buffer.

This is my interpretation of the docs: I haven’t benchmarked this at all.

–ryan.

Yes, I am having 60 frames so it isn’t really a problem. I just occasionally run CPU profiling and it just stuck out a bit, but I guess the V-Sync argument makes sense. I didn’t bother about v-sync at all on iOS but I guess it automatically happens using SDL_iPhoneSetAnimationCallback?

@ryan About the buffer discard: That’s how I interpreted things too, however, even after calling it right after SwapWindow, the opengl es profiler still screams at me for NOT doing it, which seems weird. Am I using it wrong?