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

[Harry Wentland]

On 2025-04-15 02:40, Shankar, Uma wrote:
> 
> 
>> -----Original Message-----
>> From: Simon Ser <contact at emersion.fr>
>> Sent: Tuesday, April 15, 2025 11:47 AM
>> To: Shankar, Uma <uma.shankar at intel.com>
>> Cc: Alex Hung <alex.hung at amd.com>; dri-devel at lists.freedesktop.org; amd-
>> gfx at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; wayland-
>> devel at lists.freedesktop.org; harry.wentland at amd.com; leo.liu at amd.com;
>> ville.syrjala at linux.intel.com; pekka.paalanen at collabora.com;
>> mwen at igalia.com; jadahl at redhat.com; sebastian.wick at redhat.com;
>> shashank.sharma at amd.com; agoins at nvidia.com; joshua at froggi.es;
>> mdaenzer at redhat.com; aleixpol at kde.org; xaver.hugl at gmail.com;
>> victoria at system76.com; daniel at ffwll.ch; quic_naseer at quicinc.com;
>> quic_cbraga at quicinc.com; quic_abhinavk at quicinc.com; marcan at marcan.st;
>> Liviu.Dudau at arm.com; sashamcintosh at google.com; Borah, Chaitanya Kumar
>> <chaitanya.kumar.borah at intel.com>; louis.chauvet at bootlin.com
>> Subject: RE: [PATCH V8 32/43] drm/colorop: Add 1D Curve Custom LUT type
>>
>> On Tuesday, April 15th, 2025 at 08:09, Shankar, Uma <uma.shankar at intel.com>
>> wrote:
>>
>>> We want to have just one change in the way we expose the hardware
>>> capabilities else all looks good in general.
>>
>> I would really recommend leaving this as a follow-up extension. It's a complicated
>> addition that requires more discussion.
> 
> Hi Simon,
> We have tried to solve the complex part and made it simple to understand and implement
> along with a reference implementation [1] (can also help add the same for AMD case as well).
> Without this we will end up with up 2 interfaces for 1dL Lut which is not nice where the one above
> will be able to cover the current one. Let us know the problems with the proposed interface and we can
> work to fix the same. But having a common and single interface is good and the current one will not fit
> Intel's color pipeline distribution so the generic one anyways will be needed, and it will benefit userspace
> to know the underlying LUT distribution to compute the LUT samples.
> 
> [1] https://patchwork.freedesktop.org/series/129812/
> 

I think there is a lot of value in giving userspace a simple LUT
to work with. There are many compositors and many compositor
maintainers. When someone new jumps into color management usually
same thing happens. It starts with "it's not too complicated",
and then over a period of time progresses to "this is very much
non-trivial" as understanding one bit usually opens ten more
questions.

Forcing people to deal with another level of complexity will
discourage implementations and be counterproductive to furthering
adoption of color operations for HW acceleration, IMO.

I'm am not opposed to a complex LUT definition but I don't think
it should replace a simple and well-understood definition.

Harry

> Regards,
> Uma Shankar
>