When techniques like double buffering (aka VSync ON) or triple buffering (aka FastSync/EnhancedSync) are used, there is a timing when back buffers replace the front buffer, usually through page flipping registers.
This timing is made inside the VBI (Vertical Blanking Interval) to avoid screen tearing. The VBI is split in 3 steps, vertical front porch, vertical sync and vertical back porch, followed by the vertical active. I was wondering when exactly the page flipping happens. Does page flipping happens at the beginning of the front porch (beginning of VBI), or does it happen at the vertical sync (near the middle of VBI)?
This exact timing matters when tuning your display timings for low input lag, as the closer to the vertical active the page flipping happens, the lower the input lag.
Page flipping timing inside VBI
Re: Page flipping timing inside VBI
If you don't use some form of "quick frame transport" (like substantially increasing your vertical total,) then it doesn't actually make much difference. If you do use QFT, then... yeah. That's an interesting question.
Steam • GitHub • Stack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
Re: Page flipping timing inside VBI
The actual flip is permitted to happen at any time during blanking, actually. The only requirement is that swaps complete before the raster exits blanking. There is even a test in Microsoft's driver certification for Presents occurring extremely close to the end of blanking.
VSYNC, when implemented by the driver, aims to do the flip as soon as possible. It is optimized to hit the beginning of blanking and avoid flips dangerously close to the end of blanking. That is good for eliminating tearing, but not ideal for latency.
If you want to optimize for abnormally long blanking intervals, you cannot rely on platform-provided VSYNC.
You have to turn VSYNC off and implement it yourself, because VSYNC exists for the sole purpose of preventing visible tearing. What you are asking for here is a specialization of that, one that increases the potential of visible tearing when stuff like dynamic GPU frequency scaling is active.
Incidentally, I have just finished an update to Special K's framerate limiter that does scanline-level synchronization of buffer flipping. There are a number of sources of delay that make doing this outside of a graphics driver difficult and imprecise, but it's doable.
This is part of an Open Source project, and this new feature "Latent Sync" will eventually be isolated from Special K and provided as a standalone library. As far as I know, it is the only open source implementation. Hopefully the standalone library will push things along and get this sort of functionality out of the niche it currently occupies 
VSYNC, when implemented by the driver, aims to do the flip as soon as possible. It is optimized to hit the beginning of blanking and avoid flips dangerously close to the end of blanking. That is good for eliminating tearing, but not ideal for latency.
If you want to optimize for abnormally long blanking intervals, you cannot rely on platform-provided VSYNC.
You have to turn VSYNC off and implement it yourself, because VSYNC exists for the sole purpose of preventing visible tearing. What you are asking for here is a specialization of that, one that increases the potential of visible tearing when stuff like dynamic GPU frequency scaling is active.
Incidentally, I have just finished an update to Special K's framerate limiter that does scanline-level synchronization of buffer flipping. There are a number of sources of delay that make doing this outside of a graphics driver difficult and imprecise, but it's doable.
- LATENT_SYNC.png (1.41 MiB) Viewed 1146 times