Sharing context between processes

[RickA]

I'm attempting to share a single OpenGL 3.x context across multiple processes. I use the new wglCreateContextARB function and pass in the existing context. It then returns a handle which has the same value as the handle in the other process. No errors are given, yet it doesn't work.

After some searching, I get the impression this isn't supposed to work, but shouldn't I get some kind of error then?

[Dark Photon]

I'm attempting to share a single OpenGL 3.x context across multiple processes...it doesn't work.

Google "parallel opengl FAQ":

http://www.equalizergraphics.com/doc...OpenGLFAQ.html

1. Using one Context from Multiple Threads

* Q: Why does my OpenGL application crash/not work when I am rendering from another thread?
* A: The OpenGL context is thread-specific. You have to make it current in the thread using glXMakeCurrent, wglMakeCurrent or aglSetCurrentContext, depending on your operating system.

* Q: Why does it not work if I make my context current in another thread?
* A: One OpenGL context can only be current in one thread. You have to release the context in the the other thread first, by making another or no context current.

* Q: So how can I then make use of multiple processors with OpenGL?
* A: See Section 2.

You might describe what you're trying to do in that other thread for better advice. If you need to be interacting with GL in both threads at the same time, you need multiple contexts. And what you want to do may or not be possible using ARB_sync or other mechanisms.

The usual advice is to try to keep all your GL interaction in one thread and offload CPU-heavy tasks to a background thread.

[RickA]

Thanks for your reply. I'm doing a little bit of research into creating a debugging aid for OpenGL. As such, the second thread/process is actually an entirely different program. The debugged program will have the original context, and for debugging I'd like to access all the resources this program created from inside my second program, hence the reason for sharing the contexts.

The problem might be the MakeCurrent calls, which likely don't match up at the moment. I'll give that a try later on and see if it helps.

[skynet]

I'm certain, that it is not allowed to share contexts across process boundaries.

[Dark Photon]

I'm certain, that it is not allowed to share contexts across process boundaries.

And just to be clear for those skimming this thread, we are only talking about MS Windows here.

In Linux, separate processes can share virtual address space, and in-fact this is how threads are implemented. And in fact, you can share GL contexts between processes/threads in Linux from what I read, but you still can only have one process/thread talking to GL through that context at a time.

[Bruce Wheaton]

That's not the case on Linux. You can only share indirect contexts between processes using a special NV extension. The GLX docs (at least the last I read, maybe 1.4?) are quite explicit about that.

Bruce

[Vadim]

First of all even if you could somehomw take control of open gl from another process that would be quite a major undertaking with little benefits if any.
I doubt that opengl conext is thread safe. To make it thread safe one would have to employ means of threds/processes synchronization which would slow things down dramatically. The only plausible scenario of using the same context in a separate process as I see it is offering the opengl context to another process for exlusive use so that the process that actually owns the contex does not have to access to it ( similarly how Google Chrome browser offers tab windows to the HTML engine running in another process.

Even though you probably cannot do it the way you described it in the original post is probably impossible it still can be done. Instead of using the context directly in another process you can write a proxy that woudl receive commands from another process and pass them to the current context.
Of course you would need some kind of interprocess communication such as dbus, shared memory, out of procees COM server etc. You got the idea.

[RickA]

I'm certain, that it is not allowed to share contexts across process boundaries.

Have you tested this yourself, or did you read it somewhere?

First of all even if you could somehomw take control of open gl from another process that would be quite a major undertaking with little benefits if any.
I doubt that opengl conext is thread safe. To make it thread safe one would have to employ means of threds/processes synchronization which would slow things down dramatically. The only plausible scenario of using the same context in a separate process as I see it is offering the opengl context to another process for exlusive use so that the process that actually owns the contex does not have to access to it ( similarly how Google Chrome browser offers tab windows to the HTML engine running in another process.

Even though you probably cannot do it the way you described it in the original post is probably impossible it still can be done. Instead of using the context directly in another process you can write a proxy that woudl receive commands from another process and pass them to the current context.
Of course you would need some kind of interprocess communication such as dbus, shared memory, out of procees COM server etc. You got the idea.

I need the interprocess communication in any case, and I've already tested that. Your suggestion was indeed my other option, but I'd like to have as little code as needed in the debugged process. But if I have to then that should certainly work.
As to your comment about speed, speed isn't really relevant when I'm debugging a single frame, so I'm not worried about it. If I have to add loads of sync points, I'm ok with that. Thanks for thinking with me though, it's appreciated.

[yooyo]

There is no way to access to GL context from different process.
If you want to use GL context in separate process you need to write additional layer (proxy), wrap all calls and pass them to GL context. But you have to be sure that there is no any other app messing around with same context.

Also you can try to hijack application by injection your DLL in application memory space and hook on wglSwapBuffers. After that you can install proxy. Proxy spawn thread and start communication with another app (your debugger). Proxy needs to hook every OpenGL API command in order to track GL state changes.

Good resources for this is TAKSI project on sourceforge (how to inject dll) and glIntercept (how to hook on GL).