GPU has a very high load if the monitor is turned off by KDE

[Duncan]

Qu Wenruo posted on Mon, 2 Mar 2026 10:25:31 +1030 as excerpted:

> 在 2026/2/28 09:49, Qu Wenruo 写道:
>> 
>> 
>> 在 2026/2/28 09:26, Qu Wenruo 写道:
>>>
>>>
>>> 在 2026/2/28 07:53, Qu Wenruo 写道:
>>>> Hi,
>>>>
>>>> Recently I upgraded my Arch with the following package updates:
>>>>
>>>> - Plasma (6.6.0-1 -> 6.6.1-1)
>>>> - Kernel (6.18.6 -> 6.18.9)
>>>>
>>>> Both are minor updates thus I thought it should be mostly smooth
>>>> sailing.
>>>>
>>>> But after the update, after the monitor is turned off after a timeout
>>>> (10min in my case), the fan of my GPU ramp up.
>>>> This also happens when my system is put into suspension.
>>>>
>>>> Unfortunately the behavior is not 100% reproducible, but still
>>>> frequently enough to notice the noisy fan running.
>>>
>>> Downgrading kernel ruled out the kernel bug.
>>>
>>> And I have tried 3 times to suspend, and can reproduce the high GPU
>>> load 3 times.
>>>
>>> Another thing I noticed is, previous when suspending, the eGPU seems
>>> to be completely shutdown (only the power LED lights up, the work LED
>>> shut down).
>>>
>>> But now when suspension happened, the eGPU doesn't shutdown at all,
>>> just with its fan ramping up.
>>>
>>> Will try downgrading the firmware as the next step just in case.
>> 
>> Blacklisting the amdxdna module solves the suspension problem at least.
> 
> Meanwhile for the monitor off high GPU usage, even with the xdna driver
> blacklisted, tried different kernel (LTS, the last working one, the
> latest) and firmware (the last working one with the latest), all the
> same high GPU usage when the monitor is off.
> 
> So this looks more like something in the KDE part.
> 
> Thanks,
> Qu

So I'm being lazy and replying at the convenient point without editing the 
context to what I'm replying to...

[As I'm about to post it occurs to me that as a dev, a kernel dev even, 
while I'm an experienced gentooer but NOT a dev, parts of this are likely 
insultingly obvious to you.  Please don't take offense but I'm posting as-
is anyway, because experience says when I try to take stuff out the fix 
inevitably ends up being in a path I deleted from my original reply... and 
we end up covering it after all.  Plus I'm late to work and want to have 
this posted...]

As you may remember I was active on the btrfs lists for a time... and had 
to blink a few times trying to think if I was in a Groundhog Day (deja vu 
movie) or what.

Anyway, as a list regular (tho I only update every couple weeks or so, 
thus missing the thread until now) nice to see you here. =:^)

So my viewpoint is gentoo, running most of kde (frameworks/plasma/apps) 
from live-git sources using the gentoo/kde overlay ebuilds for that 
purpose.  So I'm typically running slightly ahead of your Arch's usual 
latest-release, but with monthly releases, not by much.  Hardware-wise, 
however, the system's decade-old, amd fx6100, amdgpu polaris-11 (IIRC 
Radeon rx4600/rx5500 or so, but I've long forgotten exactly and as I've 
been kwin_wayland for years now, I don't have the xorg.log info that used 
to specify that, with kernel dmesg only saying polaris-11.)  Both are amd 
like yours but well earlier than your hardware.  On the bonus side I don't 
have your "stupid NPU/AI thing" to worry about. =:^)  (Plus, kernel-wise I 
do a monolithic build and build-in amdgpu and the related model-specific 
firmware but not AI modules (because even if I did have the hardware I 
tend to agree with the opinion you expressed), so likely wouldn't have 
amdxdna available for the kernel to screw with in any case.)

Back to software, meanwhile, one of the big benefits of running live-git 
is that I can more easily follow development directly via git commit logs 
(in addition to doing bisects as required, etc), which is where this reply 
comes in.

While I've not followed specifics likely to relate to your specific 
complaint (in part due to the old hardware), what I *can* say from 
following the git logs is that kwin (presumably kwin_wayland in both our 
cases, as opposed to the now split off kwin_x11) continues to undergo some 
rather assertive modernization, supporting color-accurate profiles and a 
whole slew of other newer features, progressively moving various bits of 
its multi-monitor support (that I *do* use, 3 4k bigscreen TVs as monitors 
altho they're cheap 60 Hz models) down to per-output layers from 
originally global layers, eliminating legacy X-specific stuff in the now 
split kwin wayland code, etc.

Thus I'd say it's quite likely your culprit is the kwin package and has to 
do with some of this rather aggressively modernized (and likely to 
continue as such for awhile, at least into plasma 6.8 which is planned to 
drop xorg support, keeping only xwayland for legacy X support) new code.

I don't know how locked down the versioning (both at the kde-plasma/
frameworks and arch-pkg levels) is, but if it's possible, you might try 
reverting just kwin to the older 6.6.0 from 6.6.1.  Being an update-
release only jump on the 6.6 feature series, there's at least some chance 
just regressing kwin itself might work, and that's what I'd try.

The other package possibility is that it's something to do with solid 
(framework level) and the plasma-level device and power-management (I 
forgot what the plasma-level package name is) stuff that I have disabled 
(not even installed or linked against but for the mandatory-dep solid, 
using gentoo's USE flags to disable it at build time) as I'm on a desktop 
system and use the TV's off buttons to shut off just the displays only or 
(not often) simply turn off the computer, here.  Obviously I'm not 
following that stuff at all to see what's changing there, so wouldn't 
know.  But were I to be putting money on it I'd still say kwin, because 
kwin has some of the fastest and deepest-degree changing code in kde, 
period, has for awhile, and will for awhile, and that *will* have follow-
on effects, at times.

If you can nail it down to kwin that'll help and you can file a bug as 
appropriate.  Naturally, if you can build that package from git and bisect 
it'd be ideal, but just the kwin package only and just 6.6.0 to 6.6.1 
should already be quite helpful, and should /hopefully/ be possible.

Of course (especially if git isn't practical for you) there's also the 
possibility of trying the reverse, all 6.6.0 but try upgrading only kwin 
to 6.6.1.  That's worth a try to, especially if all 6.6.1 but reverting 
kwin only to 6.6.0 doesn't work.

And of course being a dev and with an eye toward your specific problem, 
you might try just looking at the kwin git logs between those versions 
too, even without building it.  It's possible the culprit will leap out at 
you, and given you're a dev, I'd assume that to be more likely than it 
would be for me, tho as you're not following it routinely as I do, I 
suppose the chances more or less balance each other out.  Tho with the 
level of active changes kwin has a leap-out from the git log obviously 
won't be as likely as it would be on a less actively changing package.

>> I can not hate the stupid NPU/AI thing more.
>> 
>> Thanks,
>> Qu
>> 
>> 
>>> Thanks,
>>> Qu
>>>
>>>
>>>>
>>>> The involved platform is:
>>>>
>>>> CPU: AMD Ryzen AI 9 HX 370 w/ Radeon 890M iGPU: Radeon 890M eGPU: RX
>>>> 7600M XT
>>>>        OcuLink eGPU from Aoostar
>>>>
>>>> All monitors are connected to that eGPU.
>>>>
>>>> Any clue on what to test next? Is it something related to KDE or the
>>>> kernel?
>>>>
>>>> Thanks,
>>>> Qu
>>>
>>>





-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman