Thats nuts. I’m just sitting here doing nothing, with a browser open and I’m at 8W. Starting Plex playback jumps it to 11.2W.
That’s on bios 3.05, Arch Linux, using Firefox usually. Also using PPD on KDE, with the power profile set to power save as mentioned. This seems to work well for me. Make sure it’s actually controlling the epp profile with powerprofilesctl (iirc)
Fascinating, I’ve got almost the exact same setup, except I’m using sway instead of KDE (which, naively I would think would be better or the same). I did notice looking at powertop that pipewire uses 1W constantly (even with nothing is playing) so maybe thats a good first thing to run to ground.
ppd looks right to me:
* power-saver:
CpuDriver: amd_pstate
PlatformDriver: platform_profile
Edit: I guess this is actually not right (wrt PPD), it should be amd_pstate_epp? Do you use active/passive/guided?
Edit 2: it appears to only show up in /sys/devices/ and not in ppd, but with active I do seen significant improvement, idleing around 6W, 7W with firefox open, and hitting 9-10W on playback. @Mario_Limonciello perhaps you should include setting amd_pstate=active in the guide as well?
I do still see a few sus things in powertop, like pipewire always using 1W even with no audio playback:
Active (EPP) is the default upstream policy. You can change it in the kernel if you want to, but PPD won’t load the AMD pstate “driver” unless you have the kernel set to active.
What terminal are you using? Some terminals (like WARP) use the graphics engine and will prevent low idle.
You should also try something besides sway in case sway is causing your issue.
Understood, thanks.
I’m using wezterm, which generally seems good when doing nothing.
So, I believe the issue with pipewire was two-fold after digging in.
- I was using waybar-cava which apparently burns power for no reason (as of now I no longer use it). Normal waybar is fine.
- The discord tab in firefox was somehow using pipewire resources. I have no idea how this used so much power without audio on…
Thanks for your help, I guess the takeway is it’s always worth checking powertop every so often to make sure you’re not footgunning your battery life.
1 Like
All;
Try this series for video playback.
4 Likes
Do you have a direct patch file link?
I can’t find a way to get one directly from the lore entry.
Use B4
b4 am URL
You need both patches, this gets both and you can git am foo.mbox
I probably should explain what this does too.
It enables dynamic power gating which lets the VCN IP go to a lower power state “between” commands.
This should lower the overall power consumption of VCN during video playback.
That works for getting the patches, thanks.
But I’m having a few problems, applying the patches. Multiple hunks are being rejected when patching. This is under NixOS nixpkgs-master and patching Kernel 6.9.8.
error: builder for '/nix/store/gabrk1ib12f88x5hl3ig4094zfmbvgl6-amdgpu-kernel-module-6.9.8.drv' failed with exit code 1;
last 10 log lines:
> Hunk #8 succeeded at 883 (offset -22 lines).
> Hunk #9 succeeded at 906 (offset -22 lines).
> Hunk #10 succeeded at 928 (offset -22 lines).
> Hunk #11 succeeded at 950 (offset -22 lines).
> 1 out of 11 hunks FAILED -- saving rejects to file drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c.rej
> patching file drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> patching file drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> Hunk #1 succeeded at 386 (offset -26 lines).
> Hunk #2 succeeded at 434 (offset -26 lines).
> Hunk #3 succeeded at 462 (offset -26 lines).
For full logs, run 'nix log /nix/store/gabrk1ib12f88x5hl3ig4094zfmbvgl6-amdgpu-kernel-module-6.9.8.drv'.
error: 1 dependencies of derivation '/nix/store/5ks31ir2n09ygkga55ydzl4mjhwgakb9-linux-6.9.8-modules.drv' failed to build
error: 1 dependencies of derivation '/nix/store/vrcpnrpls0100l5yhj6m4dwfms3drsdv-nixos-system-framework-24.11.20240710.aa94615.drv' failed to build
They’re done against AMD staging DRM next (6.11 content), might need some contextual changes for older versions. I’ll work out backports later on and post some links.
1 Like
Here you go. Here’s 6.10-rc7 and 6.9 backports:
https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/log/?h=superm1/vcn-dpg-6.9
https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/log/?h=superm1/vcn-dpg-6.10
2 Likes
Tried it out for a few videos and overall saw a power consumption decrease.
Playing back a 2k video in Firefox with vp9 codec decreased power consumption by about 8-10W.
Playing back a 1080p video with AV1 codec in Firefox decreased power consumption by about 6-8W.
Playing back a 1080p x264 video with mpv saw only a small decrease of around 2-4W.
Playing back a 1080p x265 video with mpv saw a pretty big decrease of over 10W, total power draw during playback was around 17W, on idle I have about 10W power consumption.
The numbers are a pretty hefty decrease, they might have quite a bit of error margin, since I did no thorough tests.
This was tested with ppd set to balanced and only the iGPU on a framework 16.
4 Likes
That’s great to hear it’s working for you.
2 Likes
That’s an enormous decrease. I’m tempted to learn how to compile my own kernel again (haven’t done it in a decade, and I think never on arch)
1 Like
I barely managed it, the results are pretty nice, especially for lower res.
1 Like
For anyone using NixOS, you can include these patches by adding this to your config:
boot = {
kernelPackages = pkgs.linuxPackages_latest;
kernelPatches = [
# https://community.frame.work/t/guide-fw13-ryzen-power-management/42988/68
{
patch = pkgs.fetchpatch2 {
name = "amdgpu-vcn-1.diff";
url = "https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/rawdiff/?h=superm1/vcn-dpg-6.9&id=13b322789fae1d6a1fad2c09887fbd9c25ecddc4";
hash = "sha256-Apf+jhlaLf9+AbLxJ1yWb2Ka5b3OfIV3gNIqnfnNwho=";
};
}
{
patch = pkgs.fetchpatch2 {
name = "amdgpu-vcn-2.diff";
url = "https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/rawdiff/?h=superm1/vcn-dpg-6.9&id=c6b76db6ce46eab7d186b68b5ed4bea4d3800161";
hash = "sha256-yZ9p/G/YMlreloF3Cq9dsshO1Oomj6+IVJkl/TH0/VE=";
};
}
];
};
This will recompile your kernel, so in case you have /tmp mounted as a tmpfs you have to make sure that you have enough room there (around 20GB in my case) or otherwise set your nix daemon’s tmp dir to something like /var/tmp/nix-daemon, with something like
systemd.services.nix-daemon.serviceConfig.environment.TMPDIR = "/var/tmp/nix-daemon";
4 Likes
If task ‘A’ takes 30 seconds when split across 4 cores, then on 1 core, shouldn’t it take 120 seconds?
120 seconds / 4 cores = 30 seconds of processing per core, so across 2 cores, should it not be 120 / 2 = 60 seconds to complete task ‘A’, thus 100% longer?
Or are other factors implied from context? I don’t understand the conclusion.
Think about it less in terms of time to complete and more in terms of energy consumed.
The relationship of energy consumption is not linear. It depends on the operating frequency.
There is actually a ceiling where if you have cores running below a certain frequency you consume more energy for a given workload.
Furthermore there is IP that is active whether it’s one core or 4 cores that consumes energy.