I currently port an OpenGL Application (that only draws 2D stuff) to OpenGL ES to run properly on a Raspberry Pi.

For some reason is eglSwapBuffers taking a huge amount of time. Here is my benchmark I did (and you can see which functions I use):

****** BEGIN BENCHMARK RESULTS
GLESSTATS swap_buffers: 519,180 ms
GLESSTATS createShader: 5,508 ms
GLESSTATS createProgram: 3,584 ms
GLESSTATS setViewport: 0,010 ms
GLESSTATS createTexture: 17,087 ms
GLESSTATS bindTexture: 0,008 ms
GLESSTATS updateTexture: 2,192 ms
GLESSTATS drawGradientRect: 0,288 ms
GLESSTATS drawTexturedRect: 0,206 ms
****** END BENCHMARK RESULTS

Currently I try to create an RGBA surface. These are my attributes for EGL:

EGLint ctx_attrs[] = {
    EGL_RENDERABLE_TYPE, OPEN_GL_ES2_BIT,
    EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
    EGL_RED_SIZE, 8,
    EGL_GREEN_SIZE, 8,
    EGL_BLUE_SIZE, 8,
    EGL_ALPHA_SIZE, 8,
    EGL_NONE
};

EGLint surf_attrs[] = {
    EGL_RENDER_BUFFER, EGL_BACK_BUFFER,
    EGL_NONE
};

Am I doing something wrong here? All I have found out is that a mismatching pixelformat between window and surface might make swap_buffers take a long time. Ive tried it with R5G6B5, with R8G8B8 and R8G8B8A8.

1 Answers

1
robthebloke On

It's important to remember that the GPU and CPU run independently, so calls into the OpenGL driver are usually asynchronous. At some point, the CPU has to sit around and wait for those OpenGL calls to complete.

As Andreas has mention in a comment above, the call to force this CPU/GPU sync is glFinish(), and it just so happens that eglSwapBuffers will actually call glFinish before it starts swapping the buffers.

What this means is that your timing for eglSwapBuffers is most likely to include almost all of the time spent processing updateTexture, drawGradientRect, drawTexturedRect, as well as the time to swap the buffers.

I am also hoping your timing units are wrong? Half a second to render a frame doesn't sound great to me? You sure they aren't ns instead of ms?

Also, I'm hoping you're not compiling a new shader and creating a new texture each frame? (and are doing those only when they actually change?). If you need to create a new texture each frame, make sure you are deleting the GL texture once rendering has completed, otherwise a memory leak may be the cause of a slowdown.