Bug 470376

Summary:	kscreenlocker unnecessarily uses discrete GPU when integrated GPU is available
Product:	[Plasma] plasmashell	Reporter:	David Koppelman <dmkoppelman>
Component:	Screen locking	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	nate
Priority:	NOR
Version First Reported In:	6.2.4
Target Milestone:	1.0
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:	6.3.5 or earlier
Sentry Crash Report:

Description David Koppelman 2023-05-28 19:52:02 UTC

SUMMARY

I have a laptop with both an integrated and discrete GPU set up so
that the discrete GPU is only used by programs with certain
environment variables set (e.g, __NV_PRIME_RENDER_OFFLOAD). The intent
is to use the GPU only for graphics- or compute-intensive programs. At
other times the GPU is suspended, saving energy.

This works well most of the time, an exception is when the screen is
locked using kscreenlocker. While the screen is locked the discrete
GPU is active, wasting energy. This happens on AC, I have not tried it
on battery power.

It would be nice if kscreenlocker could avoid waking up the GPU so
that it remains suspended while the screen is locked.



STEPS TO REPRODUCE

1. Start with a system with both an integrated GPU and an NVidia
discrete GPU. Set up the system for render offloading.

2. Verify that discrete GPU is only being used where intended by
executing: cat /sys/devices/pciPATH-TO-GPU/power/runtime_status
(The file's contents is either "active" or "suspended".)

3. Wait for the screen to lock.

4. Check status by logging in from another system or unlock and cat
the runtime_status file. 

OBSERVED RESULT

The contents of runtime_status was "active". After the GPU is
unlocked it returns to "suspended". (In my case the keyboard is
noticeably warm with the GPU running.)

EXPECTED RESULT

The contents of runtime_status is "suspended".

SOFTWARE/OS VERSION

This occurs on a Dell Precision 7680 (and 7560), both with integrated
and discrete (NVidia) GPUs.

Fedora 38
KDE 5.27.5
Qt: 5.15.9
KDE Frameworks: 5.106.0
NVIDIA binary drivers. 
The problem occurs both under X11 and Wayland. 

ADDITIONAL INFORMATION

Other programs, such as Chrome and kwin do not use the discrete GPU
(without the environment variables et). (Chrome, for example, uses the
discrete GPU only if started with __NV_PRIME_RENDER_OFFLOAD=1 set in
the environment.)

Comment 1 Nate Graham 2023-05-31 20:22:34 UTC

In general, how do you determine which GPU an app uses? I'm not very familiar with this type of hardware.

Comment 2 David Koppelman 2023-05-31 20:48:32 UTC

When a system is set up for what Nvidia calls prime render offload, applications by default will use the integrated GPU. In order to use the discrete GPU the application has to have certain environment variables set, usually __NV_PRIME_RENDER_OFFLOAD=1, though others need to be set for Vulkan applications. For details see Chapter 35 in the Nvidia driver readme:

http://us.download.nvidia.com/XFree86/Linux-x86_64/530.41.03/README/primerenderoffload.html

On my system I only want to use the discrete GPU for graphics intensive applications. I do that by starting these applications with a script that sets the environment variables before launching the application or by appropriate .gdbinit settings (if I'm debugging one of those applications).

Comment 3 Nate Graham 2023-06-02 20:16:20 UTC

Thanks. Out of curiosity, does the discrete GPU also render the logout screen? The thing that appears when you click "Shut Down." If so, then I'm guessing the shader-based blur effects they both use are triggering the behavior.

Comment 4 David Koppelman 2023-06-03 22:14:40 UTC

(In reply to Nate Graham from comment #3)
> Thanks. Out of curiosity, does the discrete GPU also render the logout
> screen? The thing that appears when you click "Shut Down." If so, then I'm
> guessing the shader-based blur effects they both use are triggering the
> behavior.

The discrete GPU remains suspended after selecting both shut-down and
logout. When I select either of these I get a confirmation screen. The
confirmation screen has a black background and no obvious blur
effect. After selecting cancel I check the output a GPU status logger
which had been checking every half second, and it shows that the GPU
remained suspended. (After being used the discrete GPU remains active
for several seconds before suspending, so it's likely I missed
anything.)

BTW, I have the wobbly windows effect active and composited window
shadows, and neither results in the discrete GPU being activated.

Comment 5 David Koppelman 2023-06-03 22:16:39 UTC

I meant that it's *not* likely I missed anything, due to the multi-second inactivity to suspend time.

Comment 6 Nate Graham 2023-06-06 15:54:27 UTC

Thanks for the info.

Comment 7 Nate Graham 2025-05-29 16:52:44 UTC

Thanks for the bug report, and I'm sorry we weren't able to figure this out yet. A lot has changed since this was reported; can you still reproduce the issue in Plasma 6.3.5 or later? Or even better, in the Plasma 6.4 beta or the 6.4 final release in a few weeks?

Thanks again!

Comment 8 David Koppelman 2025-05-29 19:12:59 UTC

(In reply to Nate Graham from comment #7)
> Thanks for the bug report, and I'm sorry we weren't able to figure this out
> yet. A lot has changed since this was reported; can you still reproduce the
> issue in Plasma 6.3.5 or later? Or even better, in the Plasma 6.4 beta or
> the 6.4 final release in a few weeks?
> 
> Thanks again!

In Plasma 6.3.5 I don't experience the problem (the dGPU does not wake up when the lock screen is shown nor when it is unlocked). I don't remember when the problem went away.  So I consider the problem properly resolved.

Comment 9 Nate Graham 2025-05-29 19:16:56 UTC

That's great; thanks so much for following up!