Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 6 of 6

Thread: BlitFrameBuffer synchronisation

  1. #1
    Newbie Newbie
    Join Date
    Jan 2014
    Posts
    3

    BlitFrameBuffer synchronisation

    Hello all,

    Should there need to be any explicit synchronisation (like glFinish or something less heavy like glWaitSync) before a glBlitFrameBuffer command in order to guarantee the src/dest-bound framebuffer objects are ready for use? Or is this command queued with all the other draw operations and so guaranteed to run after they are complete? Or perhaps implementations generally apply an implicit sync between the drawing to any of the src/dest FBOs and the scheduling of a framebuffer blit operation?

    I've struggled to find a reference where this kind of question is addressed. The EXT_framebuffer_blit spec doesn't seem to mention it (at least not explicitly), and other pages like the OpenGL wiki's Synchronization reference (sorry, I can't type the link it as it won't let me submit this post) looked really hopeful but I still couldn't get an exact answer on what is expected of a glBlitFrameBuffer operation. If there is any other place I should be looking then please let me know, or if there are common phrases and/or terminology that implies some behaviour then I'd like to know that too.

    Many thanks in advance.
    Last edited by richardk; 01-29-2014 at 11:58 PM.

  2. #2
    Intern Contributor
    Join Date
    Nov 2011
    Posts
    51
    glBlitFramebuffer() is queued, and you can query a Framebuffer Status with the appropriate function glCheckFramebufferStatus() before try to Bind() or Blit() it.

  3. #3
    Intern Contributor
    Join Date
    May 2013
    Posts
    60
    You don't have to sync anything. Blitting will be put on the command queue.

    Before you can use glCheckFramebufferStatus you actually have to bind the FBO. And the DSA function (glCheckNamedFramebufferStatusEXT) sounds kind of pointless because the reference says it may not return FRAMEBUFFER_UNSUPPORTED correctly.
    Also for performance reasons, I only would run the check once after the FBO was created and all attachments added.

    And to prevent any miss conceptions: glCheckFramebufferStatus is only there to tell if all attachments make up an valid setup. It has nothing to do with the status of pending draw commands on the FBO!

  4. #4
    Newbie Newbie
    Join Date
    Jan 2014
    Posts
    3
    Many thanks for the replies.

    So it sounds like I should be confident that any blit operation between two FBOs should only occur after any previous drawing operations involving them are finished (no matter how much time the rendering to these targets is taking?).

    So where do find these behaviours described? I really did struggle to find any mention of it in the official specification and also in any of the extension docs or supporting webpages (like the wiki).

  5. #5
    Advanced Member Frequent Contributor arekkusu's Avatar
    Join Date
    Nov 2003
    Posts
    781
    Quote Originally Posted by richardk View Post
    So where do find these behaviours described?.
    Boilerplate language at the beginning of the GL spec:

    OpenGL Fundamentals
    Commands are always processed in the order in which they are received, although there may be an indeterminate delay before the effects of a command are realized. This means, for example, that one primitive must be drawn completely before any subsequent one can affect the framebuffer. It also means that queries and pixel read operations return state consistent with complete execution of all previously invoked GL commands, except where explicitly specified otherwise.

  6. #6
    Newbie Newbie
    Join Date
    Jan 2014
    Posts
    3
    Brilliant! Thanks arekkusu.

Posting Permissions

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