Does having 60FPS using VRR have lower input lag than 60hz? Confused*

[nursejoy]

So I read a while ago by one of the admins here that running 60FPS while having VRR on at the maximum refresh rate is much lower than running regular 60hz. What confuses me is when I would look at input lag tests from rtings for example the AW2521HF they would have results listed like this:

Native Resolution
2.7 ms
Native Resolution @ 60Hz
9.7 ms
Variable Refresh Rate
3.1 ms
Variable Refresh Rate @ 60Hz
12.7 ms

according to them the input lag for "Variable Refresh Rate" is when its "lowest input lag possible at the center of the screen, when the monitor is using its Variable Refresh Rate feature at its native resolution and max refresh rate."

What confuses me is that if I play a 60FPS game wouldn't it just bring my refresh rate down to 60hz and I would have the highest input lag i.e 12.7ms instead of the lower input lag 3.1ms because now its Variable Refresh rate @ 60hz?

[jorimt]

What confuses me is that if I play a 60FPS game wouldn't it just bring my refresh rate down to 60hz and I would have the highest input lag i.e 12.7ms instead of the lower input lag 3.1ms because now its Variable Refresh rate @ 60hz?

Assuming RTINGS is testing and describing this correctly, If you have your max physical refresh rate set to 240Hz, you would get their reported 3.1ms input lag in VRR mode. If however you set your max physical refresh rate to 60Hz, you would get their reported 12.7ms of input lag in VRR mode.

The currently set physical refresh rate dictates how fast frames will scan in, not the framerate. In other words, 60 FPS VRR at 240Hz will always have lower input lag than 60 FPS VRR at 60Hz, as the physical scanout speed of the panel is increased regardless of current framerate.

I agree the way RTINGs describes these results can be confusing.

[nursejoy]

What confuses me is that if I play a 60FPS game wouldn't it just bring my refresh rate down to 60hz and I would have the highest input lag i.e 12.7ms instead of the lower input lag 3.1ms because now its Variable Refresh rate @ 60hz?

Assuming RTINGS is testing and describing this correctly, If you have your max physical refresh rate set to 240Hz, you would get their reported 3.1ms input lag in VRR mode. If however you set your max physical refresh rate to 60Hz, you would get their reported 12.7ms of input lag in VRR mode.

The currently set physical refresh rate dictates how fast frames will scan in, not the framerate. In other words, 60 FPS VRR at 240Hz will always have lower input lag than 60 FPS VRR at 60Hz, as the physical scanout speed of the panel is increased regardless of current framerate.

I agree the way RTINGs describes these results can be confusing.

Ohh I understand now; thank you. I had a feeling it was like this but I wanted to be sure. And now I understand its about how fast the frames will scan in. I always thought it was framerate to hz.

[jorimt]

I always thought it was framerate to hz.

Right. It's a bit of a misnomer when they say VRR changes the "refresh rate." What VRR actually does to adjust the refresh rate is to change how many times the scanout cycle repeats per second, whereas the max physical refresh rate dictates how fast each of those cycles complete before repeating.

So...

- Physical refresh rate = the value you set in the Nvidia/AMD CP (or Windows display settings): 60Hz, 80Hz, 100Hz, 120Hz, 144Hz, 240Hz, etc. The higher it is set, the more quickly each individual scanout cycle completes before repeating.
- VRR = how many times the scanout cycle repeats in a second based on current framerate; 60 times at 60 FPS, 45 times at 45 FPS, 157 times at 157 FPS, and so on (assuming the given framerate is within the current physical refresh rate, of course)

[diakou]

I always thought it was framerate to hz.

Right. It's a bit of a misnomer when they say VRR changes the "refresh rate." What VRR actually does to adjust the refresh rate is to change how many times the scanout cycle repeats per second, whereas the max physical refresh rate dictates how fast each of those cycles complete before repeating.

So...

- Physical refresh rate = the value you set in the Nvidia/AMD CP (or Windows display settings): 60Hz, 80Hz, 100Hz, 120Hz, 144Hz, 240Hz, etc. The higher it is set, the more quickly each individual scanout cycle completes before repeating.
- VRR = how many times the scanout cycle repeats in a second based on current framerate; 60 times at 60 FPS, 45 times at 45 FPS, 157 times at 157 FPS, and so on (assuming the given framerate is within the current physical refresh rate, of course)

I can chime in on this; for the vg279qm


When playing melee (a 60fps game on emulator) it does NOT feel like the 60hz numbers displayed here when running freesync/g-sync compatible @ 240hz. It feels marginally better with g-sync on @ 240hz than v-sync off @ 240hz for this 60fps game. Many weird factors mentioned in 4+ threads over here. @chiefblurbusters usually has chimed in with very insightful comments regarding it in the past. I assume RTINGS just writes their results weirdly, I've had this issue with them in the past for their other explanations regarding "native" resolution. It's annoying methodology at times.

Also - to Jorimt, regarding your explanation, how does 240hz, 360hz VRR affect the scanout cycle? Wouldn't that theoretically mean that Hz does not matter at all if the given games FPS is 60? A 120hz g-sync (given that response times and signal processing is equal) would behave exactly equal to a 360hz in terms of lag/smoothness/framepacing?

edit: just misread, my brain is mush, missed the

"- Physical refresh rate = the value you set in the Nvidia/AMD CP (or Windows display settings): 60Hz, 80Hz, 100Hz, 120Hz, 144Hz, 240Hz, etc. The higher it is set, the more quickly each individual scanout cycle completes before repeating."

I already knew this, just confused myself hah. Ignore!

[Chief Blur Buster]

Right. It's a bit of a misnomer when they say VRR changes the "refresh rate."

I object to popularizing this phraseology because it makes it harder for Blur Busters to spread educational word... So let's nip this in the bud before this misterminology starts to spread. Mythbusting is harder otherwise, given the fake-news culture these days.

1. It's not a misnomer.

2. The correct phrasing is:

"The refresh rate (frequency of scanouts) is not the same thing as refresh interval (duration of scanouts)"

Quick Frame Transport can also allow shorter refresh intervals (fast scanouts) without a higher refresh rate. Quick Frame Transport is like a fixed-Hz version of VRR. For those unfamiliar with Quick Frame Transport, please read Quick Frame Transport Thread, including the most recent post to it.

For example, on an oscilloscope, a Quick Frame Transport signal at a 2x scanout acceleration factor (example Vertical Total 2250 for a normally-VT1125 1080p signal) fixed-Hz 120Hz signal, is identical to 120fps@240Hz VRR. It's exactly identical on the pixel-by-pixel sequence transmitted out of a GPU output.

Framerate is indeed the Hz on VRR output, for frametimes that are within the VRR range's own possible refresh intervals. However, the refresh interval is always at max-Hz on a VRR signal.

The "rate" versus "interval" considerations aren't exclusive to VRR!

Hard scientific termnology true meaning really can't be fudged... Claiming it is not a "rate" is tantamount to 2 + 2 = 5.

There's no difference between "refresh rate" and "physical refresh rate". They're both rates.

Most of the time, refresh interval is (1/Refresh Rate). But rate-vs-interval equation diverges for these considerations:
(A) Large Vertical Totals
(B) Quick Frame Transport
(C) Variable Refresh Rate
(D) A few other cases

Where a refresh interval can be much quicker than a refresh rate (e.g. 120Hz refresh cycles transmitting over the cable in only 1/240sec, or displaying onto a panel in only 1/240sec).

[jorimt]

1. It's not a misnomer.

"It's a bit of a misnomer" that people assume VRR controls all aspects of the refresh "rate" when it actually only controls one. I stand by the original context (and phrasing) of my statement.

If VRR was able to manipulate both repetition and completion time of the scanout, it would have far more potential control, which may allow it to avoid things such as LFC mismatch, etc, as there would no longer be any fixed cycle time left to adhere to (which obviously is not the case).

[TTT]

What reason would somebody use 60hz with VRR instead of the full 240hz in the first place?

I have seen in many threads and posts people setting their high refresh screens lower because they can't reach the max fps of the screen though.

[jorimt]

What reason would somebody use 60hz with VRR instead of the full 240hz in the first place?

I have no idea (you should use an FPS limit + max refresh rate to control effective refresh "rate" with VRR instead), but in the case of RTINGS tests, it's potentially useful for determining both VRR and non-VRR display processing lag at 60Hz on certain consoles.

[Chief Blur Buster]

"It's a bit of a misnomer" that people assume VRR controls all aspects of the refresh "rate" when it actually only controls one. I stand by the original context (and phrasing) of my statement.

I prefer a rephrase it to be then clear about context that the word "misnomer" is applied to. It may seem a little to you, but it's a very big anathema to scientists/researchers when context is misapplied. Wink. (You know me by now, ha!)

"VRR having full control of all aspects of refreshing is a misnomer. VRR only changes the refresh rate, but not the refresh cycle's scanout interval." is actually more accurate than "misnomer" being applied to "rate".

If VRR was able to manipulate both repetition and completion time of the scanout

This actually would make stutters worse.
Consistent scanouts is required to keep gametime:photontime time-relativity consistent.

it would have far more potential control, which may allow it to avoid things such as LFC mismatch

While aspirational, this is not possible -- infinite speed zero lag scanout is required to avoid LFC mismatch -- which violates laws of physics, alas... I wish infinite-speed zero-lag global refresh occured. (All global refresh technologies has behind-the-scenes lag before a global refresh occurs).

LFC mismatch only exists because refreshing is a finite-time endeavour that can have a schedule-conflict with a video game suddenly unexpectedly ready to deliver a new refresh cycle (at an unexpected time to the LFC algorithm). Game's finished rendering a frame, now it's waiting for the monitor to finish refreshing its earlier repeat-refresh cycle.

Also, scanout velocity actually dictates the maximum Hz. The faster the scanout, the higher the max Hz becomes, and the manufacturer advertises the higher Hz capability. Limited velocity scanout is governed by laws of physics.

One must ask oneself; why have a faster scanout velocity and cap the max Hz? That would mean the monitor completely idle between refresh cycles. Monitor manufacturers don't have that much hidden hertzroom (that can be unlocked in a high-quality glitch-free manner at least).

For stutter-elimination, math dictates that a chosen fixed scanout velocity is used, for fixed gametime-to-photontime consistency (absolute minimum stutter). So in this specific situation, if you had to choose a fixed sweep velocity, it is always hugely favourable to choose the fastest, lowest-lag scanout, and naturally -- this is the case.

Maybe I need to create a large Blur Busters Article that explains the physics (showing some stutter math formulas). Y'all be warned.