Message-ID: <edfc3586-84fb-4dee-a047-9f204054e6f2@kernel.org>
Date: Sat, 6 Dec 2025 18:31:46 -0600
From: Mario Limonciello <superm1@...nel.org>
To: Antheas Kapenekakis <lkml@...heas.dev>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 Robert Beckett <bob.beckett@...labora.com>, linux-acpi@...r.kernel.org,
 kernel@...labora.com, linux-kernel@...r.kernel.org,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Xaver Hugl <xaver.hugl@...il.com>, Richard Hughes <richard@...hsie.com>,
 William Jon McCann <mccann@....edu>, "Jaap A . Haitsma" <jaap@...tsma.org>,
 Benjamin Canou <bookeldor@...il.com>, Bastien Nocera <hadess@...ess.net>,
 systemd-devel@...ts.freedesktop.org,
 Lennart Poettering <lennart@...ttering.net>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs
 interface



On 12/6/25 5:35 PM, Antheas Kapenekakis wrote:
> On Sat, 6 Dec 2025 at 21:50, Mario Limonciello <superm1@...nel.org> wrote:
>>
>>>> I will reply to the earlier reply from Rafael with more context, but
>>>> runtime suspend of the GPU is not part of or related to these
>>>> notifications.
>>>
>>> Of course it isn't.
>>>
>>> What we were talking about was how to get from the "displays off, no
>>> GUI activity" user space smoothly into system suspend and back.
>>>
>>> You are saying that this has been done already on AMD, so I'm not sure
>>> why you want more.
>>>
>>
>> I'm not aware this existing in any unique way for AMD.  The decision of
>> displays off; start a timer and enter suspend would be the same for any
>> vendor.
> 
> AMD retains CRTC DPMS state from userspace to s0ix currently, and you
> fixed hibernation recently too. Intel sometimes doesn't, the screen
> will sometimes flash while entering suspend.

I was talking about what Rafael said.  "What we were talking about was 
how to get from the displays off no guid activity user space smoothly 
into system suspend and back".

> 
> There is also runtime suspend on most components. Is there a case for
> powering off the iGPU completely to improve energy use?
> 

I don't really *think& there will be much of a difference.  We already 
go into GFXOFF when GC is idle, and SDMA, VCN, JPEG and VPE will be 
clock gated when not in use.

Someone would have to do power profiling to see if it's significant 
enough difference to justify it.  The easiest way to check would be:
1) Turn off all displays
2) Connect over SSH
3) Collect a RAPL power measurement for the package.
4) Unbind the PCI device from amdgpu
5) Collect a RAPL power measurement for the package.
6) Compare 3 and 5.

> The most expensive component in this process is unfreezing, then
> runtime pm freezing the GPU IP blocks after s0ix exit, then unfreezing
> it two seconds later to perform runtime checks and freezing it again.
> So for multiple exits from suspend where the IP is inactive this will
> keep repeating.

I think we would set the auto-suspend delay appropriately if we did this 
and use DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME in this case.

> 
>> But GPUs aren't only used for display.  If you're actively running a
>> different workload (for example an LLM) using the GPU and happen to turn
>> off all the displays you wouldn't want it to suspend.
>>
>> What you would want is to key off:
>>
>> 1) All displays are off.
>> 2) All GPUs are unsused.
>> 3) Some time has passed.
>>
>> I feel that if userspace is going to adopt a policy like this kernel
>> drivers need to use runtime PM when displays are off and the GPUs aren't
>> being used for anything else.
>>
>> At least for AMD this doesn't happen today and would require driver
>> work.  But the same kind of work would be needed by any GPU driver.
>>
> 
> You could potentially do that, first you'd need to show that there is
> a latency benefit to powering off the GPU over entering s0ix (as
> userspace will be frozen in both cases for the GPU to suspend). Then,
> you'd need to show that there is an energy benefit over just staying
> unsuspended with userspace frozen and the GPU being in runtime
> suspend. WIth both of these, a case could be made for powering off the
> GPU completely for a marginal latency/energy benefit.
> 
> These notifications do not affect runtime pm though so this discussion
> is a bit tangential.
> 

I'm not worried about the latency.  We can change the policy for the 
autosuspend delay if latency is a problem.

If we added runtime suspend support to integrated GPUs this sounds like 
a really good thing to key off for that "display off notification" that 
started this whole thread.

Some infrastructure could be added so DRM core could monitor runtime 
status for all GPUs on the system.  If they're all in runtime PM it 
could use an exported symbol to send LPS0 screen off and when any one of 
them exits then send LPS0 screen on.

Powered by blists - more mailing lists