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/[email protected]/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-000d11eda...@oss.qualcomm.com
Signed-off-by: Dikshita Agarwal <[email protected]>
---
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
