Effect of swap-buffers on the GL Command Queue?

[Bruce Wheaton]

If I draw a frame, put in a query end, call swapbuffers, and then when pulling the query find that I still have time before the swap actually happens, can I use that time within the same frame?

Does that make sense? A buffer swap is pending on it's vertical interval. As far as I know the back buffer has been completely drawn, but the actual swap still has to be happen (which I understand is a simple pointer swap internally, at best).

I'd like to maybe start some texture transfers, or maybe draw to an FBO, all in the same context. Could that disrupt my swap? Or would all the commands just wait until after the swap anyway?

Bruce

[thokra]

My approach to measuring time is this:

a) start timer query
b) do everything else
c) end timer query
d) get time
e) swap buffers

My thought process is that when the command buffer is processed, the query command will be the first and last to be executed. The swap command should not be part of the measurement since it's actually not determined by how complex the scene or shaders are but you should only measure the actual frame time needed to render the frame to the back buffer (or some other buffer) before swapping.

[awhig]

It makes sense to use that time to examine the content and take a decision but is impractical as swapping operation would be faster.

Using FBO or texture transfer would be fine and may be done parallely, theoretically, but would be less profitable as by the time any decision is made, swapping would have occurred.

I have not come across any mechanism by which swapping can be stalled but redirected to any off-screen buffer. The swap is itself a command; perhaps atomic.

Lets assume, if user can control swapping operation, then your argument makes much more sense. In that case, the swap operation would be disrupted.

If frame investigation is the only motive, you may use FBO at beginning and put some checks/constraints in your shader.