Kernel 6.7? If so I’ve got another patch for you
1 Like
Yes, Kernel 6.7.4
This patch is also applied
https://patchwork.kernel.org/project/chrome-platform/list/?series=804326
Which comes from Flickering coloured glitchyness on 780M Phoenix iGPU with 6.7.0 kernel on Xorg/plasma (#3097) · Issues · drm / amd · GitLab
If it works please respond there to let author know.
Thanks, it fixed my issue
1 Like
Hello @Mario_Limonciello ,
i’ve tested the current main-branch of power-profile-daemon with the build in ABM-patches on 6.8rc4 and 6.7.4. All is working as intended. Thank you very much for this!
Unfortunately the default ABM value of 3 in balanced mode is not that appropriate at least on daylight use. With a matte display on my framework 13 you have to rise screen brightness up to about 30-50% to see all content on the display, while on abm level of 1 15% of screen brightness is sufficent. On a glare display the situation is presumably worse.
Summing up an abm level of 3 with screen brightness set to around 40% needs up to 10% more power than an abm level of 1 with a screen brightness of 15% . Maybe it would be better, to set an abm level of 1 on balanced profile and an abm level of 3 on power-saver profile as you mentioned in the post above.
How are you measuring power?
I discussed with Windows team and they use 3 by default in battery for a very long time which is how I came up with the numbers used.
I used the following procedure:
- Charge Battery to the charging threshold of 80%
- Start always the same Libreoffice impress presentation loop with mixed contend. No other background jobs are running.
- Disconnect the Charger and measure the time until the batterylevel drops 1%.
I did this three times (on balanced profile) with abmlevel of 3 / 36% screen brightness and then three times (on balanced profile) with an abmlevel 1 / 12% screen brightness. With this settings the presentation is clearly visible/readable on daylight with no sun. With the first setting the time until battery drops 1% is 8,9% shorter on average than with the second setting what leads me to the conclusion that the second setting is more efficient at least in this special test scenario. Beside that: the colors look really awful on abm level 3. Is this really intended as default on battery, as balanced profile is normally the default?
Personally, it’s not that important to me because I’ve created a shortcut to switch the abm leves like I need them.
Really appreciate the feedback and detail on your testing procedure. After conversation with others and looking more closely I completely agree with you.
I’ve made the change to PPD to not be so aggressive.
amdgpu: reduce panel_power_saving values (!155) · Merge requests · upower / power-profiles-daemon · GitLab
2 Likes
Great stuff! Am I correct in assuming we still have to wait for a kernel with this patch included before it actually takes effect?
…that’s right, except you build your own kernel with this patch applied.
1 Like
There is discussion about it maybe going to 6.8-rc5, but based on that discussion it’s probably going to push off to 6.9-rc1.
2 Likes
I’m on a FW 16, not 13, but I’m replying so I get notifications of updates.
You are a gem @Mario_Limonciello, thank you :). Are you active in other linux community forums as well?
1 Like
I’ve been relatively active here and in the AMD DRM Gitlab.
1 Like
The patches are queued up for 6.9. Anyone who want to do this in advance can backport these patches:
And then use PPD 0.20, which will use the new interface by default.
9 Likes
I ran some experiments with setting the ABM level as kernel arg. What I observed (from my limited testing) was barely any change in power draw for the display backlight, but significantly worse colors when using ABM level 3. It’s hard to describe, but it looked like the lightness of the light colors was set even higher. This was especially noticeable for the whites, but also all the other colors that are not dark. Anyone else notice this?
The contrast and brightness is changed based on image content. If you compensate by adjusting the brightness manually you’ll not see the savings.
The experience is why PPD only applies 3 on power saver and on battery.
Both of these patches appear to be in the os-build kernel-ark commits from the last couple of days for the kernel-6.9.0-0.rc0.a4145ce1e7bc.11 tag
Ah gotcha, thanks, that explains it. So this doesn’t do anything to lower the minimum brightness?
No it doesn’t. It dynamically adjusts brightness for the content and then adjusts contrast to compensate.
1 Like
Nice
But isn’t that very far away from the 6.5 kernel we are all on right now? Or will it skip straight to that in a few months
I need a rough estimate to decide if its worth learning about how to adjust all this stuff thats new to me