21

This is my current setup: I'm doing OpenGL rendering using SDL (currently on Linux). I initialize SDL (SDL_Init) and create the application window (SDL_CreateWindow) in the main thread and pass it to a second thread. This second thread creates an OpenGL context from it (SDL_GL_CreateContext) and starts a render loop, while the main thread listens for events. I think it's important to note that GL calls are completely confined to this second thread; actually most of my application logic happens there, the main thread is really only responsible for handling events that come in over SDL.

Originally I did this the other way around, but it turns out you can't process events in anything other than the main thread on OSX and probably also Windows, so I switched it around to be compatible those two in the future.

Should I have any concerns that this will not work on OSX/Windows? On Linux, I haven't had any whatsoever. There's lots of information on the internet about context sharing and doing GL calls from multiple threads, but all I want to do is do OpenGL in one thread that is not the main one. I wouldn't like to continue coding my application only to later find out that it won't work anywhere else.

Ancurio
  • 1,698
  • 1
  • 17
  • 32
  • Sounds OK to me. There's another thread about it here... [link](http://stackoverflow.com/questions/6172020/opengl-rendering-in-a-secondary-thread?rq=1) – user1961169 Aug 02 '13 at 07:17
  • @user1961169 Thanks, I already read the thread you linked. That person was having trouble with Linux/X11, which for me specifically works perfectly, it's just OSX/Win32 I was unsure about. However there were some comments in that thread that suggested it should be ok on those platforms too, so thanks for reminding me! – Ancurio Aug 02 '13 at 14:16
  • The only thing you have to assure is that OS stuff calls are in App main thread. If not then it creates often weird behaviour (on booth win and linux) like invalidation of handles,occasional exceptions, graphics artifacts,occasion GUI errors,etc... – Spektre Jan 18 '14 at 10:02
  • Just out of interest, do you REALLY need to multi-thread it or are you just doing it because you can? People quite often over-complicate applications for no reason. – TPS Aug 01 '14 at 15:01
  • @Zammalad Yes. In the secondary thread, I run an interpreted environment, and I'd like to be able to react to user events even when one of the scripts hangs/infinite loops, and present them with a "script has hanged, force quitting" dialog instead of just staying frozen. – Ancurio Aug 05 '14 at 07:29
  • @Ancurio Fair enough, just best to check as often it can be the case people want to multi-thread for the wrong reasons – TPS Aug 05 '14 at 08:23
  • @Ancurio might be worth putting a post on the SDL official forums. Sam the developer often answers specific queries such as this one. – TPS Aug 05 '14 at 08:25
  • @Zammalad I already did before coming to SO: [thread](https://forums.libsdl.org/viewtopic.php?t=9318&sid=2d2472aac5304b8c3fa0b29b8dc87980) Sam or any other core devs never responded, but instead I got some interesting suggestions such as "you can use clang's C block extension to reimplement GLX" =P – Ancurio Sep 11 '14 at 18:44

2 Answers2

3

I have an app which runs on Mac/iOS/Windows that is structured this way (all GL in a rendering thread), but I don't use SDL.

I just took a look at SDL's Cocoa_GL_CreateContext (called by SDL_GL_CreateContext on OS X) and it makes calls that I make from my main thread to set up the context.

So, if you hit any problems, try creating the GL context in the main thread and then pass that off to the rendering thread (instead of creating the GL context in the rendering thread).

Taylor
  • 5,871
  • 2
  • 30
  • 64
0

OpenGL and multithreading are basically enemies : only one thread can 'own the render context' at any given moment - yes, you can switch the GL render context whenever threads switch, but think of the cost, and also consider that, from one OEM driver to the next, it's not well supported and likely to work for some people and not others. The only logical (and sane) alternative, is to keep all your OpenGL calls to one thread (note: there are exceptions, there are things that any thread can call in gl, relating to streaming data, without them needing to own render context). Unfortunately, we can't simply pass the GL context around threads as suggested, we must call (w)glMakeCurrent, which tells GL "this caller thread now owns you", but fails to tell other threads that...

Homer
  • 89
  • 2