SDL OpenGL context and threads

Michael_Menegakis · December 31, 2010, 12:28am

It’s known that OpenGL drivers usually don’t tolerate threading.
However, does one have to deal with the main thread of SDL that
brought up a GL context? If one spawns a thread and from then on only
from there dispatches OpenGL commands will it be safe? Or does it have
to be restricted to the main thread that brought up the SDL GL
context?

Paulo_Pinto · December 31, 2010, 1:19pm

Hi,

the best way is to have just one thread deal with OpenGL commands. You may
have other threads
doing some other type of processing and then send the data ready to be sent
to OpenGL to the
drawing thread that owns the OpenGL context.–
Paulo

On Fri, Dec 31, 2010 at 1:28 AM, Michael Menegakis wrote:

It’s known that OpenGL drivers usually don’t tolerate threading.
However, does one have to deal with the main thread of SDL that
brought up a GL context? If one spawns a thread and from then on only
from there dispatches OpenGL commands will it be safe? Or does it have
to be restricted to the main thread that brought up the SDL GL
context?

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

Martin2 · December 31, 2010, 4:33pm

Hi Michael and everyone else,

two years ago, I tried this using an early SDL 1.3 and Windows Vista, and it
worked. Windows does support this officially, AFAIK.

I asked for official SDL support, but got no response at all. So, this time I
will try to word my - no, our - questions more clearly. They are:

Which platforms allow using OpenGL in a single thread that isn’t the main thread?
Will SDL officially support using this capability where it exists?

Note that this is NOT about “multi-threaded rendering”, where several threads
would use OpenGL in parallel. We just want one single OpenGL thread, but it
shall not be the main thread.

The motivation is that we are already forced (by so many systems) to do time
critical things like input/event handling in the main thread. I think it is
really a bad choice to have input handling and rendering in the same thread.

My ancient post is visible here:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2008-August/065931.html

I don’t remember if I used SDL_GL_MakeCurrent or the Windows API wglMakeCurrent.
The documentation for SDL_GL_MakeCurrent does not specify how to deactivate the
context, so I guess I used wglMakeCurrent(NULL, NULL) directly.

Of course I was careful to only let one thread at a time touch the window and/or
its OpenGL context.

Note also that I did not use the OpenGL renderer built into SDL 1.3. I don’t
know whether it could handle this use case. I called all GL functions directly.

MartinOn 31.12.2010 01:28, Michael Menegakis wrote:

It’s known that OpenGL drivers usually don’t tolerate threading.
However, does one have to deal with the main thread of SDL that
brought up a GL context? If one spawns a thread and from then on only
from there dispatches OpenGL commands will it be safe? Or does it have
to be restricted to the main thread that brought up the SDL GL
context?

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

Forest_Hale · December 31, 2010, 8:17pm

Which platforms allow using OpenGL in a single thread that isn’t the main thread?

I can’t answer this in any sort of official capacity, but from my porting experience on QuakeLive (which does not use SDL, due to the way the plugin API works), I can provide a bit of insight on which
platforms support this and which do not, at the API level (not SDL).

Windows - Full support, events are polled so they are delivered to whichever thread chooses to poll them.

Linux - You have to enable threaded Xlib, but no real problems, events are delivered by polling so they are delivered to whichever thread chooses to poll them.

Mac OS X - No support whatsoever. All API calls must be made from the main thread, this is due primarily to the way the event handling works, using a temporary zone (clustered memory allocator that
is freed after every event is processed), which all API calls utilize (in a non-thread-safe way). Even closing a window will crash if done from another thread (contrary to the documentation).

Again this is merely my observations on the API level, not SDL.

Will SDL officially support using this capability where it exists?

I do not expect SDL support this feature because of the OSX issues, but I do not speak for the SDL team, so this is only my opinion.On 12/31/2010 08:33 AM, Martin wrote:

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Michael_Menegakis · January 1, 2011, 12:06am

I had to start the OpenGL SDL context from the thread of OGL and it
tolerated having SDL_Init on the main thread.

Is it possible to start the context on the main thread without
crashing (not that it has do, for informational purposes).

I heard from OGL generic info that the context has to become “current
for the thread using it”.
Is it possible to make the GL SDL context “current” for another thread?On Fri, Dec 31, 2010 at 3:19 PM, Paulo Pinto wrote:

Hi,

the best way is to have just one thread deal with OpenGL commands. You may
have other threads
doing some other type of processing and then send the data ready to be sent
to OpenGL to the
drawing thread that owns the OpenGL context.

–
Paulo

On Fri, Dec 31, 2010 at 1:28 AM, Michael Menegakis <@Michael_Menegakis> wrote:

It’s known that OpenGL drivers usually don’t tolerate threading.
However, does one have to deal with the main thread of SDL that
brought up a GL context? If one spawns a thread and from then on only
from there dispatches OpenGL commands will it be safe? Or does it have
to be restricted to the main thread that brought up the SDL GL
context?

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

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

Martin2 · January 2, 2011, 9:49pm

Hi Michael,

see
http://wiki.libsdl.org/moin.cgi/SDL_GL_MakeCurrent
and the second Q&A in section 1 of this FAQ:
http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html

You will notice that the documentation of SDL_GL_MakeCurrent doesn’t tell you
how to “make no context current”. What I’ve read in part of the related SDL
source code makes me think that SDL_GL_MakeCurrent(win, NULL) will accomplish this.

Therefore, I think that something like this could work:

– In the main thread:
wnd = SDL_CreateWindow(…);
ctx = SDL_GL_CreateContext(wnd);
SDL_GL_MakeCurrent(wnd, NULL);

– Afterwards(!), in the other thread:
SDL_GL_MakeCurrent(wnd, ctx);

I guess that you should be very careful what to do with wnd in the main thread
while the other thread is working on ctx.

And don’t forget to check the results of all those calls in real code.

Another note:
http://wiki.libsdl.org/moin.cgi/SDL_GL_SwapWindow
I’m not sure if all platforms will be happy to do that in the other thread.

MartinOn 01.01.2011 01:06, Michael Menegakis wrote:

I had to start the OpenGL SDL context from the thread of OGL and it
tolerated having SDL_Init on the main thread.

Is it possible to start the context on the main thread without
crashing (not that it has do, for informational purposes).

I heard from OGL generic info that the context has to become “current
for the thread using it”.
Is it possible to make the GL SDL context “current” for another thread?

Martin2 · January 2, 2011, 10:17pm

Hi Forest,

thanks for the input, though I’m not aiming to move the event handling out of
the main thread. Like you, I too don’t expect SDL support for that.

In the meantime, I googled a bit. While I’m still not sure, my impression is
that the major platforms support OpenGL calls outside the main thread.

MartinOn 31.12.2010 21:17, Forest Hale wrote:

On 12/31/2010 08:33 AM, Martin wrote:

Which platforms allow using OpenGL in a single thread that isn’t the main
thread?

I can’t answer this in any sort of official capacity, but from my porting
experience on QuakeLive (which does not use SDL, due to the way the plugin API
works), I can provide a bit of insight on which platforms support this and which
do not, at the API level (not SDL).

Windows - Full support, events are polled so they are delivered to whichever
thread chooses to poll them.

Linux - You have to enable threaded Xlib, but no real problems, events are
delivered by polling so they are delivered to whichever thread chooses to poll
them.

Mac OS X - No support whatsoever. All API calls must be made from the main
thread, this is due primarily to the way the event handling works, using a
temporary zone (clustered memory allocator that is freed after every event is
processed), which all API calls utilize (in a non-thread-safe way). Even closing
a window will crash if done from another thread (contrary to the documentation).

Again this is merely my observations on the API level, not SDL.

Will SDL officially support using this capability where it exists?

I do not expect SDL support this feature because of the OSX issues, but I do not
speak for the SDL team, so this is only my opinion.