Cheers, giving the PPD & pstates a try with ubuntu 24.04.
Has anyone elaborated on e) autosuspend expansion cards, what is required to implement, any caveats if they need to be used again etc.?
I’m going to try ppd, however if I’m not satisfied with the results and going to switch back to tlp do I have to re-configure the tlp settings again?
The DP and HDMI cards already have udev rules that have been upstreamed into systemd that will put then into autosuspend.
2 Likes
hi. is this still needed on PPD 0.20? on the AUR they’re mentioning it might have been merged already?
1 Like
Nope, it has been merged!
For those following along, there are some nice improvements to power-profiles-daemon. See [RESPONDED] PPD (power-profiles-daemon) (****AMD ONLY****) - #28 by Mario_Limonciello for details.
Confirmed current power-profiles-daemon version in the repos for Ubuntu 22.04 have the update in place.
@Matt_Hartley or other FW folks, is there a way users can edit their old posts? If not, will you please note for a) and c) in my OP that @Mario_Limonciello’s updates have been merged?
Much appreciated!
And by a) and c), I mean c) and e).
btw: no longer able to edit the above post after 2 days (tried yesterday)…
I don’t have a standard user account, so this may differ. If you are not able to do what you see in the image below, you may need to create new posts for the time being.
1 Like
Thanks Matt,
I don’t have the option to edit after an indeterminate period/event (is it once somebody replies or X hrs?)
This is what is shown for the OP instead:
I’ll keep posting replies, however it would be wonderful to have a way to create and maintain a community guide like this. As it is, folks have to read the whole thread to bypass steps that are no longer needed.
I’ll next be profiling the 6.8 kernel via Ubuntu 24.04, so will have more data to post.
I’ve made it a wiki for you.
3 Likes
I found this thread after trying to find info comparing the 7640u with the 7840u. Do you have any thoughts how significant the battery performance difference would be between the two?
Primary workloads are coding, multiple vm’s and other browsing and text related stuff.
Since they both have the same power limit the battery difference should be relatively similar at high load (with the 7840u getting slightly more work done in the same time)
At low load here should not be much differences.
The biggest issue with battery on linux with the amd platform isn’t the cores anyway (imo, if you do not do any video playback it’s a different story), for some reason the hardware decoder uses an unreasonable amount of power to do basic stuff and and both the r5 and r7 have the same one on that front.
Sorry, hardware decoder?
The thing that makes compressed video not compressed video.
oh okay, gotcha. Yeah in those situations I’d likely get it plugged in. Okay thanks for your explanation!
latest discussions suggest it’s not the decoder specifically but the process of decoding and displaying video. the wrong hardware functions might be used for scaling the video while efficient hardware functions for that purpose have been included in this GPU and need to be used. that may take a while to sort out but I’ve personally seen improvements since I got my Framework. Now, on power save profile, I get 7-8W power consumption when watching video. this is an improvement over 12W I had when I got the device.
That has been discussed but no one has been able to actually demonstrate it.
Meanwhile all the actual tests we I have done/seen so far point towards the encoder using the bulk of the power. I did testing without any scaling or display and regular playback testing and in both cases the hw decoder is using more power than even sw decoding under 1080p 30. In the case of playback testing both sw and hw decoding have to use sw scaling so it should hurt both more or less equally and the main power difference is still the hw decoder.
There have been some tests indicating hw scaling does reduce playback power a bit but nowhere near enough.
I would love if somebody would back up those “it’s all the scaling and presentation and stuff” claims with a demo or some testing or anything. It doesn’t need to be anything fancy, hell it doesn’t even need to be useful. Could just be a custom binary spitting out a video directly to the display or hell even just decoding a 1080p 30 video into null for a non ridiculous amount of power.
It’s still way too much.
1 Like
That has been discussed but no one has been able to actually demonstrate it.
We discussed this at the Display Next Hackfest this year, and Leo spent cycles evangelizing the strategy of underlay planes (like a hole punch) for compositors to setup. Two of the compositors (Weston and Cosmic) have already done the work to get MPO working.
There are (at least) two patches that were part of this week’s display promotion you need that change how cursors work:
Patch 40
Patch 41
The kernel patches will be part of kernel 6.11. From my discussion with Leo those patches when paired with Weston show video offload savings. They show savings with Cosmic as well but some other bugs occur (pink flickering in the compositor and triggering some driver bugs on amdgpu).
I would love if somebody would back up those “it’s all the scaling and presentation and stuff” claims with a demo or some testing or anything.
I believe if you want to replicate the savings I’m describing you should be able to try it with the tip of the weston tree, mpv and a kernel with those patches.
4 Likes