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?

07-19-2002

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.

07-19-2002

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?

07-20-2002

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?

07-20-2002

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.

07-21-2002

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.

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.

07-21-2002

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.

07-22-2002

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.

07-22-2002

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...

07-22-2002

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.

07-23-2002

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.

07-23-2002

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! :)

07-30-2002

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.

07-31-2002

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.