Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

Looking for some clarity on large vertical totals (Low Lag)

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers. The masters on Blur Busters.

Looking for some clarity on large vertical totals (Low Lag)

Postby notthatjesus » 14 Sep 2018, 12:50

Namely, is there any benefit to having / forcing them when you aren't using a form of motion blur reduction?

For example: my main monitor is an Acer ROG PG278QR

Default CRU Settings
Image

Largest Supported* VT
Image

* at least according to my own brief testing

I was using a BenQ XL2411 prior so a higher VT was practical and the habit of patching my driver and raising VT totals carried over. The only thing resembling any form of logic as to why it may be beneficial: Higher pixel clock, more power. Of course it's complete speculation and I'm fully aware it's only slightly more logical than downloading "more RAM, for 5x performance INCREASE, only one install!"

So, can someone actually knowledgeable about monitor technology shed some light on this? (Please I desperately need more settings to micromanage)
notthatjesus
 
Posts: 10
Joined: 24 Apr 2017, 20:48

Re: Looking for some clarity on large vertical totals

Postby RealNC » 14 Sep 2018, 13:44

notthatjesus wrote:Namely, is there any benefit to having / forcing them when you aren't using a form of motion blur reduction?

When using 60Hz or similar low refresh rates, and using VTs of high refresh rates to get the scanout speed of the higher Hz, you get a reduction in overall latency. For example, if you run 60Hz, that gives you a scanout speed of 16.7ms. If you use the VT from 165Hz, your scanout speed becomes 6ms. That's 10.7ms lower, and that gives you an average reduction of latency of 5.35ms. Which is not huge, but still nice. (Btw, you don't need to do that with a G-Sync monitor. G-Sync does that automatically. Just make sure games use the highest Hz mode, even for 60FPS or 30FPS-locked games.)

But if you're already running high refresh rates, then no. There's not gonna be any tangible benefit, unless you use an extremely high VT. At 165Hz, your scanout speed is 6ms. Even if you used the VT of 200Hz, that would only result in a scanout speed of 5ms, which is a 1ms reduction, and thus the average latency decrease is 0.5ms. As you can guess, half a millisecond is a synonym for "nothing" when it comes to input latency. You gained nothing.

In other words, once you get past 144Hz, you're deep within diminishing returns territory when it comes to VT increases. You need huge VT increases to get benefits. To get a tangible latency benefit at 165Hz, you'd need the VT of something like 500Hz. Which of course isn't gonna work.

The only thing resembling any form of logic as to why it may be beneficial: Higher pixel clock, more power.

More "power"? I don't know what that means :-P Do you mean power consumption? Why would that be a benefit?
TwitterSteamGitHubStack 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
RealNC
 
Posts: 1915
Joined: 24 Dec 2013, 18:32

Re: Looking for some clarity on large vertical totals

Postby Chief Blur Buster » 14 Sep 2018, 13:56

Caveat: Some additional work is needed to get reduced input lag for VSYNC ON. Large Vertical Totals can produce reduced "VSYNC ON" input lag when used in conjunction with RTSS scan-line frame capping. You need Direct3D Present() and OpenGL glutSwapBuffers() to occur near the end of VBI (instead of beginning of VBI). This allow games that use smart inputdelay techniques (intelligently elayed input reads to as close timing as frame presentation) to gain reduced input lag.

Essentially this is like the HDMI Forum's "Quick Frame Transport" -- in a Roll-Your-Own Hack.

In summary, the advanced Large Vertical Total trick has several benefits:

Strobing Modes -- Yes, can reduces the double-image effect -- aka reduced strobe crosstalk -- on blur reduced monitors. Only on monitors capable of synchronizing panel scanout to cable scanout (e.g. BenQ XL2720Z). This is explained at http://www.blurbusters.com/crosstalk .... Basically a faster LCD scanout followed by longer pauses between refresh cycles. This allows more time for LCD pixel transitions to complete on the whole screen surface before flashing the backlight on a fully-refreshed panel. The more a faster-GtG is hidden in a long VBI between refresh cycles, the more CRT motion-clarity (no-double-image-effect) that an LCD panel can become. Be warned, some monitors already scan-convert internally, and thus, Large Vertical Total may not be able to speed up the scanout on those monitors, and does not reduce strobe crosstalk on all models.
Low Hz on High Hz Monitors -- Using Large Vertical Totals can reduce the lag of 60Hz gaming on 240Hz monitors, since some 240Hz monitors are stuck scanning their panels at full 240Hz velocity. Using Large Vertical Total (e.g. VT4400+ for a 60Hz signal) on a 240Hz FreeSync monitor, can produce a fixed-60Hz non-VRR mode that is much lower lag than a common 60Hz signal.
VSYNC ON -- Yes, when combined with RTSS new Scan Line frame capping feature (combined with VSYNC OFF) to emulate VESA Quick Frame Transport in software synchronized frame flipping. This is to flip frames near end of VBI instad of Window's default Present() timing at beginning of VBI during VSYNC ON. Delaying the pageflip allows inputdelay logic to get input reads closer to photons-hitting-eyeballs time. Flipping early in a long VBI means a long wait before the frame finally becomes displayed into photons.
VSYNC OFF -- There is no known latency benefit to using Large Vertical Total tricks on VSYNC OFF modes. This is because in unsynchronized framerates outputting willy-nilly, it all averages out to be the same lag at the end of the day. If you're using a non-strobed VSYNC OFF mode, and don't have a need for scanout-velocity compensation (e.g. speeding up cable scanout to match native panel scanout to avoid linebuffering lag) -- then don't bother worrying about Large Vertical Totals.

It's certainly a Pandora's Box of complexity that no other websites (other than Blur Busters) is able to explain. But it's massive lag reductions for a 240Hz monitor being forced to display at only 60Hz -- up to 12ms less input lag for top-edge -- to the point where I wish XBox/PlayStations supported Large Vertical Totals when connected to today's 240Hz monitors. Since this is a PC-only trick, that requires a Custom Resolution Utility, in order to utilize.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4932
Joined: 05 Dec 2013, 15:44

Re: Looking for some clarity on large vertical totals

Postby notthatjesus » 14 Sep 2018, 14:15

RealNC wrote:
notthatjesus wrote:Namely, is there any benefit to having / forcing them when you aren't using a form of motion blur reduction?

More "power"? I don't know what that means :-P Do you mean power consumption? Why would that be a benefit?


Y'know, like maximum power / performance, or at least the assumption deduced from (probably) faulty logic. The monitor equivalent to a large car spoiler, perhaps? The simple logic I'm going by is "omg +20 pixel clock boost, bet that'll make my monitor outperform all the others!!"

I appreciate both the quick replies and hammering home every single reason as to why I'm wrong. It's the only way I learn, really :D
notthatjesus
 
Posts: 10
Joined: 24 Apr 2017, 20:48

Re: Looking for some clarity on large vertical totals

Postby Chief Blur Buster » 14 Sep 2018, 14:28

For PG278QR, it's hard to say if there's any benefit.
ULMB -- It already has internal scanrate conversion, so you won't get crosstalk improvements. However, you might get "Quick Frame Transport" style benefits.
VSYNC ON -- Yes, but extremely minor.
VSYNC OFF non-ULMB -- Definitely don't bother.

But I see a clear situation where it's useless for you:
Your QFT (Quick Frame Transport) acceleration ratio is so low, that you probably shouldn't bother.

Lag Savings Formula = (original VT)/(new VT) = the lag reduction you will get

Going from VT1459 to VT1502 is only tiny.
Your "Quick Frame Transport" acceleration ratio is only (1459/1502) = 0.97x the lag.
That means if bottom edge lag was 10ms, you are now getting 9.7ms lag. That 0.3ms lag won't matter.

Top edge may or may not have benefit, depending on a panel's buffering behaviour (see below)
Screen center will be midpoint between top edge and bottom edge lag.

_________________

Large Vertical Total latency improvements only really help you if you can do large ratios,
e.g. VT4400 at 1080p on a 240Hz monitor versus the default VT1125 of a common 1080p mode = 1125/4400 = 0.255x the lag.

Meaning if the bottom edge was 16.7ms (e.g. 1080p/60Hz scanout velocity), it is now only 16.7ms x 0.255 = ~4.3ms lag! (I am currently excluding LCD GtG at the moment, for mathematical simplicity, this is more of a simple delta as GtG will remain unchanged). Here, your 12ms latency savings is rather significant, with a customized 60Hz mode with a 1/240sec cable transmission velocity.

Some panels have a fixed native scanout velocity (e.g. current 240Hz panels). So when Leo Bodnar Lag Tester is testing a 240Hz monitor (Leo Bodnar Lag Tester uses internal VT1125 -- the HDTV 1080p/60Hz standard Vertical Total) -- you will see roughly ~12ms+GtG (~15-16ms) for top edge and ~16.7ms+GtG (~20ms) for bottom edge. This is because the monitor has pre-buffered the slow-scanning 60Hz signal (VT1125) and began fast-scanning out when 3/4th finished buffering the refresh cycle. The panel began scanning out (refreshing) when 3/4ths of the refresh cycle has arrived, and the faster-panel-scanout finally catches up with the slow-cable-scanout when it hits the final scanline.

Essentially internal scanrate-conversion. By shifting a Large Vertical Total to the signal, we're having the GPU speed up the scanout instead, to deliver the refresh cycle faster (ala Quick Frame Transport - QFT effect). In /this/ specific situation, a Large Vertical Total will still reduce lag of VSYNC OFF 60Hz on these fast-scanout-only 240Hz panels, by globally subtracting roughly 12ms from the entire's panel surface thanks to the faster frame delivery that is now realtime in-sync with panel scanout. So instead of [~12ms....~16.7ms]+GTG lag gradient on the panel, you're now getting [0ms...4.2ms]+GtG lag gradient on the panel -- a global ~12ms improvement! That's major. Obviously, only occurs when you need to use a fixed-60Hz-mode on a 240Hz monitor. (Frame-capping 60fps on 240Hz GSYNC/FreeSync has the same lag-reducing effect too, by the way -- for similar reasons -- but you have to jump through a massive number of hoops to get the same low-60Hz-lag benefits on non-VRR displays -- to milk this Quick Frame Transport behaviour)

Note: Not all 240Hz monitors can support VT4400-VT4500 ranges for creating low-lag 60Hz modes, but FreeSync monitors are generally more Vertical Total forgiving than GSYNC monitors, if you want to experiment with ultralarge-VT tricks where the VBI is bigger than the active image
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4932
Joined: 05 Dec 2013, 15:44

Re: Looking for some clarity on large vertical totals

Postby Chief Blur Buster » 14 Sep 2018, 14:31

Well, the bottom line is that the tweak you're doing is actually potentially reducing lag if your monitor is doing internal scan velocity conversion -- but the savings is so tiny in your case, that it is not worth it.

If you're not strobing, and want to use large-VT for lag savings -- then it really takes large ratios of changes (e.g. VT1125 -> VT2000 -> VT3000 -> VT4000 -> VT4500) to see noticeable multi-millisecond improvements in input lag from Large Vertical Total tricks.

The biggest QFT (Quick Frame Transport) acceleration I've ever seen ever achieved was a whopping ~12.5ms lag reduction on 240Hz FreeSync monitors via a custom 60Hz ultralarge-VT signal. Most of the time, lag savings are <1ms due to inflexibility of the monitor tolerating a Large VT. But the potential is there (via ultralarge VT tricks) to save many milliseconds via hacks that forces faster cable delivery of individual refresh cycles.

I also consequently discovered that Large VT is a good way to fix 60Hz lag on 240Hz monitors too (unfortunately on PCs only, as XBox/PlayStations can't support Large VT).

Be noted that FreeSync monitors are usually better for Large VT tricks because FreeSync, is simply, a dynamic-sized VT, and so the panels are more naturally tolerant of Large VT tricks. Though a few models of forgiving GSYNC monitors (aka the overclockable GSYNC panels are sometimes large-VT-tolerant) but the ratios are very small at high Hz, it usually saves much more lag for lower-Hz modes due to more Pixel Clock headroom.

This needs to be implemented by vendors (GPU makers, operating systems, and displays) into easy pushbutton standardization.

The brand new specification "HDMI Quick Frame Transport" automates all this complex stuff I'm writing about in this thread into something easy/invisible to the end-user.

But for now, we are stuck with Custom Resolution Utility stuff + RTSS Scan Line capping feature -- in order to simulate Quick Frame Transport (over any cable, including DisplayPort) today on a PC. To create a faster-scanout signal GPU-side via a Large Vertical Total to deliver refresh cycles faster (at unchanged Hertz) to the monitor..

But that's what BlurBusters DIY hacking is for. :D
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4932
Joined: 05 Dec 2013, 15:44


Return to Area 51: Display Science, Research & Engineering

Who is online

Users browsing this forum: No registered users and 0 guests