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-...@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? 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. 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. Thanks, pq
pgpIsu8yTjITp.pgp
Description: OpenPGP digital signature
