Welcome Stranger to OCC!Login | Register

Serious Statistics Pt. 2: The Sync Encounter

   -   
» Discuss this article (2)

Borderless – Frame Rate Limiter:

With the frame rate limiter activated, it should not be at all surprising that the frame time graphs are going to be straight lines right at the 16.667 ms mark.

 

 

 

 

 

 

 

GTX 1080 - DX11

Vega 64 - DX11

 

The display time graphs are kind of odd though, because why are there some frames being shown two frames later, instead of just one?

GTX 1080 - DX11

Vega 64 - DX11

 

Now we get to the fun part, so look at these graphs and then I will talk about them. Short spoiler is that we are seeing more than one frame of latency here.

GTX 1080 - DX11

Vega 64 - DX11

 

Now that is a funky graph, but it is actually very helpful as it let me figure out what is going on with these latency graphs when in borderless window. The key is the diagonal slants you can see in the points between 16.667 ms and 33.333 ms. This means that the latency, the time between the frame being rendered and displayed, increases from one frame to the next, and then resets to 16.667 ms, the expected latency of double-buffering.

Technically this is just a guess/hypothesis, but bear with me. Without a frame limiter the engine will try to render as many frames as it can in any 16.667 ms block of time. With a frame limiter (set to 60 FPS) it will try to make sure only one frame is rendered in that same block. This presents an issue of where in the block is the frame rendered; the beginning or the end? At the beginning means you render the frame and wait until it is called, so you want it rendered at the end of the block but until you render the frame, you do not know how much time that will take. You can estimate it will take 5 ms because previous frames did, but if it takes 6 ms, the frame will be late. What do you do then? You pad your guess.

Taking that 5 ms frame time guess, that leaves about 12 ms the engine can wait before it needs to start rendering it. We want to pad it though, so we start rendering at 10 ms. This means the time between the rendering completing for two consecutive frames is not 16.667 ms, but more around 15 ms. If it were just that gap and things reset to zero, this would not be an issue, but my guess/hypothesis is that this all starts again when the frame finished, so at 15 ms instead of 16.667 ms. What this means is that the gap between when the frame will be displayed and when it completed rendering is not the 1.667 ms of 16.667 ms and 15 ms, but instead the 3.333 ms between 33.333 ms and 30 ms. The latency has just increased from one frame to the next.

Now repeat this process some more and eventually the gap will be over 16.667 ms, which would result in two frames being rendered in the same 16.667 ms block of time. To correct this, the engine drops the older of two frames and this loop starts over again.

Coming back to the graph, what we see is the latency from one frame to the next increasing, and while it might be difficult to see it in the graph, the raw data does show the dropped frames normally coming when the latency result in what I described above. This is my reasoning for why the displayed frames all have a latency between 16.667 ms and 33.333 ms, while my reason the latency is above 16.667 ms is the double buffering of the DWM.

Technically this is what is happening in all of the DWM-involved tests, but only the padding of the frame rate limiter has made it visible. It put in place a level of control over the frame time that is not present in the other tests, allowing the pattern of frame dropping to reveal itself.

That finishes up the in-game options for both fullscreen and borderless, so now we can start looking at the driver-based options.




Related Products
Random Pic
© 2001-2018 Overclockers Club ® Privacy Policy
Elapsed: 0.0523340702   (xlweb1)