[PATCH V8 32/43] drm/colorop: Add 1D Curve Custom LUT type

[Pekka Paalanen]

On Thu, 22 May 2025 11:33:00 +0000
"Shankar, Uma" <uma.shankar at 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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250530/83cfa509/attachment.sig>