Someone say this guys about "Large VT" [input lag reductions]

[DukeDice929]

Please tell me if I'm wrong, but AFAIK using lower resolution/refresh rate makes "pixel clock" and "VT" really low leading to increased input lag, especially on BenQ monitors (with older scaler). Currently I'm using XL2546 and tweaked all of my resolutions+custom refresh rates to match native VT/pixel clock (as much as possible) to gain better latency and Blur Reduction quality. https://ibb.co/tLvy3X3
As you can see on the video, guys just entered default values without tweaking VT and pixel clock values (750VT/297MHz).
Again, maybe I'm wrong and it makes no sense, but I can clearly see the difference on my BenQ.
https://www.youtube.com/watch?v=5HeSp0x ... .be&t=1812

[Chief Blur Buster]

<Advanced Thread>
This discussion thread is not for new users -- this is an advanced latency decision.

Large vertical totals can increase or decrease input lag depending on sync technology.

Useful Purposes of Custom Resolutions containing Large Vertical Totals

• Decrease strobe crosstalk
  (if using strobing, by allowing pixel transitions GtG to be hidden in VBI. Works with both VSYNC ON and VSYNC OFF)
  www.blurbusters.com/lightboost/video
  www.blurbusters.com/scanout
  www.blurbusters.com/crosstalk
  www.blurbusters.com/red-phosphor
  .
• Or Quick Frame Transport
  (applies to strobing and non-strobing VSYNC ON or any Fixed-Hz-syncing sync tech like RTSS Scanline Sync)
  forums.blurbusters.com/viewtopic.php?t=4064
  .
• Or both of the above
  (Hit two birds with one stone)

But you need to correctly use the right tool for the right job.

Default VSYNC ON usually flips at beginning of VBI (so large VBI is a long delay to next refresh cycle = adds input lag)

This default Windows behaviour needs to be overriden. You need RTSS Scanline Sync, combined with full screen exclusive mode, to create a tearingless VSYNC OFF mode (put the hidden tearline above edge of screen, near end of VBI). to inputdelay the pageflip to end of VBI to have lag-savings of Quick Frame Transport. It mainly benefits works with fps=Hz frame delivery (global frame delivery mechanism, so not VSYNC OFF). Useful for VSYNC ON or VR or RTSS Scanline Sync.

See Quick Frame Transport to understand the concept better. You can use the HOWTO in RTSS Scanline Sync to create a custom low-lag VSYNC ON mode that piggybacks on large vertical totals as a Quick Frame Transport mechansim.



TL;DR: Do not tweak large VT without understanding how to tweak large VT

Also you don't need Large Vertical totals with VRR. If you're already using G-SYNC or FreeSync, it's already doing the equivalent of large vertical totals via variable-size VBI to temporally space apart the dynamic refresh cycles.

(For computer programmers, the monitor is slaving to the software's frame presentation timing whenever the intervals between frame presentation is still within a VRR monitor's refresh rate range)



So G-SYNC and FreeSync are an easier form of large vertical totals.

However, if you have to use fixed-Hz because of a feature (such as strobing), you can use Large Vertical Totals + RTSS Scanline Sync as an equivalent of "Quick Frame Transport".

Please tell any confused YouTuber (asking about Large Vertical Totals) about this thread.

[DukeDice929]

Thanks for such a detailed response, Chief!
Your explanation about Large Vertical Totals is very useful and informative.

Yes, I was talking about less input lag as possible without any sync (240Hz) and with RTSS Scanline Sync + DyAc (custom res).
I gotta share a link to this thread.

[senny22]

Large vertical totals can increase or decrease input lag depending on sync technology.

How do you configure Vertical totals if there isn't any known value for your particular monitor? I own a XF252Qx that's 240hz and was wondering which value to use?

Also, is there any benefit of a Large VT whatsoever, if i would use 240hz non-strobing?

[Chief Blur Buster]

How do you configure Vertical totals if there isn't any known value for your particular monitor? I own a XF252Qx that's 240hz and was wondering which value to use?

Also, is there any benefit of a Large VT whatsoever, if i would use 240hz non-strobing?

Metaphorically, this is like a Grade 5 math class asking a Grade 9 math question -- which would require me to write 100 pages of reply -- so it will help to sequence this first, with some links to other articles. Hope I can cram this into just 2 pages!

First, study for a better understanding of Custom Resolution Utility.

The shape of a refresh cycle on a video cable (VGA, HDMI, DisplayPort) is actually bigger than the resolution of your screen. Hidden overscan beyond left edge, top edge, bottom edge, and right edges. Your video signal has a width equalling Horizontal Total, and your video signal has a height equalling Vertical Total.



VBI = Vertical Front Porch + Vertical Sync + Vertical Back Porch.
Vertical Total = Vertical Visible Resolution + VBI

-- Blur Busters Custom Resolution Utility Glossary
-- High Speed Videos of Scanout (read the bottom half)
-- Blur Busters Custom Resolution Utility Glossary

Click on the links first, and come back. Do you understand the above articles yet? Good. Now you understand better what those numbers in Custom Resolution Utility stands for.

Next, compare a 100Hz Auto Timings signal, versus a 100hz Large Vertical Total signal:



Now, to begin tweaking large VTs, you have to have an experimenter's gene. Some monitors will be inflexible (rejects large vertical totals) while other monitors will be flexible. FreeSync-compatible panels are easier/flexible because VRR is simply variable-sized vertical totals every single refresh cycle -- a dynamic vertical total (since VBI varies to temporally space apart refresh cycles).

Horizontal scan rate (in KHz) is always Vertical Total times Vertical Refresh Rate. So VT1125 times 60Hz is 1125x60 = 67500 pixel rows per second = 67.5 KHz scan rate = one pixel row is transmitted out of the GPU output in 1/67500sec.

Pixel Clock (dot clock) is always Vertical Total times Horizontal Total times Vertical Refresh Rate. That will be your cable's bandwidth. Your max bandwidth will be roughly equal to the Pixel Clock you got at maximum scan rate.

The rest is simply mathematics. Know enough high school math? Good.

So you can add to larger vertical totals. You can double your vertical total at half refresh rate, to maintain Pixel Clock. For example, VT1125 at 120Hz can become VT2250 at 60Hz, assuming your panel is VT-flexible (most FreeSync panels are capable of large VT in fixed-Hz operation). You can also calculate your scan rate at your highest refresh rate. Then divide by your target lower refresh rate, to get your largest vertical total you can get before violating your bandwidth budget.

Now some panels allow overclocked dotclocks, e.g. 1/280sec frame delivery at 240Hz. So you might have a larger dot clock budget available, permitting 60Hz refresh cycles to be transmitted over the cable in 1/280sec. But not all panels are horizontal-scanrate-multisync, some TCON/scalers are fixed horziontal scan rate, so whatever incoming cable scan rate is being scan-converted. Older BenQ monitors (144Hz 1080p) are horizontal scanrate multisync, but many 240Hz panels are fixed horizontal scanrate regardless of vertical totals you're providing.

The most useful use of Large Vertical Totals in input lag reductions is refilling the monitor's refresh cycle frame buffer quicker, so the monitor doesn't wait for the computer any further, before beginning to refresh. (This happens often with 60Hz on a 240Hz monitor -- the monitor is waiting for the computer to slow-scan a 1/60sec scanout -- before beginning a high-velocity 1/240sec scanout on the panel. Oftentimes, this can be fixed by doing Quick Frame Transport at the GPU level, by using a quadruple Vertical Total at one-quarter refresh rate, i.e. VT4500 at 60Hz for a monitor capable of VT1125 at 240Hz).

Your flexibility might not be this big, but an AdaptiveSync-compatible panel is very Vertical Total forgiving, which means it'll eat up almost any random Vertical Total. More overclockable monitors will usually be more forgiving too. Other panels will be uber-picky, stubbornly going black at any vertical total barely away from default (older G-SYNC panels were like that). But understanding the mathematics of Veritcal Total helps you understand how to begin experimenting with Large Vertical Totas.

If you have G-SYNC or FreeSync available, 90% of the time, I would not bother with Large Vertical Totals with varible refresh rate because VRR is an easier Quick Frame Transport. Frame-capped 60fps at 240fps VRR is the same input lag as Quick Frame Transport (4x scanout factor) 60Hz on a 240Hz panel, in theory. You have to do a ton more work doing Quick Frame Transport on fixed-Hz. VRR is already an automatic natural Quick Frame Transport, with its well known "60fps at 240Hz VRR feels much lower lag than 60fps on a 60Hz monitor" behaviors that is well loved by emulator users and 60fps game players -- some buy 240Hz monitors just to run it 60fps VRR (since those 60fps refreshes are refreshed in 1/240sec on all 240Hz VRR monitors).

Much easier than hacking a Quick Frame Transport on a fixed-Hz monitor. But, we have to, because most strobe backights are only available in non-VRR. Whenever you hear Large Vertical Total, it's usually used to reduce input lag of strobe backlights. (But it also reduces input lag of non-strobed VSYNC ON too!).

But the magic sauce of Quick Frame Transport is for strobe backlight modes, because most strobe backlights are...... fixed Hz. So all lag-reducing tricks are on the table (since we don't have the lag-reducing trick of G-SYNC and FreeSync as a VSYNC ON alternative).

...And that's where Quick Frame Transport becomes most useful (in reducing strobe backlight input lag) -- by allowing faster delivery of a refresh cycle, so the panel can be refreshed sooner, before the panel is flashed (made visible), reducing input lag from "Present()-to-strobe-flash".

Large Vertical Totals usually don't help VSYNC OFF (although it can helped strobed VSYNC OFF a little bit, because of the earlier flash). Non-strobed input lag is identical for VSYNC OFF non-QFT versus QFT, because the unsynchronized frame delivery all averages out. For a VT-double-visible-resolution, you may get half as much tearing though, because tearing will be hidden in the VBI half the time. (But if you're using non-strobed VSYNC OFF QFT at lower Hz, the pros mostly zero-out and the cons increase.... So you probably might as well use max-Hz anyway -- why are you reading this thread? Right Tool For The Right Job.... Non-strobed VSYNC OFF usually works best & feels best with max Hz).

Several VR headsets now use an internal quick frame transport techniques, because VR headsets require VSYNC ON for mandatory reasons.

That said, QFT + strobing is a match made in heaven (when combined with a modified VSYNC ON that uses end-of-VBI frame buffer swap instead of start-of-VBI frame buffer swap). And since Microsoft/NVIDIA/AMD hasn't provided that yet, we have to use RTSS Scanline Sync to create an end-of-VBI frame buffer swap that Microsoft/NVIDIA/AMD has not yet provided, in order to DIY our own Quick Frame Transport.

Have I succeeded in explaining the mathematics theory of Large Vertical Total tweaking-from-scratch?

[senny22]

Now some panels allow overclocked dotclocks, e.g. 1/280sec frame delivery at 240Hz. So you might have a larger dot clock budget available, permitting 60Hz refresh cycles to be transmitted over the cable in 1/280sec. But not all panels are horizontal-scanrate-multisync, some TCON/scalers are fixed horziontal scan rate, so whatever incoming cable scan rate is being scan-converted. Older BenQ monitors (144Hz 1080p) are horizontal scanrate multisync, but many 240Hz panels are fixed horizontal scanrate regardless of vertical totals you're providing.

The most useful use of Large Vertical Totals in input lag reductions is refilling the monitor's refresh cycle frame buffer quicker, so the monitor doesn't wait for the computer any further, before beginning to refresh. (This happens often with 60Hz on a 240Hz monitor -- the monitor is waiting for the computer to slow-scan a 1/60sec scanout -- before beginning a high-velocity 1/240sec scanout on the panel. Oftentimes, this can be fixed by doing Quick Frame Transport at the GPU level, by using a quadruple Vertical Total at one-quarter refresh rate, i.e. VT4500 at 60Hz for a monitor capable of VT1125 at 240Hz).

Your flexibility might not be this big, but an AdaptiveSync-compatible panel is very Vertical Total forgiving, which means it'll eat up almost any random Vertical Total. More overclockable monitors will usually be more forgiving too. Other panels will be uber-picky, stubbornly going black at any vertical total barely away from default (older G-SYNC panels were like that). But understanding the mathematics of Veritcal Total helps you understand how to begin experimenting with Large Vertical Totas.

When using a "overclocked" vertical timing, how can you tell if it's too high besides the screen becoming black? are there any artifacts to look out for or is everything good if there is an actual picture showing with the "overclocked" vertical timing total?

[Chief Blur Buster]

When using a "overclocked" vertical timing, how can you tell if it's too high besides the screen becoming black? are there any artifacts to look out for or is everything good if there is an actual picture showing with the "overclocked" vertical timing total?

Easy.

Horizontal Scanrate (also called “Horizontal refresh rate”, in number of pixel rows per second) or Pixel Clock becomes bigger than the number you saw in Custom Resolution the default max Hz.

A) Use the mathematics to determine if the numbers you used, is “overclocked” or not,
B) or simply load your default max Hz, write down the two numbers, and use those as “must not exceed” guidelines.

[senny22]

When using a "overclocked" vertical timing, how can you tell if it's too high besides the screen becoming black? are there any artifacts to look out for or is everything good if there is an actual picture showing with the "overclocked" vertical timing total?

Easy.

Horizontal Scanrate (also called “Horizontal refresh rate”, in number of pixel rows per second) or Pixel Clock becomes bigger than the number you saw in Custom Resolution the default max Hz.

A) Use the mathematics to determine if the numbers you used, is “overclocked” or not,
B) or simply load your default max Hz, write down the two numbers, and use those as “must not exceed” guidelines.

Ok thanks. The AMD control panel allows me to use a vertical timing total that gives me a higher pixel clock compared to standard 240hz (1692 vs standard which is around 1140) This is with a 1440x1080 resolution though.

Is it okay to use this higher "vertical total timing", even though it gives me a higher pixel clock compared to stock vertical timing total with 240hz?

[Chief Blur Buster]

Is it okay to use this higher "vertical total timing", even though it gives me a higher pixel clock compared to stock vertical timing total with 240hz?

The answer to that question is similar to "Is it okay to overclock?"?

That's a personal choice of yours. Sometimes it works and sometimes it doesn't.

[andrelip]

Chief, three questions:

1) In the past, I was able to achieve up to 480hz equivalent scanout speed in a lower resolution and 200hz. I also got 360hz equivalent at 240hz. Do you think that VRR will use this exceeding vertical value or will be limitted by the native max VBI?

2) I always believed that the scanout read the line in the front-buffer by streaming direct from the GPU(real-time). But when you talked about transmitting in 1/60 and then displayed at 1/240 you sounded like the monitor first have to receive the entire frame to it's own buffer before printing the most recent frame. What actually happens?

3) The first post talked about matching the timings with the native of the panel to reduce the input lag and provider better scaling. Is that a myth? If it's true why wouldn't the manufacturer flash the panel specification in the EDID?