Title, basically. I’ve been tracking this problem for a while, here’s a reddit thread about it:
Long story short, some newer AMD chips have had bad performance in the last few kernels. The known workaround is to put amdgpu.dcdebugmask=0x10 in your kernel args. This fixes the lag, but also significantly increases power draw.
After a kernel update I usually try booting without that parameter to find out if it’s still necessary; today’s kernel seems to have finally fixed the problem. Here’s hoping it never comes back!
If you have hardware affected by this bug, and have been using the parameter as a workaround, you should try booting without amdgpu.dcdebugmask=0x10 and see if your problem is solved.
Fastfetch output for reference:
$ fastfetch -l none
user@host
-------------
OS: Bluefin (Version: 41.20250420 / FROM Fedora Silverblue 41) x86_64
Host: 21MCCTO1WW (ThinkPad T14 Gen 5)
Kernel: Linux 6.13.8-200.fc41.x86_64
Uptime: 23 mins
Packages: 2493 (rpm), 84 (flatpak), 215 (brew)
Shell: bash 5.2.32
Display (LEN414B): 2880x1800 @ 120 Hz (as 1440x900) in 14" [Built-in]
DE: GNOME 47.5
WM: Mutter (Wayland)
WM Theme: adw-gtk3-dark
Theme: adw-gtk3-dark [GTK2/3/4]
Icons: Papirus-Dark [GTK2/3/4]
Font: Inter (10pt) [GTK2/3/4]
Cursor: Bibata-Modern-Ice (24px)
Terminal: Ptyxis 47.12
Terminal Font: CommitMono (10pt)
CPU: AMD Ryzen 7 PRO 8840U (16) @ 5.13 GHz
GPU: AMD Phoenix3 [Integrated]
Memory: 6.33 GiB / 29.99 GiB (21%)
Swap: 0 B / 8.00 GiB (0%)
Disk (/sysroot): 97.93 GiB / 952.27 GiB (10%) - btrfs [Read-only]
Local IP (wlp2s0): 192.168.0.164/24
Battery (5B11H56418): 39% [Charging, AC Connected]
Locale: en_US.UTF-8
thank you, I spent a lot of time asking AI for ideas on how to troubleshoot this and I’m not sure if I was experiencing exactly this but at some point I started seeing stuttering about 5% of the time and it’s been gradually more and more unbearable.
But, the dcdebugmask setting wasn’t it (yes I’m using rpm-ostree kargs to set boot args, this should be called out in /etc/default/grub, IMO).
I have a RX6080XT factory overclocked card, which I think means that the memory clock (as seen in radeontop) is always 100%. I tried disabling freesync on my monitor, I tried various power management amdgpu driver flags. I enabled the gnome variable-refresh-rate experimental setting.. I checked the cable.. I updated bluefin from gts to stable.
I switched over to bazzite-gnome, seeing mention of gnome VRR patches, but that wasn’t it
KDE has the goods. So bazzite:stable. (even with bazzite-gnome having a newer amd-gpu-firmware package of 20250410-1.fc42 where as bazzite:stable has 20250311-1.fc42) . I also do not have this dcdebugmask setting now.
I don’t know if my issue was a combo of the card, a kernel regression, or gnome.
I guess I should try Aurora - I need incus and zfs
just want to mention one more thing: I used Nixola/VRRTest and glxgears to test this. I’m now seeing 239.9 FPS whereas I was seeing 220 FPS before, again don’t know when that degraded.
I started seeing stuttering about 5% of the time and it’s been gradually more and more unbearable
This sounds like a different problem to me; the graphics bug that I was referring to here makes the system completely unusable without the kernel parameter. The symptoms were strange as well; animations, like swiping between desktops or opening windows, were totally smooth. As soon as you started trying to type anywhere though, the screen wouldn’t refresh at all.
The way that I would test whether a kernel update fixed the problem was like this:
Remove the kernel parameter with rpm-ostree kargs --editor
Apply changes and wait for the deployment to complete
Reboot
Log in
Open a terminal
Start typing anything, like cat .bashrc
Try pressing backspace a few times, so that the terminal should have been displaying cat .bas
Observe that “nothing happens” to the text shown on the terminal
Mouse over the terminal window and suddenly, the text updates and you see cat .bas
This would affect basically any window, and if I understand things correctly, it has something to do with the “Panel Self Refresh” not working. The debug parameter amdgpu.dcdebugmask=0x10 forcibly disables this feature, meaning that the entire panel would be refreshed every frame instead of only the area that was changed.
It fixes the problem, but causes a much higher power consumption.
It definitely seems like you’ve been debugging this problem for a while. Did the kernel update fix your issue? If not, I hope you find a solution! I unfortunately don’t have any more insight to offer; my thinkpad is my first-ever AMD machine, and I’m not too knowledgeable about hardware or kernel stuff.
for my issue, I don’t think that a kernel update fixed it because I switched bazzite from gnome to KDE which used the same kernel 6.13.9, at the time, I believe.
when I was debugging I was trying various amdgpu.ppfeaturemask settings under the theory that power saving was kicking in.
currently I’m in Aurora without any amdgpu driver kernel args being set and not seeing any performance issues.