Power consumption for HW accelerated video decoding for Radeon iGPUs is simply outrageous

changed the description

I don't think this can be addressed considering Windows doesn't fair too much better, so let's close it.

Probably the next iteration of Ryzen APUs, let's say based on RDNA4/Zen5 will be more effective in this regards.

closed

mentioned in issue mesa/mesa#10223 (closed)

I don't think there is much we can do in the driver to address this directly. Windows and android handle most of this in their compositors. To address this we need the following:

Compositors need to be updated use the overlay and compositing hardware in the display block to handle the CSC, scaling, and composition of the video. Currently most video players use graphics APIs like OpenGL to handle CSC and scaling. This uses a lot of power because GFX is powered up and the CPU is busy to keep feeding GFX. If we use the display hardware, we can keep gfx powered down and this will also generate less CPU traffic since we don't have to keep feeding GFX. Today this looks like: Compressed video stream -> VCN (video decode) -> Raw YUV data -> GFX (CSC, scaling) -> Scaled RGB data -> DCN for display what it should look like is: Compressed video stream -> VCN (video decode) -> Raw YUV data -> DCN for CSC, scaling, and display
Make sure compositors allow direct flipping for full screen video, similar to full screen graphics for games. This avoids an extra copy. This is probably already handled in most cases.
Compositor or desktop environment should pick a less aggressive CPU profile while full screen video playback is active. This is probably mostly nice to have since there should be less CPU load in general once 1 is implemented.

Thanks a ton for the explanation, @agd5f !

Does Wayland help achieve that or a display server being used is inconsequential for the issue?
Is it worth pinging mpv developers, so that at least this video player could become more frugal in terms of video playback?
Can Firefox/Chrome achieve the same under Linux?
How does Windows come off a lot more power efficient in this regard? What's wrong with Linux?
In the best case scenario what could power consumption for e.g. 4K VP/AV1 60fps stream playback be?

Does Wayland help achieve that or a display server being used is inconsequential for the issue?

It's generally not possible to use multiple planes in X, so this would be wayland only.

Is it worth pinging mpv developers, so that at least this video player could become more frugal in terms of video playback?

What would need to happen would be for the media player to be able to ask the compositor if it can just hand it the raw YUV video data. If the compositor supports that and uses display planes to handle it, then the media player can just share the YUV images rather than RGB, cutting out the GFX work in the media player. Also, a lot of users like to use custom filters that media players provide via OpenGL which might not be possible with fixed function display hardware.

Can Firefox/Chrome achieve the same under Linux?

Sure via the same mechanism as a standalone media application talking to the compositor.

How does Windows come off a lot more power efficient in this regard? What's wrong with Linux?

MS and Android put a lot of work into their compositor and media APIs to enable these use cases out of the box. One vendor defines the ecosystem. On Linux you have lots of compositors and desktop environments, each with their own goals and schedules and features. The problem is that not all hardware supports this so most compositors and media players tend to focus on the solution that will serve the largest number of users across a wide range of hardware which is usually OpenGL. Windows and Android can mandate certain hardware features from the platforms they support.

In the best case scenario what could power consumption for e.g. 4K VP/AV1 60fps stream playback be?

At least as good as windows; potentially better.

Regarding MPV, mpv --vo=dmabuf-wayland --hwdec=vaapi today will export the video and OSD (ui/subtitles) as a separate wayland surface, and use VCN hw decode through vaapi.

However, most (if not all) wayland compositors today will GFX compose the exported surfaces to a single framebuffer before sending it to the display hardware.

There's some work happing to make direct-scanout via hw planes happen: https://fosdem.org/2024/schedule/event/fosdem-2024-3557-the-state-of-video-offloading-on-the-linux-desktop/

Personally, I've been looking at enhancing libliftoff with a focus on (but not limited to) video-playback cases: emersion/libliftoff!79

I've compared mpv --vo=gpu with --vo=dmabuf-wayland and here on my side there's basically no difference. Both come at ~10.5W for a 1080p 60fps H.264 video.

That's under Wayfire 0.8.0-2.fc39.x86_64 with 1.33 scaling and a 2560x1600 120Hz display. Probably the compositor uses the GPU for scaling which makes the GPU run at higher 3D frequencies which negates any benefits from using the dmabug-wayland output. Even with scaling set to 1.0, there's barely any difference.

Looks like more work needs to be done.

I've tried pure decoding, not sure if I did it right, but this command requires less than 1.5W on average:

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i test.mp4 -f null /dev/null &> /dev/null

So decoding itself looks quite efficient. Rendering on the screen is not.

Here's the best I could manage.

Shutdown X or switch to Linux text console. Run mpv this way:

mpv --no-config --video-unscaled --hwdec=vaapi 1080p60fpsH264.mp4

This comes off at roughly 7W. Far from what I got with Intel (3.5W-4W despite using the exact same software stack, i.e. Fedora + XFCE + Firefox) but better than ~12W that I get under X.org with AMD.

I still don't understand why Intel fairs so much better and I feel like there's some very large inefficiency on the AMD side.

Like I mentioned earlier, playing 1080p 60Hz H.264 videos in Firefox under AMD keeps the CPU fluctuating between 3.4 and 4.7GHz (!!) while on Intel I'm looking at 0.7GHz with no spikes.

You can test this with this URL, live 24 hours a day:

https://player.twitch.tv/?autoplay=true&channel=asot&parent=google.com

There's something really wrong/broken/incomplete.

I'm not familiar with Intel hardware, but I suspect they may have a general purpose blitter engine what can be used independent of GFX which supports CSC and scaling and is lower power than GFX. They could use this in VAAPI rather than GFX.

Thanks a ton for your explanations. Really appreciate it!

It's not just the power consumption, one of my main use cases for hardware decoding is being able to watch 4K videos while doing CPU intensive tasks which is impossible to do even on the top of the line APUs: #2996 (comment 2266151) Currently I see no advantage in hardware decoding because power consumption is the same (and thus battery life) and it doesn't help you while running heavy tasks.

If AMD's implementation needs architectural changes to be useful (because Intel doesn't have such problems) IMHO the involved upstreams should be made aware of that so that compositors/video players can eventually implement such features. Right now no one seems to be even aware of the issue.

This looks interesting and probably pertinent:

https://floss.social/@rmader/110946838681254840

Intel has a SFC (Scaling & Format Converter) hardware in their media engine to achieve ultra-low-power video playback.

I believe this fixed-function hardware exists in Skylake (released in 2015) and newer Intel graphics. For more information, read "Intel® Graphics for Linux* - Programmer's Reference Manuals".

AMD recently introduced a similar feature called VPE. I think it's also a fixed-function hardware similar to Intel's SFC, thus changing the current situation of AMDGPU using GFX for CSC and scaling in video playback. But I can't find any detailed documentation about this feature, or even the minimum supported hardware.

It looks like Phoenix doesn't have VPE (https://www.phoronix.com/news/AMD-New-VPE-UMSCH) but it would be nice if @agd5f could confirm this.

Phoenix does not support VPE.

I also tested mpv --hwaccel=vaapi --vo=dmabuf-wayland but running on Weston since it seems like Wlroots based compositors still don't work with this?? (https://youtu.be/SMCMZwAiw2w?t=618), anyways I followed (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177) and I noticed a 2w difference between running on Hyprland vs Weston. Unfortunately it seems to be using my Nvidia dGPU, so I can't exactly tell if it would make a different with AMD.

@agd5f While the sacling and compositing layer are definitely a concern, @marcoen ffmpeg testing in the other ticket showed that for decode only (without any composing or scaling and the like) vaapi on linux used more than 3x the power than it takes for decoding and compositing on windows. Is that also not a driver issue?

Is it possible to test how much power the display pipeline takes by showing a pre-decoded video or something?

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).

This obviously doesn't explain everything, but it's one piece of the puzzle.

@hwentland are you aware of ongoing efforts to use the fixed-function hw in (major) Linux compositors? Is AMD involved in those efforts? If you could provide relevant links, that'd be splendid.

If there are no ongoing efforts to support this in major compositors, is there at least a rough plan and documentation on the things that need to be done in order to get us there? Any hints/advice are much appreciated.

@leoli from my team is looking at it from the AMD side. He's mostly looked at sway/wlroots/libliftoff, but is now also having an eye on Weston. @leoli, can you post your PR and/or issue for your sway/wlroots/work?

We're looking at sway and Weston since compositors are complex, we're new to the scene, and those are very accesible. There have been some minor talks with Gnome devs about support in mutter.

Related work has been done by Robert Mader. His mastodon account tends to have lots of news. His FOSDEM talk is a good overview.

Wow, thanks for the info, that's quite encouraging! In particular https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177 seems interesting (wondering what's the state of non-YUV buffer support now...) This gives me some hope things are about to improve.

Will definitely watch the FOSDEM video. Thanks again for the pointers!

I have some preliminary work in:

libliftoff (emersion/libliftoff!79)
hooking it up to the wlroots output layers MR (wlroots/wlroots!4348)
with sway using the scenegraph api (merged on latest)
Kernel patches to make AMD cursor behave better, which I have yet to submit

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.

Sounds interesting! Do you know if anyone is involved/aware on KDE side?

I'm not aware if anyone is looking at this from the KDE side. If you know of interested parties, please let me know

@Zamundaaa might be interested from the KDE side. I wonder if KDE already uses any KMS overlay planes or if there are plans to do so.

KWin 6.0 does direct scanout of fullscreen videos, with scaling and letterboxing when needed, but there's no overlay plane usage yet. That is planned for the near-ish future though.

One kind-of-blocker is that this only works for limited range BT.601 videos, until the color representation protocol is done. As the color management protocol is nearing completion, it shouldn't take that long anymore for the representation one to be done either though.

I tried doing (https://mastodon.social/@rmader@floss.social/112015648160051940) on my Ryzen 7 6800h machine running the latest version of Sway and PPD and while playing back the 4k version of BigBuck bunny, it only consumed 14-15 W! Way below the 21-25W I often encounter using MPV/ Firefox.

Steps:

Download files from here:https://cloud.silentundo.org/s/r8733siTjP4yRJp?dir=undefined&openfile=996972

Install:
 - flatpak remote-add --user --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo
 - flatpak install --user livi-[amd64|aarch64].flatpak
 
Run:
 - flatpak run org.sigxcpu.Livi [bbb_sunflower_2160p_60fps_normal.mp4]

Btw, I encountered issues with permissions on flatpack,it couldn't access my FS solved it using flatpak override --user org.sigxcpu.Livi --filesystem=host

Tested this again on Sintel 1080p and it only consumed 9W REALLY close to windows' 8W!

reopened

Hi @birdie, would you mind sharing your exact procedures for measuring wattage?

I use turbostat running in parallel to whatever I'm doing at the moment.

e.g.

watch "turbostat --quiet --num_iterations 1 --interval 1 --show PkgWatt --Summary | tail -1"

or

while :; do turbostat --quiet --num_iterations 1 --interval 1 --show PkgWatt --Summary | tail -1; done

(the second one is hard/impossible to get out of - either close the window or kill the root bash process)

AFAIK PkgWatt shows the full package power consumption including CPU/GPU and IO.

Reading this I'm just regretting purchasing AMD hardware. I should've stayed with Intel.

marked mesa/mesa#10223 (closed) as a duplicate of this issue

marked this issue as related to mesa/mesa#10223 (closed)

This isn't the full scope of the problem but I want to call it out because it will influence power consumption of the CPUs on the package.

The CPU is running around 4700MHz (amd-pstate-epp driver running by default)

When using amd-pstate, are you explicitly changing EPP values manually or taking what is programmed by the firmware? The amd-pstate driver doesn't change the CPPC request MSR value from the boot firmware, it will default to default. But userspace can explicitly set EPP values such as using the string balance_power or balance_performance. If you use power-profiles-daemon, upgrade to 0.20 to make sure this happens.

I'm using the defaults.

I just don't understand why the CPU is involved so much, granted most of the stuff is performed by the GPU (at the very least decoding which must be the most computationally expensive operation).

And what's interesting is that using "power", e.g.

echo power | tee /sys/devices/system/cpu/cpufreq/*/energy_performance_preference

may cut power consumption by at least 30 to 40%.

For AV1/VP9 4K 60Hz this doesn't work so well though as I get dropped frames but it absolutely works for 1080p H.264 60Hz streams.

I won't pretend that I understand how it all works but it looks like the CPU governor overshoots quite a lot (by default).

High CPU usage might indicate that the dedicated video decoder (VCN) isn't used, even though you've enabled media.ffmpeg.vaapi.enabled. You could also try to set media.hardware-video-decoding.enabled and media.hardware-video-decoding.force-enabled.

UMR can show you whether VCN is used:

Launch in gui mode sudo umr --gui
Go to "Top" column
Look at "Number of fences signaled per second" section on the right side and see if vcn_dec_0 or vcn_dec_1 is showing any activity

If this isn't showing activity Firefox isn't using the HW decoder.

You can compare with mpv. Run mpv with the hwdec=vaapi option and you should see vcn_dec activity.

Also make sure vainfo shows you something sensible. See the Arch wiki for more info if needed.

Even if VCN is being used I've seen high battery consumption from CPUs running other tasks when the EPP profile isn't actively set and it boots with firmware defaults. It's quite important for userspace to actively set one of the balanced EPP profiles.

Just tried this with PPD0.20 set to power save, running XORG since I couldn't run UMR --gui on wayland and can confirm that vcn_dec_0 is indeed working power consumption is still high same as before.

@hwentland

HW decoding is absolutely enabled and used as I see it in nvtop.

I did want to investigate how much of the excess power draw was decoding and how much was the rest of presentation so I did a bunch of testing inspired by @marcoen over in the other ticket.

Here's the test setup: I am using big buck bunny in the 480p24, 720p24, 1080p30 and 4k60 version (all h264) so others could reproduce it.

For the ffmpeg tests I use ffmpeg -re -i file -an -c:v rawvideo -f null /dev/null for sw decoding and ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -re -i file -an -c:v rawvideo -f null /dev/null for hw decoding and for actual playback I am using kodi with vaapi enabled and disabled. I am not 100% sure the accelerated ffmpeg command is entirely correct, up to the 1080 60 file it works as expected, pretty much no cpu usage and 1x rate but with the 4k60 file it produces a ton of cpu usage and plays back at around 0.3x rate, not quite sure what's going on there.

To get the power readings I take the output of powerstat over 8 minutes and I let it settle back to baseline between runs.

The testes were done on my AMD Framework 13 on arch with kernel 6.8.2 and everything up to date.

Average power above idle:

	ffmpeg sw	ffmpeg hw	kodi sw	kodi hw	ffmpeg hw-sw	kodi hw-sw
480p 24	0.45	2.74	2.13	3.66	2.29	1.53
720p 24	0.48	2.79	2.42	3.78	2.31	1.36
1080p 30	1.35	3.2	3.58	4.22	1.85	0.64
4k 60	10.48	borked	14.22	6.38		-7.84

So with and without presentation hardware decoding uses significantly more power than software decoding for 1080 30 and less, above it it helps a lot. From previous testing with 8k 60 youtube videos the difference there is over 30w.

Now if we compare the ffmpeg and the kodi values we can get an upper limit for the impact of presentation (there is also other stuff going on but it can't be more than full video playback - decode only unless I am missing something).

	sw	hw
480p 24	1.68	0.92
720p 24	1.94	0.99
1080p 30	2.23	1.02
4k 60	3.74

Not quite sure what I am seeing here but looks like presentation hurts the accelerated case less.

So @agd5f it still looks like the decode part alone uses excessive power, this part specifically could/would have to be addressed in the driver/firmware right?

Hi @chestwood96, based on the suggestions in this ticket of using Wayland and playing with mpv --vo=dmabuf-wayland --hwdec=vaapi, I've done some measurements and the results are very promising. I'm using a very minimal Wayland setup using labwc at the moment.

I used the same video files as you and ran sudo powerstat -R -d 3 in the background. This measures CPU+GPU power every second for 1 minute and then prints the average. The actual power draw from the battery is a bit more of course.

For software decoding I play back with mpv --vo=gpu --hwdec=no. Here are the results:

Idle: 0.41 Watts on average with standard deviation 0.14

Video	SW	HW
480p24	3.25 Watts on average with standard deviation 0.06	3.59 Watts on average with standard deviation 0.05
720p24	3.46 Watts on average with standard deviation 0.10	3.62 Watts on average with standard deviation 0.05
1080p30	6.09 Watts on average with standard deviation 1.54	3.77 Watts on average with standard deviation 0.05
4k60	12.20 Watts on average with standard deviation 0.16	4.42 Watts on average with standard deviation 0.05

I don't know why the power consumption goes up and down so much for the 1080p30 video when doing SW decoding. I re-ran the test and got basically the same result.

I also don't know why my numbers are so much above idle compared to yours

So far I'm quite happy with these results from where I started. I'm looking forward to testing the work that @leoli is doing.

Note that I'm running a self-built mpv, since there is a bug in the current release (v0.37.0) which caused some decoding error with the 4K60 video:

[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
Error while decoding frame (hardware decoding)!
Attempting next decoding method after failure of h264-vaapi.
[autoconvert] HW-uploading to vaapi
[hwupload] upload yuv420p -> vaapi[nv12]

This has been fixed by this commit: https://github.com/mpv-player/mpv/commit/99d387bbc81e36f60da26d63b96736e2461bcd2e

also, here is the output of tlp-stat -p on my system:

--- TLP 1.6.1 --------------------------------------------

+++ Processor
CPU model      = AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics

/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver    = amd-pstate-epp
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor  = powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors = performance powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq  =   400000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq  =  5289000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq  =   400000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq  =  5289000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference = balance_performance [EPP]
/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences = default performance balance_performance balance_power power

/sys/devices/system/cpu/cpu1..cpu15: omitted for clarity, use -v to show all

/sys/devices/system/cpu/amd_pstate/status              = active
/sys/devices/system/cpu/amd_pstate/cppc_dynamic_boost  = (not available)
/sys/module/workqueue/parameters/power_efficient       = Y
/proc/sys/kernel/nmi_watchdog                          = 0

+++ Platform Profile
/sys/firmware/acpi/platform_profile                    = balanced
/sys/firmware/acpi/platform_profile_choices            = low-power balanced performance
/sys/devices/platform/thinkpad_acpi/dytc_lapmode       = 0

~~I see that I have energy_performance_preference = balance_performance :/ Will have to re-run the tests...~~ (did not make a difference)

@marcoen Given we are taking different measurement values and a different player some of the (especially the hw decoding ones) are quite close to each other, especially on the low end. Could you try without the dmabuf thing, I am quite curious if the HW values would match even better? Would make sense that the savings from that would increase with higher resolution. The lowend number are still sad but 4ish W for 4k60 is a lot more palatable, it may finally match my t480s XD.

Not quite sure why your sw numbers are higher, not sure what kodi uses but it may not be the same as "--vo=gpu".

Something else has been raised on the Framework forums regarding power consumption that might not be obvious. Turning on scaling in GNOME or KDE does increase power consumption as graphics is going to be active to do those scaling operations.

I discovered that in Fedora, compared to 100% setting the displays scale to 200% increase the powerconsumption about 10% and 125% to 175% increase the consumption about 40%

KWin uses the display hardware for scaling instead of the GPU whenever that's possible (since 5.27), and with Gnome 46 it should happen in Gnome as well.

The increase in power consumption with 125% sounds like the application does not directly pass the video buffer to the compositor though but is rendering at 2x and then being downscaled for fractional scaling, where the rendering with ca. 2.56x as many pixels ofc causes quite a bit of overhead.

For the sake of completeness, the user previously quoted by Mario does use Gnome:

https://community.frame.work/t/framework-16-power-consumption-benchmarks/47144/29?u=fw13amd

I'm on KDE Plasma 6 myself, and while I haven't done any thorough testing, I can't appreciate any difference between scaling (125%) on and off on my FW13 internal display.

Which, coupled with what you said, would confirm that the DE is doing a good job.

I have been facing a similar problem on a Sapphire NITRO+ AMD Radeon™ RX 7900 XTX Vapor-X 24GB. 7800x3D cpu with smart access memory enabled. I use KDE+Wayland with usually with two display monitors attached and powered on (it doesn't seem to make a difference if I disconnect the additional display monitors). I've gone as far as testing mpv with vulkan decoding, and with vaapi. Tested with 100% scaling and adaptive sync off on 3840x2160 monitor at 60hz.

mpv command line for vulkan: env RADV_PERFTEST=video_decode mpv --vo=gpu-next --gpu-api=vulkan --hwdec=vulkan --gpu-context=waylandvk --player-operation-mode=pseudo-gui

mpv command line for vaapi: env RADV_PERFTEST=video_decode mpv --hwdec=auto --hwdec-codecs=all --player-operation-mode=pseudo-gui

Note: confirmed settings were used by hitting i in mpv window to show display overlay statistics.

Vainfo output:

Trying display: wayland
vainfo: VA-API version: 1.21 (libva 2.21.0)
vainfo: Driver version: Mesa Gallium driver 24.0.5-arch1.1 for AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.57, 6.8.7-zen1-1-zen)
vainfo: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

In my case the power used (as reported by CoreCtrl) goes to roughly 60-70 watts from 6-16 watts while not playing video. I was hoping this would have been solved by now

My setup is Lenovo Ideapad 5 pro with AMD 7840HS and Radeon 780M. I have not been able to see HW decoding usage on nvtop. I am on Fedora (Gnome+Wayland) and mesa-va-drivers-freeworld. I tested it on Firefox having enabled media.ffmpeg.vaapi.enabled and media.hardware-video-decoding.force-enabled. I only see video encoding usage: Is it a configuration problem on my end that decoding is done on the software side?

7840HS has a unified decoder/encoder, so there's just one value: ENC.

HW accelerated decoding works fine on your end.

It seems that the encode/decode pipeline is unified in RDNA3 hence it confuses nvtop and it shows only ENC usage. Source: https://github.com/Syllo/nvtop/issues/232

Here's something interesting and crucial.

There's a cpufreq variable called energy_performance_preference which by default is set to performance and while watching online streams it results in the CPU consistently running at maximum (boost) frequencies and consuming a ton of energy.

When changing this preference to either of balance_performance|balance_power|power the consumption drops approximately twofold where power consumption scales this way balance_performance > balance_power > power.

I've not noticed any frame drops by using any of these options.

I wonder what's going on and why that's the case. I've settled down on balance_performance in the end because the remaining two options are slow to ramp up frequencies which results in a higher latency and much worse performance for different tasks.

I wrote a script which alters this for all logical CPU cores:

https://github.com/birdie-github/useful-scripts/blob/master/perfbias.sh

and is a breeze to use. Obviously must be run under root or by using sudo.

Edit: oh, I've already mentioned all of this earlier, lol, but there was no script.

You can also use TLP to take care of that. In my case I use:

CPU_ENERGY_PERF_POLICY_ON_AC=balance_performance
CPU_ENERGY_PERF_POLICY_ON_BAT=power

Yes; Power profiles daemon 0.21 does this as well already as well. It will default to balance_performance on AC and balance_power on battery.

Power consumption for HW accelerated video decoding for Radeon iGPUs is simply outrageous

Designs

Child items ...

Activity

Admin message

Admin message

Power consumption for HW accelerated video decoding for Radeon iGPUs is simply outrageous

Activity