> -----Original Message----- > From: Harry Wentland <harry.wentl...@amd.com> > Sent: Wednesday, June 4, 2025 1:57 AM > To: Pekka Paalanen <pekka.paala...@collabora.com>; Shankar, Uma > <uma.shan...@intel.com> > Cc: Simon Ser <cont...@emersion.fr>; Alex Hung <alex.h...@amd.com>; dri- > de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; intel- > g...@lists.freedesktop.org; wayland-de...@lists.freedesktop.org; > leo....@amd.com; ville.syrj...@linux.intel.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 2025-06-03 06:51, Pekka Paalanen wrote: > > On Tue, 3 Jun 2025 08:30:23 +0000 > > "Shankar, Uma" <uma.shan...@intel.com> wrote: > > > >>> -----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-gfx@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. > > > > Is it integer or floating-point? > > > > For AMD the internal format is floating point with slightly higher precision > than > FP16. > > > If we take the full range of PQ as optical and put it into 16-bit > > integer format, the luminance step from code 1 to code 2 is 0.15 cd/m². > > That seems like a huge step in the dark end. Such a step would > > probably need to be divided over several taps in a LUT, which wouldn't > > be possible. > > > > Right, and with 32-bpc we'll get a luminance step size of > ~0.0000023 cd/m^2, which seems plenty fine-grained. > > > In that sense, if a LUT is used for the PQ EOTF, I totally agree that > > 16-bit integer won't be even nearly enough precision. > > > > This actually points out the caveat that increasing the number of taps > > in a LUT can cause the LUT to become non-monotonic when the sample > > precision runs out. That is, consecutive taps don't always increase in > > value. > > > >> 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. > > > > My argument though is to use a floating-point format for the LUT > > samples instead of adding more and more integer bits. That naturally > > puts more precision where it is needed: near zero. > > > > A driver can easily convert that to any format the hardware needs. > > > > However, it might make best sense for a driver to expose a LUT with a > > format that best matches the hardware precision, especially > > floating-point vs. integer. > > > > I guess we may eventually need both 32 bpc integer and 16 (or 32) bpc > > floating-point. > > > > While I like floating point better for representing these things I don't > think it's a > great idea to pass floating point values via IOCTLs but 32 bpc integer values > make > sense here. >
Nice, we all are on same page here. > Thanks, Uma, for pushing on this. Thanks Harry and Pekka for valuable inputs. Regards, Uma Shankar > Harry > > > > > Thanks, > > pq
