On Tue, 3 Jun 2025 08:30:23 +0000 "Shankar, Uma" <[email protected]> wrote:
> > -----Original Message----- > > From: Pekka Paalanen <[email protected]> > > Sent: Friday, May 30, 2025 7:28 PM > > To: Shankar, Uma <[email protected]> > > Cc: Simon Ser <[email protected]>; Harry Wentland > > <[email protected]>; Alex Hung <[email protected]>; dri- > > [email protected]; [email protected]; intel- > > [email protected]; [email protected]; > > [email protected]; [email protected]; > > [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; Borah, Chaitanya Kumar > > <[email protected]>; [email protected] > > 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" <[email protected]> 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
