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

[Harry Wentland <harry.wentland@amd.com>]

On 2025-04-15 02:40, Shankar, Uma wrote:
> 
> 
>> -----Original Message-----
>> From: Simon Ser <contact@emersion.fr>
>> Sent: Tuesday, April 15, 2025 11:47 AM
>> To: Shankar, Uma <uma.shankar@intel.com>
>> Cc: Alex Hung <alex.hung@amd.com>; dri-devel@lists.freedesktop.org; amd-
>> gfx@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; wayland-
>> devel@lists.freedesktop.org; harry.wentland@amd.com; leo.liu@amd.com;
>> ville.syrjala@linux.intel.com; pekka.paalanen@collabora.com;
>> 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; 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
>> 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@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
>