Visual stuttering in all programs despite perfect framepacing (Nvidia)

hreallischm · 2023-03-16 05:45:38

I posted about this on /r/archlinux a few days ago, but didn't get any responses. So, here's an abridged version of that post:

Although MangoHud shows that I only have 0.1ms frametime deviation in lighter games when using capped FPS, the image itself is extremely laggy on any FPS value other than 1/2 of my monitor's refresh rate. So, since I use a 240hz monitor, any FPS value other than 120fps (even 60 or 80) results in an image that looks absolutely awful, as if ~100 frames out of 240 were dropped, and there are major glitches/other artifacts as well. If I switch my monitor to 144hz, only 72fps will look clean. Above 480fps looks passable since the stutters only happen for 1 frame at a time. The issue is not present on Windows, or when using nouveau drivers.

Hardware:
i5 12500 (iGPU disabled)
Zotac Twin Edge OC RTX 3060 LHR
Asus TUF Z690 D4
BenQ XL2540

The odd thing is that I was previously able to fix this issue by simply opening up nvidia-settings every time I started xorg. The stutters and glitches would completely disappear, and although framerates aren't affected, MouseTester frequency/time plots would also significantly improve (all massive spikes would disappear. Essentially, the consistency with which mouse events are received would go from +-200hz to +-2hz at most, implying some kind of stalling or blocking was happening). However, despite my settings being completely identical now (composition, Sync to VBlank, VRR all disabled), opening nvidia-settings after starting xorg no longer works after deleting my nvidia-settings and xorg configs to troubleshoot an unrelated issue (or maybe I broke it some other way? I'm not sure).

Troubleshooting steps I have tried:

Several different window managers (none of which are compositing)
Using KDE instead of just a window manager
Stock kernel with nvidia and linux-tkg-bore with nvidia-dkms (issue is present on 6.0, 6.1, and 6.2. Haven't tried any other kernel versions)
Re-flashing my BIOS (5 times)
Using stock BIOS settings
Reinstalling Arch (4 times)
Re-flashing my GPU's vBIOS
Using a different (60hz) monitor
Using HDMI instead of DP
Toggling DRM
Disabling Allow Flipping
Pressing random buttons in nvidia-settings for 3+ hours hoping it would make it so that opening nvidia-settings would fix the issue again
Tried both UEFI/GPT and CSM/MBR
Tried both a minimal, manually created xorg config and one auto-generated by nvidia-xconfig
Using "Prefer Maximum Performance" instead of "Adaptive" (results in fewer stutters but more visual glitches, 1 every second of varying intensity)
Disabling VRR and Vsync through environment variables. Setting the __GL_SYNC_DISPLAY_DEVICE environment variable
Disabling composition, VRR, and UseNvKmsCompositionPipeline through xorg configuration options
Disabling ACPI in kernel parameters.
Early loading of the driver's modules
Disabling message signaled interrupts
Running xorg as root

If I had to guess, the issue is probably caused by some kind of desync between the GPU driver and something that it samples at 240hz/something that samples its output at 240hz (assuming 240fps), given that the stutters only happen for 1 frame at a time regardless of FPS value (I have 0 clue how the graphics pipeline actually works). However, I don't understand why it was previously fixable by opening nvidia-settings but isn't anymore despite my settings being identical, or why I seem to be the only person who gets this issue (to my knowledge).

journalctl -b after booting up, running startx, then running nvidia-settings
~/.local/share/xorg/Xorg.0.log

Last edited by hreallischm (2023-03-16 12:24:58)

seth · 2023-03-16 08:47:14

The odd thing is that I was previously able to fix this issue by simply opening up nvidia-settings every time I started xorg

This will temporarily move the GPU into performance mode.

Running xorg as root

Go into the corner of shame and think about what you did, young man.

Disabling Allow Flipping

Bad idea.

Tried both a minimal, manually created xorg config and one auto-generated by nvidia-xconfig

Remove that. Any of it.

Several different window managers (none of which are compositing)

Stay in this territory to rule out interference from any buggy compositor.

Post the outpputs of

xrandr --verbose | curl -F 'file=@-' 0x0.st
glxgears
__GL_SYNC_TO_VBLANK=0 glxgears

and describe the behavior of both glxgears instances.

https://www.youtube.com/watch?v=JrN3S_FTUKk

I'm not sure what I'm supposed to see on that, but WARNING to anyone with tendency to epilepsy or visually triggered nausea: don't watch that.

hreallischm · 2023-03-16 11:41:07

I know disabling Allow Flipping and running xorg as root are bad ideas. Disabling Allow Flipping gave worse performance, and many of the things I mentioned such as running xorg as root are one-offs that I tested on throwaway installs, or things I immediately reverted, to make sure I wouldn't mess anything up.

And again: opening nvidia-settings doesn't work anymore. It previously worked, but it doesn't now. The problem is pretty much a binary of working or not working and is only barely affected by power related settings.

xrandr output: https://0x0.st/H-mC.txt

glxgears
226056 frames in 5.0 seconds = 45211.074 FPS
236325 frames in 5.0 seconds = 47264.820 FPS
235526 frames in 5.0 seconds = 47105.047 FPS
235502 frames in 5.0 seconds = 47100.211 FPS
235515 frames in 5.0 seconds = 47102.898 FPS
235505 frames in 5.0 seconds = 47100.801 FPS
235489 frames in 5.0 seconds = 47097.793 FPS
235515 frames in 5.0 seconds = 47102.930 FPS
235493 frames in 5.0 seconds = 47098.430 FPS
235489 frames in 5.0 seconds = 47097.629 FPS
235538 frames in 5.0 seconds = 47107.445 FPS
235530 frames in 5.0 seconds = 47105.848 FPS

(I already had __GL_SYNC_TO_VBLANK=0 in my .bash_profile, results are the same as the other command. It's locked to 240fps if I remove it.)
This is with the Adaptive power profile, results are nearly identical with Prefer Max Performance and are totally unaffected by whether or not I've opened nvidia-settings at least once after starting xorg. The stuttering is not really perceptible in glxgears, which makes sense since it's already kind of hard to see at FPS values above 480 or so as I mentioned in the original post.

seth wrote:

I'm not sure what I'm supposed to see on that,

Actually, it seems like the result was too influenced by the browser I was using, and is less intense with chromium (shows up as regular stuttering with less flickering). I'll private the video and maybe try to get a better demonstration.

Last edited by hreallischm (2023-03-16 12:25:49)

seth · 2023-03-16 12:19:40

Apparently you've vsync disabled globally, what's the behavior of

__GL_SYNC_TO_VBLANK=1 glxgears

then?

Ftr.

  1920x1080 (0x1bf) 594.270MHz +HSync -VSync *current
        h: width  1920 start 1948 end 1980 total 2040 skew    0 clock 291.31KHz
        v: height 1080 start 1137 end 1145 total 1215           clock 239.76Hz

is somewhere between teh cvt1 and cvt12 modeline, but not eg. interlaced (what I had somewhat hoped for)

hreallischm · 2023-03-16 12:31:54

seth wrote:

Apparently you've vsync disabled globally, what's the behavior of

I edited the post to say that it locks it to 240fps with __GL_SYNC_TO_VBLANK=1, but I should probably post the full results as well, so here they are:

__GL_SYNC_TO_VBLANK=1 glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
1201 frames in 5.0 seconds = 240.164 FPS
1199 frames in 5.0 seconds = 239.760 FPS
1199 frames in 5.0 seconds = 239.761 FPS
1199 frames in 5.0 seconds = 239.760 FPS
1199 frames in 5.0 seconds = 239.761 FPS
1199 frames in 5.0 seconds = 239.761 FPS
1199 frames in 5.0 seconds = 239.760 FPS
1199 frames in 5.0 seconds = 239.761 FPS
1199 frames in 5.0 seconds = 239.761 FPS
1199 frames in 5.0 seconds = 239.761 FPS
1199 frames in 5.0 seconds = 239.761 FPS

seth · 2023-03-16 13:01:44

And how's the stutter w/ glxgears on 240Hz?

hreallischm · 2023-03-16 13:15:31

The stuttering isn't too bad in glxgears, although that's in part because syncing to vblank seems to partially mitigate the issue in all applications (though it doesn't completely remove it).

Here's a video taken at 60hz, with Chromium, to demonstrate the issue https://www.youtube.com/shorts/fNqf-Uw9FG4. Epilepsy warning, I guess. The stuttering should be pretty clear in this one (look at the top UFO, which is running at 60fps). It says Vsync is unsupported at the bottom, but this is exactly how it looks in other 2D applications, regardless of whether or not Vsync is on, so it should still work as a demonstration. Notice how bad it is at 60fps with 60hz, but it's pretty much fine for the 30fps UFO (the middle one). It's the same if I switch to 240hz: 240fps looks choppy, 60fps looks choppy, 120fps looks smooth.

It is significantly less intense with Prefer Maximum Performance--enough to be bearable for desktop use. However, there are still occasional visual glitches & times where the framerate seems to "skip ahead". Both of these, as well as the MouseTester issue, were previously completely fixable by opening nvidia-settings.

Here's some screenshots of the MouseTester issue for documentation:
https://imgur.com/a/T7T7Jig
The reason I'm using a range like 4600ms to 8400ms is because there are dips to 500hz surrounding this range, due to my mousepad & mouse sensor being unclean, as well as me not moving my mouse fast enough. This has no bearing on the usefulness of the results within the range shown, the results in both images are extremely consistent and reproducible between tests and system boots.

Last edited by hreallischm (2023-03-16 14:04:16)

seth · 2023-03-16 14:04:04

When you record your monitor, put the camera on a (makeshift) tripod and don't move it.
From what I can see it's not actually "stutter" but seems like an old frame gets injected into the buffer (the UFO snaps backwards)

Did you try to enable triple buffering?
/etc/X11/xorg.conf.d/20-nvidia.conf

Section "Device"
    Identifier "Default nvidia Device"
    Driver  "nvidia"
    Option  "NoLogo"                "True"
    Option  "CoolBits"		    "24"
    Option  "TripleBuffer"          "True"
EndSection

hreallischm · 2023-03-16 14:20:01

You're right that stuttering is the wrong word, but I didn't know what to call it, since it's rare for issues like this to happen without a framerate dip. Though rather than an old frame being injected into the buffer, it seems more like one frame being displayed twice as long as it should be (the doubling effect is maybe just MPRT blur?)

Enabling triple buffering doesn't fix it, even if I enable Vsync. Specifically setting TripleBuffer to False seems to have no effect either. Actually, I think earlier when I said that enabling syncing to vblank mitigated the issue, I was actually seeing the result of enabling VRR (since I commented out all of my graphics related environment variables all at once, including __GL_GSYNC_ALLOWED=0), which helped to mask the problem. I'm pretty sure that anything to do with vertical sync or increasing the buffer size has no bearing on the issue at all. Prefer Maximum Performance and, previously, loading my nvidia-settings config after starting xorg (even though my settings back then were literally the same as they are now to my knowledge, maybe something to do with the order the settings were listed?), are the only things that seem to make a difference that I wouldn't put in the "likely placebo" tier, besides using a different OS or graphics driver altogether.

Last edited by hreallischm (2023-03-16 14:54:25)

seth · 2023-03-16 14:46:11

Because of

Using a different (60hz) monitor

I don't think this is because of the specific output.
This will happen on the framebuffer level, can you actually record the effect?
https://wiki.archlinux.org/title/FFmpeg#Screen_capture

nvidia-settings -q all | curl -F 'file=@-' 0x0.st

hreallischm · 2023-03-16 15:15:12

One thing: I didn't reset my configs when I tested with that 60hz monitor, so that might have possibly had some impact.

nvidia-settings: https://0x0.st/H-BP.txt

Recording with ffmpeg was... weird. I specified 60fps, but the recording only came out as 30fps. Not sure if that means I did something wrong, but I doubt you can discern much from this video. There are occasional points in the video where it jumps ahead, but I don't know if those are related or not. https://www.youtube.com/watch?v=xFCSpUCMOv4. Maybe I'll try gpu-screen-recorder next, but I'm going to sleep for now.

Last edited by hreallischm (2023-03-16 15:18:26)

seth · 2023-03-16 16:45:07

Attribute 'OpenGLImageSettings' (arch:0.0): 3.

Don't set that to maximum performance.

  Attribute 'DisplayVRRMode' (arch:0[dpy:1]): 2.
    'DisplayVRRMode' is an integer attribute.
    'DisplayVRRMode' is a read-only attribute.
    'DisplayVRRMode' is display device specific.
    'DisplayVRRMode' can use the following target types: Display Device.
  Attribute 'DisplayVRRMinRefreshRate' (arch:0[dpy:1]): 48.
    The valid values for 'DisplayVRRMinRefreshRate' are in the range 38 - 58 (inclusive).
    'DisplayVRRMinRefreshRate' is a read-only attribute.
    'DisplayVRRMinRefreshRate' is display device specific.
    'DisplayVRRMinRefreshRate' can use the following target types: Display Device.
  Attribute 'DisplayVRREnabled' (arch:0[dpy:1]): 1.
    'DisplayVRREnabled' is a boolean attribute; valid values are: 1 (on/true) and 0 (off/false).
    'DisplayVRREnabled' is a read-only attribute.
    'DisplayVRREnabled' is display device specific.
    'DisplayVRREnabled' can use the following target types: Display Device.

Disable VRR - just to be sure.

hreallischm · 2023-03-17 03:18:02

Those 3 attributes are read-only and are only what my monitor reports as supporting. Unfortunately, it is not possible to disable VRR through my monitor's OSD. No matter what, it will always show "Enabled", and I can only disable it in software. You can search up "xl2540 disable freesync" and find several others with the same issue. Similarly, in nvidia-settings, it will always say "G-SYNC Mode Available: G-SYNC Compatible" and "G-SYNC Mode Enabled: Yes". So I previously just disabled it through the Allow G-SYNC/G-SYNC Compatible setting, and through the __GL_GSYNC_ALLOWED environment variable. Even with HDMI 2.0, which doesn't support VRR, it still said FreeSync was enabled. I also tried applying a custom EDID with everything related to FreeSync removed, though maybe I didn't do it correctly, since it still showed up in nvidia-settings as Enabled. But I think that using a different monitor entirely which doesn't support VRR at all should rule that out as a cause of the issue, unless it again is affected by me not resetting my configs before switching monitors/cables. I might have to test it again, this time with configs properly reset.

The Image Settings option has no discernable effect.

With gpu-screen-recorder, the video is 60fps this time, although it comes out looking a bit weird. Not really sure what to make of it. https://www.youtube.com/watch?v=SIkSzdXTcns. It's like the "stuttering" stops happening with the UFOs but starts happening with the recording itself instead? The screen looks totally smooth in person while recording though, no stuttering or other artifacts whatsoever. There are many frames where the 60fps UFO just doesn't move at all (roughly once every 20 video frames), so the recording fps seems massively misaligned with the actual framerate. I tried a few different encoders, as well as recording "DP-0" instead of "screen", and the effect was the same. Prefer Maximum Performance also has no effect. However, checking with mediainfo, the video framerate is reported as a constant 60.000fps.

By the way, in the journalctl that I posted, there are a massive number of ACPI errors relating to "CreateBufferField" for "\_SB.PC00.PEG1.PEGP._DSM" (my GPU, basically). Could this be related, or is it a red herring? Should I be posting on the Nvidia developer forums or the Asus forums instead of here?

Last edited by hreallischm (2023-03-17 05:44:51)

seth · 2023-03-18 07:14:38

If you step through the video frame by frame you'll notice that there're no stalls, skips or backward jumps.
So it's not in the framebuffer, it's actually your output.

Can you disable VRR in the monitors OSD?

ACPI errors are unfortunately common, but w/ AE_ALREADY_EXISTS I doubt that's the cause pr related to what you perceive.
How does playing a video (w/ mpv) on the console behave?

hreallischm · 2023-03-19 13:04:48

There is definitely a 1 frame stutter in the video exactly every 24 frames, for some reason it is always whenever all 3 UFOs are lined up.

I cannot disable VRR in my monitor's OSD as stated in the previous reply, but testing with both HDMI and a separate monitor should probably rule out VRR as a cause. I'll test again in a few days when I have the chance in case it was affected by not resetting my configs between tests.

The kind of flickery effect from the video I recorded with my phone camera doesn't seem to be present in videos viewed with mpv, but the videos still look stuttery/jittery at times, and when I rewind the videos to replay those stuttery parts, the stutters are gone (so it isn't something in the videos themselves).

Last edited by hreallischm (2023-03-19 13:06:53)

seth · 2023-03-19 13:26:31

when I rewind the videos to replay those stuttery parts, the stutters are gone (so it isn't something in the videos themselves)

Yes, but this is (very likely) because you're recording an unsynced source.
The browser demo isn' necessarily the best test case here, because your source is flawed.

hreallischm · 2023-03-22 00:39:36

The videos I watched with mpv were random videos I downloaded with yt-dlp, I didn't want to use any videos I recorded myself.

I think I'm just gonna send a bug report to Nvidia. It only happens on Linux, with the proprietary drivers, so clearly it is possible to fix at the driver level even if it is partly caused by hardware. Even though I have been able to work around it in the past, it's extremely inconsistent, and I'd rather not keep trying to fix it myself. I'll post an update if I get a response.

Last edited by hreallischm (2023-03-22 01:00:34)

hreallischm · 2023-03-25 13:27:56

Haven't gotten a reply from Nvidia yet (maybe I should be posting on the forums instead of e-mailing them), but here's something interesting: after flashing a BIOS update released 3 days ago, when I lock my GPU's memory clock or use Prefer Maximum Performance, the results in MouseTester are drastically improved, almost to the level they are at when using nouveau drivers (the BIOS update is possibly coincidence, and maybe it was actually caused by something else I tested, but that seems like the most likely thing). Almost all of the spikes are completely gone save for one or two every 10 seconds, and otherwise the variation stays within 2hz of perfect. The screen looks just as stuttery as before though, and even if I completely lock both graphics and memory clocks, those stutters don't go away. I also found several other users on the Nvidia developer forums with issues similar to mine despite very different hardware, the common thread being that changing power management settings seems to mitigate the symptoms.

What I'm really still curious about, though, is how I managed to completely fix the issue and all of its symptoms in the past by opening nvidia-settings after starting xorg. I'm confident it has nothing to do with the settings themselves that I had set (or if it does, it's only in a roundabout way--such as the order the settings are listed in .nvidia-settings-rc or xorg.conf), and I suspect it's some extremely technical reason that would go over my head if it was told to me. One thing that I'm almost certain about though is that fundamentally, the issue isn't that the clocks are too low by default. I think the fact that memory clocks affect it so much is solely a symptom of deeper issues with the driver, because in the past, everything would work perfectly with the Adaptive power plan and unlocked clocks as long as I opened nvidia-settings at least once after starting xorg. And because locking clocks doesn't seem to fix the visual stuttering at all.

Here are those similar issues that I found: https://forums.developer.nvidia.com/t/e … ows/245731
https://forums.developer.nvidia.com/t/d … 000/243379

I guess the next thing for me to try is downgrading to an older driver version, since one person says that the issue only began with 525.78.01

edit: Downgrading the driver version seems to make no difference.

Last edited by hreallischm (2023-03-26 09:47:39)

Arch Linux

#1 2023-03-16 05:45:38

Visual stuttering in all programs despite perfect framepacing (Nvidia)

#2 2023-03-16 08:47:14

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#3 2023-03-16 11:41:07

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#4 2023-03-16 12:19:40

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#5 2023-03-16 12:31:54

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#6 2023-03-16 13:01:44

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#7 2023-03-16 13:15:31

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#8 2023-03-16 14:04:04

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#9 2023-03-16 14:20:01

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#10 2023-03-16 14:46:11

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#11 2023-03-16 15:15:12

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#12 2023-03-16 16:45:07

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#13 2023-03-17 03:18:02

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#14 2023-03-18 07:14:38

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#15 2023-03-19 13:04:48

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#16 2023-03-19 13:26:31

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#17 2023-03-22 00:39:36

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

#18 2023-03-25 13:27:56

Re: Visual stuttering in all programs despite perfect framepacing (Nvidia)

Board footer