Page 1 of 2

FAQ: Understanding HDMI Quick Frame Transport (lower lag)

Posted: 21 Apr 2018, 16:39
by Chief Blur Buster
People who may have heard of a new method of delivering refresh cycles faster. We're very familiar with this, but few people are.

See HDMI Version 2.1 on HDMIFORUM.org which says:
HDMI Forum wrote:HDMI Quick Frame Transport (QFT) reduces latency for smoother no-lag gaming, and real-time interactive virtual reality.
Image

But what the hell is Quick Frame Transport? Well, it's simply a large blanking interval.

First, if you have seen those numbers in a Custom Resolution Utility, they are just simply mapped spatially in signal layout:

Image

Vertical Total = the entire height of this.
And VBI = Vertical Blanking Interval = (The sum of Vertical Front Porch + Vertical Sync + Vertical Back Porch).

Around here, we sometimes call this the Large Vertical Total trick, which also has other benefits such as reducing strobe crosstalk.

Normally, refresh cycles are transmitted one after the other, in tight fashion with a tiny blanking interval:
Image
However, it's possible to scanout quicker, such as delivering 100Hz refresh cycles in 1/144sec:
Image
It's possible to go even further, such as delivering 60Hz refresh cycles in 1/240sec! Basically, a frame-delivery acceleration of 4x factor, for supported platforms.

HDMI Quick Frame Transport, while specified by HDMI, the fundamental technique also works on DisplayPort and DVI connections, since it's simply a large blanking interval. A refresh cycle is transmitted faster, with a longer pause between refresh cycles.

Also, some 240Hz monitors can only scan-out their panels at full velocity (1/240sec). So they have to buffer an incoming slow-scanning 60Hz refresh cycle over the cable, before scanning-out in 1/240sec. By using Quick Frame Transport, you can do realtime concurrent LCD panel scanout in sync with cable scanout, reducing the input lag of 60Hz or 120Hz signals (e.g. XBox One consoles) on a 240Hz displays.

Ideally, a display has to advertise this feature correctly via the correct EDID/DisplayID info, to inform a computer that it supports a Quick Frame Transport mechanism. However, many existing 144Hz and 240Hz monitors support Custom Resolution Tweaking to create large VBIs, so it would be very easy to add Quick Frame Transport capabilities to these displays, for supported signal sources. Monitor manufacturers should add information to their HDMI EDIDs to include the Quick Frame Transport feature. FreeSync compatible LCDs are relatively easy to make QFT compatible.

(Currently, most 240Hz monitors are very bad at 60Hz consoles, since they only do bufferless scanout at 240Hz -- because they buffer a 60Hz scanout signal and does a full-velocity scanout on 240Hz LCD panels. Unless they're made to support a Quick Frame Transport at 60Hz with a large Vertical Total of >4000 scanlines for a 1080p signal).

Now you understand better!

______

EDIT: Want to do QFT on your computer? There's a new HOWTO for creating Quick Frame Transport:
HOWTO: Quick Frame Transport (QFT) - Large Vertical Totals (reduce lag, reduce crosstalk)

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag

Posted: 21 Apr 2018, 17:35
by Chief Blur Buster
Also -- the XBox One reportedy supports an upgrade path to HDMI Quick Frame Transport (along with 120Hz, FreeSync, etc). While further testing will be needed, as of today (April 21st, 2018), there is now an XBOX ONE Forum at Blur Busters which will grow over time.

Also -- "Quick Frame Transport" equivalent is already built into FreeSync/GSYNC. Variable refresh rate displays have have been doing this since 2012. Low frame rates shows large input-lag-reducing benefits on high-Hz variable refresh rate dispays, since those refresh cycles are delivered at full dotclock velocity of maximum Hz, even if you're just doing low frame rates (ala 40fps / 40Hz). The lag-reduction benefits show really clearly in the various Blur Busters GSYNC tests (including GSYNC 101). Quick Frame Transport is simply bringing these lag-reducing to fixed-Hz displays (benefits of faster scanout of low refresh rates).

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag

Posted: 28 Jan 2019, 02:11
by Chief Blur Buster
Experimental HOWTO For Advanded Users
DIY Quick Frame Transport is now possible on Windows PCs.

--Mainly benefits VSYNC ON motion or refreshrate-synchronized framerates--

As of 2018, manufacturers have not yet automated this (e.g. embedding in EDID and DisplayID) so this is undocumented.

By default, Windows times frame presentation at the end of a refresh cycle. But to reduce lag, you want to inputdelay the next frame as long as possible (to make the input read closer to the next refresh cycle). So you want to modify Microsoft's default Present() behavior to beginning of the NEXT refresh cycle. Basically move the presentation timing from start of VBI to end of VBI. This wasn't possible before, but now it's made possible by RTSS Scanline Sync!

It works on any video cable for a monitor supporting large VTs, and reduces VSYNC ON input lag further.
You just have to use RTSS scanline sync to force Windows to do end-of-VBI Present() instead of start-of-VBI Present()
Read RTSS Scanline Sync HOWTO

IMPORTANT:
- Remember, you only want QFT to reduce the lag of VSYNC ON even further.
- If you have VRR, try using that instead because it's much easier than doing this QFT hack.
- Some monitors will be able to QFT beyond max-Hz (e.g. LG 27GK750-B is capable of a slight QFT effect of 1/280sec refresh cycle delivery at 240Hz). Monitors supporting only "CVT-Reduced" or "Reduced Blanking" at max-Hz, will NOT support Quick Frame Transport.

Until vendors build in user-friendly QFT into their displays, this will be an advanced-user tweak.

By using VSYNC OFF + RTSS Scanline Sync + Custom Resolution, it's possible for end-users to create a Do-It-Yourself Quick Frame Transport mode (which works on VGA, DVI, HDMI, DisplayPort) on certain monitors. Basically, this is custom beam raced tearlines that raster-synchronizes Present() to put tearlines right above the top edge of the screen on a large-blanking-interval signal.

Image

Advanced-User Large blanking interval trick for DIY Quick Frame Transport (QFT) with RTSS Scanline Sync
In short.
1. Use a Custom Resolution Utility (CRU) like NVIDIA Custom Resolution or ToastyX CRU. Increase the size of your blanking interval. Gradually increase and test until your monitor stops syncing. Sometimes you can go really huge (2:1 ratios).
2. Then use RTSS Scanline Sync to re-time the frame presentation to the end of the blanking interval, to obtain the reduced-lag benefits in real-world games.

- Do not bother with below trick doing this unless you're a CRU Wizard.
- Do not bother with below trick unless you know your monitor supports ultralarge blanking intervals larger than the vertical resolution, such as "Vertical Total 2200" for 1080p.
- Do not bother with below trick if you don't understand "Vertical Total" or "Front Porch" or "Back Porch" or "Horizontal Scan Rate".
- QFT behavior is already built into VRR, so use VRR instead. It's easier to use GSYNC or FreeSync as a much easier QFT method (e.g. 60fps cap at 240Hz) since the VRR provides a very easy natural QFT mechanism. That's why lag is very low on GSYNC/FreeSync since all refresh cycles (no matter the current Hz=fps) are always delivered at max-Hz velocity.

Very few monitors support large VBIs at their maximum non-VRR refresh rate. However, a few of them do -- e.g. delivering a 60Hz refresh cycle in 1/120sec on a monitor that doesn't support 120Hz. (This is rare, but occasionally happens). Alternatively, if you're using large blanking intervals to reduce strobe crosstalk (squeezing LCD GtG into VBI to reduce artifacts with a blur reduction backlight) -- then it may be more favourable to use VSYNC OFF and adjust scan line sync late into VBI. This creates a "Quick Frame Transport" effect. Normally, Microsoft and graphics drivers does frame presentation at end of refresh cycle (bottom edge of screen), rather than beginning of refresh cycle (top edge of screen). By delaying input reads-render-present late into a superlarge VBI, via RTSS scanline frame rate capping late into VBI (small negative offsets), one can reduce lag further thanks to the Quick Frame Transport effect of the use of an ultralarge blanking interval (Example: 60Hz refresh cycles transmitted over the cable in 1/120sec via the use of an ultralarge VBI the same size of the visible image). Quick Frame Transport (QFT) is part of the HDMI 2.1 specification but is possible to DIY on any cable with Custom Resolution + Large VBI + RTSS scanline sync. Displays that are intentionally designed to support QFT works best with this trick, but I've run into some displays that have undocumented QFT capability on one of its inputs, e.g. certain 60Hz HDTVs that supports 120Hz input but the panel can't support 120Hz. (Basically frameskips, as in only displays 60 frames out of 120 per second); those displays can often be tricked into a QFT 60Hz signal (via ultralarge VBI -- maintaining same exact 135KHz horizontal scanrate but halving the vertical refresh rate from 120Hz to 60Hz) -- that speeds up delivery of 60Hz refresh cycles to 1/120sec -- reducing frame delivery latency by 8ms. If you shift your inputread-render-deliver pipeline to align with the frame transmission (presenting framebuffer very late in VBI, right on time for visible frame transmission), that reduces the input lag of VSYNC ON / Fast Sync / Enhanced Sync by 8ms without raising refresh rate on displays that supports a 2x QFT acceleration factor (documented or undocumented). First, play with custom resolutions until you've got the biggest supernova-sized galactic-sized blanking interval your monitor will sync to -- a blanking interval big enough to drive a battlecruiser through. Next, start your game, make sure it's correctly using that hacked custom frankenstein signal timings & resolution you created, THEN finally calibrate RTSS until your tearline shows up near top edge of screen, THEN calibrate it until it barely disappears above top edge. Now you've created a fixed-Hz QFT sync mode!

_________________

IMPORTANT: This DIY Quick Frame Transport trick only works if your monitor supports large vertical totals at the refresh rate you want to run at. Vertical totals twice the active resolution may reduce VSYNC ON input lag by half a refresh cycle on certain displays. e.g. VT2250 instead of default VT1125 for a 1080p signal will reduce average VSYNC ON lag by ~8ms for 60Hz VSYNC ON -- soley by the Quick Frame Transport effect -- with no changes to framebuffer backpressures!

IMPORTANT #2: Quick Frame Transport mainly helps framerate-synchronized motion, e.g. if you want an even lower-lag VSYNC ON

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag

Posted: 08 Mar 2019, 13:05
by Litzner
I am running a VG248QE+RX Vega over Display Port using ToastyX's tool to enable Lightboost 100Hz + Scanline Sync (Vsync settings dependent on game, but usually off). Can I, and would I benefit from playing around with QFT/large blanking intervals?

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag

Posted: 06 Apr 2019, 17:09
by Chief Blur Buster
Litzner wrote:I am running a VG248QE+RX Vega over Display Port using ToastyX's tool to enable Lightboost 100Hz + Scanline Sync (Vsync settings dependent on game, but usually off). Can I, and would I benefit from playing around with QFT/large blanking intervals?
Unfortunately, LightBoost only triggers on an exact Vertical Total, so trying to use an even larger Vertical Total, unfortunately turns off LightBoost. So you lose the LightBoost benefit.

Some monitors keep strobing with large Vertical Totals, such as BenQ XL2411P and XL2720Z, so those actually get reduced strobe lag with Quick Frame Transport. Meaning the VT1350 and VT1502 tricks can hit two birds with one stone (reduce strobe crosstalk AND add a quick frame transport for "VSYNC ON" equivalent-looking modes) if you combine it with end-of-VBI RTSS Scanline Sync.

Your frame transport acceleration factor formula is:

(New Vertical Total) / (Original Vertical Total)

For a 1080p display using Vertical Total 1502 (422-line VBI) instead of Vertical Total 1125 (45-line VBI), your refresh cycle is transmitted (1502/1125) = ~1.335x faster over the video cable!

However, that's only for the BenQ ZOWIE XL2411P and XL2720Z -- both of which supports VT1350 and VT1502 during 120Hz -- and does not work with VG248QE.

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag

Posted: 17 Jul 2019, 16:37
by Chief Blur Buster
Edited / updated to add new diagram.

Image

RTSS Scanline Sync is software that can use beam racing to do precision raster-positioned tearlines exactly where you want. Once this is successful, it's now possible to steer tearlines exactly offscreen to end-of-VBI, to create a lower-lag software-based "VSYNC ON QFT" out using a beam-raced "raster-interrupt-style" precise VSYNC OFF mode.

Pre-requisites
(A) Driver and game configured to VSYNC OFF
(B) Monitor that supports large vertical totals at the resolution you want to create a QFT mode for
(C) Custom Resolution Utility
(D) RTSS Scanline Sync (Install Rivatuner Statistics Server, and then enable the special mode)
(E) A game with a framerate range that is almost completely above your target refresh rate (even framerate dips)
(F) Proper RTSS fine-tuning

Then you can create a Do-It-Yourself Quick Frame Transport mode!
Users are now actively tweaking this successfully: Large vertical totals for low input lag

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag)

Posted: 31 May 2020, 15:51
by Chief Blur Buster
Crossposting an educational thread.
hmukos wrote:
22 May 2020, 19:02
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
Inserted NOTE: This panel type can gain QFT lag reduction with ALL sync technologies including VSYNC OFF

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:

Image

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
Inserted NOTE: This panel type will have no benefit from QFT with unsynchronized non-strobed VSYNC OFF, but strobing and other sync technologies can show latency reductions.

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

Image

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:

Image

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.

Image

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.

Image

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()

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag)

Posted: 04 Jan 2021, 05:31
by TheInventor
So someone said QFT was just like VRR. I guess that in theory you could ask the display to give you say 1080p at 864Hz, and then enable VRR on that, and use it to shoot the individual frames over insanely fast - even though your game console is producing them at maybe around 60Hz. The problem with this is that the TV now needs to be ready to receive frames at 864Hz just in case, and no one wants to design TV hardware that can stay cool while receiving and displaying frames at that sustained rate. So, in practice TVs will not let you select such a fast refresh rate for 1080p. With QFT, you can get the fast frame delivery benefit AND the TV (or monitor) can be designed to reasonable engineering specs. The TV can 2D scale up from 1080p to 4K or 8K - that won't increase latency - and the latency benefit will give serious gamers a competitive edge that's probably worth upgrading their hardware to get.

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag)

Posted: 04 Jan 2021, 14:46
by Chief Blur Buster
TheInventor wrote:
04 Jan 2021, 05:31
So someone said QFT was just like VRR.
More accurately, "VRR has a natural QFT mechanism built in", whereas QFT is an optional part of classical fixed Hz.

60fps QFT (4x factor, VT4500) at 240Hz fixed-Hz is in theory the same latency as capped 60fps at 240Hz VRR, assuming no VSYNC ON framebuffer backpressure.

In practice, 60fps at 240Hz VRR is lower latency than 60fps QFT because the frame can be a few microseconds late and not miss a fixed Hz, since VRR refresh cycles are delayable for "late" frames. So late frames have 0ms lateness penalty rather than a 1-refresh-cycle lateness penalty, as the monitor actually delays the refresh cycles for late-delivered frames, permitting slightly jittery 60Hz frame delivery without the penalty of a mixed fixed-Hz schedule.

Fixed-Hz is like scheduled refresh cycles (software syncs to display), while VRR is asynchronous (display syncs to software -- API Present() / glxxSwapBuffers() actually controls starting the refresh cycles!)

However, both Fixed-Hz and VRR can have QFT. Unlike being optional/manual addition to fixed-Hz, the QFT effect is already a native built-in part of VRR. Since the pixels of one refresh cycles are delivered over the cable at max-Hz speed. (e.g. 67fps=67Hz, but frames are delivered in 1/240sec for a 240Hz VRR screen).
TheInventor wrote:
04 Jan 2021, 05:31
I guess that in theory you could ask the display to give you say 1080p at 864Hz, and then enable VRR on that, and use it to shoot the individual frames over insanely fast - even though your game console is producing them at maybe around 60Hz.
Some displays already do. It's possible to have a scanout faster than max-Hz. Not all, but some cheap 60Hz displays can quickly buffer faster, like in 1/120sec even if the panel does not support 120Hz -- but it is often by design accident. It's just a buffer design.

DisplayPort and HDMI are just bitbuckets like an Ethernet connection and most display modes are using less than maximum bandwidth. So the name of the game is to max the bandwidth of the cable, without changing the panel.

In this sense, no extra cooling is needed, except a faster buffer, like using 100 Mbps connection for Netflix instead of 10 Mbps. Your 1080p buffers faster and begins playing sooner, even though picture quality is no different. Likewise, a high-spec DisplayPort connection (GPU, monitor) with a low-spec panel, presents an opportunity for electronics to simply buffer faster -- maybe a single watt of extra heating needed but that wouldn't need cooling.

Several VR headsets already use QFT, to help speed delivery from computer to the headset.

Also, the PG259QN monitor is capable of a 1/440sec QFT for 360Hz refresh cycles via a custom resolution. This was accidentally discovered in tweaking. Attempted overclocks to 440Hz worked but frameskipped/glitched badly, but reducing refresh rate while keeping the horizontal scan rate (number of pixel rows per second delivered) enabled a 1/440sec QFT.

So sometimes QFT-above-max-Hz capability is already there, hidden in your existing display, waiting for ToastyX CRU to unlock it.
TheInventor wrote:
04 Jan 2021, 05:31
So, in practice TVs will not let you select such a fast refresh rate for 1080p. With QFT, you can get the fast frame delivery benefit AND the TV (or monitor) can be designed to reasonable engineering specs.
In my experience, one-quarter of newer TVs accidentally supports a 1/120sec QFT of a 60Hz. First, try Blur Busters 120Hz From PC to TV trick.

If you have 120Hz frameskipping, it may be failing to support 120Hz, but it's already doing a QFT of 60 refresh cycles per second. Double the vertical total and halve refresh rate, and you have a 60Hz refresh rate with a 1/120sec QFT. However, lag benefits may or may not happen, depending on how fast the panel scanout, and how long the electronics buffers (partially or fully) before beginning to refresh the panel. Think of it as a Netflix buffer at the microseconds or milliseconds scale for your refresh cycle...

QFT experimenting is not very common by our forum members because QFT mainly helps strobing or VSYNC ON (or RTSS Scanline Sync) instead of VSYNC OFF, due to the way VSYNC OFF is scanout-following and VSYNC ON is global (and benefits from faster global delivery).

Most forum members here concerned about latency are using VSYNC OFF, and QFT doesn't really benefit non-strobed VSYNC OFF much on syncronous panels (cable scanout in sync with panel scanout).
TheInventor wrote:
04 Jan 2021, 05:31
The TV can 2D scale up from 1080p to 4K or 8K - that won't increase latency - and the latency benefit will give serious gamers a competitive edge that's probably worth upgrading their hardware to get.
QFT uses more bandwidth in smaller amount of time, so QFT might only be available at lower resolutions or lower refresh rates.

Think of DisplayPort as a bandwidth budget like an Ethernet connection. You've got a fixed cost of maximum number of pixels per second (Dot Clock or Pixel Clock in a Custom Resolution Utility). You can't transmit an image infinitely fast, but DisplayPort is often running below max spec. You have more QFT headroom at lower Hz and lower resolutions, and less QFT headroom at higher Hz and higher resolutions. You can easily milk this headroom on some displays (the chip can buffer fast even if the panel can't refresh fast), while it's impossible in others (out of spec)

QFT successes are sometimes more common than panel overclocking successes, while other times QFT requires simultaneous panel overclocking.

Re: FAQ: Understanding HDMI Quick Frame Transport (lower lag)

Posted: 05 Jan 2021, 07:02
by TheInventor
There are two ways to look at QFT: The first is "as a technology" and I agree with what you said in this context. Thanks for the detailed response!
The second is "as an HDMI 2.1 feature". In this context it's about achieving interoperability between devices (e.g. sources such as game consoles and sinks such as TVs) that leads to successful commercial implementations of QFR technology. This will deliver a competitive benefit to many gamers.
So, I assert that VRR alone is not as good as VRR plus QFT. For my 1080p example, VRR+QFT would technically be equivalent to VRR+864Hz refresh rate. But, if TV manufacturers were to attempt to implement the latter, they would probably have to compromise a lot somewhere else - such as on cost, energy efficiency, brightness, or image quality.
So, it will benefit consumers the most if devices implement both features and achieve interoperability. Likewise, if consumers want the minimum possible latency, they will need to look for and purchase those devices that support both VRR and QFT.