Message-ID: <0841b98d-32b3-4e7d-940b-9be204fad7af@oss.qualcomm.com>
Date: Thu, 22 Jan 2026 11:29:32 +0530
From: Vikash Garodia <vikash.garodia@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Nicolas Dufresne <nicolas@...fresne.ca>,
        Rob Clark <robin.clark@....qualcomm.com>, Sean Paul <sean@...rly.run>,
        Akhil P Oommen <akhilpo@....qualcomm.com>,
        Jessica Zhang <jesszhan0024@...il.com>
Cc: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Bryan O'Donoghue <bod@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, freedreno@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 0/3] Add support for QC08C format in iris driver


On 1/16/2026 1:16 AM, Dmitry Baryshkov wrote:
> I should have added GPU maintainers and ML beforehand. Fixing it now.
> 
> On Thu, Jan 15, 2026 at 09:02:07AM -0500, Nicolas Dufresne wrote:
>> Le jeudi 15 janvier 2026 à 10:08 +0200, Dmitry Baryshkov a écrit :
>>> On Wed, Oct 08, 2025 at 03:22:24PM +0530, Dikshita Agarwal wrote:
>>>> Add support for the QC08C color format in both the encoder and decoder
>>>> paths of the iris driver. The changes include:
>>>>
>>>> - Adding QC08C format handling in the driver for both encoding and
>>>> decoding.
>>>> - Updating format enumeration to properly return supported formats.
>>>> - Ensuring the correct HFI format is set for firmware communication.
>>>> -Making all related changes required for seamless integration of QC08C
>>>> support.
>>>>
>>>> The changes have been validated using v4l2-ctl, compliance, and GStreamer
>>>> (GST) tests.
>>>> Both GST and v4l2-ctl tests were performed using the NV12 format, as
>>>> these clients do not support the QCOM-specific QC08C format, and all
>>>> tests passed successfully.
>>>>
>>>> During v4l2-ctl testing, a regression was observed when using the NV12
>>>> color format after adding QC08C support. A fix for this regression has
>>>> also been posted [1].
>>>>
>>>> [1]:
>>>> https://lore.kernel.org/linux-media/20250918103235.4066441-1-dikshita.agarwal@oss.qualcomm.com/T/#u
>>>>   
>>>>
>>>> Changes in v2:
>>>> - Added separate patch to add support for HFI_PROP_OPB_ENABLE (Bryan)
>>>> - Updated commit text to indicate QC08C is NV12 with UBWC compression
>>>> (Bryan, Dmitry)
>>>> - Renamed IRIS_FMT_UBWC to IRIS_FMT_QC08C (Dmitry)
>>>> - Link to v1:
>>>> https://lore.kernel.org/r/20250919-video-iris-ubwc-enable-v1-0-000d11edafd8@oss.qualcomm.com
>>>>
>>>> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
>>>> ---
>>>> Dikshita Agarwal (3):
>>>>        media: iris: Add support for HFI_PROP_OPB_ENABLE to control split mode
>>>>        media: iris: Add support for QC08C format for decoder
>>>>        media: iris: Add support for QC08C format for encoder
>>>>
>>>
>>> Looking at the series again... What is the definition of V4L formats?
>>> Are they expected to be self-compatible? Transferable between machines?
>>> In DRM world we made a mistake, making use of a single non-parametrized
>>> UBWC modifier, and then later we had to introduce OOB values to
>>> represent different params of UBWC compressed images.
>>>
>>> So, I wanted to ask, is single "UBWC-compressed NV12" enough for V4L2 or
>>> should we have different format values (at least for different swizzle
>>> and macrotile modes)?
>>
>> Our expectation is that the decoder will produce the same format regardless the
>> resolution. And that format should be shareable, so that same format coming from
>> two drivers means the same thing without out of band data, except that
>> resolution and strides are needed oob anyway and can obviously be used as an
>> acceptable workaround the issue you describe. It should also have a single
>> translation to DRM fourcc + modifier, and hopefully the other way around is
>> possible too, otherwise its a bit broken and unusable.
> 
> Well... As I wrote, we made a certain decision several years go: there
> is only one DRM modifier. At that point the decision was made by
> open-source people which had a very limited information about hardware
> internals. We can probably try deprecating it and shifting towards
> multiple entries. On the other side, most of the blocks would only be
> able to support only one of very few possible configurations.
> 
>>
>> So bottom line, since V4L2 does not have modifiers, you have to treat one V4L2
>> format as a pair of DRM fourcc + modifier. Decoders typically only support a
>> subset, or hardware engineers can generally pick a handful of performant
>> configurations that works for all cases (its all 2D with similarly sized
>> macroblocks).
> 
> This is not quite applicable: even if we try to fix all other settings,
> the format differs from platform to platform because of the memory
> organisation (highest_bank_bit in drivers/soc/qcom/ubwc_config.c).
> 
> There is a description of swizzling in Mesa ([1])
> 
> [1] https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/freedreno/fdl/fd6_tiled_memcpy.cc
> 
>> Since these formats are only usable when consumed by GPU or
>> display controllers, its important that all party uses the same convention for
>> the limited information available.

Would there be a need for any client, other than GPU/display, to peek 
into the data OR to validate it, it need to decompress it. For that as 
well, it would need all the associated info to decompress it.

Again in same SOC, camera can produce compressed YUV with different 
parameter while VPU different, it would again need the associated info 
alongwith single "UBWC-compressed NV12" to decompress it.

> 
> Yes, we added UBWC config database in order to have a single source of
> information for the kernel.
> 
> So... On the practical side there can be:
>   - UBWC 1.0, 2.0, 3.0, 4.0, etc.
> 
>   - swizzle 1-2-3, 2-3 and 3, partially depends on UBWC version.
> 
>   - HBB or 13, 14, 15, 16
> 
>   - bank spreading (true or false)
> 
>  From the practical point of view, drivers/soc/qcom/ubwc.c defines the
> following formats (currently, I'd like to cross-check some of them):
> 
> - linear
> - 1.0_123_14
> - 1.0_123_14_spread
> - 1.0_123_15
> - 2.0_23_14
> - 2.0_23_14_spread
> - 2.0_23_15
> - 3.0_23_13_spread
> - 3.0_23_14_spread
> - 3.0_23_15
> - 3.0_23_16
> - 4.0_23_15_spread
> - 4.0_23_16_spread
> - 4.0_3_13_spread
> - 5.0_23_15_spread
> - 5.0_23_16_spread
> - 6.0_23_16_spread
> 
> Would it be benefitable to define separate DRM modifiers (and NV12
> compressed variant for V4L2) for each of them?
> 

Regards,
Vikash

Powered by blists - more mailing lists