[TRACKING] PPD v TLP for AMD Ryzen 7040

HW acceeleration using too much power does not mean cpu decoding uses less (though it does at 720p and barely at 1080p 30). Hw acceleration works and can handle 8k 60 without problems.

Hardware decoding a 720p 30 video on the framework uses about 4-4.5W above idle an 1080p 60 uses about 7.5 above idle. That is way more than it should (hell my 8th gen intel uses about half for the same videos). Especially with people reporting barely 1w above idle for 720 on windows.

3 Likes

Interesting read, thanks for the link.

These are higher than I observed for Netflix on Firefox, which looks to be streamed in vp09 format, however due to DRM passes through the WideVineCdm plugin. I’ll test again to double-check resolution and framerate.

What are your observations for both scenarios?

1 Like

Which scenarios?

The video part of my testing battery is 720p 30fps youtube video in firefox, 4k 60fps youtube in firefox and 720 30 and 4k 60 in kodi from local disk but firefox and kodi are within half a watt there (and h264, h265, vp9 and av1 don’t seem to make a significant difference, neither does bit-rate, at least in the hw accelerated case, with software decoding it makes a big difference).

My conclusion is something is wrong with the hw acceleration drivers, the decoders work fine and do decode whatever I thow at it but they use way too much power doing so. The windows numbers indicate the hardware is fine. If I’d got 1W over idle for 720p decoding on linux I’d be over the moon, other than the hw decoder the power consumption looks relatively fine and the performance per watt is freaking amazing.

3 Likes

I’m on Ryzen 6000 series and not yet using a framework but I also wish this would get even just relatively close to windows, on Linux it consumes about 17w(no config except auto-cpufreq) yet on windows it only consumes 8w

These scenarios:

Testing with Big Buck Bunny 1080p24 H.264 loaded in vlc looped 3X:

With va-api hw accel, 31 mins used 7% battery avg 7.45W draw.

Without hw accel, 31 mins used 7.5% batt at 7.98W avg draw.

Config for testing: ppd balanced, epp balance_power, usb autosuspend, Xfce screen scaling at 0.8, sound muted, brightness at first bar, a few terminals open, browser closed, wifi on & connected, bt off, camera & mic off via hw switches.

I’ve been encouraging observation over 10% or more battery usage for the sake of comparative data. In this case, it looks like the video would need to loop 4-5X.

In my experience, looking at ‘instantaneous’ readings are often misleading (ie: they don’t often/necessarily correlate to actual run times).

Note: after installing mpv, it exhibited some artifacts and stuttering, so I uninstalled it and used vlc, the player I’d previously tested on the FW13.

Conclusions:

  • the differential between hw accel being on/off via Netflix on FF and a local vid are similar
  • mpv may have issues (at least on Ubuntu 22.04.3)
  • as @Michael_Wu notes in his thread linked above to the video file, the Fedora freeworld drivers may have higher power drain

To clarify, my observations are ~1W differential with hw accel on (more efficient) or off (less efficient). Not vs idle usage.

1 Like

Hi @1115, looking at your other post, the 6.6.4 kernel you indicate using should offer efficient power management.

What steps have you taken to test & tune?

If you’d like some guidance, please see my previous posts above.

At very least, my suggestion is to:
a) ensure amd_pstate is active and set it to balance_power or power
b) if running PPD, set to power-saver or balanced
c) enable usb autosuspend if it isn’t already

It looks like your 6800H has a base TDP of 45W but can draw more than double that!

Hope this helps :upside_down_face:

2 Likes

It’s not quite that bad on my framework, worst case is the 8k 60 youtube video and that maxes out at around 13W

Well you did test at pretty much the point where the curves meet, below that sw decoding wins (not by much but it does), above it sw decoding looses massively.

Also you can use powerstat to get better readings than messing with battery percentages. in my testing I let it settle for a couple minutes then run powerstat for 8 minutes.

10% sounds excessive unless you have some very active background tasks or something. I have found after a couple minutes it settles.

  • Well you did test at the one point where they are relatively equal, retest with 720 and 4k and see a quite different story.
  • Don’t think there is anything specifically wrong with mpv
  • that’s probably more settings than anything else. There are some you can do to make a 1-2w difference in hw decode but it’s still way too much.

Yeah the windows observations are 1W vs not decoding at all. On my old t480s hw decoding a 720p 30 video takes a bit over 2w over idle which is much more reasonable than the 4-5 the much newer phoenix chip seems to use at this point.

My default pstate was performance. Changing pstate to power (echo "power" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference ) drops me down ~0.7W idling. I’m still a far cry from idling at 3W or whatever, but it’s still an improvement.

What is confusing though: why is PPD not making this change for me? I haven’t used linux on a laptop in ~10 years so I’m super out of touch, and the documentation is confusing to me. It reads like it would as a fall back, but because my laptop supports the “platform profile” (whatever that is) it uses that instead. I don’t know what platform profile does, but what it definitely doesn’t do is change pstates.

What is PPD’s thought process here?

There is a pull request that adds it that isn’t yet merged.

5 Likes

Powerstat/powertop are polling on an interval, so they show approximate draw.

It should be more statistically accurate to use a timer and % battery use to calculate avg draw :thinking:

I also let things settle in for a few mins before testing.

Then for whatever change I’m observing (different EPP setting or video draw), my target is 10% battery use or more as that will help smooth out any spikes to provide accurate average draw. Timer starts when the battery drops 1%. Then the timer stops when the battery changes to the target percentage.

This also lends itself well to extrapolating run time for the whole battery to evaluate specific use cases. Such as: how long can I watch a video offline? Could be useful for a long flight. Or in the case of this thread, can I work offsite without an outlet for a whole day?

I’ve tested & shared my results for Netflix and a local HD video which covers my use cases. Feel free to perform further testing & share your results. I encourage the above methodology for the reasons indicated if you’d like comparative data.

Good to know. Based on others observations and my own, it looks like multiple commits in the 6.7 kernel should help us continue to move towards parity.

Unsurprising given recent developments in AMD load scheduling et al.

Cheers!

Awesome, good to know, lurking.

For now I’ve installed auto-epp, which is not perfect but good enough for now.

The reported draw has its own averaging and it’s literally the same data source the battery uses to know the percentage, just more directly.

I have, extensively, just scroll up.

6.7rc3 hasn’t done anything for my test battery

Thank you for this, regarding the things I’ve tried, the one that has been working with the lowest power consumption for me was using ryzenajd + auto-cpufreq however I can’t stand how much slower my laptop is when using it. I tried your suggestions without installing PPD yet, just manually setting the parameters using echo and I got better idle consumption compared to the “stock” I was using which was just AMD pstate passive.
I idle at 8.5W now using the suggestions you gave. I used to get 8.0W with ryzenadj + auto-cpufreq and video playback with that was around 12W with current settings it’s around 17W but I still get a lot of frame drops for 60fps videos, also tried using MPV.

So with regards to idle and overall “feel and responsiveness” of the system, I’m sticking with this and will be trying PPD too. Thank you very much for your suggestion. Really hope the situation for HW video accel improves.

What exactly did you do with ryzenadj? Setting the power limit too low actually hurts efficiency and makes the laptop feel pretty bad.

That is way too high, something is not right there.

1 Like

I basically used to cap stapm and the others at 5 watts LOL.

Just a bit higher than windows, I idle at 6W on windows, I’m not using a framework yet btw, I’m using an Asus TUF a15 w/ ryzen 7 6800h.

I would not do that, that just makes it less efficient (and the confised hw decoder ignores the limit anyway, it was the first thing I tried when I figured out it was the culprit XD).

On the 7480u the sweet spot seems to be in the 10 to 15W region, capping to 5w gives it bad performance per watt and bad performance, 10 gives it pretty great perf per watt and good performance. Capped to 5 you’ll actually use more power to do the same stuff, I’d assume it’s even worse on the 6000 but it’s not like I have one to test.

That thing got a dgpu that doesn’t idle right or something? 6w idle is still a lot.

1 Like

Sooo, i am reading this thread again and again but as someone not very experienced in the power saving side i am not entirely able to get actionable bullet points out of it. I tried to randomly screw around and for now i did:

  • disable ppd
  • installed tlp and used the settings someone postet somewhere up here
  • added the amd_pstate kernel parameter

i have no clue if what i did did anything useful. Especially the pstate stuff seems to rely on additional settings i havent done anyway?

furthermore, i have clicked around a bit in powertop and it says all good except “VM writeback timeout” and “autosuspend for usb device hdmi expension card [framekwork]” which i can use with enter and turn “good” but only for the current startup.

While i am writing this i am at 11.8 Watt drawn which seems a bit much when there is nothing going on except a passive firefox and a console with powertop. So i guess i am doing it wrong?

So kind people, what is your collective conclusion so far?

3 Likes

I haven’t done extensive testing as others on here have, but I think the single biggest positive change to my power draw was swapping out to the 6.5 OEM kernel. This kernel has AMD_pstate configured as default.

I thought TLP was making a big difference but I changed back to PPD a few days ago and my idle seems about the same, around 4w.

console with powertop

What console application are you using? I’d been monitoring my draw with BlackBox, which is apparently really poorly optimized as the application seemed to be causing a 4-5 watt draw simply rendering characters! I changed to the Kitty terminal which uses hardware accel and it made a huge difference.

1 Like

“Konsole”, the KDE one. I am on kernel 6.6.4 I didn’t even realize that the pstate is on per default, so i could just have not added the kernel parameter? I guess the console application is quite relevant for blinking cursor stuff, i dimly remember some story of vscode devouring plenty of power for that effect alone.

Also, when i say “only powertop in a console” i off course mean “a full blown KDE desktop environment with all the panel stuff constantly displaying data and 5% display brightness”

2 Likes

Yeah it was really bad, I really couldn’t stand how slow it is, so now I’ll just be sticking to the optimizations recommended here :grin: feels a lot better though it consumes a little bit more power.

Well that’s how much it idles on Windows w/ the dGPU turned off, on Linux it’s 8W(wish I could get it to 6W like windows haha) but I’ve double checked and GPU really is off on Linux too at 8W.