vo_dmabuf_wayland: reject formats not supported by the gpu #13500
Conversation
Dudemanguy
force-pushed
the
dmabuf-wayland-gpu-formats
branch
from
548ae45 to
e9fb7e7
Compare
|
Are you sure that looking at the planes is the correct way to go about this? I would assume that the number of formats that are supported for direct scanout are only a subset of the formats that the GPU can sample and render. E.g. on my GPU DRM_FORMAT_XRGB1555 is supported by the GPU but not for scanout. You would also have to make sure that the plane you're looking at is a primary plane. |
Does libdrm have anything better for seeing what formats are supported? I've always looked at planes.
Good point, thanks. |
I expect the supported formats to depend on the API that you're actually using. If you want to attach a framebuffer to a plane, then the IN_FORMATS drm property is what you want to look at. But this would only apply if mpv is using modesetting directly (i.e. mpv was started from a VT) and this MR sounds like there is a wayland compositor in between. egl and vulkan have APIs to query the supported formats+modifiers. These are what I'm using in my compositor to get the list of available formats. I assume vaapi has something similar. |
Hmm I wouldn't be too sure about that but I'll take a look. |
|
Yeah tbh I'm not familiar with vaapi. I just assumed that at some point you would have to tell it the output format you want and that would either have to be trial and error or it would have to give you a list of supported formats. |
|
vaapi won't help here because vaapi output formats don't have to be directly displayable. |
Dudemanguy
force-pushed
the
dmabuf-wayland-gpu-formats
branch
from
e9fb7e7 to
c4b1f97
Compare
This has been a long standing gap. This VO requires that your compositor and GPU/driver supports the format. We've been checking what the compositor supports and rejecting formats based on that, but probing the gpu was not done until now. This relies on the main_device event in linux-dmabuf and checking the planes using libdrm. To keep things simple, we only check the very first plane and store the formats there. Unlike what we get from compositor supported formats, these have no modifiers but it's better than nothing. This allows mpv's autoconverter to automatically kick in instead of getting broken colors because the compositor supports the format but not the gpu.
Cosmetic. This is to better indicate that these formats come from the compositor.
Dudemanguy
force-pushed
the
dmabuf-wayland-gpu-formats
branch
from
c4b1f97 to
8b5b303
Compare
|
Well for now I made it grab the first primary plane we find. I also just realized that the main device can change at anytime meaning that you could in theory lose the supported formats in the middle of playback. Not sure how exactly I want to handle that yet. |
|
Download the artifacts for this pull request: |
|
Closing in favor of #14815. |
The best way to test is to have trash hardware that doesn't support NV12 (yes really).
We probe compositor-supported formats for dmabuf_wayland but we do not check what the gpu supports. If the gpu doesn't support the format, then we should reject it as well. This is still a WIP in progress because although mpv's auto converter does work with this, I have to specify
--hwdecotherwise it will fail. Looks like it tries to go directly to yuv420p -> vaapi[bgr0] instead of the two step process of yuv420p -> bgr0 then brg0 -> vaapi[bgr0].