Bug 94061 - [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
Summary: [radeon - Kaveri] dpm works badly - much to high power consumption compared t...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-01 12:26 UTC by Klaus Maier
Modified: 2020-12-03 20:02 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.14.x ... 3.19.
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (67.49 KB, text/plain)
2015-03-09 11:41 UTC, Klaus Maier
Details

Description Klaus Maier 2015-03-01 12:26:19 UTC
With all kernel versions >= 3.14 (I didn't test versions below), radeon / dpm consumes about 6 W more compared to catalyst in idle mode (X-server 1.15 / 1.16) with Kaveri graphics (AMD A10-7800 Radeon R7).

Idle mode: Xorg runs (KDE 4.11.x), screen saver off, static screen, load: 0.0

If the screen is turned off by X, the power consumption finally reaches the same level as with catalyst. It's raising immediately again at the moment the screen is switched on again by X.

Seams the lowest rate is never reached as long as even a static screen has to be drawn - but it should!
Comment 1 Michel Dänzer 2015-03-02 07:01:49 UTC
Presumably you're using the same backlight brightness in both cases?
Comment 2 Klaus Maier 2015-03-02 15:50:05 UTC
Yes - backlight management is switched off because it doesn't work at all w/ catalyst. Always full. Brightness, ... - it's all configured by the monitor itself. Management via KDE or software is done only for on or off (switching monitor to standby) - nothing more.
Comment 3 Klaus Maier 2015-03-09 11:39:22 UTC
Retested with 4.0 rc2

Now, the graphic unit consumes even more power (3W more) when radeon is loaded compared to not loaded radeon.

cat /sys/kernel/debug/dri/0/radeon_pm_info
uvd    disabled
vce    disabled
power level 0    sclk: 35122 vddc: 4850

cat /sys/class/drm/card0/device/power_profile
default

cat power_dpm_force_performance_level
auto

cat power_dpm_state
balanced

cat power_method
dpm
Comment 4 Klaus Maier 2015-03-09 11:41:33 UTC
Created attachment 169961 [details]
dmesg
Comment 5 Alex Deucher 2015-03-09 13:39:25 UTC
You can enable bapm (append radeon.bapm=1 to the kernel command line in grub) which may help.  However, it has caused stability problems on some systems which is why it is not yet enabled be default.  Same goes for some of the clock and powergating features.  See the settings of rdev->cg_flags and rdev->pg_flags in radeon_asic.c.
Comment 6 Klaus Maier 2015-03-09 15:14:40 UTC
radeon.bapm=1 brings back the originally reported behaviour (based on 3.14). 

I didn't enable rdev->cg_flags and rdev->pg_flags as it is already known to be broken because it needs a complete kernel recompile.

The relevant code already was in 3.12, which was released 2013-11-03.

When will there be a fix? It is working w/ Catalyst. Why not w/ radeon? Both drivers are made by AMD finally ... .
Comment 7 Klaus Maier 2015-04-04 09:17:10 UTC
Tested your suggestion to activate the powergating by removing the comments you mentioned above w/ 3.19.3 and radeon.bapm=1. This even raised the power consumption about 5 W more as w/o it. This "feature" is completely broken.

I recompiled the *complete* kernel to test your suggestion. This is a pain. Is there an external radeon module which can be compiled outside of the complete kernel and which can be used with more than one kernel version - like fglrx?

It's much more easy to change the complete video stack with catalyst as with radeon. The radeon stack architecture is completely unusable because it is spread over the whole system and I even have to always change the complete kernel if there is a problem w/ the graphics driver. The kernel change most often results in other problems w/ other hardware which is broken on other versions because of missing QA.

Another question: Why can't you see this while programming? Didn't you check your code w/ a ammeter?

According to http://xorg.freedesktop.org/wiki/RadeonFeature/ DPM is done for Kaveri. This is obviously wrong and you know about it but you're nevertheless claiming the opposite.
Comment 8 John Bridgman 2015-04-04 17:28:34 UTC
>>Is there an external radeon module which can be compiled outside of the
>>complete kernel and which can be used with more than one kernel version -
>>like fglrx?

Upstream kernel drivers are coded for the kernel version that they live in, ie kernel core and kernel drivers evolve together. Not sure if code to support other kernel versions is absolutely forbidden or just very strongly discouraged but I don't think any upstream driver includes support for other kernel versions today.
Comment 9 Klaus Maier 2015-04-04 20:49:08 UTC
(In reply to John Bridgman from comment #8)

> Upstream kernel drivers are coded for the kernel version that they live in.

That exactly is the problem - the missing downward compatibility. But there are a lot of drivers which can be used w/ older kernels:

https://www.kernel.org/pub/linux/kernel/projects/backports/stable/

This makes it possible to run the old working kernel w/o having the need to run a bleeding edge kernel which most of the time breaks some other devices (as w/ 3.19., which breaks USB on boot up here). And it makes it possible to compile just the module which is needed - de facto the same handling as it is provided by Catalyst.
Comment 10 mirh 2020-12-03 17:49:56 UTC
Stable kernels are stable exactly because you don't backport too much sensitive cruft..

Anyway, while bapm is still disabled by default on radeon on kaveri, am I right to understand that if you switch to amdgpu it's good to go?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c?h=v5.10-rc6#n2833
Comment 11 Alex Deucher 2020-12-03 18:02:12 UTC
The dpm code for kaveri is identical for both radeon and amdgpu.
Comment 12 mirh 2020-12-03 20:02:45 UTC
I see that [amdgpu_]kv_smc_bapm_enable is equivalent, but the condition guarding it seems quite different. 

Then I'm not really pretending to understand much else about the two kv_dpms.

Note You need to log in before you can comment on or make changes to this bug.