From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding
Date: Fri, 13 Oct 2023 16:13:59 +0300 [thread overview]
Message-ID: <20231013131402.24072-2-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20231013131402.24072-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
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>
---
include/drm/drm_color_mgmt.h | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 81c298488b0c..6be3cbe18944 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -36,20 +36,16 @@ struct drm_plane;
*
* Extract a degamma/gamma LUT value provided by user (in the form of
* &drm_color_lut entries) and round it to the precision supported by the
- * hardware.
+ * hardware, following OpenGL int<->float conversion rules.
*/
static inline u32 drm_color_lut_extract(u32 user_input, int bit_precision)
{
- u32 val = user_input;
- u32 max = 0xffff >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
+ if (bit_precision > 16)
+ return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(user_input, (1 << bit_precision) - 1),
+ (1 << 16) - 1);
+ else
+ return DIV_ROUND_CLOSEST(user_input * ((1 << bit_precision) - 1),
+ (1 << 16) - 1);
}
u64 drm_color_ctm_s31_32_to_qm_n(u64 user_input, u32 m, u32 n);
--
2.41.0
next prev parent reply other threads:[~2023-10-13 13:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 13:13 [Intel-gfx] [PATCH 0/4] drm/i915: Fix LUT rounding Ville Syrjala
2023-10-13 13:13 ` Ville Syrjala [this message]
2023-10-31 9:15 ` [Intel-gfx] [PATCH 1/4] drm: Fix color " Jani Nikula
2023-10-31 16:06 ` Ville Syrjälä
2023-11-20 13:03 ` Borah, Chaitanya Kumar
2023-11-20 13:17 ` Borah, Chaitanya Kumar
2023-11-20 14:27 ` Ville Syrjälä
2023-10-13 13:14 ` [Intel-gfx] [PATCH 2/4] drm/i915: Adjust LUT rounding rules Ville Syrjala
2023-11-20 6:08 ` Borah, Chaitanya Kumar
2023-11-20 14:26 ` Ville Syrjälä
2023-11-21 6:15 ` Borah, Chaitanya Kumar
2023-10-13 13:14 ` [Intel-gfx] [PATCH 3/4] drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack() Ville Syrjala
2023-11-03 4:39 ` Borah, Chaitanya Kumar
2023-10-13 13:14 ` [Intel-gfx] [PATCH 4/4] drm/i915: Fix glk+ degamma LUT conversions Ville Syrjala
2023-11-20 6:13 ` Borah, Chaitanya Kumar
2023-10-13 20:27 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix LUT rounding Patchwork
2023-10-13 20:27 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-10-13 20:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-10-15 1:55 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-11-13 17:37 ` [Intel-gfx] [PATCH 0/4] " Jani Nikula
2023-11-20 14:30 ` Ville Syrjälä
2023-11-21 10:51 ` Maxime Ripard
2023-11-23 17:35 ` Ville Syrjälä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231013131402.24072-2-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox