Tech Focus: VRR Is Not A Magic Bullet - Why G-Sync/FreeSync Can't 'Fix' Performance

Variable refresh rate - as seen in G-Sync, FreeSync and console VRR - is one of the most transformative display technologies we've seen in gaming. Rather than limit a GPU's performance to the refresh rate of the screen, your hardware takes control instead, eliminating tearing and smoothing away variable frame-rates... except it's no magic bullet. VRR can only go so far - and it has no answer to egregious stuttering. Alex reveals all in a new Tech Focus.

0:00:00 Introduction
0:01:06 What are VRR's benefits?
0:07:20 What are VRR's limitations?
0:16:00 Why can't VRR fix game performance?
0:22:16 Conclusion

[CaptainLyoner]

18:51 "Judder Survivor" is good lmao

[Onikann]

Unfortunately, the video contains a few inaccuracies or things that are expressed in a misleading way.
Alex says that there is no frame holding with VRR. This is not quite true. With sample & hold displays and active VRR, a frame / image is kept active after the scanout until a new frame is supplied by the source.

With a 120Hz display, this means that the scan-out always takes ~8.3ms even with VRR active. The screen is put into a hold state after the scan-out phase. For example, if a source delivers a constant 60fps, the scan-out still takes 8.3ms, after which the screen waits 8.3ms for the next frame, then displays the next delivered frame in 8.3ms, then waits another 8.3ms, etc.

Technically speaking, with VRR the display still operates at 120Hz and there is no change to the scan-out duration (~8.3ms).
However, monitors cannot keep an image active indefinitely without a further scan-out, even modern screens like OLED monitors/TVs can't do that.

That's why Alex's description of LFC is not quite right either.
The lower VRR limit is defined by the maximum holding time of the monitor. For LG's 120Hz OLED TVs, for example, this is 25ms (40Hz).
This means that a new scan-out must take place after 25ms at the latest. And this is where LFC comes into play.
If the GPU cannot deliver a newly rendered image after 25ms, it simply delivers the previously delivered image again.

Hopefully it is clear from the above description that the scan-out for this repeated frame still only takes 8.3ms after which the GPU may deliver a next frame.
In other words the GPU may send a new frame after 25+8.3 = 33.3ms for a 120Hz display.
This means that the representation in the video at 13:15 is not quite correct. With LFC the GPU does not necessarily display 2 consecutive frames with a duration of 22.2ms if a game is currently being rendered at 45fps. In this scenario the GPU may send another frame after 30.5ms (22.2+8.3) and not 44.4ms (22.2+22.2) in case the next rendered image is available at an earlier time.

I deliberately said “necessarily” here because current LFC implementations are more than just simple multiple representations of already rendered fames. Instead, the GPU manufacturers try to keep the frame times as stable as possible in their drivers when LFC is active. I.e. they sometimes deliberately delay the delivery of a new frame in order to cushion excessive frame time fluctuations.

[AnimeUniverseDE]

VRR is best used with an arbitrary framerate cap, as you are no longer bound to V-Sync and fractions of your monitors' refresh rate

[alanamarko]

totally agree with getting rid of the "FPS graphs" altogether and instead focusing on smoothness and consistency, which is WAY more important than number going bigger.

[Wallguy]

FPS graphs are as important to me as frame time variance. I will always want both covered. One without the other is only part of the story and insufficient. So I am happy that DF has taken it upon themselves to raise the profile of FTV in the minds of the average viewer. Good work Alex. :)

[cubefox]

Small correction: Hz doubling with VRR+LFC does not increase persistence blur on sample-and-hold screens like LCD or OLED. This is because showing one frame for, say, 20 ms does not look different than showing a doubled frame for 10+10 ms. In the latter case the screen just overwrites one frame with another that looks exactly the same, which will not be visible at all. So persistence blur stays the same with LFC.

LFC frame doubling can be noticeable on pulsed displays like CRTs (or strobed LCD backlights or OLED with black frame insertion) though, since having one pulse per 20 ms looks different from having two pulses in 10+10 ms. The former could look somewhat flickery, the latter would lead to an double image effect in persistence blur cases.

[AVerySillySausage]

VRR on the PC side has gotten people to underestimate the value of a stable framerate. I try to never let my GPU run at 100%, I like using conservative frame caps that I can hit nearly 100% of the time so I never notice anymore performance changes. Consistent frame pacing just feels smoother and it's much better for immersion.

[macklin]

i really really appreciate these videos that just break down some aspect or Technical Thing™about video game performance. loved the one y'all did on anti-aliasing.

[tsorakin]

Alex is doing the lords work here. I've been hoping for discussions such as this for years now. The Rtings video opened the door for VRR flicker from OLED technology, and this video further emphasizes how inconsistent frametimes has been the culprit the entire time. I now have hope that more effective solutions will surface with the recent spread of awareness on these issues.

[tvguy]

Hi Alex, thank you for the video as always.

Just a note regarding the various display limitations when engaging VRR. The Sony X90J (used as an example here) and all Sony FALD TV using their XR processor have been updated to be able to use local dimming with VRR engaged. As per Rtings, with very minimal IQ degradation, but a ~4ms input lag increase at 60hz.

To my knowledge this is the only brand that offers that, otherwise you have to go OLED

[hadiabdul]

The RTings VRR Flicker test on OLED is not unrealistic at all. I've gotten even worse flicker playing Skyrim. its really bad. as it stands i leave it disabled all the time

[ymi_yugy]

The tech focus videos are my favorite by DF, thank you for making them.
One aspect I didn’t quite understand is how low frame rate compensation works and how the GPU adjusts display refresh rate.
Since frame times depend on the application the GPU doesn’t know the frame time ahead of time. So when a GPU sends a frame to the display it can’t “set” the frame rate since it doesn’t know when the next frame will come. So all the display can do is to display that frame until the next one comes. If that falls within the VRR range everything is fine, but what when it falls below it. Let’s say the frame is 24 ms long, but the lower bound of vrr is 22.2 ms (upper bound 8.3ms). Ideally it would display the frame twice each time for 12ms. But since it doesn’t know how long the frame time will be I assume it will display it for 22ms and then again for 8.3ms. Am I understanding LFC correctly or is there something else going on?

[Scrawlerism]

"judder survivor" is my favorite Freudian slip of the month, at least.

[TheErazar]

Have a VA monitor, and flickering is a real issue in darker games when FPS is even relatively unstable. A real bummer

[tomvandongen]

I'm officially charmed by the way Alex pronounces "obfuscates"

[JKHYT]

Preach! Frame times consistency is what should be the primary focus point for gamers! 1% and 0.1% lows are okay as general indicators but even better are frame time variance plots. These are much less common to see in hardware reviews but the 5800X3D review by Igor's Lab shows the kind of plots I'm talking about. It's great to see outlets like DF and GN pushing in this direction.

[Wipou]

VRR is not meant to "fix framerates" (in fact, by definition, it UNFIXES it) its simply meant to be the best way to display video with irregular frame times AND IS.

[filip]

Nothing can fix a game's performance other than its developers. That is one of the major reasons Nvidia has made all of these AI technologies, from upscaling to frame generation and even ray reconstruction; to bandaid growing problems with PC games. Have people forgotten the times when they needed 2 GPUs to run a *single* game? Even then the support for multi GPU setups was minimal or unimplemented (and the tech was wrought with micro stutters), but the point still stands that not enough resources are allocated to the Graphics Programmers to optimise the systems to an appreciable level, especially when the AAA side of the industry keeps on getting great sales with subpar PC and console performance.

I'm a Games student looking to get into graphics programming, so I always enjoy watching your videos guys. Thank you for your deep dives.

[superjoy]

As an arcadehead, VRR has been truly a godsend. So many games run in weird nonstandard refresh rates and it's been wonderful no longer dealing with that issue in Mame.
Same with RetroArch and any PAL 50hz game

[SpontaneousWeasel]

Thanks largely in part to this channel, I've become increasingly aware of these issues and how to best 'curb' them using vrr and frame capping as a tool. I'm not sure how others feel but the fps graphs feel like a comfort to watch on the df comparison videos - I think I'd miss them! But without doubt consistent frame times are ALWAYS better than a wildly variable one. I love how series x can just use LFC and VRR on any game.