moonlight-stream / moonlight-qt

GameStream client for PCs (Windows, Mac, Linux, and Steam Link)
GNU General Public License v3.0
9.81k stars 569 forks source link

Vulkan HDR on Intel iGPU not working. (HDR toggle grayed out) #1356

Open gschintgen opened 1 month ago

gschintgen commented 1 month ago

Describe the bug tl;dr: moonlight built from source with libplacebo falls back to "normal" vaapi/kms (?) rendering, HDR grayed out.

According to the wiki it should be possible on my hardware (Intel iGPU) to request an HDR/10-bit stream when launching moonlight from the command line. Since the snap does not seem to be built with libplacebo / Vulkan support (I checked its snapcraft.yaml), I decided to build from source.

make release does pick up the Vulkan support:

Project MESSAGE: Vulkan support enabled via libplacebo

After compiling I transferred the binary to the target system and installed the necessary dependencies so that moonlight can start.

Unfortunately the HDR toggle is still grayed out and the logs seem to have some relevant errors:

00:00:00 - SDL Info (0): V-sync disabled
00:00:00 - SDL Warn (0): Failed to get render node path. Using the SDL FD directly.
00:00:00 - SDL Error (0): Unable to open DRM display for VAAPI
00:00:00 - SDL Info (0): Skipping VAAPI fallback driver names on libva 2.20+
00:00:00 - SDL Error (0): Failed to initialize VAAPI: 3
00:00:00 - SDL Warn (0): Failed to get render node path. Using the SDL FD directly.
00:00:00 - SDL Error (0): Unable to open DRM display for VAAPI
00:00:00 - SDL Info (0): Skipping VAAPI fallback driver names on libva 2.20+
00:00:00 - SDL Error (0): Failed to initialize VAAPI: 3
00:00:00 - SDL Error (0): SDL_Vulkan_CreateSurface() failed: Vulkan can't find any displays.
00:00:00 - SDL Error (0): SDL_Vulkan_CreateSurface() failed: Vulkan can't find any displays.
00:00:00 - SDL Error (0): SDL_Vulkan_CreateSurface() failed: Vulkan can't find any displays.
00:00:00 - SDL Error (0): SDL_Vulkan_CreateSurface() failed: Vulkan can't find any displays.
00:00:00 - SDL Info (0): Trying SdlRenderer for codec hevc_cuvid due to preferred pixel format: 0x9f
00:00:00 - SDL Info (0): Trying DrmRenderer for codec hevc_cuvid due to compatible pixel format: 0x9f
00:00:00 - SDL Info (0): Sharing DRM FD with SDL
00:00:00 - SDL Error (0): drmGetVersion() failed: 9
00:00:00 - SDL Info (0): Sharing DRM FD with SDL
00:00:00 - SDL Error (0): drmGetVersion() failed: 9
00:00:00 - SDL Info (0): Trying PlVkRenderer for codec hevc_cuvid due to compatible pixel format: 0x9f
00:00:01 - SDL Error (0): SDL_Vulkan_CreateSurface() failed: Vulkan can't find any displays.
00:00:01 - SDL Error (0): SDL_Vulkan_CreateSurface() failed: Vulkan can't find any displays.
00:00:01 - SDL Warn (0): No renderer can handle output from decoder: hevc_cuvid
00:00:01 - SDL Warn (0): Failed to get render node path. Using the SDL FD directly.

Steps to reproduce

Screenshots HDR grayed out...

Affected games all

Other Moonlight clients other clients, notably Windows, can enable HDR

Moonlight settings (please complete the following information) nothing, fresh install from source

Client PC details (please complete the following information)

Server PC details (please complete the following information)

Moonlight Logs (please attach) starting, then quitting moonlight: moonlightvk.log

Just to be clear: If a 10-bit stream is not yet possible on my client device that's ok too. I'm primarily interested in finding a definitive answer that is not due to packaging details. (Having a 10-bit stream would be a nice bonus of course. The hardware is able to decode 10-bit HEVC 4:2:0 according to Intel and vainfo.)

gschintgen commented 1 month ago

Some more info. When I start a stream, moonlight reprobes the decoding pipeline and then there are additional, more explicit messages:

00:00:51 - SDL Info (0): V-sync disabled
00:00:51 - SDL Warn (0): Failed to get render node path. Using the SDL FD directly.
00:00:51 - SDL Error (0): Unable to open DRM display for VAAPI
00:00:51 - SDL Info (0): Skipping VAAPI fallback driver names on libva 2.20+
00:00:51 - SDL Error (0): Failed to initialize VAAPI: 3
00:00:51 - SDL Warn (0): Failed to get render node path. Using the SDL FD directly.
00:00:51 - SDL Error (0): Unable to open DRM display for VAAPI
00:00:51 - SDL Info (0): Skipping VAAPI fallback driver names on libva 2.20+
00:00:51 - SDL Error (0): Failed to initialize VAAPI: 3
00:00:51 - SDL Error (0): VDPAU is not supported on the current subsystem: 13
00:00:51 - SDL Error (0): VDPAU is not supported on the current subsystem: 13
00:00:53 - SDL Warn (0): Vulkan device 'Intel(R) HD Graphics 630 (KBL GT2)' does not support VK_KHR_video_decode_h265
00:00:53 - SDL Warn (0): Vulkan device 'llvmpipe (LLVM 17.0.6, 256 bits)' does not support VK_KHR_video_decode_h265
00:00:53 - SDL Error (0): No suitable Vulkan devices found!
00:00:54 - SDL Warn (0): Vulkan device 'Intel(R) HD Graphics 630 (KBL GT2)' does not support VK_KHR_video_decode_h265
00:00:54 - SDL Warn (0): Vulkan device 'llvmpipe (LLVM 17.0.6, 256 bits)' does not support VK_KHR_video_decode_h265
00:00:54 - SDL Error (0): No suitable Vulkan devices found!
MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:794: FINISHME: support more multi-planar formats with DRM modifiers
00:00:56 - SDL Info (0): Vulkan rendering device chosen: Intel(R) HD Graphics 630 (KBL GT2)
00:00:56 - SDL Warn (0): Immediate present mode is not supported by the Vulkan driver. Latency may be higher than normal with V-Sync disabled.
00:00:56 - SDL Info (0): Using FIFO present mode with V-Sync disabled
MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:794: FINISHME: support more multi-planar formats with DRM modifiers
00:00:57 - SDL Info (0): Vulkan rendering device chosen: Intel(R) HD Graphics 630 (KBL GT2)
00:00:57 - SDL Warn (0): Immediate present mode is not supported by the Vulkan driver. Latency may be higher than normal with V-Sync disabled.
00:00:57 - SDL Info (0): Using FIFO present mode with V-Sync disabled
00:00:57 - SDL Info (0): Using Vulkan renderer
00:00:57 - FFmpeg: [hevc_mp4toannexb @ 0x561c9d42fa80] The input looks like it is Annex B already
00:00:57 - FFmpeg: [hevc_v4l2m2m @ 0x561c9d46b4c0] Could not find a valid device
00:00:57 - FFmpeg: [hevc_v4l2m2m @ 0x561c9d46b4c0] can't configure decoder
00:00:57 - SDL Error (0): Unable to open decoder for format: 100
00:00:57 - SDL Info (0): Using SDL renderer
00:00:57 - FFmpeg: [hevc_mp4toannexb @ 0x561ca26f8040] The input looks like it is Annex B already
00:00:57 - FFmpeg: [hevc_v4l2m2m @ 0x561c9d46b4c0] Could not find a valid device
00:00:57 - FFmpeg: [hevc_v4l2m2m @ 0x561c9d46b4c0] can't configure decoder
00:00:57 - SDL Error (0): Unable to open decoder for format: 100
00:00:57 - SDL Info (0): Trying DrmRenderer for codec hevc_cuvid due to compatible pixel format: 0x17
00:00:57 - SDL Info (0): Sharing DRM FD with SDL
00:00:57 - SDL Info (0): GPU driver: i915
00:00:58 - SDL Info (0): Plane 31 is active on CRTC 51
00:00:58 - SDL Info (0): Plane 47 is active on CRTC 51
00:00:58 - SDL Info (0): DRM backend supports exporting EGLImage

I suppose the line Vulkan device 'Intel(R) HD Graphics 630 (KBL GT2)' does not support VK_KHR_video_decode_h265 means game over for now?

gschintgen commented 1 month ago

On mpv-player's github repo I found some valuable information regarding Vulkan decoding:

Requirements for Intel: A GPU supported by the ANV driver You must set ANV_VIDEO_DECODE=1 in your environment to expose video decoding"

After exporting the env. variable Vulkan decoding is indeed being used according to the logs. That flag should probably be documented in the Wiki.

MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:794: FINISHME: support more multi-planar formats with DRM modifiers
00:00:22 - SDL Info (0): Vulkan rendering device chosen: Intel(R) HD Graphics 630 (KBL GT2)
00:00:22 - SDL Warn (0): Immediate present mode is not supported by the Vulkan driver. Latency may be higher than normal with V-Sync disabled.
00:00:22 - SDL Info (0): Using FIFO present mode with V-Sync disabled
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80] Using device: Intel(R) HD Graphics 630 (KBL GT2)
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80] Alignments:
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80]     optimalBufferCopyRowPitchAlignment: 128
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80]     minMemoryMapAlignment:              4096
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80]     nonCoherentAtomSize:                64
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80]     minImportedHostPointerAlignment:    4096
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80] Using queue family 0 (queues: 1) for graphics compute transfers
00:00:22 - FFmpeg: [AVHWDeviceContext @ 0x560e0b1c5f80] Using queue family 1 (queues: 1) for decode
00:00:22 - SDL Info (0): Using Vulkan video decoding
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] nal_unit_type: 32(VPS), nuh_layer_id: 0, temporal_id: 0
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] nal_unit_type: 33(SPS), nuh_layer_id: 0, temporal_id: 0
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] nal_unit_type: 34(PPS), nuh_layer_id: 0, temporal_id: 0
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] nal_unit_type: 21(CRA_NUT), nuh_layer_id: 0, temporal_id: 0
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Decoding VPS
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Main profile bitstream
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Decoding SPS
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Main profile bitstream
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Decoding VUI
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Decoding PPS
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Format vulkan chosen by get_format().
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Format vulkan requires hwaccel initialisation.
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Decoder capabilities for hevc profile "Main":
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Maximum level: 62 (stream 120)
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Width: from 64 to 4096
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Height: from 64 to 4096
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Width alignment: 64
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Height alignment: 64
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Bitstream offset alignment: 32
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Bitstream size alignment: 32
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Maximum references: 16
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Maximum active references: 8
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Codec header name: 'VK_STD_vulkan_video_codec_h265_decode' (driver), 'VK_STD_vulkan_video_codec_h265_decode' (compiled)
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Codec header version: 1.0.0 (driver), 1.0.0 (compiled)
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Decode modes: reuse_dst_dpb
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     Capability flags: separate_references
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0] Choosing best pixel format for decoding from 1:
00:00:22 - FFmpeg: [hevc @ 0x560e0ab8cdc0]     nv12* (Vulkan ID: 1000156003)

But the HDR toggle is still grayed out. And, more importantly, exiting the stream triggers a hang in moonlight. At least the screen is stuck in a completely black state. The logs show this as follows:

Average decoding time: 2.91 ms
Average frame queue delay: 10.50 ms
Average rendering time (including monitor V-sync latency): 1.86 ms
00:00:52 - SDL Info (0): Stopping input stream...
00:00:52 - SDL Info (0): done
00:00:52 - SDL Info (0): Stopping audio stream...
00:00:52 - SDL Info (0): ENet wait interrupted
00:00:52 - SDL Info (0): Control stream connection failed: 4
00:00:52 - SDL Info (0): done
00:00:52 - SDL Info (0): Stopping video stream...
00:00:53 - SDL Info (0): done
00:00:53 - SDL Info (0): Stopping control stream...
00:00:53 - SDL Info (0): ENet peer acknowledged disconnection
00:00:53 - SDL Info (0): done
00:00:53 - SDL Info (0): Cleaning up input stream...
00:00:53 - SDL Info (0): done
00:00:53 - SDL Info (0): Cleaning up video stream...
00:00:53 - SDL Info (0): done
00:00:53 - SDL Info (0): Cleaning up control stream...
00:00:53 - SDL Info (0): done
00:00:53 - SDL Info (0): Cleaning up audio stream...
00:00:53 - SDL Info (0): done
00:00:53 - SDL Info (0): Cleaning up platform...
00:00:53 - SDL Info (0): done
00:00:53 - Qt Info: Found "gamecontrollerdb.txt" at "/home/gilles/.cache/Moonlight Game Streaming Project/Moonlight/gamecontrollerdb.txt"
00:00:53 - SDL Info (0): Loaded 334 new gamepad mappings
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)
00:00:53 - Qt Critical: Could not queue DRM page flip on screen HDMI1 (Device or resource busy)

The error message in the original title ("Vulkan can't find any displays") is still present but seems unrelated.

There is also mention on mpv's page that:

Vulkan filters are supported from Mesa 24.1 onward.

Are those needed for HDR support? (I may have to upgrade mesa to a more bleeding edge version like kisak-mesa PPA)

Erfboom commented 1 month ago

i tried for a while to get hdr working on intel igpu with moonlight and here's my findings.

gamescope was needed with any binary, appimage, distro package, or flatpak. that was the only way to get the hdr button to be exposed.

recently, you can do it without gamescope but you need to set an environmental flag to do so. it's prefer_vulkan=1 or something like that, if you want i can dig deeper into my notes.

the only way it'll work without gamescope is appimage or flatpak if you're on wayland, or from tty. recently the moonlight appimage nightly has hardware acceleration turned off, so really it's just flatpak. moonlight from distros, unless bleeding edge, won't have the necessary flags enabled in the build from what i understand. can confirm on opensuse at least. gamescope won't trigger the hdr button.

tty, gamescope will crash and burn last time i checked. intel hdr is very poorly under developed with issues in libplacebo and possibly in mesa, and ultimately the kernel driver itself for intel. it goes back to the chip itself. intel did a poor job, from my understanding, to implement hdr and they did it kinda of hacky. it works in windows somewhat.

there's an issue with mapping color spaces to what the driver supports to what the chip can actually decode. as soon as hdrpq10 is involved, vulkain swapchain breaks because a mapping failed.

the only way around this is to force the mapping yourself. in other words, if you specify that all hdr10 colors should map to bt2020 or something else, hdr will technically work. you can test this using mpv as mpv lets you use hardware, doesn't need gamescope, and lets you map the colorspace. hdr will work.

hdr will also work with libreelec, but libreelec has a mess of patches to make hdr work on intel igpus. it'll work, technically, colors may be messed up.

some people have successfully loaded kodi without lilbreelec from tty and gotten hdr to work, but that's only with a gles backend and some other setting which means compiling kodi yourself.

in short, unless some nice development has happened in the intel igpu realm, you're out of luck. there's only a few people working on intel igpu because the demand is super low. i opened an issue with gamescope and libplacebo i believe.

from what i remember, a new driver is about to replace the old one for intel igpus in the linux kernel. mesa is also actively developing and trying to narrow down the swapchain issue. gamescope is always being developed so i don't doubt they're close to figuring that issue out as well.

but as i now have switched to amd, i can tell you moonlight works as intended with sunshine as a host. hdr just works out of the box for flatpak, and appimage until recently, no gamescope needed.

Erfboom commented 1 month ago

but from your logs, you should be using ihd instead of i915. check the arch wiki for details on intel hardware acceleration including testing vaapi, and enabling drm content. i also see other errors. you haven't hit the vulkan swapchain wall i did yet.

gschintgen commented 1 month ago

Thanks @Erfboom for your insight! Today I tested iHD (intel-media-va-driver on Ubuntu) in both variants free and non-free. The logs did not change much compared to the previous run with vulkan decode but grayed out HDR. I also briefly tried the flatpak but that wouldn't even start:

(2 lines about defaulting to eglfs then the failure below)
00:00:25 - Qt Warning: Could not create GBM device (No such file or directory)
00:00:25 - Qt Fatal: Could not open DRM device

As for PREFER_VULKAN=1 that didn't change much (but moonlight logged that it deprioritized vdpau due to this env. variable).

That's as far as I'm taking this. I'm also just seeing that I essentially filed a duplicate of https://github.com/moonlight-stream/moonlight-qt/issues/1310 but with more details.

but as i now have switched to amd, i can tell you moonlight works as intended with sunshine as a host. hdr just works out of the box for flatpak

Interesting! That's slightly unexpected though given that Moonlight's docs only mention Intel. Otherwise I wouldn't have tried.

Linux client requirements for HDR streaming Moonlight must be launched directly from the console, rather than within a desktop environment This is required to allow Moonlight to directly configure the display for HDR Intel GPU (other vendors may work but are untested) HDR10-compatible display

https://github.com/moonlight-stream/moonlight-docs/wiki/Setup-Guide#additional-requirements-for-hdr-streaming

I may have been a bit too focused on 10-bit encoding (not HDR as such), that I missed the requirement of having a HDR10-compatible display. I'm not sure if that's a hard requirement for a "HEVC Main 10 SDR" stream, which Moonlight on Windows is capable of when streaming from the same Sunshine host. (No actual HDR on either end.)

I'm leaving this open for now, but I won't mind if it's closed as probably some kind of user error.

Erfboom commented 1 month ago

I have a junk hdr400 monitor and some mapping is definitely happening.

The running moonlight in tty was true for a while but I don't know if the documentation is outdated.

Nothing for me ran in tty with Intel. Gamescope, moonshine, kodi, nothing.

That flatpak error is what kodi also needs to run on shell! Gbm. I haven't seen it from inside a DE though.

It's not a hard requirement to have an hdr10 monitor to stream using hevc. I have a EDID emulator that's cloned my shitty hdr400 monitor. So my client has the real monitor, my host has the emulator.

I can turn on hdr, use hevc, and hdr10 content maps to hdr400 properly.

Probably using the wrong terminology too lol. It's a regular hdr monitor with 440nits max.

When I had a dummy plug with no hdr, I could still use hevc.

On Thu, Jul 11, 2024, 5:26 PM Gilles Schintgen @.***> wrote:

Thanks @Erfboom https://github.com/Erfboom for your insight! Today I tested iHD (intel-media-va-driver on Ubuntu) in both variants free and non-free. The logs did not change much compared to the previous run with vulkan decode but grayed out HDR. I also briefly tried the flatpak but that wouldn't even start:

(2 lines about defaulting to eglfs then the failure below) 00:00:25 - Qt Warning: Could not create GBM device (No such file or directory) 00:00:25 - Qt Fatal: Could not open DRM device

As for PREFER_VULKAN=1 that didn't change much (but moonlight logged that it deprioritized vdpau due to this env. variable).

That's as far as I'm taking this. I'm also just seeing that I essentially filed a duplicate of #1310 https://github.com/moonlight-stream/moonlight-qt/issues/1310 but with more details.

but as i now have switched to amd, i can tell you moonlight works as intended with sunshine as a host. hdr just works out of the box for flatpak

Interesting! That's slightly unexpected though given that Moonlight's docs only mention Intel. Otherwise I wouldn't have tried.

Linux client requirements for HDR streaming Moonlight must be launched directly from the console, rather than within a desktop environment This is required to allow Moonlight to directly configure the display for HDR Intel GPU (other vendors may work but are untested) HDR10-compatible display

https://github.com/moonlight-stream/moonlight-docs/wiki/Setup-Guide#additional-requirements-for-hdr-streaming

I may have been a bit too focused on 10-bit encoding (not HDR as such), that I missed the requirement of having a HDR10-compatible display. I'm not sure if that's a hard requirement for a "HEVC Main 10 SDR" stream, which Moonlight on Windows is capable of when streaming from the same Sunshine host. (No actual HDR on either end.)

I'm leaving this open for now, but I won't mind if it's closed as probably some kind of user error.

— Reply to this email directly, view it on GitHub https://github.com/moonlight-stream/moonlight-qt/issues/1356#issuecomment-2223966789, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANOCNB4D2KG7JXPRLOOCYEDZL32BHAVCNFSM6AAAAABKVYABA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTHE3DMNZYHE . You are receiving this because you were mentioned.Message ID: @.***>

cgutman commented 4 weeks ago

00:00:00 - SDL Error (0): Unable to open DRM display for VAAPI 00:00:00 - SDL Error (0): SDL_Vulkan_CreateSurface() failed: Vulkan can't find any displays.

These errors in particular imply some significant issues with Vulkan and VAAPI on the system, so it's not surprising that things are broken.

Can you try from a desktop environment and see if Vulkan is properly detected there?

That flag should probably be documented in the Wiki.

Vulkan Video decoding is not necessary to use Vulkan rendering or HDR. In fact, the Flatpak doesn't even have Vulkan Video compiled into the FFmpeg build (due to Vulkan SDK issues) but it works fine using VAAPI for decoding and Vulkan for rendering. Though something seems wrong with VAAPI on your system due to the "Unable to open DRM display for VAAPI" errors that show up in your log.

Since Vulkan Video is not enabled by default in Mesa, I assume it is not ready for prime time, so I don't encourage users to use it yet. Users that want to try can use one of the RADV or ANV debug flags to enable it.