The vast majority of Vulkan code running in Moonlight
is part of FFmpeg or libplacebo, so the debug layers
really just slow things down without finding any bugs
in our code.
Additionally, there are some overzealous checks firing
constantly on libplacebo and FFmpeg with certain Vulkan
drivers that we can't do anything about.
It's possible that modesetting will also change the resolution
not just the refresh rate. This can happen in cases where the
CRTC is currently set to 4K 30 Hz and we choose 1080p 60 Hz as
a better mode match for displaying a 1080p 60 FPS stream.
Streaming 10-bit content on Nvidia GPUs spams the log with the following for every rendered frame:
Masking `blit_src` from wrapped texture because the corresponding format 'rx10' does not support PL_FMT_CAP_BLITTABLE
Masking `blit_src` from wrapped texture because the corresponding format 'rxgx10' does not support PL_FMT_CAP_BLITTABLE
Even with a fix for the Intel IVB rendering issue, there are still problems on
other older cards that make it not really worth it to enable D3D11VA.
The big benefit of D3D11VA is independent flip in windowed mode using
overlays and that isn't supported on those old cards anyway.
This reverts commit 7074463d0ffce743e52f5d5490f91474f6580474.
This case basically works like a degenerate case of a DRM hwaccel
without DRM master where we just provide EGL export functionality
except that we don't even need a DRM FD in this case.
There are patches floating around the FFmpeg list for this:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=12604
These aren't supported upstream (and probably never will be) and recent
Intel drivers for Tiger Lake and later support the Microsoft standard
HEVC RExt profiles now.
SpacemiT K1's BSP has a version of FFmpeg that contains both
v4l2m2m and their own *_stcodec decoders. Not only is their
V4L2 driver for their mvx decoder seemingly totally broken
(output buffers are all zeros), but it doesn't have any of
the DRM_PRIME support work that is maintained out of tree.
The result is we use a broken copyback decoder instead of
a (mostly) working zero-copy decoder because we didn't
include any logic to rank non-hwaccel decoders by pixfmt
like we have with device type for hwaccel decoders.
