@Mario_Limonciello There seems to be a problem with the amdgpu driver in linux kernel 6.12 (using Fedora 40, Gnome Shell 46.7).
Whatever has changed in the amdgpu driver (from 6.11 to 6.12), the display is now noticeably and annoyingly choppy/slow/laggy when using the internal laptop display.
Scrolling a static webpage from rest used to be smooth under 6.11, but with 6.12 it takes a short but noticeable time period for the display to react, resulting in the scrolling being choppy at the start. Quite annoying.
The same thing happens with the mouse cursor. From rest it noticeably jumps, before having smooth movement again. It’s as if it’s missing a noticeable number of frames.
Similarly for typing. If there is no change on the screen for about a second or two and then typing starts, the first few letters being typed feel like they’re going through a slow remote connection.
All of this suggest that part of the GPU is sleeping on static content, and it takes too long to wake up in order to be responsive.
The choppiness does not seem to occur when the laptop is plugged into an external display and under mains power. The lag is also less noticeable when the display is active in some way, such as a video playing in another window.
Can you restore the smooth display behaviour that we have in kernel 6.11?
There are regressions all the time in the kernel. Like every single one, a lot more detail is needed to get down to what the actual issue is and if it’s still present.
Are you on the latest 6.12.y (6.12.8 at the time of writing)? Did it not happen on the last 6.11.y before that went EoL (6.11.11)? Is it a regression from 6.12 to 6.12.8?
Are you sure it’s a kernel change and not a mesa change causing it?
What power mode are you in? Balanced? This could be specifically from power profiles policy (different on AC vs DC).
Does it only happen in GNOME? Or does it in happen in KDE too? It could be a compositor bug if it’s just one or the other.
Is this a Framework 13 or 16? I see it’s posted in Framework 13 section but if it’s a 16 it could be panel replay.
As you can see a lot of questions. I don’t have a direct answer for you on where the regression is, but hopefully that can help narrow things down. If you’re sure it’s the kernel, I suggest bisecting it.
FWIW - I am currently booted into 6.12.7 on a Framework 13 running plasma CachyOS (Arch linux based) and I don’t have this behavior you describe.
plugging in power (but no external display) does not fix the problem
tested only in Gnome + Mutter 46.7 (I don’t use KDE)
internal display set to 1920x1200, 60Hz
fractional scaling not enabled
Mesa 24.1.7
No changes to Mesa version - I only updated the kernel.
Rebooting into 6.11.11 reliably fixes the problem. This strongly suggests the bug is in 6.12.7; it is also present in 6.12.6, and likely in earlier 6.12.x versions.
I suspect the bug is closely related to the following issue on freedesktop dot org, though the jerkiness/laginess is definitely present at 60Hz for me:
battery power + plugging in external display (2560x1440 @ 59.95 Hz) does not fix the issue on the internal display
mains power + no external display does not fix the issue on the internal display
mains power + plugging external display seems to fix the issue on the internal display (EDIT: issue still present even with mains power + external display)
Could you try building that specific hash identified and the one before it and see if it’s the same root cause? If so; it’s best to follow along there. If it’s something different, then I think it would be best for you to perform your own bisect (don’t forget to include the results from those two tested hashed though to rule out more steps!)
@Mario_Limonciello I don’t have the bandwidth for bisection, though I can 100% confirm the bug is in kernel 6.12.7 and is not in kernel 6.11.11.
Will report results from “balanced” vs “powersave” when time allows.
I understand that open source development can be a bit messy, though I wish the changes in amdgpu weren’t so drastic between kernel versions, especially for well-established RDNA 2 and 3 hardware.
Drivers should be getting more stable with age, not less stable. If stuff works, don’t break it.
Perhaps fence off the required changes for RDNA 3.5/4 from stuff that is know to work well with RDNA 2/3 ? Or have more thorough testing before pushing the changes to the upstream kernel?
Either way, less mucking around with drivers would be beneficial. Regressions like this really give a sour taste in the mouth.
Are we sure this is happening due to video drivers? I had the same keyboard/mouse lag issue these days and it seems to only happen to devices that are plugged to my FW through a USB dongle (Logitech). Doesn’t matter if they are plugged directly or through a dock. Maybe it has something to do with a bit too fast USB auto suspend? Same devices connected through Bluetooth work normally without issues. I’m on KDE though.
I’ve been on Bluefin for a while and decided to check out Fedora 41 again on the FW13 AMD. On the most recent kernel (6.12.8) the display is noticeably choppy when both internal and external displays are enabled. No issues if only one of the displays is enabled. Bluefin was on 6.11.8 so no issues there.