Hi, Le mercredi 06 novembre 2024 à 16:53 +0100, Benjamin Gaignard a écrit : > + nicolas Thanks for the CC, I'm obviously watching kernel@xxxxxxxxxxxxx, I don't know why it didn't make it to my mailbox. I'm adding explicitly Lucas and Philipp, as I believe they can provide relevant information here. > > Le 06/11/2024 à 14:30, Benjamin Gaignard a écrit : > > Verisilicon hardware video decoders can produce tiled (8x4 or 4x4) > > and compressed video framebuffers. > > It considerably reduces memory bandwidth while writing and reading > > frames in memory. I've seen for years this 8x4 references, but in reality, and I've implemented software converters that works on all the VSI/Hantro drivers we have mainline, there is no such thing as 8x4 tiled coming out of these chips. Unless we have new evidence, and V4L2 patches enabling these formats, I don't see any point of bringing what I believe is a TRM mistake, or an historical format. > > > > The underlying storage in NV12 (for 8-bit) or NV15 (for 10-bit). > > > > Display controllers, like imx DCSS, could use these modifier definition > > as input for overlay planes. > > > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxxxxx> > > --- > > The original code comes from: > > https://github.com/nxp-imx/linux-imx/commit/ab01b7fe82d5a11dfb533cfbd08c4dfa140815de > > I have port it and modify DRM_FORMAT_MOD_VENDOR_VSI value. > > > > include/uapi/drm/drm_fourcc.h | 27 +++++++++++++++++++++++++++ > > 1 file changed, 27 insertions(+) > > > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > > index 78abd819fd62..31d09a98d0d7 100644 > > --- a/include/uapi/drm/drm_fourcc.h > > +++ b/include/uapi/drm/drm_fourcc.h > > @@ -421,6 +421,7 @@ extern "C" { > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 > > #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a > > +#define DRM_FORMAT_MOD_VENDOR_VSI 0x0b > > > > /* add more to the end as needed */ > > > > @@ -1607,6 +1608,32 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > #define AMD_FMT_MOD_CLEAR(field) \ > > (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT)) > > > > +/* Verisilicon framebuffer modifiers */ > > + > > +/* > > + * Verisilicon 8x4 tiling layout > > + * > > + * This is G1 VPU tiled layout using tiles of 8x4 pixels in a row-major > > + * layout. > > + */ > > +#define DRM_FORMAT_MOD_VSI_G1_TILED fourcc_mod_code(VSI, 1) I have code in GStreamer mainline that handle the tiled G1 output in software and its 4x4, no doubt here ... > > + > > +/* > > + * Verisilicon 4x4 tiling layout > > + * > > + * This is G2 VPU tiled layout using tiles of 4x4 pixels in a row-major > > + * layout. > > + */ > > +#define DRM_FORMAT_MOD_VSI_G2_TILED fourcc_mod_code(VSI, 2) ... Meaning this split make no sense, G2 shares the same format in V4L2 and works well in GStreamer software converters. In fact, in the NXP TRM, you should notice that in the G1 section, they document G2 tile and G1 tile is ignored. Perhaps the DCSS do implement some 8x4 tiling, but considering we don't have evidence of anything producing that, we should probably not have it.
