Bug 94061
| Summary: | [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Klaus Maier (abcdmail) |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | NEW --- | ||
| Severity: | normal | CC: | alexdeucher, john.bridgman, mirh, szg00000 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.14.x ... 3.19. | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | dmesg | ||
|
Description
Klaus Maier
2015-03-01 12:26:19 UTC
Presumably you're using the same backlight brightness in both cases? 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. 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 Created attachment 169961 [details]
dmesg
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. 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 ... . 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. >>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.
(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. 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 The dpm code for kaveri is identical for both radeon and amdgpu. 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. |