Comme=
nt # 172
on bug 91880<=
/a>
from <=
span class=3D"fn">Jon Doane
(In reply to Thomas DEBESSE from comment #171)
> > This sounds a lot like what I've been doing=
manually which sounds nice.
> > Thanks for the input. I honestly would like a solution that doesn=
't cause my
> > machine to draw an additional 90 watts at idle though.
>=20
> Unlike the kernel patch above, that systemd service is setting the GPU=
to
> "low battery" by default, which is the most energy saving pr=
ofile. The
> provided `dpm query` tool allows you to change that at any time. That'=
s what
> I'm doing: at init, my GPU is set to "low battery" profile, =
and when I need
> to do some heavy time, I do that:
>=20
> dpm-query set all high performance
>=20
> And then once the heavy task is done, I do that to save energy again:
>=20
> dpm-query set all low battery
>=20
> With the default config for the service, you just have to add your own=
user
> to the "video" group to have the right to change the profile=
as user.
>=20
> So, even if the patch above get merged one day, this service and tool =
is
> still useful, it's an easy way to change the default profile, whatever=
the
> default is.
>=20
> Notice that the kernel patch above only set the level to "high&qu=
ot;, but keep
> the state to "balanced", so it's still adaptative. What &quo=
t;high balanced" does
> is setting the shader and memory frequencies to the max, which is draw=
ing
> more power than default, but you will notice the fan are still idling =
and
> stopped if you do nothing because it's still saving a lot of energy. I=
f you
> set "high performance" the fan will almost instantaneously s=
tart because
> there is no saving anymore. So "high balanced" is less energ=
y saving that
> "auto balanced", but is still saving a lot of energy because=
it does not
> have to cold the chip while doing nothing (meaning the chip does nothi=
ng
> strong enough to get hot).
Unless something has changed with how the dpm state is handled, I don't exp=
ect
that to make the system completely stable. They're more stable than balanced
but, it's not stable enough to prevent a crash. I tried by starting off wit=
h:
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level
The only method that I've had luck with while retaining clock scaling is th=
is:
echo 234567 > /sys/class/drm/card0/device/pp_dpm_sclk
This disables the 300Mhz clock step which seems to work however, I've obser=
ved
that doing this also forced memory clocks to full tilt instead of idle so, =
I'm
uncertain if the memory clock or core clock is responsible.
Something I've observed is that if my machine crashes and I use the reset
button to restart it, that when X loads and if I don't force clocks up, it
always crashes and that part of the old image that was on the screen when it
initially crashed gets displayed, albeit rather garbled but, enough to iden=
tify
it which makes me think that it's related to the memory clock or how GPU me=
mory
is managed.
One way or another, I have ways around the problem but, these are hacks that
would be considered intolerable solutions by a regular user.