Firmware Fixes To Fix for VRR Blank Out Issues (Monitors Randomly Going Black For 2 Seconds)

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
Post Reply
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Firmware Fixes To Fix for VRR Blank Out Issues (Monitors Randomly Going Black For 2 Seconds)

Post by Chief Blur Buster » 17 Oct 2021, 18:43

This does not affect all VRR panels, but there are too many situations where this happens:

"You're playing a game with highly fluctuating frame rates with VRR enabled. Then suddenly, screen goes off for 2 seconds. Once every few minutes. You get frustrated. You wonder what is happening and nothing seems to fix the problem."

How can we solve this for a bigger percentage of VRR setups?

Monitor Blanking Out When VRR Goes Below Min Hz Without LFC

Too many VRR monitors automatically goes blank randomly due to firmware issues or driver issues. This is both a hardware fault (monitor fault) AND also software fault (drivers, OS). Both sides need to mitigate situations where refresh rates become too low without LFC activating.

Some people use ToastyX to raise VRR Hz to 55Hz or 65Hz, to help solve this problem, but this is easier to do on Radeons than GeForces, since NVIDIA doesn't always respect the VRR Hz range in EDID.

There should be hidden VRR refresh rate headroom below min Hz. Both the hardware and software side needs to have built-in safety margins to prevent this from happening. But the hidden safety margin is sometimes being removed accidentally by many monitor firmwares by all the major Taiwanese vendors of big names.

VRR Range Safety Headroom

It’s a hidden feature only for situations where the graphics drivers fail to LFC for frametimes longer than 1/48sec. Basically a safety margin below the EDID-reported VRR range. This is what I recommend all manufacturers do. This would remain undocumented, and only be a fallback for buggy drivers.

Also, very rarely other software can also sometimes cause properly working drivers to occasionally fail LFC – e.g. a different driver running at realtime priority may starve the LFC code in the graphics driver. Or that the driver doesn’t run LFC at a sufficient realtime priority. So sometimes (rarer) the problem also happens with perfectly fine drivers. Refresh cycles on a VRR monitor is software-trigger by computer responsibility – including LFC events that need to happen when frametimes get too long – which is why sometimes we see these below-Hz LFC fails occasionally, from a lot of factors.

Once a panel adds unadvertised VRR Hz range below EDID-advertised VRR Hz range, then QA testing can be done by using ToastyX on an AMD card, and then range-editing down to something like 40Hz or 35Hz or 30Hz, testing it to make sure that low framerates are still functioning LFC-lessly (OSD framerate display doesn’t suddenly double or triple). Even if slightly artifacty / ghosty / slightly flickery / poor overdrive, since low native refreshrates (with no repeat-refresh LFC algorithms) can have side effects for LCDs. But that’s still preferable for those 1-2 seconds that an LCD would otherwise go black when Hz went below minimum.

This unadvertised VRR safety headroom below EDID VRR Hz range below is simply a lesser-of-evils backup for driver-based LFC failures.

Obviously there are a lot of other mitigations (simply pressing NVIDIA/AMD to fix drivers, as well as Microsoft), but this is something that Eve can also partially mitigate. It may not solve 100% of LFC issues (e.g. LFC failures that sustains for a whole second) but it will accomodate slight timing slips such as “graphics drivers being late in activating LFC by a few milliseconds late” and prevent blacking-out the monitor in those situations.

Usually (most of the time) it is a very easy modification of some scaler registers on a panel. 48 Hz is a threshold chosen intentionally for refresh quality reasons, but the panels can easily refresh all the way down to 30 Hz natively in single-pass refresh (just with some minor problems like GtG-fade flicker, overdrive issue, or inversion artifacts, etc).

VRR Refresh Cycle Timing And LFC Is Software Responsibility, But Windows is Not An RTOS

The software code in the graphics driver controls refresh cycle timing of VRR, including LFC timing of generic adaptive sync panels -- including FreeSync, VESA Adaptive Sync, HDMI VRR, and G-SYNC Compatible (non-native).

The problem is many scaler vendors decide that 48 Hz is a hard cutoff threshold and simply just go blank when generic VRR fall below 48 Hz without LFC. Rather, 48 Hz should be the advertised cutoff, with a much lower unofficial unadvertised cutoff as a hardware-based backup for driver issues. This is the software-jitter safety headroom, given the software-controlled nature of VRR refresh cycle timing on non-native-GSYNC panels. Sometimes even a realtime thread in a driver sometimes gets mucked up, as Windows is not a true RTOS…

I have noticed that, sometimes NVIDIA drivers seem to have more problems staying within FreeSync (“G-SYNC Compatible”) ranges than FreeSync inventor AMD does, which is why the FreeSync blankings happen more often with NVIDIA cards (G-SYNC Compatible is simply NVIDIA’s own branding for NVIDIA certification of FreeSync panels). The sudden blankout problem happens far less with native G-SYNC and as well as AMD graphics cards on FreeSync monitors.

Manufacturers, Please Add Undocumented VRR Headroom Below 48 Hz To Reduce Warranty Claims
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply