When I run an application at a low framerate, the refresh rate (as reported by the monitor OSD) fluctuates wildly. I’m testing with Ōkami HD (which is locked at 30 FPS), mpv (playing 24 or 25 FPS videos) and “strangle glxgears -fullscreen”. For Ōkami, the refresh rate constantly jumps between 48 and 80 Hz (never a multiple of 30). For mpv, the refresh rate fumps around all over the place, even to the monitors maximum refresh rate. I’m pretty sure it used to hold the refresh rate fairly steady at an integer multiple of the video’s refresh rate, but I don’t remember when I last checked. Interestingly though, If I pause mpv, the refresh rate holds steady at a constant 48 Hz.
For glxgears, I run at 57 FPS, the refresh rate holds fairly steady, but I decrease to 56 FPS or lower on one of my monitors (an Acer 27" Nitro VG271US), the refresh rate start wildly. On my other monitor (a Gigabyte G27Q), this starts happening at 54 Hz. I have only one of the monitors on at a time in order to be able to use VRR. The fact that this starts happening at low refresh rates leads me to think it’s an issue with the LFC.
It doesn’t seem like this fluctuation affects the frame delivery (based on what I can see with high speed video recording), but when running at these low framerates the monitors starts to flicker, which might be connected. It starts out subtly at the edges of the screen, but gradually grows worse and starts covering the whole screen. Same thing happens on both monitors.
Operating System: openSUSE Tumbleweed 20240307
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12
Kernel Version: 6.7.7-1-default (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 62.7 Gibyte of RAM
Graphics Processor: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2
Manufacturer: ASUS
Driver: 550.54.14
nvidia-bug-report.log.gz (1.0 MB)
1 Like
My guess is, in the case of Ōkami, it duplicates the frame rate, from 30 to 60 FPS. But then instead of showing each resulting frame for 16.7 ms, it shows every other frame for 20.8 ms and every other frame for 12.5 ms. Every other frame being shown for a different duration then causes a static charge to build up, which causes the flickering, because frames with one voltage are shown for longer than frames with the opposite voltage. But that’s just a guess.
I don’t seem to get the flickering from mpv, in which the refresh rate fluctuates randomly rather than alternating between two values.
1 Like
Some videos to display the problem. They show glxgears in fullscreen, with Mangohud to limit framerate and display frametimes. They were filmed at 240 FPS and slowed down to 30 FPS to allow seeing the transitions in the refresh rate. The big yellow number is the refresh rate overlaid by the monitor, and the stuff below it is from Mangohud.
50 FPS. Refresh rate fluctuates significantly, even though the frame time reported by Mangohud is fairly constant:
60 FPS. Refresh rate is fairly stable.
Though it’s not quite consistent at high framerates either. With a 160 FPS limit:
Very interesting, I can also reproduce something similar to this on my Samsung Odyseey G5.
To test this more accurately I used VRRTest which allows control over the framerate.
While I don’t have videos yet here’s the observed behavior on my end, which seems somewhat similar.
So, first of all, the monitor’s VRR range is from 48-144Hz, meaning LFC should kick in when the client presenting drops below 48fps.
Framerate 55-144: VRR works correctly, the refresh rate is within ±~1Hz from the target client’s framerate
Framerate 48-55: VRR works with a periodic stutter (~300ms?) & flicker caused by a refresh rate fluctuation back to and from the max refresh rate (50Hz->144Hz->50Hz)
Framerate <48: LFC should kick by doubling (Or more, depending on the case, doubling would be better in preventing flickering in stuttery games) the client’s frames to get back in range but, instead, there is a quickly repeating periodic stutter (Don’t have exact measurements but it’s enough to constantly flicker the monitor so its cycle it’s probably only a few milliseconds) caused by the refresh rate jumping from 48-144Hz pretty much constantly.
I have tested this on most GNOME versions since VRR was available (46), including GNOME 47.beta.
I only tested Wayland; I’m also running the proprietary driver with GSP Disabled.
This reproduces on pretty much all driver versions starting from 555 that I’ve tested up until the latest 560.35.03.
I also locked the GPU Clocks to the max while running this so that pstate fluctuations aren’t skewing the results.
Here’s an nvidia-bug-report.log.gz (726.7 KB)
It seems, to me at least, that LFC isn’t working at all, at least on this hardware/software combination, which is causing most of the issues (most of the stuttering and flickering).
I wonder what could cause the other issue before LFC kicks in (48-55Hz) if dropped frames aren’t to blame.
I can’t personally recall a driver version in which this hasn’t been an issue but I’ve only started testing VRR with 555 drivers.
1 Like