On Fri, 2021-08-06 at 11:08 -0400, Alex Deucher wrote: > On Fri, Aug 6, 2021 at 10:29 AM Bastien Nocera <hadess@xxxxxxxxxx> > 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
