Power-saving/performance toggles for amdgpu

[Bastien Nocera]

On Fri, 2021-08-06 at 11:08 -0400, Alex Deucher wrote:
> On Fri, Aug 6, 2021 at 10:29 AM Bastien Nocera <hadess at hadess.net>
> wrote:
> > 
> > Nearly a year later, hello again, :)
> > 
> > On Mon, 2020-09-14 at 01:46 -0400, Alex Deucher wrote:
> > > On older radeons (e.g., pre-GCN hardware), there were separate
> > > power
> > > states for battery and AC, but these asics are supported by the
> > > radeon
> > > kernel driver.  None of the hardware supported by amdgpu exposes
> > > anything like that anymore.  The rest is mainly for profiling and
> > > debugging.  For more information see the relevant kernel
> > > documentation:
> > > https://www.kernel.org/doc/html/latest/gpu/amdgpu.html#gpu-power-thermal-controls-and-monitoring
> > > I don't think there is anything you'd want to tweak there.
> > 
> > Is the power_dpm_force_performance_level sysfs property for the
> > amdgpu
> > driver not something that one could tweak?
> > https://www.kernel.org/doc/html/latest/gpu/amdgpu.html#power-dpm-force-performance-level
> > 
> > System76's own power management daemon changes it:
> > https://github.com/pop-os/system76-power/blob/master/src/radeon.rs
> > 
> > So I'm wondering whether it would have any effect, for example, I
> > would
> > expect setting "high" when a performance mode is requested so that
> > there's little latency in terms of frequency switching, "low" to
> > force
> > minimal power draw in a power saving mode, and "auto" the rest of
> > the
> > time.
> 
> One could, but it's mainly there for debugging or profiling.  There
> is
> a microcontroller on the GPU that dynamically adjusts the clocks and
> voltages at runtime based on GPU load.  It's tuned to do a good job
> in
> as many cases as possible by default.  If you really want to tweak
> things, it would probably be better to adjust pp_power_profile_mode.
> That has a bunch of preset profiles (or you can specify a custom one)
> that adjust the heuristics (how quickly the clocks ramp up/down,
> etc.)
> for the dynamic reclocking done by the GPU.

But the microcontroller doesn't really know user-intent, and can't
really predict the future, which is the reason why a lot of OSes still
have power profile selection knobs.

So I'm mostly wondering whether:
- those clock ramping transitions could be a problem on heavy workloads
with varying intensity, say stuttering in a game that needs to be able
to go from simple to really complicated in short order
- setting the minimum clock would avoid short bursts of activity
clocking up then down (in a GPU-based desktop environment for example),
thus reducing the battery life

>   That said, for most
> workloads, I doubt you'll see much of a change.

I would indeed expect "automatic" to work as expected, but not always
be what the user intends for the GPU to be doing.

>   When the GPU is idle,
> clock and power gating kick in for most blocks and we also support
> runtime power management so the dGPU will effectively get turned off
> if it's idle.  The only tricky part with runtime power management, is
> that we can't enable it if the framebuffer console is enabled because
> the kernel keeps a persistent kmap of the framebuffer, so we can't
> power down the GPU because we never know when an access might come
> in.
> We probably need some sort of deferred IO or shadow framebuffer
> design
> to handle that, but we haven't had time to delve into fixing that.
> 
> Alex