Will NixOS be added to that support list over the next few years?
Fixed, latest dnf updates have you on the latest PPD for Fedora 39. We no longer need the COPR per updates from AMD.
2 Likes
Any experts in this thread know if autocpu-freq is making use of PPD in the background or if there are undesirable disadvantages to autocpu-freq on the FW 16? From what I can tell PPD just sets scheduler to whatever is desired, and autocpu-freq does that as well.
They conflict. You should not use at the same time as PPD.
Thanks :-). I’ll do some testing then to see which better suits my needs. Is there one you prefer of the two?
Update: Simply switching from auto-cpufreq to power-profiles-daemon resulted in a drastic 1W minimum power draw reduction down to ~-5.5W at desktop. Pair that with better integration with my DE (Plasma) and it’s a no-brainer to switch.
1 Like
FYI PPD 0.21 just released today:
Ping your distros to pull it in.
7 Likes
Tested and gave karma for F39 on bodhi.
I had to undo my script mess, but I’m thankful that just works now.
2 Likes
Watching videos on fedora is now similar to windows or is it still wild for amd??
This does not fix the deficiencies in the software stack causing high power consumption for video playback. This is a much bigger problem and requires changes in the compositors.
4 Likes
And whatever the hell is wrong with the decoder/driver even without the rest of the sub.optimal software stack.
Thanks. Did see the .21 come through on Arch.
Think this is a logical step in the right direction and look forward to using it.
lol, can you elaborate? On Ubuntu things were a mess but since Arch I haven’t noticed as many issues but still have A/V sync issues. Just want to make sure I understand other quirks I may not be aware of.
Battery doesn’t seem to be an too bad since Arch, but Ubuntu was ridonkulous power consumption w/ video
For some reason the hardware decoder uses more power for just the decoding bit (no scaling or displaying or anything, just decode and discard) than complete playback with scaling and displaying on windows. On windows you can play a 1080p 30 file for a but under 1W over idle, on linux just decoding it takes a bit over 3W and with display over 4W.
As it is video playback ob battery about matches my old t480s which has a smaller battery. The intel hw decoders apparently don’t have that problem.
This is pretty much the only reason I kind of regret going with amd, especially since it does not seem to get addressed and just gets dismissed. Otherwise the amd platform is pretty amazing.
2 Likes
Oh, wow, that is drastic. I guess since on ubuntu I had high cpu issues with video that I didn’t realize that although now my cpu is very low with playback that power consumption is very high compared to windows. and now thinking harder it dies slower but thinking back it is still actually quite fast for what it is.
That is a huge bummer, and it doesn’t sound like something that is getting addressed / will finish being addressed anytime soon.
Appreciate you explaining it.
1 Like
Depends on the playback software, and if the playback software uses the hardware capable codec to decode or not. So kind of: It depends.
The vp9 stuttering thing was addressed relatively quickly once it was acknowledged, wishful thinking says this one might be too XD.
It’s kind of a catch 22, if you use more video below 1080p 30 you may be better off turning off hw decoding for now, but you’ll get obliterated once you try playing 4k 60 stuff or higher.
Yep - playing back 2K → 4K only.
Then hw outperforms software decoding at least, still uses a stupid amount of power though.
As I mentioned somewhere else (another thread I think?) the lowest level issue is a kernel issue with how the cursor is blended by the compositor. I don’t feel anything is being dismissed. This is the absolute first step to solving this issue.
After that’s been resolved, the next step is to work on the compositors working with libliftoff which Valve already uses for Gamescope. This will start with Weston, and then $FAVORITE_COMPOSITOR needs to add support for it.
Then all the compositors need to use scan out to display the video. There is work ongoing for this right now too.
just the decoding bit (no scaling or displaying or anything, just decode and discard)
Again, if the cursor is being blended by the compositor incorrectly then the GPU won’t be in GFXOFF. Take “video playback” out of the picture and compare a simple workload of moving a cursor in Windows and Linux and you should see differences that the GPU isn’t in the best sleep state. When this is fixed by the kernel and compositors it should bring battery improvements as well for non-video workloads.
I have to emphasize none of what I said above is trivial and quick. I’ve done what I could on the “CPU side” and “Display side” of the equation with amd-pstate, amdgpu ABM and PPD, but there are “way more cooks in the kitchen” when it comes to GPU power optimization.
7 Likes