Jump to content
  • Advertisement
Sign in to follow this  
venkatdoss

GL Synchronization between process

This topic is 809 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Dear Folks,

 

        I am new  to glFence and glWaitsync commands.I looking for help in GL calls synchronization in multiprocess application.

 

I understood to use glFence and glWaitSync commands in multithread application.But my query is how we can 

 

make use of these sychronization commands in mutiprocess application.Say, how process B will sync with object 

 

created in Process A.

 

Thanks in Advance

Share this post


Link to post
Share on other sites
Advertisement

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.

Edited by Matias Goldberg

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

Edited by Matias Goldberg

Share this post


Link to post
Share on other sites

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.

Edited by Osbios

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

+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.

Share this post


Link to post
Share on other sites

 

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.

Edited by Osbios

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!