Thread safeness of OpenGL

This is a discussion on Thread safeness of OpenGL within the Game Programming forums, part of the General Programming Boards category; I have written quite a bit of OpenGL code lately and I have noticed something. As it is a state ...

  1. #1
    Registered User
    Join Date
    Jul 2002
    Posts
    273

    Thread safeness of OpenGL

    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?

  2. #2
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,267
    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.
    Last edited by no-one; 07-19-2002 at 05:43 PM.
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  3. #3
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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?

  4. #4
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,267
    >
    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?
    Last edited by no-one; 07-20-2002 at 01:39 PM.
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  5. #5
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  6. #6
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,267
    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...
    Last edited by no-one; 07-20-2002 at 11:30 PM.
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  7. #7
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  8. #8
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,267
    >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.
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  9. #9
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  10. #10
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,267
    > 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...
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  11. #11
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  12. #12
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,267
    >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.
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  13. #13
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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!

  14. #14
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,267
    >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.
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  15. #15
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.
    always looking, make an offer. get me out of this place.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Terminating secondary thread from another thread
    By wssoh85 in forum C++ Programming
    Replies: 13
    Last Post: 12-19-2008, 04:14 AM
  2. Thread Prog in C language (seg fault)
    By kumars in forum C Programming
    Replies: 22
    Last Post: 10-09-2008, 01:17 PM
  3. Multithread pthread with OpenGL
    By parad0x13 in forum C++ Programming
    Replies: 8
    Last Post: 07-24-2008, 03:04 PM
  4. multithreading question
    By ichijoji in forum C++ Programming
    Replies: 7
    Last Post: 04-12-2005, 10:59 PM
  5. Replies: 12
    Last Post: 05-17-2003, 05:58 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21