<p>It's a bit complicated because the actual wait for vsync does not happen on the CPU, it happens on the GPU. The GPU wait then creates <a href="https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7" rel="noreferrer">back-pressure</a> that propagates back to the queue of submitted command lists on the CPU, through the GL driver, and eventually to your app. The exact behavior will depend on the details of how the GPU vendor chose to implement their GL driver, and also probably depends on the behavior of the windowing system as it controls frame presentation. Unfortunately there are no real guarantees about this in GL as far as I'm aware, it's really up to the vendors.</p>

<p>In this case, it seems likely that you're seeing the wait become visible to your app at the first GL command that causes the driver to try to begin recording into a new command list (which may entail waiting for a previous command list to finish executing on the GPU, so that the driver can reuse it for the new frame). Clears, draw calls, dispatches, buffer mapping or copying, etc would probably qualify, while (for example) state-setting calls or memory allocation calls might not issue any actual commands to the GPU.</p>

CC BY-SA 4.0
2020-05-21T22:32:44.020Z
2020-05-21T22:32:44.020Z
Nathan Reed
<p>When having vsync enabled I'm imagining that OpenGL has an explicit wait function to try and keep the frame rate constant. If so where is this function implemented exactly? After running some tests <code>glClear()</code> function seems to take almost 16 ms with minimal OpenGL script on my machine. When removing this function, the wait seems to happen where the first (?) <code>glDrawArrays()</code> or <code>glDrawElements()</code> function is implemented. If none of these functions are implemented then on my machine the wait happens during <code>glxSwapBuffers()</code>.</p>

<p>I'm hoping to get some better understanding behind his, partly to know when to best poll the input events. Previously I polled at the start of the main loop and then rendered the scene. But since there's a wait during <code>glClear()</code> function, I'm experiencing a bit of an input delay. So maybe it would make more sense to poll in-between clearing the buffers and rendering the scene?</p>

<opengl>
With vsync enabled where does the wait happen in OpenGL?
Lenny White
# With vsync enabled where does the wait happen in OpenGL?

(Asked by: username_0 on 2020-05-21)

When having vsync enabled I'm imagining that OpenGL has an explicit wait function to try and keep the frame rate constant. If so where is this function implemented exactly? After running some tests `glClear()` function seems to take almost 16 ms with minimal OpenGL script on my machine. When removing this function, the wait seems to happen where the first (?) `glDrawArrays()` or `glDrawElements()` function is implemented. If none of these functions are implemented then on my machine the wait happens during `glxSwapBuffers()`.

I'm hoping to get some better understanding behind his, partly to know when to best poll the input events. Previously I polled at the start of the main loop and then rendered the scene. But since there's a wait during `glClear()` function, I'm experiencing a bit of an input delay. So maybe it would make more sense to poll in-between clearing the buffers and rendering the scene?

**Tags:** opengl


---

## 1 answers

### Answer by username_1 on 2020-05-21. Score: 5 | Accepted answer

It's a bit complicated because the actual wait for vsync does not happen on the CPU, it happens on the GPU. The GPU wait then creates [back-pressure](https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7) that propagates back to the queue of submitted command lists on the CPU, through the GL driver, and eventually to your app. The exact behavior will depend on the details of how the GPU vendor chose to implement their GL driver, and also probably depends on the behavior of the windowing system as it controls frame presentation. Unfortunately there are no real guarantees about this in GL as far as I'm aware, it's really up to the vendors.

In this case, it seems likely that you're seeing the wait become visible to your app at the first GL command that causes the driver to try to begin recording into a new command list (which may entail waiting for a previous command list to finish executing on the GPU, so that the driver can reuse it for the new frame). Clears, draw calls, dispatches, buffer mapping or copying, etc would probably qualify, while (for example) state-setting calls or memory allocation calls might not issue any actual commands to the GPU.


---

