PDA

View Full Version : Sharing Texture amongst different Process



Raghavan
08-25-2009, 04:40 AM
I would like to know if its possible to share Texture across two independant processes.

Here is my situation.
1. Process A(cpp) operates a Image Pixel Data & performs various processings & leaves the image on GPU
2. Process B(say java/cpp) Needs to pick up this Image & Render it on Screen.

Key Performance Crieteria : Reading Image Back to CPU & Passing to Process B needs to be avoided.

My Question:
1. Is there any mechanism currently available to share texture/image pixel data across processes ?
2. If not ? What would be the most optimized method the share the image without affecting the Performance criteria.

Request your support..
Thanks in Advance
Raghavan

P.S Searched for a while & Couldnt find a topic on this context easily, He posting as a new topic.

martinsm
08-25-2009, 06:27 AM
I really doubt that something like that is possible.
Best you can do is read image back to CPU, and communicate with other process with shared memory through memory-mapped files. And then in other process upload image back to gpu.

mfort
08-25-2009, 08:28 AM
Sharing is not possible.

NVIDIA has released new extension GLX_NV_copy_image:
http://developer.download.nvidia.com/opengl/specs/GL_NV_copy_image.txt

It can copy data between two contexts. If the 2 contexts are on the same GPU, then it avoids the CPU memory round trip. But there is no info if the two contexts can be in two processes or not. Try it.

Dark Photon
08-25-2009, 09:18 AM
I would like to know if its possible to share Texture across two independant processes.

Here is my situation.
1. Process A(cpp) operates a Image Pixel Data & performs various processings & leaves the image on GPU
2. Process B(say java/cpp) Needs to pick up this Image & Render it on Screen.


I'm no expert on this (never done it), from the ARB_create_context, I see:

If <share_context> is not NULL, then all shareable data (excluding OpenGL texture objects named 0) will be shared by <share_context>, all other contexts <share_context> already shares with, and the newly created context. An arbitrary number of GLXContexts can share data in this fashion.
Hmmm.

So by sharing state between contexts, you might be able to. Also by using a single context in multiple threads, and making absolutely sure that context is only current in one of those threads at a time (that is, only one thread can talk to OpenGL at once), then you might be able to do this. See Parallel OpenGL FAQ (http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html).

Also, one thing folks do for cases (for performance) is to have only 1 thread talk to OpenGL. Have that main thread map PBOs (buffers for data to load into textures later), pass those PBO pointers to a background thread, and that background thread then fills those PBOs at its leisure. When done, it kicks the foreground thread, which unmaps the PBOs and after suitable delay loads the data into textures. ...but this is for CPU-generation of the texture data, so that doesn't help you.

Bruce Wheaton
08-27-2009, 01:10 PM
In theory, (and I speak only from trying stuff on NVidia), a GLX direct context cannot be shared between processes - it says it in a GLX programmers guide online somewhere.

But sharing between Indirect GLX contexts is possible using an extension - you'll have to look for which one. Indirect contexts can do less, but quite a few things were added recently via extensions, so it may work for you.

On Nvidia, you might also be able to use Cuda - not sure. Maybe OpenCL, once it's out.

Bruce

Edit: Import Context Extension (http://www.opengl.org/registry/specs/EXT/import_context.txt)