Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Sharing context between processes

  1. #11
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,124

    Re: Sharing context between processes

    For those finding this thread later, let me follow up and re-state that my previous post was based on what I've read. I haven't actually done this (shared a single context between multiple threads) myself, as I haven't needed this ... yet. Various sources (e.g. random googles here, here)) assert you can use the same context from different threads with locking, but I of course defer to those that have sifted the spec on this issue. Apparently, this behavior is not guaranteed to work, and so while we might be able to do this, if the assertions are true, we should avoid it.

    However, you piqued my curiosity Bruce, so I went looking through the GLX spec. Didn't find what you mentioned. Got a pointer? Though (related) I did find:

    Quote Originally Posted by GLX 1.4 Spec
    Each thread can have at most one current rendering context. In addition, a rendering context can be current for only one thread at a time.
    This in-and-of-itself doesn't preclude multiple threads accessing GL through the same context, so long as they don't ever both have it active simultaneously. It also seems curious wording if you should only make the thread current in the thread that created it... Why would this even be allowed?

    Elsewhere in the spec we find:

    void glXDestroyContext( Display *dpy, GLXContext ctx );

    If ctx is still current to any thread, ctx is not destroyed until it is no longer used.
    Again, this seems odd wording if GLX contexts cannot be shared between threads. I mean if that really is the case, then why wouldn't glXCreateContext bookmark the thread ID in the client state and reject all attempts to make it current in or destroy it from any other thread?

    Things that make you say "hmmmmm....."

  2. #12
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    661

    Re: Sharing context between processes

    It simply means: you can pass a context around between threads of a process. All threads may access the context, but only one of them at any time.

    To pass a context C, current to thread A, to thread B,
    first call wglMakeCurrent(0,0) in thread A, then you may call wglMakeCurrent(hdc, C) in thread B.

    It is not true, that only the thread, that created the context, may use it.

    You can have multiple contexts, each made current to a separate thread. You can concurrently issue OpenGL commands in each of these threads (there are some peculiarities with shared objects to be obeyed, though)

  3. #13
    Advanced Member Frequent Contributor yooyo's Avatar
    Join Date
    Apr 2003
    Location
    Belgrade, Serbia
    Posts
    872

    Re: Sharing context between processes

    skynet is right... Long time ago I played with composite UI design, trying to simulate multiple applications running on different framerate composed in 3d evnironment. UI must not suffer from low framerate of some application. So.. to make that test I create multiple GL contexts and threads and pass one of contexts to one of threads (one thread is one application). All contexts share their objects. First context belong to composition thread. All other contexts & threads render their stuff in offscreen texures. Composition thread & context collect textures and compose on screen.

    You can create multiple contexts in one thread, but do not make them current in that thread. Better pass context to some other thread and then make them current from host thread. Also.. context sharing must be done in same thread. Both context must not be current.

  4. #14
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,124

    Re: Sharing context between processes

    Good stuff. Thanks, guys!

  5. #15
    Intern Contributor
    Join Date
    May 2008
    Location
    USA
    Posts
    99

    Re: Sharing context between processes

    GLX contexts can definitely be shared between threads, assuming you don't use them on more than one, although I wouldn't recommend it - X is very fussy about the X Display Connection you used to create the context, and the connection you use to work with the context, and then also about using Display Connections across threads. I would/do share the contexts to see the same objects, but use each one very specifically in a single thread.

    I was answering your 'processes' question - you were calling it threads/processes, and in this context, they're very much different things.

    I recall that I had to piece it together. From the GLX 1.3 Programmer's guide:

    Direct Rendering and Address Spaces
    One of the basic assumptions of the X protocol is that if a client can name
    an object then it can manipulate that object. GLX introduces the notion
    of an Address Space. A GLX object cannot be used outside of the address
    space in which it exists.
    In a classic UNIX environment, each process is in its own address space.
    In a multi-threaded environment, each of the threads will share a virtual
    address space which references a common data region.

    Meanwhile, 'skynet' found the extension I referred to: GLX_EXT_import_context
    That lets you share between indirect contexts. I did mess with that, but for my use they were notably crappier. I believe, on NV cards at least, they're more capable now.

    Bruce

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •