Well you must be lucky, a bug was affecting mostly 64GB RAM or more : Flickering or constant solid white screen with kernel >=6.1.4 w/ 64GB+ RAM (#2354) · Issues · drm / amd · GitLab
Fix landed in kernel 6.6-rc2 and got also backported to earlier kernels apparently.
Yeah I was aware borked scatter gather was a thing but it got fixed before I got my laptop XD.
Never ran anything lower than 6.6 non rc so it never hit me.
Man I was kinda hoping there was something about the excess power consumption while hardware decoding in there.
As for the other ones, I have experienced none of these on kernel 6.6 (after the 3.03 bios update).
@Matt_Hartley I think something got confused here, the refered issue is about stutters and crashes with VP9 HW decoding, I don’t have that.
The issue is excessive power consumption of the hw decoder in general on linux which isn’t in any of the listed issues unfortunately.
Now that’s exactly what I meant. Even the numbers line up pretty nicely with mine, looks like 720 or 1080 don’t make a huge difference here.
Software decoding is only more efficient below a certain threshold though, 4k 60 sw decoding is like 20W vs the 12 with hw decoding but the 12 are still way more than it takes on my old thinkpad (7.7).
You may want to get that one added to the open issue list thread.
1W over idle for 1080p playback is much better than what even my thinkpad did so that would indeed be a massive win.
Greetings apologies but I do not own a framework laptop (yet). But I also experience this same issue with a ryzen 7 6800h laptop, kernel 6.6.4 with default mesa v1.23 on wayland. In fact I can’t even play 60fps videos in 720 or more without getting huge framedrops (Youtube videos don’t even move at 720p60fps). Just wanna if you can play 60fps without any issues? and if there’s anyway I could help resolve this? Thanks a lot.
So I have the 7840U on endeavouros (~arch) @ 6.1.65-1-lts, and regardless of whether I enable or disable vaapi in firefox, having a 1080p60 YT video running[1] will have it discharging at ~20W, when I’d be otherwise discharging at ~7W with the video paused. Forcing YT to run h264 has me at 20W in hardware, and ~18-19W in software.
All of this seems like a lot? I don’t have wattage numbers for other devices, but my gut feel is that video decoding shouldn’t be this costly. This means that running YT in the background effectively halves (or worse) general idle browsing, which is not something I’ve noticed before on a laptop.
[1] while also reading the net etc, this isn’t a controlled test with a single FF tab and nothing else occurring.
Just wondering, is the playback smooth? I don’t know if it’s a firefox issue but on my machine with 6800h and 680m I can’t play back any 60fps video at all on firefox, it just turns to a static image on MPV it works but with lots of dropped frames. Thanks a lot. As for power mine is also similar to your although I’m using a 6800h with a higher TDP but on windows video playback is just 8w even for 1080p60fps.
This sounds like a separate issue for which AMD has shared a test firmware. Addresses the video stutter/frame drop issue, not power consumption.
There was an upstream linux-firmware release a couple of days ago, but it doesn’t have an update to that particular firmware file, so I’m assuming this isn’t an official fix, yet.
Edit: Above was for Phoenix in the FW 13 AMD. Noticed you have a Rembrandt, that test firmware is in the same issue thread here. I don’t think that has made it to this latest linux-firmware update either, but if that’s available on your distro (it got to stable today for Fedora 39) it’s worth a try.
Tbh I’m not sure if it’s the same issue, I tried the reproducer test script yesterday, I was able to get to 500+ runs before I just got bored and stopped it.
@SCdF How did you get hardware decoding to work at all? I can’t get it to work on Ubuntu 22.04, Firefox just says ‘blacklisted force disabled by glxinfo’
Erm well I’m on Arch so it will be a different experience, but from memory I just installed the mesa va-api driver, and then enabled va-api in Firefox in about:config. Maybe your version of mesa is too old? I am on 23.2.1.
FWIW because with it enabled battery drain is so bad, and periodically when I wake I get a white screen that requires a hard reboot, I’ve both disabled vaapi in FF and used enhanced-h264ify (FF plugin) to force h264 only. This also means nothing on YT higher 1080p60, and the quality of h264 is notably worse even ignoring the res issues, but I’d rather that than terrible battery life and instability.
I’m going to wait awhile and see how much linux stabilises, and maybe if it doesn’t get better switch to Windows.
In a quite concerning turn of events the high decoding power use ticket was closed as a duplicate of a newer ticket and there someone claims it is an architectural issue that may not be fixable (despite it working well enough on windows).
If this turns out to be true I kind of regret getting the amd despite it’s great performance otherwise, video playback is one major use case on battery.
@Adrian_Joachim I quote from further in the thread.
Harry Wentland:
" The display pipeline isn’t the thing that’s burning (lots of) power. The things that burn power are GPU and CPU. Windows has optimizations that use fixed-function HW (the display pipeline) for video playback via direct scanout surfaces. Most Linux compositors don’t have the same optimizations (yet)…"
Leo Li:
" I have some preliminary work in:
There are still lots left to tidy up before it’s in any state to merge. I was initially looking at sway as a vehicle to tie everything together, but mutter/kwin/weston are definitely not out of the picture."
And to that I ask the same I asked there: why does decode only (without displaying anything) use 3x as much power on linux as deconde and display uses on windows? Also why does software decoding use less power <1080p30 when both use as little fixed function stuff for the rest?
I am very glad to see there are related optimizations made in stuff I use but the point of the decoder itself using way too much power.
The thing mentioned above about the cursor isn’t quite obvious to everyone; but the issue with the cursor is that it’s composited with the desktop plane rather than running on it’s own hardware plane.
So IIUC that means you’re spinning up the GFX engine in order to have a cursor. Moving it to it’s own plane will mean that the compositor doesn’t need to have GFX running as frequently. Doing direct scanout will mean that the compositor doesn’t need to have GFX running.
All these optimizations to use the hardware more efficiently should add up.
Very nice and I am looking forward to those improvements, however: Y HW-DECODER USE SO MUCH POWER XD
Without scannout to the display (like just to dmabuf) can you see if the new PHX VCN F/W that was upsteamed today still consumes too much (specifically with EPP set to balanced)?