Skip to content

Commit c6fbb6b

Browse files
committed
drm: Fix color LUT rounding
The current implementation of drm_color_lut_extract() generates weird results. Eg. if we go through all the values for 16->8bpc conversion we see the following pattern: in out (count) 0 - 7f -> 0 (128) 80 - 17f -> 1 (256) 180 - 27f -> 2 (256) 280 - 37f -> 3 (256) ... fb80 - fc7f -> fc (256) fc80 - fd7f -> fd (256) fd80 - fe7f -> fe (256) fe80 - ffff -> ff (384) So less values map to 0 and more values map 0xff, which doesn't seem particularly great. To get just the same number of input values to map to the same output values we'd just need to drop the rounding entrirely. But perhaps a better idea would be to follow the OpenGL int<->float conversion rules, in which case we get the following results: in out (count) 0 - 80 -> 0 (129) 81 - 181 -> 1 (257) 182 - 282 -> 2 (257) 283 - 383 -> 3 (257) ... fc7c - fd7c -> fc (257) fd7d - fe7d -> fd (257) fe7e - ff7e -> fe (257) ff7f - ffff -> ff (129) Note that since the divisor is constant the compiler is able to optimize away the integer division in most cases. The only exception is the _ULL() case on 32bit architectures since that gets emitted as inline asm via do_div() and thus the compiler doesn't get to optimize it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231013131402.24072-2-ville.syrjala@linux.intel.com Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org>
1 parent 12b7142 commit c6fbb6b

1 file changed

Lines changed: 8 additions & 11 deletions

File tree

include/drm/drm_color_mgmt.h

Lines changed: 8 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -36,20 +36,17 @@ struct drm_plane;
3636
*
3737
* Extract a degamma/gamma LUT value provided by user (in the form of
3838
* &drm_color_lut entries) and round it to the precision supported by the
39-
* hardware.
39+
* hardware, following OpenGL int<->float conversion rules
40+
* (see eg. OpenGL 4.6 specification - 2.3.5 Fixed-Point Data Conversions).
4041
*/
4142
static inline u32 drm_color_lut_extract(u32 user_input, int bit_precision)
4243
{
43-
u32 val = user_input;
44-
u32 max = 0xffff >> (16 - bit_precision);
45-
46-
/* Round only if we're not using full precision. */
47-
if (bit_precision < 16) {
48-
val += 1UL << (16 - bit_precision - 1);
49-
val >>= 16 - bit_precision;
50-
}
51-
52-
return clamp_val(val, 0, max);
44+
if (bit_precision > 16)
45+
return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(user_input, (1 << bit_precision) - 1),
46+
(1 << 16) - 1);
47+
else
48+
return DIV_ROUND_CLOSEST(user_input * ((1 << bit_precision) - 1),
49+
(1 << 16) - 1);
5350
}
5451

5552
u64 drm_color_ctm_s31_32_to_qm_n(u64 user_input, u32 m, u32 n);

0 commit comments

Comments
 (0)