Kaldaien wrote: ↑16 Aug 2021, 16:00
Oh, that is interesting. I have code in place to under/overshoot VBLANK, but it is relative to the beginning of VBLANK. I move the target just slightly before VBI fires off so that the present never gets rescheduled to the next refresh cycle.
This is a hugely annoying part of Windows behavior, its compositing pipeline is not QFT-friendly (yet...) (...deep sigh...)
Auto Low Latency (ALL) has nothing to do with Quick Frame Transport (QFT) -- they are two independent latency lowering standards Although ALL could technically negotiate QFT in a roundabout way... ALL still can lower latency by itself via automatically disabling lag-increasing processing (e.g. automatically disabling interpolation or enhanced color processing modes), and QFT can lower latency by itself by faster signal transport).
QFT is just fundamentally an ultralarge blanking interval which can be several times taller than the visible image.
In fact, a 60Hz QFT-4x signal (4x signal delivery velocity) is identical to a 60fps-capped 240Hz VRR signal, from a signal layout structure. Think of it as a fixed-Hz-capped VRR with a 0Hz VRR range. The use of VRR is just a variable size blanking interval, and QFT simply fixes the blanking interval to a fixed ultra-large sizes.
The boom of FreeSync compatible panels made them pretty much defacto "undocumented QFT compatible".
Kaldaien wrote: ↑16 Aug 2021, 16:00
I guess it goes without saying the discussion assumes VSYNC is off
A present that occurs in the middle of blanking tends to be penalized with a 1 frame delay if you let Windows decide where the deadline is and you really have to arrive even earlier than that if DWM composition is active. So I've been moving things the other way forever.
In custom frame rate capping software (using tearingless VSYNC OFF algorithms to emulate bufferless VSYNC ON) you really want to delay Present() to the end of the VBI, to gain the proper latency reductions. This inputdelays whatever your game/software is doing closer to frame presentation timing.
You still should have an option to select end-of-VBI presentation even with Fast Sync or Enhanced Sync algorithms since certain versions of some graphics rivers are reasonably well-designed to allow frame presentation to flush to the screen as long as presentation occurs before end of VBI. But it must be made optional, only VSYNC OFF is the way to guarantee it.
In my experience, tearingless VSYNC OFF is reliable on all modern GPUs in High Performance Mode (microsecond timers enabled) and GPU power management is force-disabled by making sure GPU is revved up at least 1-2ms before a microsecond-precision-delayed Present(). However, with an ultra large VBI, you can Present() early in VBI, but don't return from Present() until end of VBI. So the "simulated VSYNC ON" blocking behavior is now end-of-VBI. So you might theoretically modify a frame rate capping algorithm to the following:
1. Continue your existing algorithm internally (present to screen just before end of VBI), to let compositor work properly
2. But block returning to your application software until just exactly after the VBI.
This provides an immediate instant universal 12ms lag reduction for 60Hz single-strobed emulators including XG2431's single strobe support:
www.blurbusters.com/xg2431 ... No software BFI needed; it's true native 60 Hz single strobe support.
This forces an inputdelay to the software since the next inputread is often done immediately upon return of Present(). So this would end up becoming a VSYNC ON compatible QFT, as a framerate capper "present timing modification" to make Windows QFT-friendly.
It's my understanding Special K frame rate capper already has a built-in inputdelayer, so adding QFT support to Special K probably is easy.
If you get one of those new 60Hz single strobed LCDs that I have worked on and released this summer, download
www.blurbusters.com/strobe-utility-viewsonic (ViewSonic XG2431)