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.)
In general, how do you determine which GPU an app uses? I'm not very familiar with this type of hardware.
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).
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.
(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.
I meant that it's *not* likely I missed anything, due to the multi-second inactivity to suspend time.
Thanks for the info.
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 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.
That's great; thanks so much for following up!