Created attachment 124464 [details]=
Information about the supported gpu states
Linux 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/L=
inux
I thought my problem was perhaps a duplicate of
https://bugs.freedesktop.org/show_bug.c=
gi?id=3D70654 but I'm pretty sure that
this isn't the same problem. The problem I'm having is that I can't set the
highest frequency state from my gpu (AMD A8-4500M APU + HD 7640G), in a
consistent and persistent way. And this is regardless of whether uvd is ena=
bled
or not (as I assume this is enabled automatically and I haven't been running
any application that requires it)
In other words I would like to be able to set the dpm level to 'high' so th=
at
it stays in the higher frequency state, but I can't set the
power_dpm_force_performance variable to anything other than 'auto' and 'low=
'. I
get the following output:
=CE=BB echo high | sudo tee
/sys/class/drm/card0/device/power_dpm_force_performance_level
high
tee: /sys/class/drm/card0/device/power_dpm_force_performance_level: Invalid
argument
It turns out that after some testing, I have noticed that it's more stable =
to
set 'performance' dpm state and force it to 'low', which leaves the GPU
frequency at ~335MHz, than setting it to auto which makes the frequencies j=
ump
between modes [335/490/655]MHz depending on the load. I would obviously lik=
e to
be able to set a single mode and have a constant frequency. If I can set 65=
5MHz
permanently that would be ideal.
I've already tried using 'dynpm' and 'profile' modes, but they don't work. I
tried a bunch of times, even enabled/disabled some radeon parameters to see=
if
they were somehow conflicting but I wasn't able to succesfully change state=
s a
single time. It would permanently stay at 200MHz with either of these two
profile modes set. That left me with the single choice of using 'dpm', as it
was the only mode that was able to at least change the states.
I was told in IRC that the reason I couldn't set the 'high' value permanent=
ly
was due to a hardware limitation of Trinity chips. I don't see how this can
possibly be true as I can get this same GPU to be consistently at its highe=
st
frequency state in Windows 8. So if anything this is a limitation of the
driver?
I've attached the kernel info about the available states, the list of radeon
parameters and their values in my system, and the output of /proc/cpuinfo. =
As
of now I don't know what else to add so feel free to ask for any additional
information, I'll make it available as soon as I can.