[Bug 94061] New: [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061
Bug ID: 94061 Summary: [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst Product: Drivers Version: 2.5 Kernel Version: 3.14.x ... 3.19. Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: abcdmail@freenet.de Regression: No
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!
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #1 from Michel Dänzer michel@daenzer.net --- Presumably you're using the same backlight brightness in both cases?
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #2 from Klaus Maier abcdmail@freenet.de --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #3 from Klaus Maier abcdmail@freenet.de --- 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
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #4 from Klaus Maier abcdmail@freenet.de --- Created attachment 169961 --> https://bugzilla.kernel.org/attachment.cgi?id=169961&action=edit dmesg
https://bugzilla.kernel.org/show_bug.cgi?id=94061
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com
--- Comment #5 from Alex Deucher alexdeucher@gmail.com --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #6 from Klaus Maier abcdmail@freenet.de --- 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 ... .
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #7 from Klaus Maier abcdmail@freenet.de --- 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.
https://bugzilla.kernel.org/show_bug.cgi?id=94061
John Bridgman john.bridgman@amd.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |john.bridgman@amd.com
--- Comment #8 from John Bridgman john.bridgman@amd.com ---
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.
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #9 from Klaus Maier abcdmail@freenet.de --- (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.
https://bugzilla.kernel.org/show_bug.cgi?id=94061
mirh (mirh@protonmail.ch) changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
--- Comment #10 from mirh (mirh@protonmail.ch) --- 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/driv...
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #11 from Alex Deucher (alexdeucher@gmail.com) --- The dpm code for kaveri is identical for both radeon and amdgpu.
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #12 from mirh (mirh@protonmail.ch) --- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org