v3d: Support SAND128 base modifier
The BROADCOM_SAND128 modifier is usually used with an extra parameter to pass in the stride via a side channel. Quoting from drm_fourcc.h:
The pitch between the start of each column is set to optimally switch between SDRAM banks. This is passed as the number of lines of column width in the modifier (we can't use the stride value due to various core checks that look at it , so you should set the stride to width*cpp).
So apparently this is just a workaround for limitations in some kernel
APIs. DRM modifiers, however, are arguably a bad fit for extra
parameters that aren't known in advance. In the Wayland/KMS ecosystem
many components depend on being able to treat modifiers as opaque, e.g.
for negotiations etc. In practice the current approach requires various
software components to manually use the
DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT()
macro - using the
DRM_FORMAT_MOD_BROADCOM_SAND128
modifier directly with formats like
NV12
results in a rejection in the KMS driver and corrupted output
in Mesa (because we'd bail out early in v3d_sand8_blit()
).
Fortunately the stride check limitations mentioned above don't seem to
apply to Mesa though. Thus we can just add support for the base modifier
and stride (coming from V4L2), allowing various toolkits, Wayland
compositors and V4L2 decoder implementations to support e.g.
NV12
+ DRM_FORMAT_MOD_BROADCOM_SAND128
(NC12
in V4L2) in a generic
way.
Notes:
- Wayland compositors trying to offload composition to KMS will still fail when doing a test commit.
- There is another limitation - in the V4L2 MPLANE API - that requires userspace to know the correct offset of the second plane. That's a known API limitation though and only affects V4L2 decoder implementations.
Signed-off-by: Robert Mader robert.mader@collabora.com
Example running showtime
on a RPi4 with HEVC hardware decoding:
Never mind the green part at the bottom, that's an issue with the sink.
Example of weston
and the Gst waylandsink
(so Weston renders the content):
Note that this was only tested with NV12 so far, not with P030. There's no reason to assume that it would behave differently, however, and there's no know user which could regress by landing this MR. Tested both NV12
and P030
, on RPi4 and RPi5.
Related:
- v4l2codecs: decoder: Translate V4L2 formats int... (gstreamer/gstreamer!7355 - merged)
- Draft: backend-drm: Implement DRM_FORMAT_MOD_BR... (wayland/weston!1640)
cc: @chema @ndufresne