Welcome Stranger to OCC!Login | Register

Serious Statistics Review


V-Sync Tests:

With my curiosity engaged by the DirectX 11 results and DWM forced v-sync, I decided to do a few runs with different v-sync settings. I had v-sync off, v-sync on, and v-sync on with triple buffering while running the Hatsheput course using DirectX 11 in Exclusive Fullscreen. Before going too far, I want to explain what v-sync, or vertical sync, is.

After a GPU renders a frame it presents it to the frame buffer, which is what will be sent to the display. If the frame buffer is updated at the same frequency as it sends the frame to the monitor, everything is wonderful and nice. When the GPU is able to update the buffer more frequently, we can get screen tearing. This is a result of the frame being updated with new information while it is being sent to the display. Suddenly the older top half of the frame is matched with a newer bottom half, and if things do not align between the halves, it looks like the screen tore. If the GPU is particularly fast, there can be multiple tears in a single displayed frame, because the buffer has been updated multiple times before the GPU finishes sending it to the display.

Here is the course graph with v-sync off. The black dots are the MsBetweenPresents points, just like earlier in the article, and the blue dots are the MsBetweenDisplayChange points. The red dots are the MsUntilDisplayed, and there are also green dots for MsUntilRenderComplete, but they are completely covered by the red dots because the frames are being sent to the buffer just as quickly as they are completed.


With double buffering, the GPU has two buffers to work with, just as the name suggests, and these are called the front and back buffers. The front buffer holds the frame that will be sent to the display, and it is always supposed to be a coherent frame, meaning no tearing. The back buffer is what the GPU can write the next frame to. From here one of two things may happen, and as it happens both occurred in my testing.

One possibility is that the GPU will swap the buffers as it finishes rendering a frame, allowing the GPU to render just as fast as it can. The older frames will be dropped so new frames can be written into the back buffer. The other possibility is that the frames will not be dropped but a frame rate limit or target will be imposed.

The former case, with frames being dropped, is what happens with DirectX 11 in Borderless Fullscreen/Window, as the double buffering is being done by the Desktop Window Manager and not the game engine itself, so it does not know to impose a limit or target. The latter, where such a limit or target is used is what happens when v-sync is enabled within the game, and we can see this in the data.


As you can see, the black dots all hang right around 16.667 ms, so the framerates were sticking right around the 60 FPS mark. If you scroll back up to see the previous course graph, the frame times were varying quite a bit, and almost all of the points were beneath the 16.667 ms line.

To further demonstrate what is going on, here are the display time graphs for these two runs.



You may notice there are no dropped frames indicated on the second graph, which is further evidence that turning on v-sync is imposing a frame rate limit or target of 60 FPS.

Looking back to the colorful course graph from the v-sync on test, we see the red dots, the MsUntilDisplayed data, is up around 33.333 ms. This makes sense because while the time between frames being displayed is sticking to 16.667 ms, the frames are 33.333 ms old by the time they make it to the display. This is because a frame has to go from the back buffer to the front buffer, and that means waiting for 16.667 ms for the frame in the front buffer to be displayed, and then from the front buffer to the display after another 16.667 ms, waiting for the monitor refresh cycle, and this adds up to the 33.333 ms of the data. Unfortunately this means there is increased input latency, because by the time the frame is shown, the events in it are already that old.

I am not sure if one can really say if it is better to have unlimited frames with some dropping, or limited/targeted frames without any dropping, as both offer certain advantages and disadvantages. To achieve a balance of the pros and cons, the next v-sync method was developed.

Triple buffering is exactly what it sounds like as it adds a third buffer to the mix, so now we have one front buffer and two back buffers. The intent is that while the front buffer is being sent to the display, the two back buffers can be rendered to, with one always holding a coherent frame. When a new frame is needed for the front buffer, it and the back buffer with the coherent frame are swapped. This allows the GPU to go at full speed without screen tearing and with minimal input latency. At least that is the theory behind its development.

By the way, I am doing these tests in DirectX 11 instead of Vulkan because triple buffering was not allowed when Vulkan was selected.


Looking at the graph we see again there is a frame rate limit/target in play as the MsBetweenPresents is all grouped around 16.667 ms. Further, we can see the red MsUntilDisplayed data is up near 50 ms, which matches with a rendered frame having to wait for the third opportunity in my displays refresh cycle to be shown. This also means there is even greater input latency than there was with double buffering. Neither the unlimited framerate nor the reduced latency that comes with it are being provided by this implementation of triple buffering.

I do have at my disposal another means of implementing triple buffering, and it is specifically meant to allow for higher framerates and reduced latency. It is NVIDIA's Fast Sync in the drivers, if your GPU supports it (Maxwell and Pascal). As this is outside of the game's options, I am not going to share the graphs I have for it, but I will talk about it.

Fast Sync in theory is nice, but it is not perfect. For one thing it requires the game is hitting a multiple of your monitor's refresh rate, such as 120 FPS and 180 FPS in my case. If the game does not match these or higher multiples, then Fast Sync will not have any impact, and if the framerate is not those exactly, there can still be screen tearing. I also observed the framerate was targeting or being limited specifically to 120 FPS or 180 FPS, depending on which it could hit. At these high framerates, we do get the benefit of reduced input lag. At least this is the case with DirectX 11. I tried with Vulkan but the game crashed if I tried to enter Exclusive Fullscreen, and in Borderless Fullscreen/Window it seemed Fast Sync was not in play.

I also tested setting the maximum FPS in the game, as it is an option with both DirectX 11 and Vulkan. Both APIs held around 16.667 ms very well. The time until displayed stayed much lower than either v-sync option, so the input latency would be minimal under these settings. This seems to suggest the game was targeting 60 FPS, so frames would start being rendered in time to hit 16.667 ms, instead of being rendered and waiting however long for the monitor refresh cycle, as was happening with both v-sync options. Here is what that course graph looks like, with low times until displayed data:

  1. Serious Statistics - Introduction
  2. Serious Statistics - Software/Tools
  3. Serious Statistics - Testing and Processing
  4. Serious Statistics - Vulkan - Hatsheput
  5. Serious Statistics - Vulkan - Dunes
  6. Serious Statistics - Vulkan - Thebes - Karnak
  7. Serious Statistics - OpenGL - Hatsheput
  8. Serious Statistics - OpenGL - Dunes
  9. Serious Statistics - OpenGL - Thebes - Karnak
  10. Serious Statistics - DirectX 11 - Hatsheput
  11. Serious Statistics - DirectX 11 - Dunes
  12. Serious Statistics - DirectX 11 - Thebes - Karnak
  13. Serious Statistics - V-Sync Tests
  14. Serious Statistics - Conclusion
Related Products
Random Pic
© 2001-2018 Overclockers Club ® Privacy Policy
Elapsed: 0.1614289284   (xlweb1)