Re: [PATCH V9 16/43] drm/colorop: Add 3x4 CTM type

[Pekka Paalanen <pekka.paalanen@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]

On Mon, 16 Jun 2025 11:30:23 +0000
"Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com> wrote:

> > -----Original Message-----
> > From: Alex Hung <alex.hung@amd.com>
> > Sent: Wednesday, April 30, 2025 6:41 AM
> > To: dri-devel@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> > Cc: wayland-devel@lists.freedesktop.org; harry.wentland@amd.com;
> > alex.hung@amd.com; leo.liu@amd.com; ville.syrjala@linux.intel.com;
> > pekka.paalanen@collabora.com; contact@emersion.fr; mwen@igalia.com;
> > jadahl@redhat.com; sebastian.wick@redhat.com;
> > shashank.sharma@amd.com; agoins@nvidia.com; joshua@froggi.es;
> > mdaenzer@redhat.com; aleixpol@kde.org; xaver.hugl@gmail.com;
> > victoria@system76.com; daniel@ffwll.ch; Shankar, Uma
> > <uma.shankar@intel.com>; quic_naseer@quicinc.com;
> > quic_cbraga@quicinc.com; quic_abhinavk@quicinc.com; marcan@marcan.st;
> > Liviu.Dudau@arm.com; sashamcintosh@google.com; Borah, Chaitanya
> > Kumar <chaitanya.kumar.borah@intel.com>; louis.chauvet@bootlin.com;
> > Daniel Stone <daniels@collabora.com>
> > Subject: [PATCH V9 16/43] drm/colorop: Add 3x4 CTM type
> > 
> > From: Harry Wentland <harry.wentland@amd.com>
> > 
> > This type is used to support a 3x4 matrix in colorops. A 3x4 matrix uses the
> > last column as a "bias" column. Some HW exposes support for 3x4. The
> > calculation looks like:
> > 
> >  out   matrix    in
> >  |R|   |0  1  2  3 |   | R |
> >  |G| = |4  5  6  7 | x | G |
> >  |B|   |8  9  10 11|   | B |
> >                        |1.0|
> > 
> > This is also the first colorop where we need a blob property to program the
> > property. For that we'll introduce a new DATA property that can be used by all
> > colorop TYPEs requiring a blob. The way a DATA blob is read depends on the
> > TYPE of the colorop.
> > 
> > We only create the DATA property for property types that need it.  
> 
> Is there any value to adding pre-offsets [1] in the uapi? 
> 
>  |R/Cr|    | c0 c1 c2 |   ( |R/Cr|   |preoff0| )   |postoff0|
>  |G/Y | = | c3 c4 c5 | x ( |G/Y | + |preoff1| ) + |postoff1|
>  |B/Cb|   | c6 c7 c8 |   ( |B/Cb|   |preoff2| )   |postoff2|
> 
> Handling limited range values is one use case that I can think of.  

Hi,

in the mathematical sense, no. A pre-offset can always be converted
into a post-offset by multiplying it with the 3x3 matrix (and adding to
the existing post-offset). This can be pre-computed, no need to do
it separately for every pixel.

For hardware reasons, I have no idea.

> [1] https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_color.c#n112
> 

Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]