Thread safeness of OpenGL

[Hershlag]

I have written quite a bit of OpenGL code lately and I have noticed something. As it is a state machine and you go through setting global states before you write out entities, can OpenGL be accessed in a thread safe manner?

I would like to figure out a way to make calls in multiple threads and I have run into problems because certain calls can not be made between "begin" and "end". Specifically, I want to be able to create display lists in a different thread than is doing the rendering. Is this an unreasonable idea in OpenGL?

[no-one]

if im not mistaken, it is supposed to be thread safe, but this may be driver/implementation dependant, even so you still must synchronize drawing with the other threads yourself.

>
I want to be able to create display lists in a different thread than is doing the rendering. Is this an unreasonable idea in OpenGL?
<

try to avoid ever making anything you can make at load time during runtime, if you can't avoid runtime display lists then you'll have to synchronize the threads youself to avoid errors if the threads share an RC.

[Hershlag]

well the thing is, this is an internet app. It downloads models as it's running.

But here's the real question. what if you have two windows open, both opengl. Certainly they should both have their own material, lighting, matrix queue, etc... right? I don't see how you can have these things unique to an rc. RC and display lists seem to be the only things that are per-instance.
When you are trying to draw to both at the same time, you'll have overlapping state changes. THIS IS BAD!!!! any ideas?

[no-one]

>
But here's the real question. what if you have two windows open, both opengl.Certainly they should both have their own material, lighting, matrix queue, etc... right? I don't see how you can have these things unique to an rc.
<

they very much should have everything OpenGL specific to the RC, though this may be implementation specific(eg. you probably have to ask the video card vendor)

im pretty sure state changes if anything would be specific to the RC.

>When you are trying to draw to both at the same time, you'll have overlapping state changes. THIS IS BAD!!!! any ideas?

ok lemmie clarify for me exactly what is going on,

are you creating two RCs in the same app or are you starting two instances of the app and having this trouble?

[Hershlag]

it would be two RC's in the same app. Actually, an MDI app. This means that states are shared as far as I can tell. You don't pass an RC into the Material, MultMatrix, Light etc... calls so there doesn't seem to be any way to distinguish between instances aside from switching the current RC. This is something that is procedural and will mean that two threads can't be rendering in their own RC at the same time.

[no-one]

ok this changes things a little,

>
This is something that is procedural and will mean that two threads can't be rendering in their own RC at the same time.
<

as far as i know only one thread can be rendering to a given context per app at one time, so your probably going to have to synchronize the
threads and switch contexts as needed.

look in the MSDN for syncronization functions specifically, InitializeCriticalSection(), TryEnterCriticalSection(), EnterCriticalSection(), LeaveCriticalSection(), ect...

[Hershlag]

yeah, that's kinda what I was fearing. it removes some of the advantage to multithreading. so basically I'm going to have to do some major critical section work in order to use OpenGL.

What about DirectX? is there a similar issue there? Or can I just render to a given directX object whenever I want.

[no-one]

>What about DirectX? is there a similar issue there?

based on how this stuff has to work i would say yes, though Direct-X may have some built in functionality to handle this transparently, i don't really know for sure.

[Hershlag]

The reason I would say there is a difference is that directX has an object per DrawingSurface which means methods on that object instead of global states. So you aren't "Setting Current RC" kind of thing in DirectX, you just make the calls directly to the surface you mean to change.

[no-one]

> So you aren't "Setting Current RC" kind of thing in DirectX, you just make the calls directly to the surface you mean to change.

then the so called "RC changing" or "surfacr changing" is probably done transparently...

[Hershlag]

no, I think they don't have a need to swap context. It's object oriented. The object they are calling has the correct context in it. I believe that since you just call the correct pointer and the two objects don't share variables there would be no thread problem.

[no-one]

>no, I think they don't have a need to swap context. It's object oriented.

doesn't mean anything. it C underneath, the C++ is a wrapper.
yeah, eventually after it goes far enough the money says its gonna. as a developer you'll never see it but its there.

>
The object they are calling has the correct context in it. I believe that since you just call the correct pointer
<

my money says, it just auto switches them at a lower level, so you don't have to worry about the syncronizing yourself.

>and the two objects don't share variables there would be no thread problem.

GL's RC's dont share variables either, the doc's say they are independant. if their not, then its MS's crappy implementation, of OS support for GL, or the cards manufacturer is a moron and thinks he can get away with sharing RC's data, in either case they both need a severe beating.

[Hershlag]

ok, so it's C underneath. at least that's your guess. I wonder if there's actually been any documentation on any of this. I certainly haven't seen it if there is. Not for OpenGL anyway. Is anyone else out there? this isn't a private conversation!

[no-one]

>ok, so it's C underneath. at least that's your guess.

thats the fact, Jack.

> I wonder if there's actually been any documentation on any of this.

yeah, search around theres gotta be some.

[Hershlag]

The reason I question it is that C does not necessarily mean global states. Only sloppy old C coders still do that. You can do instance based C code just fine and this would allow thread safeness. Windows is like this because it uses handles to tell the API what instance you are talking about. Windows GDI calls all pretty much have a DC passed in.

example:
WINGDIAPI BOOL WINAPI BitBlt(HDC, int, int, int, int, HDC, int, int, DWORD);

this is how you know what DC or instance you are talking about.

OpenGL has no RC passed into most functions. It just set's the "current" one globally.

glFlush(); // flush which one?

Since you are calling an object method in DirectX it could be fair to say that you are talking about an instance. All data could be in that instance.