EGL / GLES2 multithreading question (eglSwapBuffer

This topic contains 1 reply, has 2 voices, and was last updated by  Joe Davis 6 years, 3 months ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #30559

    Hi. I am a little confused about proper multithreaded usage of EGL and OpenGL ES.
    After I explain what I’m currently doing, I hope someone can point me in the right direction.

    Using the PowerVR’s GLES2 emulation for windows,
    the main thread initializes EGL and and creates two GLES2 contexts.
    EGLint ai32ContextAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };
    m_glContextApp    = eglCreateContext(m_eglDisplay, m_eglDisplayConfig, EGL_NO_CONTEXT,        ai32ContextAttribs);
    m_glContextRender = eglCreateContext(m_eglDisplay, m_eglDisplayConfig, m_eglRenderAPIContext, ai32ContextAttribs);

    I then immediately bind the application context to the main app thread.
    eglMakeCurrent(m_eglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, m_glContextApp);

    Later in my initialization, I spawn a render thread and from that thread I call:
    eglMakeCurrent(m_eglDisplay, m_eglWindowSurface, m_eglWindowSurface, m_glContextRender);

    In my render thread, I clear the color buffer and call eglSwapBuffers.
    However, calling eglSwapBuffers from the render thread causes the application to hang inside the function and never return.

    If I call eglSwapBuffers from the main thread (which initialized EGL), the app doesn’t hang and I can see the expected rending results (ignoring the fact that the threads are aren’t synced the the screen flickers).

    Any thoughts on how to properly call eglSwapBuffers() from the render thread, etc. would be appreciated.

    WhatsInAName2011-06-22 04:32:31

    #34961

    Joe Davis
    Member

    Threads not being support in VFrame is a known bug (see the related FAQ item).

    Is there any reason you need to use more than one rendering thread? Would it be possible to do all EGL initialization in your m_glContextRender thread?

    For performance reasons, we suggest using a single context per application (where possible) as there is a cost associated with context switching (and it allows you to get around the VFrame bug until we fix it 😉 )

    Cheers,

    Joe

Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic.