On 12/6/25 5:35 PM, Antheas Kapenekakis wrote:
On Sat, 6 Dec 2025 at 21:50, Mario Limonciello <[email protected]> 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.
