On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote:
On Wed, 10 Nov 2021 00:02:16 +0200 Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
On 2021-11-08 04:54, Pekka Paalanen wrote:
On Thu, 4 Nov 2021 12:27:56 -0400 Harry Wentland harry.wentland@amd.com wrote:
On 2021-11-04 04:38, Pekka Paalanen wrote:
On Wed, 3 Nov 2021 11:08:13 -0400 Harry Wentland harry.wentland@amd.com wrote:
> On 2021-09-06 17:38, Uma Shankar wrote: >> Existing LUT precision structure is having only 16 bit >> precision. This is not enough for upcoming enhanced hardwares >> and advance usecases like HDR processing. Hence added a new >> structure with 32 bit precision values. >> >> This also defines a new structure to define color lut ranges, >> along with related macro definitions and enums. This will help >> describe multi segmented lut ranges in the hardware. >> >> Signed-off-by: Uma Shankar uma.shankar@intel.com >> --- >> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++ >> 1 file changed, 58 insertions(+)
...
If the framebuffer is not in FP16 the question then becomes how the integer pixel values relate to LUT addressing.
Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping is to match minimum unsigned integer value to 0.0, and unsigned maximum integer value to 1.0. This is how things work on the cable too, right? (Also taking full vs. limited range video signal into account. And conversion to cable-YUV if that happens.)
If you want integer format FB values to map to something else, then you have to tag the FB with that range information, somehow. New UAPI.
On the cable we send integer values, not floating point. AMD HW uses floating point internally, though, and the PWL API defines floating point entries, so on some level we need to be clear what the floating point entries mean. Either we document that to be [0.0, 1.0] or we have some UAPI to define it. I'm leaning toward the latter but have to think about it some more.
As for Intel hw if you have an integer pixel value of 0xff... (with however many bits you have with a specific pixel format) it will get extended to 0.fff... (to whatever precision the pipe has internally). So if we go by that a fixed point 1.0 value in the proposed drm_color_lut_range would be considered just outside the gamut. And pretty sure fp16 input of 1.0 should also result in a 0.fff... internal value as well [1]. I think that definition pretty much matches how GL UNORM<->float conversion works as well.
Does it work that way in GL though?
I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not 255.0/256.0.
Taking a random spec: OpenGL ES 2.0.25
Section 2.1.2 Data Conversions says:
Normalized unsigned integers represent numbers in the range [0, 1]. The conversion from a normalized unsigned integer c to the corresponding floating-point f is defined as f = c / (2^b - 1)
Note how the divisor has -1.
That seems to match what I said, or at least tried to say (~0 <-> 1.0 in float). drm_color_lut_range being fixed point would follow the ~0 side of that. Or at least that interpretation would very easily map to our hw.