GL Synchronization between process

I'm afraid you're mistaken / got the wrong information.

glFence and glWaitSync are used to synchronize between a single process, single threaded with the GPU. It's not used to sync between multiple threads or processes. This functionality mostly to determine if the GPU commands issued before the fence have finished. apitest shows how to do it.

Thanks for reply.

If that is the case then how we can ensure that GPU commands issues from different process have finished or not.

Is any other solution.I need to trace all the GL calls in sequence,my application can be mutithreaded or multiprocess application.

Actually that is exactly what sync objects are good for, too!

If you do anything with OpenGL objects (except sync objects them self) you ALWAYS have to use sync objects before another thread can uses them.

In case of a simple thread, e.g. only loading some data into a texture, a simple glFinish will also do the job. And after that you can send a signal to the other thread that the objects are ready to be used.

What Osbio means is that you have to use fence/ClientSync (as shown in apitest) in the thread that issue those operations, and when this thread is notified the GPU has finished, this thread informs whatever other thread/processes are waiting for it via conventional means (synchronization primitives provided by the OS like mutexes, semaphores, barriers, conditional variables, shared memory, pipes, sockets, etc).

Nope. I only mentioned the thread signaling in combination with the glFinish.

You can create a sync object, then "give" this sync object directly to another thread and this other thread with his own OpenGL Context can then wait/test for the sync object status.

EDIT: Just to include all details. You must create share OpenGL contexts to interchange anything between them. But most helper libraries, like for example SDL2, do this by default.

Nope. I only mentioned the thread signaling in combination with the glFinish.

You can create a sync object, then "give" this sync object directly to another thread and this other thread with his own OpenGL Context can then wait/test for the sync object status.

EDIT: Just to include all details. You must create share OpenGL contexts to interchange anything between them. But most helper libraries, like for example SDL2, do this by default.

That is irrelevant though because the OP specified in #3 that they need the information between different processes, not just threads in the same process.

+1 to what BitMaster said

Nope. I only mentioned the thread signaling in combination with the glFinish.

You can create a sync object, then "give" this sync object directly to another thread and this other thread with his own OpenGL Context can then wait/test for the sync object status.

EDIT: Just to include all details. You must create share OpenGL contexts to interchange anything between them. But most helper libraries, like for example SDL2, do this by default.

I strongly advise not to use context sharing. There are very strong limitations on what can be shared, which is platform-dependent and not very well defined, and often drivers are too buggy for serious usage when it comes to context sharing.

Nope. I only mentioned the thread signaling in combination with the glFinish.

You can create a sync object, then "give" this sync object directly to another thread and this other thread with his own OpenGL Context can then wait/test for the sync object status.

EDIT: Just to include all details. You must create share OpenGL contexts to interchange anything between them. But most helper libraries, like for example SDL2, do this by default.

That is irrelevant though because the OP specified in #3 that they need the information between different processes, not just threads in the same process.

Well I stand corrected.

In that case what Matias Goldberg mentioned before. Waiting for the sync object in the original process and then after the signal tell the other process about it via some form of inter process communication.

As far as I can tell even just sharing OpenGL data over processes always depends on some kind of system extensions and there is no standard way. So except for maybe some esoteric extension there won't by and inter-process signaling.

I strongly advise not to use context sharing. There are very strong limitations on what can be shared, which is platform-dependent and not very well defined, and often drivers are too buggy for serious usage when it comes to context sharing.

I only use it on PC for simple worker threads that load textures or shader strings and it works fine. But considering how many issues id tech hat with there OpenGL games esp. on AMD drivers... And I don't even want to know how colorful all the driver implementations are on mobile platforms. So on mobile that is probably right.