<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 17, 2015 at 6:10 PM, Björn Blissing <span dir="ltr"><<a href="mailto:bjorn.blissing@vti.se" target="_blank">bjorn.blissing@vti.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""></span><br>
But my main point still stands; it is possible to record latencies that are close to the scanout time of the screen with VSync Off (albeit for very simple rendering).<br></blockquote><div><br></div></div>Yes, but not consistently for every frame. Assuming that each frame you are drawing takes the same time, you need "to get lucky" for that to happen and then the next frame is going to have a much higher latency. When you do get lucky, the next frame buffer swap will happen slightly earlier now relative to the start of the scanout, because you didn't start drawing after the vsync event but earlier. This will keep going on for several frames, shifting the buffer swap point earlier and earlier relative to the scanout cycle until you, again, hit that sweet spot where you measure the low latency. Your measurement shows this "beating" between the scanout/display update frequency and your buffer swaps (when you are starting the timer, I presume) quite nicely. <br><br></div><div class="gmail_extra">The best you can do from the latency point of view is to synchronize to the scanout using the fences. Then you will have always at most one frame latency (the GPU is scanning out the previous frame from the front buffer while you are drawing the current one in the back buffer) if you can fit your drawing calls within the duration of a single frame.<br><br>Don't get confused by the "late latching" tricks that Oculus is promoting. That has nothing to do with display latency but user input/tracking one. There they incorporate the tracking data at the very end of the rendering process just before the buffer swap, achieving very low apparent input latency relative to when the frame is going to be scanned out. But the display latency (the time from buffer swap to pixels changing on the screen) is unaffected by that. <br><br><br></div></div>