From patchwork Fri Oct 13 13:13:59 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= X-Patchwork-Id: 13420910 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 33CCECDB47E for ; Fri, 13 Oct 2023 13:14:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7380F10E608; Fri, 13 Oct 2023 13:14:16 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 17ED610E608; Fri, 13 Oct 2023 13:14:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697202852; x=1728738852; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sRdaAneFm1tqOIfNUOOIGJYqZR3ZNY941Wkdz46zgTk=; b=Uv6iMWw1VmkPdTcsx64MaaCkt1lo8NAEuIc91mq4ej0Sr/WmCBN/BlGs zNAGhHS/IbB18WiM0RgxvMSgxFP4UWldyPY5VGN7TEQMHNjL7kQi72qPv K3SLNcINgXMtD+OeXf7BsSHNj6nW0K4EmnJn75kozW5kvTeZQgj/PsZoe HZZnTJm+8cSWfCOZOuEdpK7ZzneGOYakq3yGbtCEDhsUWqfb3doqAGz/p JeXOYzQMfKtWWpewwOfwks5FM5i1HGyljbHJljYk6a99H4vqyu2GZlVZC 7ifEs4ctq6nBkpws8a/yLmbBVrFoYM1V+fAxLKSVWjWgK2qgLJzAvPtr7 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10862"; a="449370217" X-IronPort-AV: E=Sophos;i="6.03,222,1694761200"; d="scan'208";a="449370217" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2023 06:14:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10862"; a="1086135998" X-IronPort-AV: E=Sophos;i="6.03,222,1694761200"; d="scan'208";a="1086135998" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.74]) by fmsmga005.fm.intel.com with SMTP; 13 Oct 2023 06:14:06 -0700 Received: by stinkbox (sSMTP sendmail emulation); Fri, 13 Oct 2023 16:14:06 +0300 From: Ville Syrjala To: intel-gfx@lists.freedesktop.org Subject: [PATCH 1/4] drm: Fix color LUT rounding Date: Fri, 13 Oct 2023 16:13:59 +0300 Message-ID: <20231013131402.24072-2-ville.syrjala@linux.intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231013131402.24072-1-ville.syrjala@linux.intel.com> References: <20231013131402.24072-1-ville.syrjala@linux.intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" From: Ville Syrjälä 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ä Reviewed-by: Chaitanya Kumar Borah --- 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);