> -----Original Message-----
> From: Pekka Paalanen <pekka.paala...@collabora.com>
> Sent: Friday, May 30, 2025 7:28 PM
> To: Shankar, Uma <uma.shan...@intel.com>
> Cc: Simon Ser <cont...@emersion.fr>; Harry Wentland
> <harry.wentl...@amd.com>; Alex Hung <alex.h...@amd.com>; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; wayland-de...@lists.freedesktop.org;
> leo....@amd.com; ville.syrj...@linux.intel.com; pekka.paala...@collabora.com;
> m...@igalia.com; jad...@redhat.com; sebastian.w...@redhat.com;
> shashank.sha...@amd.com; ago...@nvidia.com; jos...@froggi.es;
> mdaen...@redhat.com; aleix...@kde.org; xaver.h...@gmail.com;
> victo...@system76.com; dan...@ffwll.ch; quic_nas...@quicinc.com;
> quic_cbr...@quicinc.com; quic_abhin...@quicinc.com; mar...@marcan.st;
> liviu.du...@arm.com; sashamcint...@google.com; Borah, Chaitanya Kumar
> <chaitanya.kumar.bo...@intel.com>; louis.chau...@bootlin.com
> Subject: Re: [PATCH V8 32/43] drm/colorop: Add 1D Curve Custom LUT type
>
> On Thu, 22 May 2025 11:33:00 +0000
> "Shankar, Uma" <uma.shan...@intel.com> wrote:
>
> > One request though: Can we enhance the lut samples from existing
> > 16bits to 32bits as lut precision is going to be more than 16 in certain
> > hardware.
> While adding the new UAPI, lets extend this to 32 to make it future proof.
> > Reference:
> > https://patchwork.freedesktop.org/patch/642592/?series=129811&rev=4
> >
> > +/**
> > + * struct drm_color_lut_32 - Represents high precision lut values
> > + *
> > + * Creating 32 bit palette entries for better data
> > + * precision. This will be required for HDR and
> > + * similar color processing usecases.
> > + */
> > +struct drm_color_lut_32 {
> > + /*
> > + * Data for high precision LUTs
> > + */
> > + __u32 red;
> > + __u32 green;
> > + __u32 blue;
> > + __u32 reserved;
> > +};
>
> Hi,
>
> I suppose you need this much precision for optical data? If so,
> floating-point would
> be much more appropriate and we could probably keep 16-bit storage.
>
> What does the "more than 16-bit" hardware actually use? ISTR at least AMD
> having some sort of float'ish point internal pipeline?
>
> This sounds the same thing as non-uniformly distributed taps in a LUT.
> That mimics floating-point input while this feels like floating-point output
> of a LUT.
>
> I've recently decided for myself (and Weston) that I will never store optical
> data in
> an integer format, because it is far too wasteful. That's why the electrical
> encodings like power-2.2 are so useful, not just for emulating a CRT.
Hi Pekka,
Internal pipeline in hardware can operate at higher precision than the input
framebuffer
to plane engines. So, in case we have optical data of 16bits or 10bits
precision, hardware
can scale this up to higher precision in internal pipeline in hardware to take
care of rounding
and overflow issues. Even FP16 optical data will be normalized and converted
internally for
further processing.
Input to LUT hardware can be 16bits or even higher, so the look up table we
program can
be of higher precision than 16 (certain cases 24 in Intel pipeline). This is
later truncated to bpc supported
in output formats from sync (10, 12 or 16), mostly for electrical value to be
sent to sink.
Hence requesting to increase the container from current u16 to u32, to get
advantage of higher
precision luts.
Thanks & Regards,
Uma Shankar
>
> Thanks,
> pq
