Welcome Stranger to OCC!Login | Register

Serious Statistics Pt. 2: The Sync Encounter

   -   
» Discuss this article (2)

Borderless – No V-Sync:

On modern versions of Windows OS, the rendering of all windows is handled by the Desktop Window Manager. Whether it is an explorer window, your browser, a video, anything that is contained in a window (meaning not exclusive fullscreen), the DWM handles it. A feature Microsoft decided to add some versions ago was that it will, by default, apply double buffer to the rendering of all windows, so screen tearing should not be possible but you may also see some latency. It is possible for a flag to be set to disable the double buffer for a window, but a developer must choose to do this. Unless you are using Vulkan. It appears Vulkan does not actually use true borderless but a fake borderless where it is still exclusive fullscreen, but is relatively safe to Alt-Tab from. For this reason I only did a single run with Vulkan borderless, because the data will be no different between fullscreen and borderless for this API.

This double buffering is something I ran into in the previous article, as the PresentMon/OCAT data caught that the display times were being aligned on multiples of 16.667 ms while the frame times were unaffected. Naturally this is still the case.

 

 

 

 

GTX 1080 - DX11

GTX 1080 - Vulkan

Vega 64 - DX11

Vega 64 - Vulkan

 

If I did not have the filenames clearly marked for which runs these graphs are from, you would not be able to tell these are for the borderless runs and not the fullscreen runs, which is a good thing. The display time graphs are a very different story though, except for Vulkan.

 

GTX 1080 - DX11

GTX 1080 - Vulkan

Vega 64 - DX11

Vega 64 - Vulkan


Perhaps amusingly, this is actually more the kind of graph we would expect from using triple buffering. The line of dots along 0 ms is for the frames that were dropped, which means the back buffers were flipped more than once in the time it took to scan out the front buffer. The blue trend line being nearer to 0 ms means more frames were dropped than rendered.

 

 

GTX 1080 - DX11

GTX 1080 - Vulkan

Vega 64 - DX11

Vega 64 - Vulkan


Here we see spikes just at the integer frame later marks, which makes sense because DWM is only going to send a frame to a display to match the refresh rate, or drop it.

 

 

GTX 1080 - DX11

GTX 1080 - Vulkan

Vega 64 - DX11

Vega 64 - Vulkan


Now things are getting kind of weird. At first I did not even understand what I was looking at, but I still spent the time to design an intelligent graphing system and after collecting some more data, I figured out what was happening (or at least have a reasonable guess).

 

Anyway, first thing to cover is that the negative-latency points are from dropped frames. Because they are dropped the MsUntilDisplayed is 0, but there is still a positive MsUntilRenderComplete value because the frames were still rendered. I threw in those boxes so you can see the proportion of frames dropped and displayed. That is not the only interesting thing here as we see a gap between 0 ms and 16.667 ms. This means that of the displayed frames, they are all waiting at least 16.667 ms, one full frame, before being displayed. Not ideal.




Related Products
Random Pic
Most Popular Articles
© 2001-2018 Overclockers Club ® Privacy Policy
Elapsed: 0.0449199677   (xlweb1)