Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: glFlush or glFinish with mulithreading?

  1. #11
    Junior Member Regular Contributor pjcozzi's Avatar
    Join Date
    Jun 2004
    Location
    Philadelphia, PA
    Posts
    196

    Re: glFlush or glFinish with mulithreading?

    I see. Good call.

    Patrick

  2. #12
    Junior Member Regular Contributor pjcozzi's Avatar
    Join Date
    Jun 2004
    Location
    Philadelphia, PA
    Posts
    196

    Re: glFlush or glFinish with mulithreading?

    I'd also like to ask your opinions on best practices for sync objects. Specifically, if you have worker thread(s) creating and uploading GL resource, lets assume textures, that will be rendered by the main thread, where should the wait on the fence happen? I can imagine a few possibilities:

    a) A single worker thread uploads a texture then creates a fence. Both of these are put on a queue for the main thread. The worker thread can then continue uploading textures and creating fences. The main thread uses a server wait, glWaitSync, before using the corresponding texture.

    b) Several worker threads each upload a texture, create a fence, and immediately issue a client side wait, glClientWaitSync. The texture is not added to the queue for the main thread until the fence is signaled. It is safe for the main thread to use a texture once it is on the queue.

    c) A single worker thread uploads a texture then creates a fence. A client side wait with a timeout of zero is used to poll the fence. A texture is not added to the queue until its fence is signled. Meanwhile, the worker thread can upload additional textures.

    My thoughts are:

    a) May be ok because by the time the main thread issues glWaitSync, the fence may already be signaled. If this is not the case, the wait would stall the GPU but not the CPU.

    b) Is a bit harder to manage but could perform well if glClientWaitSync is not implemented with busy waiting and only blocks the GL client for the thread's context. Does anyone know if this is the case or will other contexts also be blocked? Likewise, does glWaitSync block just the current context or all contexts?

    c) I hate to poll the fence but the implementation is a bit simpler than (b) and doesn't have the potential of stalling the GL server like (a).

    What are your thoughts? Are there other worthwhile approaches I have not considered?

    Thanks,
    Patrick

  3. #13
    Intern Contributor
    Join Date
    May 2008
    Location
    USA
    Posts
    99

    Re: glFlush or glFinish with mulithreading?

    Huh. Further to my replay a few back, I found that in my multi-threaded texture transfer system, I wasn't actually calling glFlush, to my surprise.

    Which is very nice and mellow from a threading perspective, but probably slows things down quite a bit.

    I'm trying that now. But it looks like you can skip it, with the caveat that you're reliant on other commands and/or flushes to get things started.

    Bruce

  4. #14
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: glFlush or glFinish with mulithreading?

    Quote Originally Posted by pjcozzi
    c) I hate to poll the fence but the implementation is a bit simpler than (b) and doesn't have the potential of stalling the GL server like (a).
    Polling does not work well for me. See this thread:

    http://www.opengl.org/discussion_boa...;Number=277431

  5. #15
    Intern Contributor
    Join Date
    Mar 2010
    Posts
    59

    Re: glFlush or glFinish with mulithreading?

    You do need a glFlush() sometime after the glFencSync() call otherwise anyone that waits in this sync object may wait forever. It doesn't need to be immediatly after the glFenceSync() call, but just at some point so that it doesn't unnecessarily stall the other thread. This applies to both glSyncWait() and glClientSyncWait().

    The advantage of using glSyncWait() vs glClientSyncWait() is that glSyncWait() doesn't stall your application. It can continue to queue commands to the GPU, while the GPU itself waits on the other thread. When it's released the GPU immediatly has stuff to continue working on without having to wait for the application to feed it more stuff.

  6. #16
    Junior Member Regular Contributor pjcozzi's Avatar
    Join Date
    Jun 2004
    Location
    Philadelphia, PA
    Posts
    196

    Re: glFlush or glFinish with mulithreading?

    Quote Originally Posted by mfort
    Polling does not work well for me. See this thread:

    http://www.opengl.org/discussion_boa...;Number=277431
    To be more clear, I would not use GetSynciv in a different thread to poll. The worker thread would create/upload the texture, call FenceSync, and put this pair on a local queue. The worker thread would check the return of ClientWaitSync with a timeout of zero. If the fence is signaled, the texture is moved from the local queue to a shared queue for use by the main thread, otherwise the worker thread goes on with its work and checks the fence later.

    You had performance problems calling GetSynciv in a different context than FenceSync, correct?

    One question I have is if ClientWaitSync (and WaitSync) will block more than the current thread/context. The spec says it "causes the GL to block" - is that just the current context or all contexts in the process? I suppose this isn't too important when ClientWaitSync is called with a timeout of zero since it should not block at all.

    Regards,
    Patrick

  7. #17
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: glFlush or glFinish with mulithreading?

    Quote Originally Posted by Piers Daniell
    You do need a glFlush() sometime after the glFencSync() call otherwise anyone that waits in this sync object may wait forever.
    Thanks for confirmation. I understand the reason. The only think I was confused was the documentation. I did find any info about this situation. Maybe it worths adding one sentence to ARB_sync document. One the other hand it never hangs when glFlush is not called due to internal platform specific timeout .

    Quote Originally Posted by pjcozzi
    You had performance problems calling GetSynciv in a different context than FenceSync, correct?
    Yes.

    Quote Originally Posted by pjcozzi
    ... ClientWaitSync is called with a timeout of zero since it should not block at all.
    I've never tried ClientWait with zero timeout. I will try it one day. But timeout zero and close-to-zero time spent in this API are two different things. I expect ClientWaitSync (..., 0) to have similar performance characteristic as GetSynciv.

    On the other hand I do not see any benefit of having pure worker thread for loading textures. Do some benchmarks and you will see that if you call some function in one OGL thread then the other OGL thread is blocked. You will end up chasing obscure timing problems in you main thread. Some trivial OpenGL API will sometimes takes ages just because your worker thread called glTexImage. (at least on NVIDIA, Windows)

    Use PBO for loading textures. It is much better.

  8. #18
    Junior Member Regular Contributor pjcozzi's Avatar
    Join Date
    Jun 2004
    Location
    Philadelphia, PA
    Posts
    196

    Re: glFlush or glFinish with mulithreading?

    Quote Originally Posted by mfort
    On the other hand I do not see any benefit of having pure worker thread for loading textures. Do some benchmarks and you will see that if you call some function in one OGL thread then the other OGL thread is blocked. You will end up chasing obscure timing problems in you main thread. Some trivial OpenGL API will sometimes takes ages just because your worker thread called glTexImage. (at least on NVIDIA, Windows)
    This is exactly what I am afraid of. Given different contexts in different threads, you would think a large number of GL calls could execute in parallel (with the understanding that there is probably only a single GPU). Of course, I figure calls like glGenTextures need to lock.

    Quote Originally Posted by mfort
    Use PBO for loading textures. It is much better.
    I hear ya. We've used this successfully in the past by giving a pointer from glMapBuffer to a worker thread. Do you know if this can be done without pointers, e.g., by calling glBufferData in the worker thread? Or is using any GL in the worker thread a potential problem?

    Regards,
    Patrick

  9. #19
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,008

    Re: glFlush or glFinish with mulithreading?

    I expect ClientWaitSync (..., 0) to have similar performance characteristic as GetSynciv.
    Why? One of these is a glGet, which is always considered a bad idea in performance code. The other has specific language in its specification as to how it behaves and performs.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •