multiple apps accessing same resources


we have a need for one app to access the opengl resources of another app. i’ve seen examples for threads. and i’ve seen examples on the same thread. but these will be two different apps: one that loads resources and another app alltogether that will require access to the same resources (no point in wasting memory).

does anyone know if this is allowed?


OpenGL does not (in general) work cross-process. There may be some X-Windows/GLX protocol for communication that might work, but I wouldn’t know about that.

The main problem is that the OpenGL client state (both the OpenGL specified client and the implementation’s client state) lives in the client process. This means it lives in the client process’s address space. And one process can’t access another process’s address space, nor can a process make an OpenGL implementation use global memory for its client state.

thanks, korval.

i’d happily lose the client state of the machine (we could track the important stuff with another mechanism) if we could just get access to the object resources (textures, buffers) on the server. i was under the impression that the memory on the card wasn’t securitized.

i was under the impression that the memory on the card wasn’t securitized.
Not in the sense of virtual memory. But to use the resources, the driver has some data in main memory (e.g. a pointer to the texture data). And the driver won’t let you exchange these between processes, so it effectively is “emulating” memory protection.

i suppose that that would prevent sharing even calling wglShareLists under windows (capturing the HGLRC from one app - since it seems to reduce to a simple int - and sending it to the other app for use). or no?

looks like glx allows for such behaviour upon context creation. has anyone tried this? correct me please, but it looks like wgl and mac (agl or cgl) are both limited to the same address space.

just out of curiosity, in what context would you need to share resources between applications like that? I could understand the need for the system to do that to conserve memory (like cross-process shared surfaces in WPF), but not at the application level.

I’ve been straining to imagine a case for this, and I think I just pulled something :wink:

glxCreateContext / wglShareLists does exactly what you need.

Have a master rendering context (which loads and keeps all your shared resources), and create your own context for all your other apps, which share the master’s resources.

Or have one master app, of which the other apps share the resources of…

Not sure of the performance differences between the two, but it’ll come down to your software design in the end.


(I’m not sure how this’ll work via the network w/ windows, windows has never been great at network transparency)

On Linux you might try GLX_EXT_import_context, which allows multiple processes to share a single indirect context.

On Windows, there´s nothing you can do. As stated earlier, you cannot use wglShareLists() for rendering contexts of different processes.

hmm, I was under the impression you ‘could’ use wglShareLists to share resources inter-process…

In that case you’re going to have to use a single context amoung all the processes, and some kind of IPC (presumably whatever you’re using to send the context you wanted to share to/from the processes) to coordinate which process has access to the context at any given point in time, as a context can only be ‘current’/‘active’ in one thread (and thus one process) at a time. Basically an inter-process semaphore for the graphics context… :slight_smile:

On a side note, this also means you’re going to want to have some kind of load-balancing for when all the other processes are waiting for their turn to use the context…

hmm, I was under the impression you ‘could’ use wglShareLists to share resources inter-process…
Read the wglShareLists manual, it says:
“You can only share display lists with rendering contexts within the same process.”

In that case you’re going to have to use a single context amoung all the processes.
No, you can not send the context around between processes. There are resourcess attached to the context and each process has an own virtual memory area. No way.

You could create a central process using OpenGL and interact with it from other processes via some command mechanism, because that central process is the one which owns the context and is the only one allowed to issue command to it.

wow. thank you all. just got off the plane and there’s some pretty good information. from what i can tell after more research (although nothing proved yet), wgl can’t do this. glx supposedly can. and directx on vista is designed for it - the api returns global handles to the resources.

to answer the use context, much of it is to relieve memory pressure. and some of it is to assist in performance.

so has anyone actually pulled it off under glx? a quick check, before i head off into glx land.