VRR in conjunction V-sync

[Stizzie]

Can someone clarify how they interact when both are enabled? To my understanding, V-sync waits for the VBLANK signal to swap buffers. VBLANK signals are straightforward with a fixed refresh rate, as they occur at set intervals (33.3ms, 16.6ms respective to 30hz 60hz,...) However, I'm curious about how variable refresh rate communicates the VBLANK signal from the GPU.

I've learned from Chief's post over here:

TL;DR for software developers, Direct3D Present() and OpenGL glutSwapBuffers() begins delivering the refresh cycle practically immediately, as long as your API-call interval is within VRR range, e.g. An interval 1/30sec thru 1/144sec for a "30Hz-144Hz" VRR display -- means the display refresh cycle, is indeed software-triggered by your API timing! Yep, you, my dear software developer, are the master of the refresh cycle on a FreeSync/GSYNC display!

So the API's present or swap buffers calls are controlling the starting of a new scanout in VRR, not a fixed interval I'm I correct ? Well in the case of VSYNC ON those present calls actually wait for the VBLANK signal to execute, which doesn't exist since vrr is just extending the VBI and wait for a present call to start a new scan out.
It just make more sense with VSYNC OFF, in which case the API can just present whenever a frame is finished drawing and control the scan out. Of course that will lead to tearing if outputed frame rate exceeds max refresh rate; a frame limiter would ensure that doesn't happend to prevent tearing.

[jorimt]

Short answer is with VRR on + V-SYNC option off, there is no longer a strict adherence to the VBLANK signal, which means VRR can still tear within its range in instances where frametime performance is unstable enough.

VRR on + V-SYNC option on fixes this.

In other words, the V-SYNC option does not actually = V-SYNC with VRR + V-SYNC option + framerate within the refresh rate, and is a necessary component for tear-free VRR operation.

As for that Fallout 4 mod documentation, I can't speak to its validity. May be engine and/or mod-specific, or referencing something else entirely.

What I can say is, the VRR + V-SYNC option on/off topic has been brought up so frequently that I created an entry dedicated specifically to it in my Closing FAQ several years back. See entry #2:
https://blurbusters.com/gsync/gsync101- ... ttings/15/

[Stizzie]

I will quote Chief from some posts and found him covering this topic. Hopefully having a brief reply from him too

Blur Busters Custom Resolution (CRU) Glossary 101 / FAQ
Vertical Sync: Also known as VSYNC or Vertical Blanking or VBI. There are hidden synchronization pixels beyond top edge and after bottom edge (e.g. like 1st week and 5th week). The purpose is to signal a display to begin the next refresh cycle. Videogames use "VSYNC ON" / "VSYNC OFF" to tell the game whether or not to synchronize frames with the refresh cycles of the display, for better smoothness. Sometimes when saying VSYNC, it excludes the padding/overscan (Vertical Back Porch and Vertical Front Porch), but often VBI and VSYNC is used interchangeably for most signals because the porches usually are tiny.
Vertical Blanking Interval -- Known as VBI. The entire interval between refresh cycles. The sum of (Vertical Back Porch + Vertical Sync + Vertical Front Porch)

Chief's take on how Freesync works

Between refresh cycles, the monitor is essentially looping inside VBI. It's continually outputting new dummy VBI scanlines (Back Porch, for you video signal geeks) until Present() or glutSwapBuffers() at which point the next scanline output of the GPU output is the beginning of the new refresh cycle. There may be a granularity associated with it (potentially 1ms) but there doesn't have to be a granularity, at least when operating within the VRR range.

So your API call controls the beginnings of new refresh cycles. It's asynchronous refreshing.

I fully understand what he explained.
With fixed refresh rate V-sync ON, applications essentially sync its present or swap buffer calls to the VBLANK signal, which come in a set intervals (every 33.3ms 16.6ms ,..relative to 30hz 60hz refresh rate). That is great ! If syncing its what I want I want to sync to something comes in set intervals, like dancing to a music beat with a constant BPM.

My inquiry deprives from how Freesync handle VBLANK signals. Essentially from what I learned from Chief's quoted post, Freesync extend its VBI by adding dummy Back porch scanline and wait for present or swap buffer calls to start a new scanout. Well now the music beat is trying to sync to my dancing instead of me trying the opposite.

So its either me listening to a music beat and match my moves with the BPM ( Vsync ON ) or just freestyle and the beat have to adapt its BPM to my moves ( VRR ). Having both Vsync ON and VRR its like trying to dance to a beat that also trying to dance to you it sounds pretty funny to put it like that.

I'm not trying to troubleshoot anything since Vsync On and Freesync have been properly working in tandem for me ever since. I'm just curious how that is the case. I would assume Freesync actually communicate VBLANK signal in its VBI loop otherwise the mentioned dancer and music theorem will occur

[Stizzie]

Short answer is with VRR on + V-SYNC option off, there is no longer a strict adherence to the VBLANK signal, which means VRR can still tear within its range in instances where frametime performance is unstable enough.

VRR on + V-SYNC option on fixes this.

In other words, the V-SYNC option does not actually = V-SYNC with VRR + V-SYNC option + framerate within the refresh rate, and is a necessary component for tear-free VRR operation.

Right. To add to that, the higher the refresh rate, the less likely a tear would occur in VRR + Vsync OFF correct ? It makes much sense to me cause the faster a scanout takes place the less chance for a frame time variant to slip in mid-scanout. I have a 180hz panel and I have not yet seen tearing with VRR + Vsync OFF even in the most chaotic of frame times; frames are capped of course.

In case of GSYNC and VSYNC, this I quote from your coverage:

G-SYNC + V-SYNC “On” (what I call “frametime compensation” in this article) allows the module (with average framerates within the G-SYNC range) to time delivery of the affected frames to the start of the next scanout cycle, which lets the previous frame finish in the existing cycle, and thus prevents tearing in all instances.

And since G-SYNC + V-SYNC “On” only holds onto the affected frames for whatever time it takes the previous frame to complete its display, virtually no input lag is added; the only input lag advantage G-SYNC + V-SYNC “Off” has over G-SYNC + V-SYNC “On” is literally the tearing seen, nothing more.

The module is a factor, so I'm unable to test this behavior because I use Freesync and its software solutions rather than a dedicated module. Does it require driver VSYNC? Since the implementation of VSYNC in games is highly inconsistent, I've encountered some old DX9 games where the Vsync option is just a frame rate limiter and it disregards VBLANKs entirely.

[jorimt]

To add to that, the higher the refresh rate, the less likely a tear would occur in VRR + Vsync OFF correct ? It makes much sense to me cause the faster a scanout takes place the less chance for a frame time variant to slip in mid-scanout. I have a 180hz panel and I have not yet seen tearing with VRR + Vsync OFF even in the most chaotic of frame times; frames are capped of course.

Correct.

As explained here, the higher the physical refresh rate, the less time there is for tearing to occur with or without VRR:
https://blurbusters.com/gsync/gsync101- ... ettings/6/

The module is a factor, so I'm unable to test this behavior because I use Freesync and its software solutions rather than a dedicated module.

Replace the "module" with "driver" in this case. Same behavior with or without module, minor possible differences in tolerance notwithstanding.

Does it require driver VSYNC? Since the implementation of VSYNC in games is highly inconsistent, I've encountered some old DX9 games where the Vsync option is just a frame rate limiter and it disregards VBLANKs entirely.

Not necessarily, but as you say, game-side V-SYNC options can be hit-or-miss, so it varies by game. I've found 99% of the time NVCP V-SYNC and in-game V-SYNC options have the same effect when paired with G-SYNC, but there can be exceptions.

That said, with FreeSync, I've heard AMD CP V-SYNC doesn't apply to most games, in which case you need to resort to in-game V-SYNC options anyway, but that could have changed since (I don't use AMD).

[Chief Blur Buster]

Remember that we have two sync technologies involved.

VRR is the primary sync technology active, if frame rates are within VRR range.

When framerates try to exceed VRR range, it has to use a fallback backup sync technology (either VSYNC ON or VSYNC OFF).

Metaphorically, to reuse your music analogy, VRR is like the music being able to beat to your dancing, but if you dance too fast, the beating goes out of sync. And then music will only beat at maximum frequency allowed until your dancing goes back into sync, then synchronization roles are reversed again.

So VRR+VSYNC ON means excess frame rate (beyond VRR range) creates have laggy framerate=Hz, and VRR+VSYNC OFF means excess framerate (beyond VRR range) creates tearing artifacts. The synchronization roles changes whether you're inside VRR range or not.

Hope that makes this easier to understand!

Please note that sometimes games can have wonky behaviours (e.g. mouseturn wonkiness) when their software isn't expecting framebuffer backpressure (nonexistent during VRR range, suddenly existant during VRR+VSYNC ON) during framerates trying to exceed maxHz). However, this is usually not a problem, and it is recommended to use the VSYNC OFF setting in game engines (better for variable refresh rate syncing to variable frame rate), while you configure VSYNC ON/OFF in the drivers.

If you never want to see the backup sync technology activate, purchase a VRR display with a refresh rate range bigger than your frame rate range. 480Hz+ can be great, if you're going to use that approach. No caps, no fallback sync technology, just framerates breathing completely inside VRR range. VRR+VSYNC might as well as be defacto VRR-only if framerates never hit MaxHz. It sidesteps this question completely.

[Chief Blur Buster]

which means VRR can still tear within its range in instances where frametime performance is unstable enough.

Disambiguation Required: This can turn the same statement simultaneously true/false, depending on who is reading.

There are infinite ways to compute frame rates (averaging, median, instantaneous, and how big a trailbehind window to average/median on). Different people make different assumptions, so I add this detail for those readers who might pounce on this technicality.

During 300 frames per second, there's potentially 300 different instantaneous frame rates involved (1/frametime = instantaneous framerate for specific frame).

It is true that average frame rate (over many frametimes), you can still have tearing at average frame rates below VRR range, since instantaneous frame rates (aka 1/frametime for a specific frame) can exceed VRR range. Like you may have 142fps, but is actually a variable 137-147fps. In that case, you still have a few instantaneous 144-147fps frames that exceed VRR range of 144Hz.

Also, frametime can be further jittered by GPU overheads and other factors beyond the application software, so a frametime a game thinks is within VRR range, may momentarily exit VRR range (frametimes that are faster than 1/maxHz) when including driver and GPU overheads. That error margin is generally under a millisecond or so, but can sometimes spike to multiple milliseconds during power-management situations.

[Luviaz]

Fastinating how these stuff work !
Chief, where exactly is the Vblank signal in the Vertical blanking interval ? Is it sanwiched between the 2 porch or is it at the very end of the back porch ?
Does VRR manipulate the vblank signal in its operation ?

This is what I suppose happends in a VSync on VRR operation:

Vblank is communicated at max set Refresh rate. Suppose every 16.6ms at 60hz.

A frame takes 16.7ms, it misses the vblank and wait for the next which is 16.5ms away. How can VRR can detect that a frame has miss a vblank and extend the VBI for it exactly ?

[Chief Blur Buster]

Fastinating how these stuff work !
Chief, where exactly is the Vblank signal in the Vertical blanking interval ? Is it sanwiched between the 2 porch or is it at the very end of the back porch ?
Does VRR manipulate the vblank signal in its operation ?

This is what I suppose happends in a VSync on VRR operation:

Yes.

The GPU is outputting pixel rows at a perfectly fixed rate (the horizontal scan rate, or horizontal refresh rate). A 1080p signal (with a 45 pixel row VBI for a total of 1125 pixel rows per 1080p refresh cycle) has a scan rate of 1125x60 = 67 kilohertz.

Now VRR doesn't vary the scan rate. So the GPU just adds additional scanlines to the end of the VBI until the frame is presented. Varying-size blanking intervals is how VRR refresh cycles are temporally separated. This is true for all VRR techonologies including FreeSync, VESA Adaptive Sync, HDMI VRR, and G-SYNC (although G-SYNC had some proprietary extensions).

Here's the structure of a video signal, imagine an extended virtual resolution (overscan) beyond the visible desktop:


From this old thread: viewtopic.php?t=8889#p69658

Since the next refresh cycle is immediately after, VBI (Vertical Blanking Interval) is a contiguous sequence of [Vertical Front Porch + Vertical Sync + Vertical Back Porch]. VBI is the spacer temporally spacing apart refresh cycles.

(Did you know? For 1080p with 45 scan lines in VBI (total of porches and sync), that's a Vertical Total of 1125 pixel rows per refresh cycle. So 1080/1125ths of a refresh cycle is spent scanning out, and 45/1125ths of a refresh cycle is spent idling. This was formerly done in the analog days to allow the CRT electron beam to return to the top, but today it's just a defacto guard delay between refresh cycles (to give displays time to initialize a new refresh cycle). It's temporally identical between analog and digital eras, which is why a passive adaptor can successfully convert 1080i between analog and digital back in the early HDTV days. In fact, today's modern 1080p 60Hz can still display the picture from a 1985 Japanese MUSE HD videotape recording since it was 1125 scanlines interlaced (and most 1080p displays still can display 1080i visible of a 1125i signal) -- when piped through such an adaptor. It's still the same standardized temporal timings, across both the analog to digital domain.)

It will be the Vertical Back Porch that is dynamic, all VRR technologies use a varying Vertical Back Porch, since that's at the end of the the overscan above the top edge of the screen. It's most convenient for VRR to be a simple bolt-on to classical display refreshing, if we're inserting a variable number of extra Vertical Back Porch rows dynamically right above the first visible scan line (topmost pixel row of visible frame).



In other words, when a game presents a frame, the GPU will begin immediately outputting the first pixel row of a new refresh cycle instead of continuing to output Vertical Back Porch pixel rows (in a looping fashion at the current horizontal scan rate). As long as this is done within the VRR range, the display will begin to refresh immediately right on the spot.

So yes, the display has defacto sync'd to the software, because when the software presents the frame, the frame is the new refresh cycle, as long as the frametime is in the VRR range (e.g. 1/144sec thru 1/48sec, for a 48-144Hz VRR display). Frametimes longer than min Hz will cause the drivers or display to independently refresh the previous refresh cycle (LFC aka Low Framerate Compensation), and frametimes briefer than max Hz will automatically switch to the fallback sync technology.

How can VRR can detect that a frame has miss a vblank and extend the VBI for it exactly ?

There's no such thing, so the question is non-sequitur.

VRR intentionally keeps the GPU in permanent vblank as long as frametime is still within VRR range. Vertical Back Porch is a subset of vblank. Therefore, there's no such concept of "missing the vblank" when the frametime (instantaneous framerate) is perfectly within VRR range.

Let's take a 144 Hz VRR display as an example, with a 48-144Hz VRR range.

It will generally take exactly 1/144sec to scanout a refresh cycle (plus minimum-size vblank, which only occurs at maxHz of VRR range). Then the display is idling (at least until minHz, aka 1/48sec later from the start of previous refresh cycle). As the GPU is looping on extending the vblank by looping on outputting Vertical Back Porch scanlines. It will only exit the vblank the instant the software Present()'s a new frame and the GPU begins outputting the first pixel row of the frame.

The beauty of this, is when frametimes are completely inside VRR range, there's no such concept of "missing the vblank". Because the display is guaranteed to be in vblank (because the GPU is looping on Vertical Back Porch scanlines) when a game presents a new frame, as long as it is presented [1/144sec...1/48sec] after the prevent frame presented.

During 300fps operation on 360Hz display, you can have 300 different unique refresh rates (instantaneous frametimes = refreshtimes) per second. Amazing, isn't it?

[Stizzie]

The GPU is outputting pixel rows at a perfectly fixed rate (the horizontal scan rate, or horizontal refresh rate). A 1080p signal (with a 45 pixel row VBI for a total of 1125 pixel rows per 1080p refresh cycle) has a scan rate of 1125x60 = 67 kilohertz.
During 300fps operation on 360Hz display, you can have 300 different unique refresh rates (instantaneous frametimes = refreshtimes) per second. Amazing, isn't it?

Such neat magical trickery.

The GPU in permanent vblank as long as frametime is still within VRR range. Vertical Back Porch is a subset of vblank. Therefore, there's no such concept of "missing the vblank" when the frametime (instantaneous framerate) is perfectly within VRR range.

This is the clarification I need.
I've always assumed that the Vsync signal in the middle is the VBLANK that APIs try to wait for in "wait for VBLANK", and the 2 porches act as sort of a timing padding (similar to a delay for hotkeys, if a hotkey is send to window in real time, often time it will not get registered). To reiterate Chief: the whole VBI ( Front porch + vsync + back porch ) is read from the perspective of the API as VBLANK; meaning at any point of time as long as the current pixel signal falls in the VBI then it is considered VBLANK and the API can flip if it's V-synced.