Screen blanking after firmware 104 while gaming?

Figured I’d be a good sport and try it with Displayport instead of HDMI. Flickering still occurred. I can also confirm as said above when using DP and Adaptive Sync is set to off in the OSD then the NV control panel does not even present the option for G-sync. The pendulum demo confirms g-sync is fully disabled. The issue of it remaining enabled despite turning off in the OSD I guess is limited to HDMI only?

While I was playing an HDR game tonight and the blank issue occurred, when the screen came back on HDR mode had been turned off at the system level. Was able to toggle it back on fine and resume playing. I rarely play PC HDR games so this may always happens when the flicker occurs but an additional piece of info that I have now witnessed. I’ll test more with DP in SDR mode tomorrow.

Originally I had a section here saying DP seemed much happier turning on HDR mode. I’ve since run into just as many issues as HDMI so have removed those statements.

1 Like

Windows 10 version 21H1
After a couple days of usage on driver 496.13 I’ve seen the screen blanking happened roughly twice. On the previous driver it would have been more like 10 times or more, so there does seem to be improvement, Thought it is not completely gone. I have not had a chance to test 471.41.


Some monitor-generic background information as I’m getting annoying blankings occasionally on many ASUS and ViewSonic panels too so it’s an industry wide problem too;

One mitigation I’ve done on multiple vendor monitors is using ToastyX CRU to raise the minimum refresh rate from 48Hz to approximately 55Hz (for 144Hz VRR) or 65Hz (for 240Hz VRR). This solves a lot of blanking problems.

LFC penalty is negligible on 240Hz VRR monitors, and sometimes LFC has superior quality to non-LFC when the VRR range is unusually wide (e.g. 30Hz-360Hz).

In these events, a generous bump-up of the LFC threshold is needed to improve quality (color quality, overdrive quality, inversion-artifact quality, flicker, etc). Stutters from LFC is negligible as the LFC stutterwidth is based on max Hz.

The halftime of a 240Hz refresh cycle (2ms halftime, the stutter penalty) is lost in the motion blur of 33ms frametimes (30fps). Thus, LFC stutter penalty is negligible for ginormous VRR ranged monitors, and it’s better to raise the minimum VRR Hz.

I should add that the ToastyX trick usually works more reliably on AMD cards on FreeSync panels, than with NVIDIA cards on G-SYNC panels (ignores ToastyX EDID override). However, this is sometimes confusing when it comes to FreeSync on NVIDIA cards.

The industry standard 48 Hz can be adjusted to a different threshold in the EDID (either in native hardware, or via a Windows registry EDID override created by ToastyX CRU app), preferably between common framerates. A 65Hz threshold forces 24fps material to LFC 3x per refresh cycle, and 72Hz overdrive/inversion is usually superior.

Raising the FreeSync min Hz to “65” also forces 60fps material to automatically LFC at 120Hz, which can be superior for 60fps material because 120fps on most FreeSync panels have better VRR overdrive. Now, that being said, for proper LFC function you want max Hz to be at least 2.5x min Hz, so the threshold should be rated to 55 for 144Hz panels, instead of 65, when creating a custom EDID override for VRR ranges.

But it is the firmware responsibility to do its best to minimize this issue, such as adding hidden low-Hz support (e.g. panel able to function at lower VRR Hz even suboptimally without blanking, in an “emergency” if LFC is accidentally not enabled).

Panels with dynamic overdrive (G-SYNC native) can work better to even lower Hz without LFC than panels with fixed overdrive during VRR. This is another consideration on deciding the proper min-Hz threshold, because at a certain panel-specific crossover point, LFC becomes superior to native Hz.

Many other VRR Panels can go down to approx 30-35 Hz instead of 48Hz, even though VRR range is 48Hz+. This gives a safety margin if LFC accidentally does not activate in graphics drivers during frametimes longer than 48fps.


Can you suggest a tool to test if the VRR changes are actually working? Only thing I can think of so far is the NV Pendulum test which lets me set frame rates within the app.


Generically (vendor independent):

A monitor’s built-in framerate counter in the monitor is a good LFC test.

Frame rate counters in the OSD of the monitor will show a multiple of the framerate displayed by Pendulum or from a frame rate cap (e.g. RTSS).

Frame rate counters in majority of monitors for all VRR technologies, is designed to work correctly only for VRR operation, as it counts refresh cycles, since VRR works by keeping Hz synchronized to framerates when in VRR range. Graphics drivers on almost all VRR monitors (that isn’t native G-SYNC chipped) is responsible for initiating LFC correctly, so software bugs can lead to LFC bugs.

But extra range in the VRR hardware (generous undershoot headroom below min Hz) can help resist software issues better. That is one of the roles that an upgraded firmware and upgraded drivers can help play, in cooperating better between monitor and drivers.


That presents an interesting finding now that I understand the FPS counter on the monitor is displaying refresh cycles. (Also looks like information in OSD is providing the value captured from the moment you open it in Info)

Right now in Pendulum LFC is engaging at ~fps<53fps (>53 and it disables/provides native VRR numbers to 144). Meaning the FPS counter when set to 50/50 (min/max) in Pendulum displays as 100 in both the onscreen FPS or OSD. Toasty shows the EDID of the monitor as 48-144. Is that normal LFC behavior to engage above the minimum?

I realize this isn’t your product to provide support for but do you see similar results on your testing hardware?

Current setup for test:
D03 Firmware 104
HDMI 2.1 @ 4k @ 144hz / rgb / 10 bit
G-sync Enabled, window and full screen
NV 496.13

1 Like

Hi, has anybody experienced even longer periods of blanking (or maybe even the monitor is crashing?). I was playing Valorant at 4K 144hz SDR with adaptive sync HDMI 2.1 and I experienced a black screen for around 20-30 seconds. I think I was also unable to bring up the OSD. I eventually lost patience and manually turned off the monitor and then turned it back on. But I had to wait another maybe 10 seconds until the screen started showing things again. I haven’t experienced this before with my PC and previous monitor.

I’m on Windows 11 Insider Preview, so Nvidia driver is actually 510.10.

1 Like

I do have times where I have to alt-tab out of the game I’m in order for the monitor to start displaying again, but it always come back when I do. Sometimes its comes back on it’s own, but sometimes it seems not to till I alt-tab.


I did notice this evening that while playing Warzone the same issue occurred (final circle too, great timing). The monitor black screened for what seemed to be 20 seconds or so. Then came back on its own.

The only things that have changed recently were the most recent Win 10 updates, and Nvidia Driver Updates to 496.13.

I’ve also noticed BSOD related to watchdog timing, and other OC related err codes (even though I have no CPU OC running).

I may try to roll-back one of the drivers and see if the issues persists to try to determine if it’s the recent Win10 Updates, or Nvidia Driver Updates.

1 Like

Hey, Mark! @BlurBusters

Thank you very much for sharing insight into the blanking behavior! It helps us a lot in the process of resolving it for Spectrum.

Based on your recommendation, we’ll look into supporting an extended refresh rate below the VRR range (48-144Hz for ES07D03) without the presence of LFC.

The graphics card determines the availability of LFC. In other words, knowing the VRR range of a monitor, the graphics card executes low framerate compensation when the in-game FPS falls below the VRR range, multiplying frames and feed the monitor with a frame rate within the VRR range. Therefore, assuming that the graphics card driver incorrectly disables LFC in some situations, blanking may occur as the panel fails to display an image when the frame rate is below the VRR range.

This is an interesting find and appears to be misbehavior. We’ll investigate the root cause.


I conducted some more testing in attempt to try and determine the cause of the screen blanking on the Eve Spectrum with G-Sync enabled.

I also tried setting the VRR to 55Hz as per BlurBusters suggestion but it didn’t help in my case unfortunately so I reverted back to the default.

However, the odd thing is in my case I noticed that specifically when opening up the application RetroArch (which locks at 60hz?) my screen would start screen blanking instantly so I felt it was a good place to start looking for solutions.

I would open RetroArch, if it started blanking instantly I would Ctrl + Shift + Esc and close it, change settings in the NVIDIA Control Panel, open RetroArch again and keep doing this until RetroArch didn’t cause instant screen blanking.

After numerous testing of various settings in the NVIDIA Control Panel I came to a resolution to stop the screen blanking in RetroArch by conducting the following:

NVIDIA Control Panel > Global Settings > Vertical sync = Off (This setting will force V-Sync to always be off)

Unfortunately upon testing in games such as Call of Duty Warzone/Quake I was still getting various screen blanking from time to time.

It’s odd to me that forcing Vertical Sync off in the NVIDIA Control Panel solved the instant screen blanking with specific applications such as RetroArch but not all applications.

If you do this for future firmwares or future monitors, do not modify the EDID. Keep the EDID at its existing 48 Hz minimum.

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).

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.

If you added something to the issue tracking system, add this notes to give QA instructions on how to QA-test the unadvertised emergency-backup VRR range support.


Things seem to be degrading for me, from simple screen blanking, to Windows actually completely losing the monitor temporarily (as I can see my other monitors trying to refresh / rearrange themselves to the new multi display setup every time it happens). This was not the case before as the Specturm would blank, but Windows was not losing the display.
I will be trying a different HDMI cable later today to make sure if it is not cable related, but I thought it would be good to mention this.

1 Like