Constant single-frame visual stutters, perfect ingame framepacing

I sent this to about a week ago, but I’m not sure if anyone actually checks that inbox anymore. I apologize if it is still actively monitored.

Video of the issue at 60hz, look at the top UFO (epilepsy warning?)

The issue happens in all programs, and does not happen on Windows or with nouveau drivers. I believe the stutters happen for a single frame of the application’s framerate, rather than a single refresh cycle. So, the stutters are not perceptible on my 240hz monitor at very high framerates (>480 or so, although even at high framerates the image seems to ‘skip ahead’ a few times a minute when I’m experiencing the issue).

The issue does not seem to happen if the application’s framerate is exactly 1/2 of my refresh rate. If my monitor is set to 60hz, the issue will not happen at 30fps. If my monitor is set to 240hz, the issue does not occur at 120fps, but does occur at 60fps, oddly. I’m not sure if this is shown correctly in the video I sent though, I imagine the browser itself is still running at 240fps.

The issue is significantly less intense with locked memory clocks or Prefer Maximum Performance: rather than happening constantly, the stutters will happen in bursts almost exactly every 20 seconds. The effect still remains quite annoying though, and this is absolutely not a fix.

On my previous Arch Linux installation, I was able to completely fix the issue by opening nvidia-settings every time I started xorg, even with the Adaptive power plan. This does not work anymore, despite my settings being identical. I have also spent several hours going through and changing every possible setting over and over, which made no difference.

Although the issue doesn’t show up on frametime graphs, it does show up on MouseTester frequency/time plots, as frequent 10hz and 200hz spikes.

I have also tried:

Using a different (60hz) monitor which doesn’t support VRR
Using different DP ports
Using HDMI instead of DP
Downgrading Nvidia drivers to 525.60.11. I also tried a few even earlier versions, but xorg won’t start with them installed. I have also used every driver version in between this version and the latest one at some point.
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 (several times)
Using stock BIOS settings
Disabling all GPU-related power saving in BIOS
Locking graphics clocks
Reinstalling Arch (several times)
Re-flashing my GPU’s vBIOS
Toggling DRM
Toggling Allow Flipping
Installing Arch on both UEFI/GPT and CSM/MBR
Using a minimal, manually created xorg.conf
Using xorg configuration generated by nvidia-xconfig
Not using an xorg config file
Disabling VRR and Vsync through environment variables.
Setting the __GL_SYNC_DISPLAY_DEVICE environment variable
Disabling anything related to composition or VRR through xorg configuration options
Disabling ACPI in kernel parameters
Early loading of the driver’s modules
Disabling message signaled interrupts

None of which made any difference.

Here is the nvidia-bug-report log after booting up, starting xorg, opening nvidia-settings, then starting Chromium.
nvidia-bug-report.log.gz (1.1 MB)

My hardware:
i5 12500 (iGPU disabled)
Zotac Twin Edge OC RTX 3060 LHR
Asus TUF Z690 D4 with CSM (though I’m pretty sure disabling CSM made no difference)
BenQ XL2540

Unfortunately, no xorg logs and config is caught in the logs.
An oddity is that chromium doesn’t show up in the nvidia-smi process list, i.e. doesn’t use it. So it won’t get a vsync as well.
Did you try setting

Option "ForceCompositionPipeline" "true"

in your xorg.conf?

ForceCompositionPipeline removes screen tearing (as would be expected from composition), but does not remove the stuttering. Though even if it did, I would not want to enable composition due to the added input latency.

Here is Xorg.0.log after running “startx – -logverbose 6”, then opening nvidia-settings:
Xorg.0.log (307.3 KB)

Here is my current xorg.conf, although as stated in the original post, using either an empty xorg configuration, one auto-generated by nvidia-xconfig, one manually created, or one auto-generated by nvidia-settings seems to make no difference:
xorg.conf (1.7 KB)

Looks normal. Did you check about:gpu in chromium why it doesn’t use the nvidia gpu?

The issue isn’t with Chromium at all. It happens in all programs, it’s just that Chromium made it easy to capture on video since it’s most noticeable with 2D sidescrolling motion rather than 3D motion. Chromium is absolutely using the Nvidia GPU. Maybe I was just mistaken and I didn’t open Chromium before I ran, that log was from a week ago so I don’t remember exactly.

I have my iGPU disabled in BIOS as well, the issue is definitely not programs not using the right GPU.

Ok, looks normal, you likely didn’t have chromium open.
Does setting
__GL_MaxFramesAllowed = 1
in your system env change anything?

It does not, unfortunately.

An additional detail that might narrow things down:

Even though opening nvidia-settings after starting xorg doesn’t completely fix my issue on this Arch install like it did on my previous one, it does seem to remove the stuttering for 4-5 seconds even when the settings have already been applied. Specifically, applications seem to freeze for about 1/10 of a second whenever I open the nvidia-settings GUI, and then the stutters stop for a few seconds afterward.

The interesting thing, however, is that this does not happen when I run “nvidia-settings --load-config-only”. Applications do not freeze at all, and the stuttering is not ‘reset’ like it is when opening the GUI. It also does happen with “nvidia-settings -n”. So, rather than the issue being caused by any settings not being applied before nvidia-settings was opened, I think it might have just been the act of opening the GUI itself that somehow fixed it in the past. I’m really not sure how that could happen, though–and it seems to imply a very obscure/technical cause. The stutters also do not disappear when opening any other program.

I’ve also noticed that when opening the nvidia-settings GUI through the command line, even with the “-n” argument, the line

(nvidia-settings:4969): GLib-GObject-CRITICAL **: 12:12:22.866: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed

is printed. I’m not sure if this is relevant or not, though. There are also many ACPI errors related to my GPU in my nvidia-bug-report.log, but again, I’m not sure if they’re relevant here.

[ 1.847775] ACPI BIOS Error (bug): Failure creating named object [_SB.PC00.PEG1.PEGP._DSM.USRG], AE_ALREADY_EXISTS (20221020/dsfield-184)
[ 1.847779] ACPI Error: AE_ALREADY_EXISTS, CreateBufferField failure (20221020/dswload2-477)
[ 1.847781] ACPI Error: Aborting method _SB.PC00.PEG1.PEGP._DSM due to previous error (AE_ALREADY_EXISTS) (20221020/psparse-529)

(this repeats about 15 times).

Just a blind shot but I have the same issue and it gets fixed after running glxinfo then xrandr without any arguments. Don’t ask me why, but running those have some hidden side effect most likely.

I’m glad to hear at least someone else is getting the same issue.

It doesn’t permanently fix it for me, but running glxinfo definitely causes it to stop for a few seconds in the exact same way that opening nvidia-settings does. So I guess that answers the question of why opening nvidia-settings seems to “fix” it sometimes, and shifts the question to: why does reading glxinfo seem to “fix” the issue sometimes? Why did it fully fix things on my previous install, but now only fixes it for a few seconds, like something is being “refreshed”?

xrandr seems to do nothing for me, unfortunately.

By the way, what kind of hardware do you have? And can you post your xorg.conf/other files? Sorry, but I really would like to know if there is anything I can do that might help me get my system back to a state where I can fix the issue, even temporarily.