vo: prefer dmabuf_wayland over other fallback VOs

[kasper93]

No description provided.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-aarch64-pc-windows-msvc
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-aarch64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-i686-w64-mingw32
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-x86_64-pc-windows-msvc
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-x86_64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-x86_64-w64-mingw32

macOS

• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-macos-14-arm
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-macos-15-arm
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-macos-15-intel
• mpv-v0.41.0-dev-g29a3b9858-pr17497-22612546390-macos-26-arm

[na-na-hi]

dmabuf_wayland scaling is most likely bilinear, worse than wlshm by default.

Also the documentation says:

It can still work in some circumstances without --hwdec due to mpv's internal conversion filters, but this is not recommended as it's a needless extra step.

Doesn't this mean that with the default config, it will always do something that is not recommended?

[kasper93]

dmabuf_wayland scaling is most likely bilinear, worse than wlshm by default.

If you want quality use gpu/gpu-next, if you want speed use dmabuf_wayland. wlshm is neither of those.

Also the documentation says:

It can still work in some circumstances without --hwdec due to mpv's internal conversion filters, but this is not recommended as it's a needless extra step.

Doesn't this mean that with the default config, it will always do something that is not recommended?

wslhm doesn't support mapping hardware frames at all.

Those extra steps described here, are basically the possibly frame upload and conversion (if needed), which will happen with any and all rendering pipelines at some point, only using hwdec can take advantage of fully on GPU processing.

Are you familiar with wlshm code? It supports only rgb8 output, with software scaler injected to do scaling and conversion on cpu. While the default scaling may be higher quality than bilinear the overhead of converting everything to rgb is not worth. Additionally it doesn't support HDR or anything other than srgb really, because software scalers are not configured to do any tonemapping or gammut mapping.

dmabuf_wayland can support all those things, it's basically wlshm on steroids. Allowing mapping hardware frame, allowing sending yuv frame direction.

[na-na-hi]

if you want speed use dmabuf_wayland

On most hardware the speed advantage is minimal compared to profile=fast.

wlshm is neither of those.

wlshm has compatibility. dmabuf-wayland does not, and it is less compatible than gpu/gpu-next on most hardware. #14627

The context of this comparision is as a fallback for gpu/gpu-next, and I consider compatibility a higher priority here.

wslhm doesn't support mapping hardware frames at all.

For my second point I am not making any wlshm comparision. The documentation points out its many caveats and encourages users to use gpu/gpu-next instead.

[Dudemanguy]

Compatibility is not a problem if it properly falls back during the autoprobe.

[na-na-hi]

Compatibility is not a problem if it properly falls back during the autoprobe.

The same can be said for hwdec. It is not a problem if it properly falls back to software decoding when it does not work.

Given that dmabuf-wayland is highly dependent on GPU hardware and drivers, are you sure that it knows 100% when it does not work properly? Because the same point is used to argue against enabling hwdec by default.

[Dudemanguy]

I really don't like bogus arguments. hwdec is known to cause gpu resets or permanent stalls on machines with bugged drivers.

[Dudemanguy]

Just remembered but if we go forward with this, we can probably remove ra_ctx_create_by_name. That was created specifically for vo_dmabuf_wayland so it wouldn't be autoprobed since at the time it was very much a WIP VO that needed a lot of work. I think it's more than mature enough now so probably ra_ctx_create works fine.

Also we could remove Experimental from the manual entry/description of this VO driver while we're at it.