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

[bhoff]

I deleted all my resolutions except 120hz & 60hz QFT for testing, here's a screen shot of a fully working normal 120hz and a screen shot of the 60hz QFT that gives a black screen.

[Chief Blur Buster]

I deleted all my resolutions except 120hz & 60hz QFT for testing, here's a screen shot of a fully working normal 120hz and a screen shot of the 60hz QFT that gives a black screen.

Thanks!

The easy QFT formula is much more unreliable on monitors that do not support FreeSync. XL2411P does not support FreeSync.

While fixed-Hz QFT is not VRR, the existence of FreeSync means the scaler is usually QFT-compatible.

However, XL2411P does support some undocumented QFTs but requires a lot more random hacking of the VTs. You now found your upper bounds of experimentation. Now try locking the radio button on the refresh rate, and then decrementing your VT until it works. XL2411P does support smaller large vertical totals at 60Hz.

You may, possibly try to continue to attempt QFT on XL2411P by using a different porch (e.g. modify the Front Porch, the Sync, and the Back Porch) to transfer the some VBI allowances between all three. Vertical Total is the vertical sum of (sync + back porch + visible + front porch):



So on some monitors, a problem is solved by changing the ratios between the porches as well as the sync. However, this does not always work on all monitors, and you have to instead just begin decreasing the porches instead to a more manageable number like VT1500 or thereabouts.

You lose the easy QFT formula in this QFT HOWTO, so you have to do more experimentation/hacking to get XL2411P to do a QFT mode. There are some documented working QFT modes in some of the other threads (e.g. VT1350 and VT1502)

[bhoff]

I tried playing around with it and was able to get this working

working out of range.PNG (34.5 KiB) Viewed 6445 times

What's weird is my monitor says "Out of range" and blocks me from accessing the monitor settings, but the image looks perfectly fine.

[jbltecnicspro]

Good afternoon,

Using a Viewsonic XG2431 here and I have successfully created a mode for 60hz QFT. But for some reason I see no difference in the cross-talk of the top and bottom edges of the monitor. As in - no difference whatsoever. The Viewsonic utility reports 4500 vertical total, so I'm wondering what's up? I'm using an HDMI cable - do I need to use the displayport? Thanks!

[FlameOnion]

Does increasing Vertical Total helps to reduce lag when converting from cvbs(retro console,nes) to hdmi or vga?
Increasing Vertical Total has the same effect on CRT?
Increasing vertical Total works with this: scart(rgb) to vga (https://www.geocities.ws/podernixie/htp ... l#scartvga)
This cable lets you connect a DVD player, DTV receiver or any other device with RGB scart output to an Arcade or PC monitor.(nes composite>DVR scart rgb> vga xl2411 or crt)

[RealNC]

Does increasing Vertical Total helps to reduce lag when converting from cvbs(retro console,nes) to hdmi or vga?

Yes. But not sure how you'd do that. Vertical total is something controlled by the source, not by the display. Your retro console uses standard vertical total.

Increasing Vertical Total has the same effect on CRT?

It would, if it worked. But on CRTs the video signal is actually used to steer the electron beam. It will most probably not be able to cope with a large vertical total.

Increasing vertical Total works with this: scart(rgb) to vga (https://www.geocities.ws/podernixie/htp ... l#scartvga)
This cable lets you connect a DVD player, DTV receiver or any other device with RGB scart output to an Arcade or PC monitor.(nes composite>DVR scart rgb> vga xl2411 or crt)

Again, the source (the DVD player or whatever) would need to output a larger vertical total. I don't see how that's possible.

[Chief Blur Buster]

Does increasing Vertical Total helps to reduce lag when converting from cvbs(retro console,nes) to hdmi or vga?

Unfortunately, this won't help because QFT is not supported in original retro consoles.
QFT needs to be done by a supported chip (e.g. NVIDIA, AMD)

Increasing Vertical Total has the same effect on CRT?

It works on some CRTs but it has some severe side effects like very flat image size.
Large VBIs often create weird effects with CRT beam steering.
However, it would only work with a GPU (AMD/NVIDIA) capable of VGA output, or if you used a low-lag converter like a HDFury that converts digital output to analog.

Increasing vertical Total works with this: scart(rgb) to vga (https://www.geocities.ws/podernixie/htp ... l#scartvga)
This cable lets you connect a DVD player, DTV receiver or any other device with RGB scart output to an Arcade or PC monitor.(nes composite>DVR scart rgb> vga xl2411 or crt)

This won't work because retro consoles don't have QFT support built into them.
You have to use an emulator from a PC to use QFT, and use QFT via the NVIDIA/AMD GPU, because the GPU generates the QFT.

[roro13200]

hello for a qft mode must we have vsync on in the nvcp?

[Chief Blur Buster]

hello for a qft mode must we have vsync on in the nvcp?

You can instead use these alternatives to "VSYNC ON":
- RTSS Scanline Sync
- Special K Latent Sync

These are software-based sync technologies, like creating a VSYNC ON clone out of VSYNC OFF. The above two are tearingless VSYNC OFF systems via beam-raced raster-timed Present()'s at a specific scanline number index, such as just before the beginning of refresh cycle, or just after the end of a refresh cycle. These can VSYNC ON look-and-feel at practically VSYNC OFF latencies, provided GPU utilization 50% or less and game can do perfect framerate=Hz. These scanline-sync technologies, both inspired by Blur Busters, are very QFT-friendly.

Also, QFT still reduces strobe lag and low-Hz lag even for VSYNC OFF. Meaning 60Hz QFT on a 240Hz panel that is laggy for 60Hz, can still reduce VSYNC OFF lag for 60Hz, because of reduced buffering stage in the panel, as in earlier replies.

Now, there are cases where QFT will not reduce VSYNC OFF lag at all, relative to native non-QFT Hz -- that happens on horizontal scanrate multisync panels (e.g. already low-lag 60Hz capability on a 240Hz panel). The net latency becomes 0ms difference, since you're just randomly chopping (tear-lines-ing) the same refresh interval that is synchronous scanout between cable and panel. The figurative virtual tearline can also be in the VBI portion of a refresh cycle too.

Since the randomization of tearlines throughout the refresh cycle would have no net average lag reduction for QFT vs non-QFT, unless the lag comes from another cause than scanout lag, such as:
- Bypassing scan-conversion lag (buffering a slow-scan non-QFT 60Hz signal for a fast-scanout to a fixed-horizontal-scanrate panel)(
- Bypassing strobe lag (by delivering refresh cycle sooner so it can strobe sooner).
Then in these cases, VSYNC OFF will still have reduced lag from QFT.

[Chief Blur Buster]

Crossposting an educational thread.

I would understand this if multiple frameslices to be scanned out in this cycle would be somehow preremembered and scanned only after as a whole. But doesn't scanout happen in realtime and show frame as soon as it is rendered?

There's a cable scanout and a panel scanout, and they both can be higher/lower than each other.

Jorim nailed most of it for the panel scanout level, though there should be two separate scanout diagrams to help understand context (scanout diagram for cable, scanout diagram for panel) whenever the scanout are different velocities.

However, there are some fundamental clarifications that is needed.

The frameslices are still compressed together because the frameslices are injected at the cable level, but the monitor motherboard is buffering the 60Hz refresh cycle to scanout in 1/240sec.

Fixed-Scanrate Panels

Fixed-scanrate panels create input lag at refresh rates lower than max-Hz, unless Quick Frame Transport is used to compensate.
I would bottom-align the 60Hz like this, however:



Scaler/TCON scan conversion "compresses the scanout downwards" towards the time delivery of the final pixel row. So about 3/4ths of 60Hz scanout is delivered before the panel begins refreshing at full 1/240sec velocity.

Also, sometimes this is intentionally done by a panel with a strobed backlight or scanning backlights, to artificially increase the size of VBI, to reduce strobe crosstalk (double image effects), by creating a VBI large enough to hide LCD GtG pixel response between refresh cycles (hiding GtG in backlight-OFF).

Flexible Scanrate Panels

However, some panels are scanrate multisync, such as the ASUS XG248 or the ViewSonic XG2431, which has excellent low 60Hz console lag:



Learn more about Quick Frame Transport

For more information about compensating for buffering lag, you can use Quick Frame Transport (Large Vertical Totals) to lower latency of low refresh rates on 240Hz panels: Custom Quick Frame Transport Signals.

The Quick Frame Transport creates this situation:



This can dramatically reduce strobe lag, but Microsoft and NVIDIA needs to fix their graphics drivers to use end-of-VBI frame Present(). Look at the large green block, so frame Present() needs to be at the END of the green block, to be closer to the NEXT refresh (less lag!).

Microsoft / NVIDIA Limitation Preventing QFT Lag Reductions

Unfortunately, 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. So hacks have often been needed.

This simulates a VSYNC ON with a inputdelayed Present() as late as possible into the vertical blanking interval.

The software API, called Present(), built into all graphics drivers and Windows, to present a frame from software to the GPU. Normally Present() blocks (doesn't return to the calling software) until the blanking interval. But Present() blocks until the very beginning of VBI (after the final scan line) before releasing. Many video games does the next keyboard/mouse read at that instant right after Present() returns. So it's in our favour to delay returning from Present() until the very end of the VBI: That delays input reads closer to the next refresh cycle! Thus, delayed Present() return = lower input lag because keyboard/mouse input is read closer to the next refresh cycle.

A third party utility, called RTSS, has a new mode called "Scanline Sync", that can be used for Do-It-Yourself Quick Frame Transport.



Then that dramatically reduces VSYNC ON input lag (anything that's not VSYNC OFF) on both fixed-scanrate and flexible-scanrate panels, because the 60Hz scanout velocity is the same native velocity of 240Hz.

Great for reducing strobe lag, too!

(Not everyone at Microsoft, AMD, and NVIDIA fully understand this.)

We successfully reduced the input lag of ViewSonic XG270 PureXP+ by 12 milliseconds less input lag, while ALSO reducing strobe crosstalk, with this technique. ViewSonic XG270 120Hz PureXP+ Quick Frame Transport HOWTO.

Earlier, I tried large Front Porches, hoping that Microsoft inputdelayed to the first scanline of VBI before unblocking return from Present() API call. But unfortunately, Microsoft/NVIDIA unblocks Present() during VSYNC ON at the END of visible refresh (before first line of Front Porch). Arrrrrrgh. Turning Easy QFT, into Complex QFT.

But Wait! G-SYNC and FreeSync are Natural Quick Frame Transports

Want an easier Quick Frame Transport? Just use a 60fps cap at 240hz VRR. All VRR GPUs always transmit refresh cycles at maximum scanout velocity. Present() immediately starts delivering the first scanline at that instant (if monitor not currently busy refreshing or repeat-refreshing) since the monitor slaved to the VRR.



Present() is already permanently connected to the end of VBI during VRR operation. Unless the monitor is still busy refreshing (frametime faster than max Hz) or the monitor is busy repeat-refreshing (frametime slower than min Hz). As long as frametimes stay within the panel's VRR range, software is 100% controlling the timing of the monitor's refresh cycles!

This is why emulator users love high-Hz G-SYNC displays for lower emulator lag.

60fps at 240Hz is much lower latency than a 60hz monitor, because of the ultrafast 1/240sec scanout already automatically included with all 60fps material on all VRR monitors! The magic of delivering AND refreshing a "60Hz" refresh cycle in only 4.2 milliseconds (both cable and panel), means ultra-low latency for capped VRR

This is why VRR is is the world's lowest latency "Non-VSYNC-OFF" sync technology.

It doesn't help when you need to use fixed-Hz (consoles, strobing, non-VRR panels).

This Posts Helps you to:
- Understand Flexible-Scanrate LCD panels (most 1080p 144Hz panels, few 1080p 240Hz panels)
- Understand Fixed-Scanrate LCD panels (most 1080p 240Hz panels, most 144Hz 1440p panels)
- Understand Quick Frame Transport
- Understand Quick Frame Transport's ability to workaround low-Hz lag on Fixed-Scanrate Panels
- Understand VRR
- Understand How VRR is similar to Quick Frame Transport
- If you are a software developer, Understand that software controls triggering variable refresh monitor's refresh cycle via Present()