hwdec=vulkan with RADV still not working on my system

[Brisse89]

mpv Information

mpv 0.38.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.349.0
FFmpeg version: 7.0.2-3
FFmpeg library versions:
   libavutil       59.8.100
   libavcodec      61.3.100
   libavformat     61.1.100
   libswscale      8.1.100
   libavfilter     10.1.100
   libswresample   5.1.100

Other Information

• Linux version: "Debian GNU/Linux trixie/sid"
• Kernel Version: Linux debian-desktop 6.10.3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.3-1 (2024-08-04) x86_64 GNU/Linux
• GPU Model: [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] [1002:7300] (rev cb)
• Mesa/GPU Driver Version: Mesa 24.1.6-1 (Also tested 24.2.rc4)
• Window Manager and Version: GNOME 46.4-1
• Source mpv: Debian testing repository
• Introduced in version: Ever since hwdec=vulkan was available

Reproduction Steps

RADV_PERFTEST=video_decode mpv --no-config --vo=gpu-next --gpu-api=vulkan --hwdec=vulkan --gpu-context=waylandvk

Expected Behavior

Video playback with no issues and Vulkan Video hardware accelerated decoding

Actual Behavior

Depends on whether video is h264 or h265, but neither is working properly. Sometimes system completely hangs (kernel panic?).

h264:
No video output and error messages printed to console and dmesg, although some files produce garbled video output including big_buck_bunny_1080p_h264.mov.
mpv console output: https://gist.github.com/Brisse89/93eaa4d3a0a00e2fe9084ef496188e1a
dmesg: [ 6394.783530] amdgpu 0000:09:00.0: amdgpu: Disabling VM faults because of PRT request! [ 7369.984141] [drm:amdgpu_uvd_cs_pass2 [amdgpu]] *ERROR* )Handle 0x48780001 already in use!

h265:
There's garbled video output and error messages printed to console and dmesg

Log File

output.txt

Sample Files

https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[CounterPillow]

If it hangs your kernel, it almost certainly sounds like a driver bug. I doubt AMD will care about a 9 year old GPU though, but it's still worth reporting.

[kasper93]

Could you try with older Linux kernel? Curious to see if that's a regression. Either way, probably not a mpv/ffmpeg issue, so you would be better off the report it upstream.

I doubt AMD will care about a 9 year old GPU though, but it's still worth reporting.

If the issue is in common code somewhere, still would be nice to get fixed, though surly harder to get attention to such issue.

[Brisse89]

Could you try with older Linux kernel? Curious to see if that's a regression. Either way, probably not a mpv/ffmpeg issue, so you would be better off the report it upstream.

I've been occasionally trying to see if it works over the course of the last year, probably since this event:
[2023-09-29] Accepted mesa 23.2.1-1 (source) into unstable

The result was always the same.

The kernel version at that time was
[2023-09-24] linux-signed-amd64 6.5.3+1 MIGRATED to testing
according to the Debian Package Tracker.

Meanwhile, VAAPI has been working fine but curiously broke recently, probably when ffmpeg 7.0 arrived in Debian testing, but I have yet to confirm for sure. Working fine in gstreamer though. Anyway, this is probably a separate issue.

[llyyr]

Report it here https://gitlab.freedesktop.org/drm/amd/-/issues/

[kasper93]

Report it here https://gitlab.freedesktop.org/drm/amd/-/issues/

What he says. Also test with ffmpeg directly to minimize testcase.

This is how you would normally test it:

ffmpeg -hide_banner -hwaccel vulkan -hwaccel_output_format vulkan -i <file> -f null - 

[Brisse89]

Report it here https://gitlab.freedesktop.org/drm/amd/-/issues/

What he says. Also test with ffmpeg directly to minimize testcase.

This is how you would normally test it:

ffmpeg -hide_banner -hwaccel vulkan -hwaccel_output_format vulkan -i <file> -f null - 

Thank you for the suggestion.

Basically, the issue presents with ffmpeg as well.

First try: I got no errors from ffmpeg or dmesg, but there was flickering artifacts on my screen and some desktop elements (icons and such) were not showing properly afterwards.

Second try: My desktop was completely garbled and unresponsive. I could ssh into the machine from my mobile but it did not respond to my reboot command so I had to reach for the physical reset button.

[llyyr]

First try: I got no errors from ffmpeg or dmesg, but there was flickering artifacts on my screen and some desktop elements (icons and such) were not showing properly afterwards.

My guess is that there were probably messages in dmesg about a gpu reset, which your compositor tried to recover from but didn't properly. So on the second reset it dies completely.

Are you on Wayland or X11?

[Brisse89]

Wayland.

Edit: Tried X11 as well. Roughly having the same issues, just different looking artifacts, and at first it didn't hang completely but eventually it did anyway.

[Brisse89]

Reported here:
https://gitlab.freedesktop.org/drm/amd/-/issues/3561

[Brisse89]

Could you try with older Linux kernel? Curious to see if that's a regression. Either way, probably not a mpv/ffmpeg issue, so you would be better off the report it upstream.

This is slightly off topic as it is a separate issue, but you were on to something there I think. I mentioned VAAPI also broke quite recently but I found that it works if I boot into my fallback kernel which is 6.9. It's broken in 6.10.

The main topic (Vulkan Video) is different though. It's been broken on my end since it became publicly available. I've been testing it every now and then but I just didn't have the energy to report it back then.

VAAPI issue is possibly related to this: https://gitlab.freedesktop.org/drm/amd/-/issues/3565

[kasper93]

This is slightly off topic as it is a separate issue, but you were on to something there I think. I mentioned VAAPI also broke quite recently but I found that it works if I boot into my fallback kernel which is 6.9. It's broken in 6.10.

As it is recent regression hopefully it will get more attention, but at the same time there are issues that are lingering in recent kernel revisions, so ymmv.

[Brisse89]

VAAPI issue seems to have resolved with a recent kernel update (6.10.3->6.10.4)

[laichiaheng]

By the way, hwdec=vulkan causes unstable refresh rate on my adaptive sync monitor.

[baalau]

@Brisse89

Can confirm that Kernel 6.10.4 indeed fixed the VAAPI issue on your end?

Kernel 6.10.4 and above trashed the VAAPI acceleration on my end. Playback fails with an error message in dmesg:

[ 83.488268] [drm:amdgpu_uvd_cs_pass2 [amdgpu]] *ERROR* msg/fb buffer ff00e22000-ff00e24000 out of 256MB segment

On previous kernels (6.10.x) I occasionally had artifacts and observed general instability. On LTS kernel (6.6.47-1-lts) it seems all good. Kernel 6.9.9 was also ok.

I have x11 xfce, AMDGPU driver, ATI FirePro W5000 (South Island Graphics Core Next 1 (GCN1); essentially AMD HD7000 series), Arch linux.

[Brisse89]

Just tried again and the situation seems slightly improved but not entirely.

big_buck_bunny_1080p_h264.mov now works with Vulkan Video Decode on my system, as does some h265 videos, including those recorded on my Samsung S10 mobile phone. Other h264 files still not working with the exact same symptoms as before. Don't know what causes it, and I don't know what changed to make some files suddenly work properly. In short, some of those which previously had garbled video output now seems to work. Others still have garbled video. Those previously without video output and only error messages and crashes are still broken, but I didn't get any kernel panics, rather it was only error messages and mpv freezing sometimes.

Currently on mesa 24.2.2-1 and kernel 6.10.9-1

[laichiaheng]

The --hwdec=vulkan works horribly with adaptive-sync, so I suggest you to stick with --hwdec=vaapi

[Brisse89]

The --hwdec=vulkan works horribly with adaptive-sync, so I suggest you to stick with --hwdec=vaapi

I've noticed, and I've seen your report here: #14697