Le jeudi 05 novembre 2026 à 12:52 -0800, Rob Clark a écrit : > On Thu, Nov 5, 2026 at 12:35 PM Nicolas Dufresne > <[email protected]> wrote: > > > > Le jeudi 05 novembre 2026 à 13:35 +0100, Robert Mader a écrit : > > > On 04.11.26 23:11, Rob Clark wrote: > > > > 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. > > > > > > Oh, do I understand you correctly that the P010+UBWC implementation is > > > not compatible with QC10C, meaning on the GPU side (Mesa and display) we > > > don't yet have any support for QC10C exposed to userspace? If that's so > > > then we don't have a choice but to introduce DRM_FORMAT_TP10 I guess? > > > > > > On the plus side - this would allow us to make the format single plane, > > > matching what we get on the V4L2 side. > > > > Since its single plane, we should aim for a variation of > > DRM_FORMAT_YUV420_10BIT. Similar to YUV420_10BIT, there is no obvious linear > > single plane packing for that, it would only be there to support the > > compression. Or maybe this one is abstract enough to be used anyway? > > Oh, sorry, maybe I was a bit misleading/unclear. TP10 is still a > semi-planar format with a Y and UV plane. But each of those planes > combines UBWC metadata and pixel data. > > Within each plane, the pixel part of the data combines 3 samples in > 32b (compared to P010 which is a single sample per 16b. So not quite > the same thing as DRM_FORMAT_YUV420_10BIT.
I believe DRM_FORMAT_YUV420_10BIT is defined as fully packed, no padding indeed, but I'm not sure if it actually matters considering there is no linear representation of these. What really matter is that its a single stride/offset format, which TP10 is not. I would not mind to see another pair for format, but I just wanted to emphasis about the number of expected strides. Nicolas > > BR, > -R > > > Nicolas > > > > > > > > > > > > > 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 > > > > > >
signature.asc
Description: This is a digitally signed message part
