Make sure that you’re actually using 440.82 first. Ubuntu 20.04 currently installs 440.64 “disguised” as 440.82 for some reason. This also overrides the “legit” 440.82 present in the ppa unless you manually select it. Some other minor problems related to VRR similar to yours (like this one: Adaptive Sync causes screen signal loss after power cycling the monitor) were solved on my machine by simply upgrading to 440.82.
Maybe that’s all it takes. LFC is the only thing that still fails on my end right now.
Happy to finally found a thread describing my exact issue.
My panel Acer VG271U is also 48-144Hz.
In Windows the pendulum demo works perfectly, even when forced to a lower FPS I see LFC kick in and refresh rate jumps into the 90s.
I’ve been trying to get Witcher 3 working in Proton but in areas where I’m in the 60s FPS small stutters cause it to drop and I loose display output. My monitor doesn’t do a full reset it just seems to go out of range and then come back. On return it takes an extra second for Gsync to kick in again.
I’ll try raising the minimum variable refresh rate like was mentioned above.
I finally tried the 450.57 drivers and, while they fixed a lot of other problems, this nasty bug is still there… 😟
I wish we had a way to just disable LFC altogether just to be able to see if it’s really the root cause of all this.
I mean… LFC isn’t working properly anyway so why keep it at this point knowing that it could cause much worse problems than occasional tearing.
I was also able to help reduce this problem by editing the EDID to a minimum refresh rate of 70Hz. However I am still getting display drop outs in loading screens consistently, and during gameplay although a lot less often.
I did some testing, this was just from general observation but could be totally wrong…
It seems in Windows when FPS drops below 48Hz it then starts frame doubling, so the refresh rate doubles to 90Hz while the game runs at 45 FPS, displaying the same image twice.
In Linux I haven’t noticed any doubling kicking in, as soon as I hit a stutter that send it below 48 FPS I get a black screen so I can’t see what the refresh rate is.
“Flickering” means going from black to normal very fast many times in the span of a second. That’s another known problem with Freesync monitors and Nvidia GPUs. The issue we’re suffering from here makes our monitors go completely blank only to recover after a straight second or so. So is it flickering or is it “blanking” for you?
If your monitor doesn’t have LFC and you still suffer from the same problem as we do, it might be further proof that the currently “borked” LFC implementation that we have now on Linux is not the root cause of the problem but a separate one.
EDIT: I just tried sabotaging again LFC (on Linux this time) by setting my VRR range to 130-240 (so that LFC would never kick-in) and my screen still blanks out… I don’t think we need more proof than this that they are separate problems.
In order to “fully” support LFC, your max refresh rate value must be at least double of your lower VRR range value. With monitors that normally don’t support LFC like yours, you can usually try to extend your lower VRR range value. Setting yours to 37-75 should be enough to enable LFC. Not all monitors can handle this though and, more often that not, you’ll get flickering or blanking as a result. Some cheap monitors can’t even handle the range they advertise and they show these symptoms even without any EDID editing…
I discovered another little detail that might become relevant at some point (I hope). I recently installed the same game (No Man’s Sky) on both Windows and Linux this time in clean environments.
Since my monitor’s VRR range is 48-240, at some point during the initial loading screen, my monitor’s HUD on Linux shows a stable refresh rate of 48. That checks out but, shortly after, the screen still blanks out.
On Windows though, at the same point during the same loading screen, it always showed a steady 49. Never going all the way down to 48 and never blanking the screen. Since Windows never suffers from this screen blanking bug (unless I try to manually sabotage LFC and set the refresh rate to 47 or lower), I thought this might be relevant.
Maybe it’s a rounding error somewhere rounding “48” down to “47”. I suppose I should be talking about frametimes here instead of Hz but I hope you get the idea…
Since the code base is the same between the two, I also thought of some possible compiler shenanigans going on here… I don’t know what is used to build everything in Windows but, on Linux, I wonder if the nvidia kernel module can be built using clang instead of gcc just to see if something changes…
Also I just realized that it’s been a whole year since I reported this bug. I didn’t organize anything for the occasion but I promise that I’ll come prepared for the second anniversary next year. ;P
Hi,
I’m also getting this issue with anything full screen. I thought the 460 drivers had fixed it but it has re-emerged. Everything works fine on Windows on the same machine. It’s AOC Gaming 24G2U monitor with a 1060 card.
Also chipping in to say I am still experiencing this issue under Linux, I have done a fresh install since the last time I posted. I am running the 460.32.03 driver.
Well, I recently tried an AMD card with the same exact hardware: same monitor, same cable, same motherboard all except the GPU. Suffice to say that, contrary to my 1070ti, both variable refresh rate and LFC worked perfectly fine.
This black screen bug is a major issue worthy of the “Novideo” meme and should be high on the priority list but, instead, more than a year later, nothing has changed.
I’d still very much like to see this bug fixed or at least addressed in some way or another. Even being able to disable LFC altogether could be a big improvement since occasional tearing when the fps drop would be much better than frequent random black screens.
Today I decided to revisit using GSYNC on my machine and dropped back to 1 monitor (damn X11).
My face lit up when I turned on the refresh rate display on my monitor and saw a constant 48 (my monitors min refresh rate) during the loading screen. Previously as soon as I saw 48 I was guaranteed a drop but today it didn’t happen.
I have only tested for about 30 seconds as I was so excited I had to reply :D I did get 1 small stutter during my quick test and again there was no drop.
Driver version - 465.27 - Running Arch - just ran updates today.
Any change on your end? Fingers crossed we can finally enjoy GSYNC, it’s sooo smooth
Unfortunately I’m unable to test 465.27 now since all I could get after installing it is a total system freeze after install. This was with multiple distros and all on fresh installs… I guess I’ll have to wait for it to be packaged by main distro.
The changelog mentions a black screen fix with active DP dongles but nothing specific about GSYNC.
The latest driver that I managed to get working is 460.73.01 and it works just as bad as it always did.
Just wanted to add some further details in case this helps.
When the display output drops it almost seems to crash my monitor. If I have the monitor’s menu open at the time it exits out and I have to re-open it when the display comes back.
And here we are two years after first reporting this bug and thousands of views later…
Happy second anniversary to those who decided to stick around for this long. 🎉🎊🎈
Since the 465 drivers came out, 5 months ago I’ve been completely unable to test Adaptive Sync ever since. I went from being able to tell that Adaptive Sync wasn’t working properly to being completely unable to tell if it works at all since connecting a Display Port cable now causes a system freeze.
After two years I honestly did not expect anything to change, really.
That said, I also certainly did not expect things to get even worse…
The latest drivers supposedly fixed the freeze for some users. For many others, me included, they didn’t.
Now I can’t even tell if Wayland support changed anything at all…
At this point I’ve officially given up: that’s all folks.
I used to laugh at “Novideo” memes until it happened to me.
Don’t let this happen to you: just get an AMD card next time.