[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #12 from mirh (m...@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. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) --- The dpm code for kaveri is identical for both radeon and amdgpu. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 mirh (m...@protonmail.ch) changed: What|Removed |Added CC||m...@protonmail.ch --- Comment #10 from mirh (m...@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/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c?h=v5.10-rc6#n2833 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #9 from Klaus Maier --- (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. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 John Bridgman changed: What|Removed |Added CC||john.bridgman at amd.com --- Comment #8 from John Bridgman --- >>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. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #7 from Klaus Maier --- 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. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #6 from Klaus Maier --- 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 ... . -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #5 from Alex Deucher --- 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. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #4 from Klaus Maier --- Created attachment 169961 --> https://bugzilla.kernel.org/attachment.cgi?id=169961=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #3 from Klaus Maier --- 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 uvddisabled vcedisabled power level 0sclk: 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 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #2 from Klaus Maier --- 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. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #1 from Michel Dänzer --- Presumably you're using the same backlight brightness in both cases? -- You are receiving this mail because: You are watching the assignee of the bug.
