HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by RealNC » 10 Aug 2021, 00:52

Arbybear wrote:
09 Aug 2021, 19:13
So you can't have matching resolution and refresh rate in an EDID, but is there a way to switch out what EDID is stored in the registry (faster than editing a resolution in ToastyX)?
You can export the EDID in CRU. So you can prepare two EDID files and import and apply the one you want in CRU. After importing one and applying it, run restart64.exe to restart the GPU driver so that it reads the EDID again from the registry.
SteamGitHubStack 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.

Slender
Posts: 573
Joined: 25 Jan 2020, 17:55

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by Slender » 10 Aug 2021, 03:29

i play cs:go 240hz, 400fps ingame cap, 1024 768 LCD reduce.
play warzone 1440 1080, 144hz
Qs i need QFT?

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by RealNC » 10 Aug 2021, 08:01

Slender wrote:
10 Aug 2021, 03:29
i play cs:go 240hz, 400fps ingame cap, 1024 768 LCD reduce.
play warzone 1440 1080, 144hz
Qs i need QFT?
No. QFT helps a little bit with latency at 60Hz. At 144Hz it won't give you much. If you wanted to try it, what you'd basically do is make your 240Hz monitor use 240Hz scanout speed at 144Hz. But the difference in latency would be something like 1.5ms, which is pretty much not worth it.

At 60Hz however, if you ever wanted to use 60Hz for whatever reason, using 240Hz scanout speed would improve latency by 6ms. So QFT in this case is worth it.
SteamGitHubStack 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.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by Chief Blur Buster » 10 Aug 2021, 14:21

QFT is mainly a tweak available to lower refresh rates (than monitor's maximum refresh rate).

If you're using an overclockable monitor (e.g. BenQ XL2411T), you can overclock it first, and derive your 144 Hz QFT mode from the overclocked resolution.

Also, QFT does not help the latency of non-strobed VSYNC OFF on horizontal-scanrate multisync panels. Most players use VSYNC OFF, so bear this in mind.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

howiec
Posts: 183
Joined: 17 Jun 2014, 15:36

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by howiec » 11 Aug 2021, 11:07

Another excellent guide worth pinning!

Kaldaien
Posts: 21
Joined: 22 Jan 2020, 21:27

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by Kaldaien » 15 Aug 2021, 16:58

Oh, wow. I sort of assumed turning Auto-Low Latency Mode on automatically negotiated this signal timing and was the only way to get QFT up and running.

This is great news, I had written the idea of using QFT in combination with Black Frame Insertion on my LG OLEDs out on the grounds that BFI mode doesn't work as soon as you turn the display's ALLM on. It assumes you want full-persistence G-Sync.

Doing this programmatically will be a big win for the 50 or 60 Hz BFI modes I often run at.

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by elexor » 15 Aug 2021, 20:40

Kaldaien wrote:
15 Aug 2021, 16:58
Oh, wow. I sort of assumed turning Auto-Low Latency Mode on automatically negotiated this signal timing and was the only way to get QFT up and running.

This is great news, I had written the idea of using QFT in combination with Black Frame Insertion on my LG OLEDs out on the grounds that BFI mode doesn't work as soon as you turn the display's ALLM on. It assumes you want full-persistence G-Sync.

Doing this programmatically will be a big win for the 50 or 60 Hz BFI modes I often run at.
I think the new low latency mode is just changing the tv into a native 60hz scanrate mode, older lg oleds were scanconverting 60hz to 120hz creating extra lag due to the buffering required, You can see this if you go on rtings and look at the responsetime tests. Image

you could use retroarch BFI with 120hz output from a pc and see if the latency is better then lg's motion pro high@60hz. persistence will be higher 8ms vs 4ms but it's still a nice blur reduction and twice as bright.

Would be interesting to see if the oled accepts a 60hz@120hz scanrate QFT mode. If you have a lag tester pls test.

as you probably know motion pro high with native 60hz input is pretty laggy.

Image

also Quick Frame Transport currently only reduces lag if you simultaneously use RTSS Scanline Sync (with negative number tearline indexes) to move Present() from beginning of VBI to the end of VBI.

could special k be made to move Present() forward? these modes are very useful for strobed lcd, allows reduction of crosstalk + potential reduction of lag. vrr automaticly does this but that's not useful for fixed hz blur reductions.

more explanation here viewtopic.php?t=4064

Kaldaien
Posts: 21
Joined: 22 Jan 2020, 21:27

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by Kaldaien » 16 Aug 2021, 16:00

elexor wrote:
15 Aug 2021, 20:40
also Quick Frame Transport currently only reduces lag if you simultaneously use RTSS Scanline Sync (with negative number tearline indexes) to move Present() from beginning of VBI to the end of VBI.

could special k be made to move Present() forward? these modes are very useful for strobed lcd, allows reduction of crosstalk + potential reduction of lag. vrr automaticly does this but that's not useful for fixed hz blur reductions.

more explanation here viewtopic.php?t=4064
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.

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.

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by elexor » 16 Aug 2021, 20:53

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.
Ah, right. Vsync off average latency does not benefit from QFT.

Only 2 ways I know of to get pseudo vsyncOn that has QFT lag benefits:

* Scanline sync with the tearline positioned right above the top edge of the screen
* vrr gsync/freesync lower fps @ max hz.

Can also reduce lag with strobed lcd because less strobedelay is needed for crosstalk reduction, but this does not apply to oled.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Post by Chief Blur Buster » 17 Aug 2021, 00:45

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.

Image

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)
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply