Blur Busters Forums

Will fast frame escape from large VBI running on V-SYNC OFF?

KKNDT wrote:Will fast frame escape from large VBI running on V-SYNC OFF?

If you mean if a VSYNC OFF frameslice (partial frame between two tearlines) is completely hidden by a large VBI (Vertical Blanking Interval) -- then yes it can happen.

If there's a "frame time" that's less than "VBI-time", and that the first tearline aligns just off the bottom edge of the screen -- then yes, a frameslice is hidden by VBI. (Metaphorically, frame rates high enough -- where there are times that two (or more) tearlines inside the same VBI -- means at least one frameslice is hidden between refresh cycles).

Then, correct, that frameslice never shows up anywhere on the screen.

This phenomenon mainly only occurs if you're running ultra-high frame rates (like 1000fps combined with intentionally-large VBI). Even at 60Hz, most VBI is only ~0.5ms so you'd need 0.5ms frametimes (2000fps) to successfully occasionally hide a few frameslices per second (by random chance). What's more important is that pixel visiblity of the active surface of the screen is time-proportional to gametime, so if you have a finite VBI, you actually *want* to throw away frameslices whenever the display is not refreshing (aka display pausing between refresh cycles: the VBI = vertical blanking interval = an interval between refresh cycles). That keeps pixel time proportional to game time -- you only want to refresh on the fly. Even at 2000fps, you may only have 5 or 10 out of 2000 frameslices per second hidden by VBI by chance, since many frameslices will overlap the VBI rather than align completely inside VBI (two framebuffer flips occurs during VBI).

Bottom line, it doesn't matter in the real world, since it doesn't hurt the "VSYNC OFF" feel.

____

More detailed answer about why it doesn't matter:
If you're essentially spraying tons of framerate -- then your frameslices are so tiny and huge in numbers. Like playing Quake at 1000fps+ on a modern machine. You're usually only staring at the center of the screen, not the frameslices near the top/bottom of the screen, so any frameslices adjacent to the topmost/bottommost frameslices, are the least important frameslices for your gameplay. As you already know, you target your enemies using your crosshairs -- your crosshairs is comfortably in your screen centre. Metaphorically, the hidden frameslice is below bottom edge of screen (of last refresh cycle) and above top edge of screen (of next refresh cycle). So that missed frameslice is not missed -- it's beyond the screen rectangle for that particular frametime instant, so nothing needs to be shown. Even for professional eSports players. One indeed may need to react to enemies at top/bottom edge of screen using peripheral vision, but most enemies are near the middle row of your screen. And if you wanted to see more above/below of your screen edges, you'd get a bigger screen (or sit closer) and increase your FOV. But most don't do that to play Quake. Metaphorically, whatever happened above/below your screen is pretty much immaterial if you like your screen size already. So that hidden frameslice (Caused by super high framerates with frametimes shorter than VBI time) is a lot more unimportant than you would expect.... and if you're successfully achieving 1000fps, you're probably already getting amazing mousefeel and things are silky already!

Question:

What are you currently using Large Vertical Totals for?
Large Vertical totals is mainly useful for two things at the moment:

(A) Improving the quality of display motion blur reduction modes.
reducing strobe crosstalk, mainly on non-NVIDIA strobed displays. Basically reducing those double-image artifacts seen during strobe-backlight modes. This often requires CRU tweaking. ULMB/LightBoost does this automatically (within monitor -- accelerated scanout and longer VBI) so no manual large VT tweaking needed for NVIDIA strobe backlight technologies.

(B) Or reducing input lag of VSYNC ON
-- Large Vertical Totals (correctly adjusted with correct porch settings) behaves similarly to HDMI 2.1's "Quick Frame Delivery" protocol. Double your dotclock will allow you to deliver the refresh cycles twice as fast, if you're synchronizing to VSYNC.
-- Variable refresh rates automatically varies the vertical totals to change the refresh rate on the fly. This is also why input-lag is extremely low at all frame rates -- e.g. 60fps on a 240Hz VRR display -- the refresh cycle is delivered in 1/240sec, even for lower Hz during VRR, if the max Hz of the VRR range is currently set 240Hz. VRR varies the size of the Vertical Total in realtime to change the refresh rate; and lower refresh rates (Frame rates) essentially have a large VBI / large Vertical Total -- this post explains further. This does not require CRU tweaking

Currently, Large Vertical Totals are not useful for non-strobed VSYNC OFF modes.

I was adjusting the VT to 2000+ and running at 120HZ while turning on strobe mode on my XL2540 to eliminate strobe crosstalk.
To my understanding, if I set VT to such high level, I may lose almost half of the frameslices/information with VSYNC OFF?

KKNDT wrote:I was adjusting the VT to 2000+ and running at 120HZ while turning on strobe mode on my XL2540 to eliminate strobe crosstalk.
To my understanding, if I set VT to such high level, I may lose almost half of the frameslices/information with VSYNC OFF?

Only if ultra-high framerates such as 1000fps, only for super-huge blanking intervals (VBI's as big as the active picture -- e.g. VT2000 for 1080p). Most of the time, the frameslices will overlap to the top edge or bottom edge, not fully fit inside the VBI.

But this is more than offset by lag reductions of strobing & motion clarity improvements of strobing. You also have less lag-graident effect due to less lag differential between panel scanout (in dark) and panel visibility (flash). Basically, less lag differences between the top edge and bottom edge during VSYNC OFF strobed operation. So the benefical effects does cancel-out the bad effects.

The grand total of information is the same (same number of pixels seen per second) because the important frameslices (near crosshairs) become bigger to compensate for those missing frame slices. That's because of the higher pixel clocks that Large Vertical Totals, so the vertical spacing between tearlines is bigger for the same frame rate at the same refresh rate, when using Large Vertical Totals with that refresh rates.

You're getting bigger-surface-area reduced-lag frameslices onscreen (at no additional latency cost) to compensate for those missing offscreen frameslices. You've got faster scanout during Large Vertical Total mode, so you get more pixels per frameslice for a given frametime and framerate. That compensates hugely for the missing frameslices hidden by VBI.

In other words, due to the higher pixel clock of large VT's, the screen displays MORE information from the now-bigger onscreen frame slices to compensate for the missing frame slices. So at the end of the day, you're seeing the same amount of information in a counter-balanced way. Same resolution at the same refresh rate, you're just seeing a different number pixels from each frame slices, but the mathematical total number of pixels seen per second is the same (for the same refresh rate).

Same grand total amount of information -- you're getting new information from larger visible low-lag frameslices, that cancels out the lost information from the other frame slices. In other words, you're getting an equal amount of information, on average.

You're still only getting refresh-rate granularity updates for a specific given pixel, regardless of sync mode, so the missing frameslices tend to have no effect on the majority of gaming (on average). That frameslice closest to focus (e.g. crosshairs) is certainly the most important frameslice, and you'll be glad to know you've gotten a bigger frameslices (at no extra latency cost!) that overlaps the crosshairs, and any visible parts of screen, to make up for that lost frame slice hidden offscreen.

For a 144 Hz 1080p gaming monitor -- mathematically it's (1920x1080) x (144) = you're seeing 144Hz worth of 1920x1080 resolution, no matter what Vertical Total you use and how the frameslices essentially jigsaw-puzzle together, and the panel scanout latency of a frameslices is (1/framerate) second latency differential between top edge and bottom edge of a frameslice. So a bigger frameslice at the same framerate (e.g. 1000fps VSYNC OFF), without extra latency, nor latency gradients, is a bonus at where you're staring onscreen (e.g. say, a ball, a crosshairs, an enemy, etc) fully compensating for the missing frameslices that's far away from your screen focus anyway (action occuring just below bottom of screen, or action occuring just above top edge of screen anyway). So -- do you understand how things generally cancel out now?

Also, if you're using strobed operation, you're accepting strobed lag already (Sometimes strobed has competitive advantages outweigh strobed lag, for certain kinds of game tactics), which is a bigger factor than the stuff in this thread...

In real-world practical applications, this is a molehill thread compared to the mountain that is the strobe-lag discussion. Overall Lag tends to be the a bigger eSports question.

(This topic matter is indeed a good scientific question though, of curiousity -- but...)

Frames that are too short are known as "runt frames". You can research that.

In short, due to various factors (including driver hiccups), a frame can be so short (just a few scanlines) as to be practically considered non-visible.

RealNC wrote:Frames that are too short are known as "runt frames". You can research that.

In short, due to various factors (including driver hiccups), a frame can be so short (just a few scanlines) as to be practically considered non-visible.

Yes, that's usually the kind of tiny frameslices that gets easily hidden by VBI -- at least for normal-sized Vertical Total situations.

Although, if you successfully run at around 10,000 frames per second (e.g. very simple solid polygon graphics -- your "Hello World" 3D program -- like a spinning cube on a GTX 1080 Ti) -- then every single frameslice on your screen is a runt frame.

At 60Hz, that's over one hundred tearlines per refresh cycle on your screen, too -- albiet all at extremely tiny offsets.

Number of tearlines per refresh cycle is (framerate / refreshrate) except for those specific tearlines hidden by VBI. So, you see, the bigger the Vertical Total in CRU, the more tearlines get hidden by VBI but the onscreen tearlines fall in number (aka bigger frameslices during Large Vertical Totals). The runt frameslices become less runty.