4/7/24, 4:14 PM c++ - At what point does vsync "wait" (block)?

- Stack Overflow

At what point does vsync "wait" (block)?

Asked 9 years, 10 months ago Modified 9 years, 10 months ago Viewed 4k times

Say I have a program that is really fast and, if vsync were disabled, would run >60fps. When does vsync
force the program to wait? Does it block when you clear the screen or when you flip the buffers? Or is it
5 some other time I'm not aware of?

I'm referring to OpenGL, incidentally.

BONUS QUESTION

Given there's not necessarily a specific point at which the blocking occurs, how would I measure how
long the blocking is taking? In other words, how would I work out how fast the program could run?

c++ opengl

Share Improve this question Follow edited Jun 10, 2014 at 12:20 asked Jun 10, 2014 at 8:03
Clonkex
3,492 8 40 58

vsync blocks front-back buffer swapping until next display sync signal. Clear and other drawing just draws to back
buffer, which is not on screen [yet] – keltar Jun 10, 2014 at 8:07

The effect is probably not visible from your code and will be handled by the graphics driver. – Kerrek SB Jun 10,
2014 at 8:07

Most openGL commands are nonblocking. The waiting for vsync is done when the buffer to which is drawn is
swapped with the buffer to which is rendered. With glut this is done with the command glutSwapBuffers() , buth
other libraries have other names for this function. GLFW has glfwSwapBuffers(window) for instance. – Lanting
Jun 10, 2014 at 8:19

I don't believe GL exposes API to answer your bonus question. And even if it did, you can't just extrapolate this
value and expect non-vsync framerate to match your estimate - because there are really a lot of factors affecting
frame rate. But you can switch vsync on and off on the fly with (WGL|GLX)_EXT_swap_control extensions. – keltar
Jun 10, 2014 at 18:07

@keltar But unfortunately not on mobile. The problem is that on most mobile devices, vsync is forced on.
– Clonkex Jun 11, 2014 at 0:38

1 Answer Sorted by: Highest score (default)

The comments to your answer show, that this remains still a topic with a lot of misconceptions.

To make a long story short: There is no explicit point at which your program will block.
12
The swap buffer call returns immediately. Don't believe me? Write a program that measures the time
spent in one single swap buffers call (i.e. don't enter a rendering loop). But I hear you say: If I enable V-
Sync and measure the frame rate in my program it shows the right frame rate, so somewhere it has to
block.

https://stackoverflow.com/questions/24135853/at-what-point-does-vsync-wait-block/24136893#24136893 1/2
4/7/24, 4:14 PM c++ - At what point does vsync "wait" (block)? - Stack Overflow

Whats happening is, that after a call to swap buffers the back buffer is kind of "protected"; the back
buffer is to be presented on the front buffer with the contents it had the the time of calling SwapBuffers.
So the next operation that would alter the contents of the back buffer blocks after a call to SwapBuffers
until the swap happened.

BUT (and that's a big but) the OpenGL command queue is asynchronous. What blocks is the execution
of the command queue, but unless a synchronization point is inserted or the queue maximum capacity
has reached all the OpenGL calls will return immediately. glFinish introduces a synchronization point.
But if you place a glFinish right after a SwapBuffers, since it only acts on any drawing operation
happening between itself and the previous SwapBuffers, there's nothing to finish yet and it will likely
return immediately as well.

So you're in a rendering loop and measure the time of SwapBuffers there, and all of a sudden it takes
one V-Sync interval to return. What's going on? Well, SwapBuffers implies a glFlush . But more
importantly a buffer swap leaves the back buffer in an undefined state, which means, that a buffer swap
operation is on the same level of buffer content modification as drawing commands. But because there
are only two buffer (front and back) if there's already a buffer swap queued, the following one invokes a
synchronization block until the previous swap has been performed. This stalls the command queue and
ultimately makes one OpenGL drawing command or the SwapBuffers command block eventually.

Share Improve this answer Follow edited Jun 10, 2014 at 10:22 answered Jun 10, 2014 at 9:02
datenwolf
161k 13 188 303

1 Well, there is a good difference between GL swap buffer and drivers (or better - hardware) internal one.
WGL/GLX/AGL SwapBuffers does not invoke glFinish but rather glFlush, and returns quickly. Driver is a different
story - it delays buffer swap until drawing is complete and vsync interval is matched. In my observation in GL block
happens in SwapBuffers when one buffer is already in wait queue, while application tries to submit another one -
but this is not guaranteed (as, well, almost everything). – keltar Jun 10, 2014 at 9:50

@keltar: Sorry, I meant to write SwapBuffers implies a glFlush ; I fleshed out that part a bit as well.
– datenwolf Jun 10, 2014 at 10:18

@datenwolf Thanks, that helps greatly! What I'm trying to is measure the time that the program is blocking from
vsync, so that I can calculate an approximate framerate that the program could run at if vsync were disabled (trust
me, I have a sensible reason for wanting to do this). Would you have any recommendations for this? – Clonkex
Jun 10, 2014 at 11:57

1 @Keltar: Actually, if you disassemble OpenGL32.dll as I have done for another similar question you will notice
that the GDI path (right-hand side) invokes a full glFinish (...) ; the ICD path (left-hand side) leaves the
implementation up to the ICD. But that really should not be too surprising if you think about it, when you do
rendering on the CPU the pipeline is already synchronized with ... the CPU so glFinish (...) is appropriate ;)
– Andon M. Coleman Jun 10, 2014 at 12:07

2 Rumors are that some vendors don't block on glFinish() . – Reto Koradi Jun 10, 2014 at 14:45

https://stackoverflow.com/questions/24135853/at-what-point-does-vsync-wait-block/24136893#24136893 2/2