On Thu, Nov 5, 2026 at 12:30 PM Nicolas Dufresne <[email protected]> wrote: > > Le mercredi 04 novembre 2026 à 14:11 -0800, Rob Clark a écrit : > > On Wed, Nov 4, 2026 at 11:00 AM Robert Mader <[email protected]> > > wrote: > > > > > > Nice, very happy to see the series! > > > > > > On 04.11.26 17:36, Dmitry Baryshkov wrote: > > > > The comment describing the QC10C buffer layout calls it a compressed > > > > P010. It is not: > > > > > > If I'm not mistaken the display engine / the DRM side (including Mesa) > > > describes it as P010+QCOM_COMPRESSED as well, and so does my pending > > > Gstreamer MR [1] . So if we can't pretend that QC10C == > > > P010+QCOM_COMPRESSED, then we probably need a DRM_FORMAT_TP10, wire that > > > up everywhere etc. OTOH if we want to keep the DRM side as is, then the > > > comment should reflect that, IMO. > > > > IMHO we need DRM_FORMAT_TP10.. on the GPU side, we have TP10 and P010 > > as distinct formats, both with and without UBWC. I'm not sure if the > > same is true on video side but P010+UBWC was never exposed, or if it > > truely only supports linear P010 and UBWC TP10. > > Xilinx ZynMP is all matching TP10 (they had GEY and YUV semi-planar variants), > but they never upstreamed it, hence why we don't have it in V4L2. Just fyi, we > named it creatively NV12_10LE32 in GStreamer, but careful, I cannot guaranty > the > padding in on the same side. > > Though, how do we deal with backward compat here?
On the qc side, it seems like apparently what the display advertises as P010+UBWC is actually TP10+UBWC. I'm willing to call that a bug and just fix it. On the GPU side there is an MR[1] to add P010 for vk. For gl, I think linear P010 should already be handled via shader lowering. I'd like to add TP10, although there doesn't seem to be (yet) a vk format for this. (And I'd like to stay away from hacks pretending TP10+UBWC is P010+UBWC at the API.) For now I think we could workaround the lack of a vk format by using DRM_FORMAT_TP10. The main use-case to start would be dma-buf import, so that seems like it would be enough for now. On the v4l2 side, I'm not sure. But it is also not clear to me if the viddec hw (iris) supports all four combinations of P010/TP10 vs linear/UBWC. I guess there is already some fourcc translation needed between v4l2 and drm, so maybe it is ok to stick with QC10C on the v4l2 side? BR, -R [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45721 > > > > BR, > > -R > > > > > Best regards, > > > > > > Robert > > > > > > 1: > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8195 > > > > > > > P010 stores each sample in 16 bits, QC10C packs three > > > > 10-bit samples in each 32-bit word, which is what the stride computed > > > > below (width * 4 / 3) assumes. Name the format correctly. > > > > > > > > Signed-off-by: Dmitry Baryshkov <[email protected]> > > > > --- > > > > drivers/media/platform/qcom/iris/iris_buffer.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c > > > > b/drivers/media/platform/qcom/iris/iris_buffer.c > > > > index eb8de60c1177..ec2bf2a2d953 100644 > > > > --- a/drivers/media/platform/qcom/iris/iris_buffer.c > > > > +++ b/drivers/media/platform/qcom/iris/iris_buffer.c > > > > @@ -266,7 +266,7 @@ static u32 iris_yuv_buffer_size_qc08c(struct > > > > iris_inst *inst) > > > > > > > > /* > > > > * QC10C: > > > > - * UBWC-compressed format for P010. > > > > + * UBWC-compressed TP10, YUV 4:2:0 with three 10 bit samples packed in > > > > 32 bits. > > > > * Contains 4 planes in the following order - > > > > * (A) Y_Meta_Plane > > > > * (B) Y_UBWC_Plane > > > >
