From: Harry Wentland <harry.wentland@amd.com>
To: Melissa Wen <mwen@igalia.com>
Cc: amd-gfx@lists.freedesktop.org,
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>,
sunpeng.li@amd.com, Alex Deucher <alexander.deucher@amd.com>,
dri-devel@lists.freedesktop.org, christian.koenig@amd.com,
Xinhui.Pan@amd.com, airlied@gmail.com, daniel@ffwll.ch,
Joshua Ashton <joshua@froggi.es>,
Sebastian Wick <sebastian.wick@redhat.com>,
Xaver Hugl <xaver.hugl@gmail.com>,
Shashank Sharma <Shashank.Sharma@amd.com>,
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>,
sungjoon.kim@amd.com, Alex Hung <alex.hung@amd.com>,
Pekka Paalanen <pekka.paalanen@collabora.com>,
Simon Ser <contact@emersion.fr>,
kernel-dev@igalia.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 01/34] drm/amd/display: fix segment distribution for linear LUTs
Date: Fri, 8 Sep 2023 10:40:07 -0400 [thread overview]
Message-ID: <93a868ae-9734-478d-86b7-dd17cd67fecb@amd.com> (raw)
In-Reply-To: <20230908141159.6hfne5r7hxi6bycs@mail.igalia.com>
On 2023-09-08 10:11, Melissa Wen wrote:
> On 09/06, Harry Wentland wrote:
>> On 2023-08-10 12:02, Melissa Wen wrote:
>>> From: Harry Wentland <harry.wentland@amd.com>
>>>
>>> The region and segment calculation was incapable of dealing
>>> with regions of more than 16 segments. We first fix this.
>>>
>>> Now that we can support regions up to 256 elements we can
>>> define a better segment distribution for near-linear LUTs
>>> for our maximum of 256 HW-supported points.
>>>
>>> With these changes an "identity" LUT looks visually
>>> indistinguishable from bypass and allows us to use
>>> our 3DLUT.
>>>
>>
>> Have you had a chance to test whether this patch makes a
>> difference? I haven't had the time yet.
>
> Last time I tested there was a banding issue on plane shaper LUT PQ ->
> Display Native, but it seems I don't have this use case on tester
> anymore, so I wasn't able to double-check if the issue persist. Maybe
> Joshua can provide some inputs here.
>
> Something I noticed is that shaper LUTs are the only 1D LUT on DCN30
> pipeline that uses cm_helper_translate_curve_to_hw_format(), all others
> (dpp-degamma/dpp-blend/mpc-regamma) call cm3_helper_translate_curve_*.
>
Yeah, they use different codepaths, unfortunately. Might be nice if we
could make them use the same.
> We can drop it from this series until we get the steps to report the
> issue properly.
>
Thanks. If you have concrete steps that show the issue (or even better,
an IGT test) I would be happy to include this.
Harry
> Melissa
>
>>
>> Harry
>>
>>> Signed-off-by: Harry Wentland <harry.wentland@amd.com>
>>> Signed-off-by: Melissa Wen <mwen@igalia.com>
>>> ---
>>> .../amd/display/dc/dcn10/dcn10_cm_common.c | 93 +++++++++++++++----
>>> 1 file changed, 75 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c
>>> index 3538973bd0c6..04b2e04b68f3 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c
>>> @@ -349,20 +349,37 @@ bool cm_helper_translate_curve_to_hw_format(struct dc_context *ctx,
>>> * segment is from 2^-10 to 2^1
>>> * There are less than 256 points, for optimization
>>> */
>>> - seg_distr[0] = 3;
>>> - seg_distr[1] = 4;
>>> - seg_distr[2] = 4;
>>> - seg_distr[3] = 4;
>>> - seg_distr[4] = 4;
>>> - seg_distr[5] = 4;
>>> - seg_distr[6] = 4;
>>> - seg_distr[7] = 4;
>>> - seg_distr[8] = 4;
>>> - seg_distr[9] = 4;
>>> - seg_distr[10] = 1;
>>> + if (output_tf->tf == TRANSFER_FUNCTION_LINEAR) {
>>> + seg_distr[0] = 0; /* 2 */
>>> + seg_distr[1] = 1; /* 4 */
>>> + seg_distr[2] = 2; /* 4 */
>>> + seg_distr[3] = 3; /* 8 */
>>> + seg_distr[4] = 4; /* 16 */
>>> + seg_distr[5] = 5; /* 32 */
>>> + seg_distr[6] = 6; /* 64 */
>>> + seg_distr[7] = 7; /* 128 */
>>> +
>>> + region_start = -8;
>>> + region_end = 1;
>>> + } else {
>>> + seg_distr[0] = 3; /* 8 */
>>> + seg_distr[1] = 4; /* 16 */
>>> + seg_distr[2] = 4;
>>> + seg_distr[3] = 4;
>>> + seg_distr[4] = 4;
>>> + seg_distr[5] = 4;
>>> + seg_distr[6] = 4;
>>> + seg_distr[7] = 4;
>>> + seg_distr[8] = 4;
>>> + seg_distr[9] = 4;
>>> + seg_distr[10] = 1; /* 2 */
>>> + /* total = 8*16 + 8 + 64 + 2 = */
>>> +
>>> + region_start = -10;
>>> + region_end = 1;
>>> + }
>>> +
>>>
>>> - region_start = -10;
>>> - region_end = 1;
>>> }
>>>
>>> for (i = region_end - region_start; i < MAX_REGIONS_NUMBER ; i++)
>>> @@ -375,16 +392,56 @@ bool cm_helper_translate_curve_to_hw_format(struct dc_context *ctx,
>>>
>>> j = 0;
>>> for (k = 0; k < (region_end - region_start); k++) {
>>> - increment = NUMBER_SW_SEGMENTS / (1 << seg_distr[k]);
>>> + /*
>>> + * We're using an ugly-ish hack here. Our HW allows for
>>> + * 256 segments per region but SW_SEGMENTS is 16.
>>> + * SW_SEGMENTS has some undocumented relationship to
>>> + * the number of points in the tf_pts struct, which
>>> + * is 512, unlike what's suggested TRANSFER_FUNC_POINTS.
>>> + *
>>> + * In order to work past this dilemma we'll scale our
>>> + * increment by (1 << 4) and then do the inverse (1 >> 4)
>>> + * when accessing the elements in tf_pts.
>>> + *
>>> + * TODO: find a better way using SW_SEGMENTS and
>>> + * TRANSFER_FUNC_POINTS definitions
>>> + */
>>> + increment = (NUMBER_SW_SEGMENTS << 4) / (1 << seg_distr[k]);
>>> start_index = (region_start + k + MAX_LOW_POINT) *
>>> NUMBER_SW_SEGMENTS;
>>> - for (i = start_index; i < start_index + NUMBER_SW_SEGMENTS;
>>> + for (i = (start_index << 4); i < (start_index << 4) + (NUMBER_SW_SEGMENTS << 4);
>>> i += increment) {
>>> + struct fixed31_32 in_plus_one, in;
>>> + struct fixed31_32 value, red_value, green_value, blue_value;
>>> + uint32_t t = i & 0xf;
>>> +
>>> if (j == hw_points - 1)
>>> break;
>>> - rgb_resulted[j].red = output_tf->tf_pts.red[i];
>>> - rgb_resulted[j].green = output_tf->tf_pts.green[i];
>>> - rgb_resulted[j].blue = output_tf->tf_pts.blue[i];
>>> +
>>> + in_plus_one = output_tf->tf_pts.red[(i >> 4) + 1];
>>> + in = output_tf->tf_pts.red[i >> 4];
>>> + value = dc_fixpt_sub(in_plus_one, in);
>>> + value = dc_fixpt_shr(dc_fixpt_mul_int(value, t), 4);
>>> + value = dc_fixpt_add(in, value);
>>> + red_value = value;
>>> +
>>> + in_plus_one = output_tf->tf_pts.green[(i >> 4) + 1];
>>> + in = output_tf->tf_pts.green[i >> 4];
>>> + value = dc_fixpt_sub(in_plus_one, in);
>>> + value = dc_fixpt_shr(dc_fixpt_mul_int(value, t), 4);
>>> + value = dc_fixpt_add(in, value);
>>> + green_value = value;
>>> +
>>> + in_plus_one = output_tf->tf_pts.blue[(i >> 4) + 1];
>>> + in = output_tf->tf_pts.blue[i >> 4];
>>> + value = dc_fixpt_sub(in_plus_one, in);
>>> + value = dc_fixpt_shr(dc_fixpt_mul_int(value, t), 4);
>>> + value = dc_fixpt_add(in, value);
>>> + blue_value = value;
>>> +
>>> + rgb_resulted[j].red = red_value;
>>> + rgb_resulted[j].green = green_value;
>>> + rgb_resulted[j].blue = blue_value;
>>> j++;
>>> }
>>> }
>>
next prev parent reply other threads:[~2023-09-08 14:40 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 16:02 [PATCH v2 00/34] drm/amd/display: add AMD driver-specific properties for color mgmt Melissa Wen
2023-08-10 16:02 ` [PATCH v2 01/34] drm/amd/display: fix segment distribution for linear LUTs Melissa Wen
2023-09-06 19:15 ` Harry Wentland
2023-09-08 14:11 ` Melissa Wen
2023-09-08 14:40 ` Harry Wentland [this message]
2023-08-10 16:02 ` [PATCH v2 02/34] drm/drm_mode_object: increase max objects to accommodate new color props Melissa Wen
2023-08-10 16:02 ` [PATCH v2 03/34] drm/drm_property: make replace_property_blob_from_id a DRM helper Melissa Wen
2023-08-10 16:02 ` [PATCH v2 04/34] drm/drm_plane: track color mgmt changes per plane Melissa Wen
2023-08-10 16:02 ` [PATCH v2 05/34] drm/amd/display: add driver-specific property for plane degamma LUT Melissa Wen
2023-08-10 16:02 ` [PATCH v2 06/34] drm/amd/display: add plane degamma TF driver-specific property Melissa Wen
2023-08-10 16:02 ` [PATCH v2 07/34] drm/amd/display: explicitly define EOTF and inverse EOTF Melissa Wen
2023-08-22 11:02 ` Pekka Paalanen
2023-08-25 14:18 ` Melissa Wen
2023-09-06 20:15 ` Harry Wentland
2023-09-07 7:49 ` Pekka Paalanen
2023-09-07 14:10 ` Harry Wentland
2023-09-08 7:45 ` Pekka Paalanen
2023-09-08 14:14 ` Melissa Wen
2023-08-10 16:02 ` [PATCH v2 08/34] drm/amd/display: document AMDGPU pre-defined transfer functions Melissa Wen
2023-08-22 11:45 ` Pekka Paalanen
2023-08-10 16:02 ` [PATCH v2 09/34] drm/amd/display: add plane HDR multiplier driver-specific property Melissa Wen
2023-08-22 11:54 ` Pekka Paalanen
2023-08-10 16:02 ` [PATCH v2 10/34] drm/amd/display: add plane 3D LUT driver-specific properties Melissa Wen
2023-09-06 19:30 ` Harry Wentland
2023-09-07 7:57 ` Pekka Paalanen
2023-09-08 14:19 ` Melissa Wen
2023-08-10 16:02 ` [PATCH v2 11/34] drm/amd/display: add plane shaper LUT and TF " Melissa Wen
2023-09-06 19:33 ` Harry Wentland
2023-09-08 14:21 ` Melissa Wen
2023-08-10 16:02 ` [PATCH v2 12/34] drm/amd/display: add plane blend " Melissa Wen
2023-08-10 16:02 ` [PATCH v2 13/34] drm/amd/display: add CRTC gamma TF driver-specific property Melissa Wen
2023-08-10 16:02 ` [PATCH v2 14/34] drm/amd/display: add comments to describe DM crtc color mgmt behavior Melissa Wen
2023-08-10 16:02 ` [PATCH v2 15/34] drm/amd/display: encapsulate atomic regamma operation Melissa Wen
2023-08-10 16:02 ` [PATCH v2 16/34] drm/amd/display: add CRTC gamma TF support Melissa Wen
2023-08-10 16:02 ` [PATCH v2 17/34] drm/amd/display: set sdr_ref_white_level to 80 for out_transfer_func Melissa Wen
2023-08-10 16:02 ` [PATCH v2 18/34] drm/amd/display: mark plane as needing reset if color props change Melissa Wen
2023-08-10 16:02 ` [PATCH v2 19/34] drm/amd/display: decouple steps for mapping CRTC degamma to DC plane Melissa Wen
2023-08-22 12:11 ` Pekka Paalanen
2023-08-25 14:29 ` Melissa Wen
2023-08-28 8:17 ` Pekka Paalanen
2023-08-30 10:59 ` Michel Dänzer
2023-09-06 14:46 ` Harry Wentland
[not found] ` <CAEZNXZCfvc909iFZQMdNEz=P_T=rYEYKq1Tdrt+8RNQpBSNt_g@mail.gmail.com>
2023-08-28 10:23 ` Pekka Paalanen
2023-08-28 13:56 ` Melissa Wen
2023-08-29 8:51 ` Pekka Paalanen
2023-09-06 14:52 ` Harry Wentland
2023-08-10 16:03 ` [PATCH v2 20/34] drm/amd/display: add plane degamma TF and LUT support Melissa Wen
2023-08-10 16:03 ` [PATCH v2 21/34] drm/amd/display: reject atomic commit if setting both plane and CRTC degamma Melissa Wen
2023-08-10 16:03 ` [PATCH v2 22/34] drm/amd/display: add dc_fixpt_from_s3132 helper Melissa Wen
2023-08-10 16:03 ` [PATCH v2 23/34] drm/amd/display: add HDR multiplier support Melissa Wen
2023-08-10 16:03 ` [PATCH v2 24/34] drm/amd/display: add plane shaper LUT support Melissa Wen
2023-08-10 16:03 ` [PATCH v2 25/34] drm/amd/display: add plane shaper TF support Melissa Wen
2023-08-10 16:03 ` [PATCH v2 26/34] drm/amd/display: add plane 3D LUT support Melissa Wen
2023-08-10 16:03 ` [PATCH v2 27/34] drm/amd/display: handle empty LUTs in __set_input_tf Melissa Wen
2023-08-10 16:03 ` [PATCH v2 28/34] drm/amd/display: add plane blend LUT and TF support Melissa Wen
2023-08-10 16:03 ` [PATCH v2 29/34] drm/amd/display: allow newer DC hardware to use degamma ROM for PQ/HLG Melissa Wen
2023-09-06 18:01 ` Harry Wentland
2023-09-08 14:28 ` Melissa Wen
2023-08-10 16:03 ` [PATCH v2 30/34] drm/amd/display: copy 3D LUT settings from crtc state to stream_update Melissa Wen
2023-08-10 16:03 ` [PATCH v2 31/34] drm/amd/display: set stream gamut remap matrix to MPC for DCN301 Melissa Wen
2023-08-22 12:30 ` Pekka Paalanen
2023-08-25 14:37 ` Melissa Wen
2023-08-28 8:20 ` Pekka Paalanen
2023-09-06 18:10 ` Harry Wentland
2023-08-10 16:03 ` [PATCH v2 32/34] drm/amd/display: add plane CTM driver-specific property Melissa Wen
2023-09-06 18:14 ` Harry Wentland
2023-09-08 14:41 ` Melissa Wen
2023-09-08 14:42 ` Harry Wentland
2023-08-10 16:03 ` [PATCH v2 33/34] drm/amd/display: add plane CTM support Melissa Wen
2023-09-06 18:18 ` Harry Wentland
2023-09-08 14:49 ` Melissa Wen
2023-08-10 16:03 ` [PATCH v2 34/34] drm/amd/display: Use 3x4 CTM for plane CTM Melissa Wen
2023-09-06 18:28 ` Harry Wentland
2023-09-06 19:33 ` [PATCH v2 00/34] drm/amd/display: add AMD driver-specific properties for color mgmt Harry Wentland
2023-09-08 14:52 ` Melissa Wen
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=93a868ae-9734-478d-86b7-dd17cd67fecb@amd.com \
--to=harry.wentland@amd.com \
--cc=Rodrigo.Siqueira@amd.com \
--cc=Shashank.Sharma@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=alex.hung@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=contact@emersion.fr \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=joshua@froggi.es \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mwen@igalia.com \
--cc=nicholas.kazlauskas@amd.com \
--cc=pekka.paalanen@collabora.com \
--cc=sebastian.wick@redhat.com \
--cc=sungjoon.kim@amd.com \
--cc=sunpeng.li@amd.com \
--cc=xaver.hugl@gmail.com \
/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
Powered by JetHome