[SDL] Multi-threaded OpenGL+SDL
Stephane Marchesin
stephane.marchesin at wanadoo.fr
Sat Jan 6 11:29:49 PST 2007
Andrew Zabolotny wrote:
> Hello!
>
> I'm trying to do a simple heightmap viewer that transparently loads
> chunks of potentially visible heightmaps in background (in another
> thread). Since my application uses framebuffer objects for vertex and
> index buffers, I thought it would be logical to convert the heightmap
> info those buffers right after loading them in the second thread.
> However, my first experience finished with the application crashing as
> soon as I call any GL function in the second thread.
>
>
Yes, not all OpenGL implementations are thread-safe. Actually, I know of
no implementation, be it on windows or linux, that is fully thread safe
(by thread safe, I mean doing OpenGL from multiple threads works and
doesn't cause weird bugs). Nvidia for linux comes close to it, though.
> Upon closer examination it turned out that I have to make some GL
> context active in the second thread, since the context is a
> thread-specific variable. I have two choices here: I can make current
> the same context I use in main thread, and further use a mutex to avoid
> GL reenterancy on the same context, and create a shared GL context and
> use it without restrictions, still sharing same FBOs.
>
> However, I found that GL context is burried so deep inside SDL that I
> have no access to it. I still was able to do what I need by using
> GetCurrentContext() in the main thread, then making a shared context
> off it. But that's quite a hack since it's a) OpenGL specific, b)
> Platform-specific (I use GLX functions here).
>
> In the light of dual-core (and in perspective - quad-core) CPUs
> invading the market, threading becomes a imperative for new
> applications so that they get the most off the new CPUs. I think SDL
> needs some generic solution here.
>
Well, SDL doesn't need a solution. Non thread-safe OpenGL
implementations do.
> The sequence when starting a new thread should be this:
>
> * Unbind current GL context in the original thread.
> * Create a new thread
> * The new thread should create a new shared context using the original
> thread's context.
> * Make the new context current in the new thread.
> * Signal somehow the original thread that it can make its context
> current again.
>
> I think there should be some special function for starting a new thread
> with a GL context in it (SDL_CreateThreadGL ?).
>
> And while I'm at it, I would like to propose one more feature to SDL...
> I know it's not too nice but it would be great if it would be possible
> somehow to know SDL window's handle. I have found no way to find this,
> but if this is possible, the following does not matter.
>
You can do that with SDL_GetWMInfo .
Stephane
More information about the SDL
mailing list