DEVICE: Framework Laptop 16 with 7840HS and RX 7700S
I recently purchased the AMD graphics module for my Framework laptop and noticed some weird slowness, particularly in opening my terminal emulators. I generally like to have multiple TE’s running and thus would regularly open multiple instances. I noticed recently with kitty, alacritty and konsole that it would hang for a second before opening. I was able to record this behavior using alacritty -v
As you can see on the fourth line, there was something happening between it loading the config and EGL being activated. If I were to open a terminal emulator window right after this, however, it would open normally. Only after resting for a moment does this behavior occur. This happens accross multiple softwares (I’ve noticed: Firefox, Discord, Konsole, Kitty, Alacritty, Wezterm, Dolphin.)
I’ve seen this behavior on Niri window manager and KDE plasma wayland. It might only happen on wayland sessions. I presumed steam would also be affected, but it isn’t and opens at a reasonable speed, which led me to theorize that xwayland/x11 sessions might be fine. If anyone knows how to remedy or fix this problem, please let me know.
So I know the reason for this is that the application is waiting for the dGPU to come out of the suspended state, which takes a second or two, and by default the dGPU will only stay active for 5 seconds if no application is using it. The annoying part is that some applications (ive noticed at least kitty, firefox, mpv) wait for the dGPU even if they’re only going to be using the iGPU.
Assuming your system lays PCIe devices out the same way as mine, you can run this command in a terminal window to see what the dGPU is doing in terms of power state:
This checks the power status of the dGPU every 0.5 seconds, and highlights the output text when there is a change, to make it easier to notice.
In terms of solutions, I’m not sure there’s an easy one.
Looking into mpv, I thought forcing a specific GPU device would prevent it from looking for the dGPU, but mpv checks all available render devices for capabilities when it starts - which means it has to wait for the dGPU to start up.
I assume most of the applications that suffer the delay have similar behaviour.
The quick and dirty fix is to keep something like nvtoprunning in a minimised terminal window, as it prevents the dGPU from going into suspend, meaning no apps will have to wait for it to wake up. Obviously this comes at a small but non-trivial power cost.
I haven’t looked into it yet, but there’s almost certainly a way to prevent dGPU from suspending when plugged into a charger, and allow it to suspend when on battery - this is probably be the simplest, lowest-compromise setup I can think of.
This is anecdotal knowledge, but I remember sth about vulkan/gtk/etc querying all GPUs. In turn this means that if your dGPU is in D3cold (which it should be there for majority of the time), every time you open an application that inits a GPU, it has to wait until the dGPU wakes up.
There is a bug report already filed for GTK/vulkan.
