AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Hung <alex.hung@amd.com>
To: Simon Ser <contact@emersion.fr>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org, harry.wentland@amd.com
Subject: Re: [V7 33/45] drm/colorop: Add 1D Curve Custom LUT type
Date: Thu, 16 Jan 2025 16:33:19 -0700	[thread overview]
Message-ID: <4d13fddf-d3d1-4e94-b736-e240a4ba8658@amd.com> (raw)
In-Reply-To: <bEQfY8v5JGKxFSuZE_Sx7wUPe4j7WtdrnKcY13WAyoMEA9vtUrCkyZoYUcFyPILmVZGW2Y8pOSk9hyhlp_Y0Stxx32osdADBMbpwJjBRPh8=@emersion.fr>



On 1/15/25 01:14, Simon Ser wrote:
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>> index a3e1fcad47ad..4744c12e429d 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -701,6 +701,9 @@ static int drm_atomic_color_set_data_property(struct drm_colorop *colorop,
>>   	bool replaced = false;
>>   
>>   	switch (colorop->type) {
>> +	case DRM_COLOROP_1D_LUT:
>> +		size = colorop->lut_size * sizeof(struct drm_color_lut);
> 
> Should we set the element size and the number of elements instead of
> multiplying? Or is that only useful when either of these are controlled by
> user-space to avoid integer overflows?

This multiplication here is to calculate the total size for the data blob.

The user-space communicates the lut_size (which is read-only) without 
multiplying sizeof(drm_color_lut) in drm_atomic_colorop_get_property, i.e.,

+	} else if (property == colorop->lut_size_property) {
+		*val = colorop->lut_size;

Is this what you meant?

> 
>> +		break;
>>   	case DRM_COLOROP_CTM_3X4:
>>   		size = sizeof(struct drm_color_ctm_3x4);
>>   		break;
>> @@ -750,6 +753,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
>>   		*val = state->bypass;
>>   	} else if (property == colorop->curve_1d_type_property) {
>>   		*val = state->curve_1d_type;
>> +	} else if (property == colorop->lut_size_property) {
>> +		*val = colorop->lut_size;
>>   	} else if (property == colorop->data_property) {
>>   		*val = (state->data) ? state->data->base.id : 0;
>>   	} else {
>> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
>> index 665b23900cc0..e6dea2713490 100644
>> --- a/drivers/gpu/drm/drm_colorop.c
>> +++ b/drivers/gpu/drm/drm_colorop.c
>> @@ -64,6 +64,7 @@
>>   
>>   static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
>>   	{ DRM_COLOROP_1D_CURVE, "1D Curve" },
>> +	{ DRM_COLOROP_1D_LUT, "1D Curve Custom LUT" },
> 
> Since we now have both a "normal" 1D curve, and a "special" one… Would it make
> sense to change our minds regarding the naming of the former? For instance, we
> could rename it to DRM_COLOROP_FIXED_1D_CURVE. Or is the current name clear
> enough (and only the human-readable name can be switched to "1D Fixed Curve")?

How about keeping "1D Curve" and simplifying "1D Curve Custom LUT" to 
"1D LUT" such as the following?

    	{ DRM_COLOROP_1D_CURVE, "1D Curve" },
+	{ DRM_COLOROP_1D_LUT, "1D LUT" },


  reply	other threads:[~2025-01-16 23:33 UTC|newest]

Thread overview: 127+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-20  4:33 [V7 00/45] Color Pipeline API w/ VKMS Alex Hung
2024-12-20  4:33 ` [V7 01/45] drm: Add helper for conversion from signed-magnitude Alex Hung
2025-02-24 16:07   ` Louis Chauvet
2025-02-24 18:50     ` Alex Hung
2025-02-25  9:35       ` Louis Chauvet
2024-12-20  4:33 ` [V7 02/45] drm/vkms: Round fixp2int conversion in lerp_u16 Alex Hung
2025-02-24 16:07   ` Louis Chauvet
2025-02-25  9:37   ` Louis Chauvet
2025-02-25 11:28     ` Simon Ser
2025-02-25 14:05       ` Louis Chauvet
2025-02-25 14:43         ` Harry Wentland
2025-02-25 14:45           ` Simon Ser
2025-02-25 16:00             ` Louis Chauvet
2024-12-20  4:33 ` [V7 03/45] drm/vkms: Add kunit tests for VKMS LUT handling Alex Hung
2025-02-24 16:07   ` Louis Chauvet
2025-02-25  9:51   ` Louis Chauvet
2025-02-25 14:45     ` Harry Wentland
2024-12-20  4:33 ` [V7 04/45] drm/doc/rfc: Describe why prescriptive color pipeline is needed Alex Hung
2024-12-20  4:33 ` [V7 05/45] drm/colorop: Introduce new drm_colorop mode object Alex Hung
2025-01-13  8:04   ` Simon Ser
2025-02-24 16:07   ` Louis Chauvet
2025-02-25 10:05   ` Louis Chauvet
2025-02-28 15:55     ` Harry Wentland
2024-12-20  4:33 ` [V7 06/45] drm/colorop: Add TYPE property Alex Hung
2025-01-13  8:05   ` Simon Ser
2025-02-24 16:07   ` Louis Chauvet
2025-02-25 10:07   ` Louis Chauvet
2024-12-20  4:33 ` [V7 07/45] drm/colorop: Add 1D Curve subtype Alex Hung
2025-01-13  8:07   ` Simon Ser
2025-02-24 16:07   ` Louis Chauvet
2025-02-25 10:13   ` Louis Chauvet
2025-02-28  1:07     ` Alex Hung
2025-02-28  9:24       ` Louis Chauvet
2024-12-20  4:33 ` [V7 08/45] Documentation/gpu: document drm_colorop Alex Hung
2025-01-13  8:18   ` Simon Ser
2025-02-10 22:03     ` Harry Wentland
2025-02-15 14:40       ` Simon Ser
2025-02-21 16:18         ` Harry Wentland
2025-02-21 16:42           ` Simon Ser
2025-02-21 18:41             ` Harry Wentland
2025-02-21 18:48               ` Simon Ser
2024-12-20  4:33 ` [V7 09/45] drm/colorop: Add BYPASS property Alex Hung
2025-01-13 17:49   ` Simon Ser
2025-02-24 16:07   ` Louis Chauvet
2025-02-25 10:15   ` Louis Chauvet
2024-12-20  4:33 ` [V7 10/45] drm/colorop: Add NEXT property Alex Hung
2025-01-13 17:54   ` Simon Ser
2025-02-24 16:07   ` Louis Chauvet
2025-02-25 10:21   ` Louis Chauvet
2024-12-20  4:33 ` [V7 11/45] drm/colorop: Add atomic state print for drm_colorop Alex Hung
2025-01-13 17:55   ` Simon Ser
2024-12-20  4:33 ` [V7 12/45] drm/plane: Add COLOR PIPELINE property Alex Hung
2025-01-13 18:08   ` Simon Ser
2024-12-20  4:33 ` [V7 13/45] drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE Alex Hung
2025-01-13 18:23   ` Simon Ser
2025-01-22 19:48     ` Harry Wentland
2025-01-22 20:05       ` Simon Ser
2024-12-20  4:33 ` [V7 14/45] drm/vkms: Add enumerated 1D curve colorop Alex Hung
2025-02-25 11:18   ` Louis Chauvet
2025-03-10 19:43     ` Harry Wentland
2024-12-20  4:33 ` [V7 15/45] drm/vkms: Add kunit tests for linear and sRGB LUTs Alex Hung
2025-02-25 11:19   ` Louis Chauvet
2025-03-10 15:09     ` Harry Wentland
2024-12-20  4:33 ` [V7 16/45] drm/colorop: Add 3x4 CTM type Alex Hung
2025-01-13 18:19   ` Simon Ser
2025-02-25 11:20   ` Louis Chauvet
2024-12-20  4:33 ` [V7 17/45] drm/vkms: Use s32 for internal color pipeline precision Alex Hung
2024-12-20  4:33 ` [V7 18/45] drm/vkms: add 3x4 matrix in color pipeline Alex Hung
2025-02-25 11:21   ` Louis Chauvet
2024-12-20  4:33 ` [V7 19/45] drm/tests: Add a few tests around drm_fixed.h Alex Hung
2024-12-20  4:33 ` [V7 20/45] drm/vkms: Add tests for CTM handling Alex Hung
2024-12-20  4:33 ` [V7 21/45] drm/colorop: pass plane_color_pipeline client cap to atomic check Alex Hung
2024-12-20  4:33 ` [V7 22/45] drm/colorop: define a new macro for_each_new_colorop_in_state Alex Hung
2025-01-15  7:48   ` Simon Ser
2024-12-20  4:33 ` [V7 23/45] drm/amd/display: Ignore deprecated props when plane_color_pipeline set Alex Hung
2025-01-15  7:56   ` Simon Ser
2025-01-22 21:05     ` Harry Wentland
2025-01-23 20:29       ` Simon Ser
2024-12-20  4:33 ` [V7 24/45] drm/amd/display: Add bypass COLOR PIPELINE Alex Hung
2024-12-20  4:33 ` [V7 25/45] drm/amd/display: Skip color pipeline initialization for cursor plane Alex Hung
2024-12-20  4:33 ` [V7 26/45] drm/amd/display: Add support for sRGB EOTF in DEGAM block Alex Hung
2025-02-13 15:35   ` Leo Li
2024-12-20  4:33 ` [V7 27/45] drm/amd/display: Add support for sRGB Inverse EOTF in SHAPER block Alex Hung
2024-12-20  4:33 ` [V7 28/45] drm/amd/display: Add support for sRGB EOTF in BLND block Alex Hung
2024-12-20  4:33 ` [V7 29/45] drm/colorop: Add PQ 125 EOTF and its inverse Alex Hung
2025-01-15  8:00   ` Simon Ser
2025-01-23 20:06     ` Harry Wentland
2025-01-23 20:33       ` Simon Ser
2025-01-17  9:04   ` Pekka Paalanen
2025-01-23 20:09     ` Harry Wentland
2024-12-20  4:33 ` [V7 30/45] drm/amd/display: Enable support for PQ 125 EOTF and Inverse Alex Hung
2024-12-20  4:33 ` [V7 31/45] drm/colorop: add BT2020/BT709 OETF and Inverse OETF Alex Hung
2025-01-15  8:04   ` Simon Ser
2025-01-23 20:13     ` Harry Wentland
2025-01-16  8:56   ` Pekka Paalanen
2025-01-17  9:06     ` Pekka Paalanen
2025-01-23 20:16       ` Harry Wentland
2025-01-27 12:05         ` Pekka Paalanen
2024-12-20  4:33 ` [V7 32/45] drm/amd/display: Add support for BT.709 and BT.2020 TFs Alex Hung
2025-02-12 23:03   ` Leo Li
2024-12-20  4:33 ` [V7 33/45] drm/colorop: Add 1D Curve Custom LUT type Alex Hung
2025-01-15  8:14   ` Simon Ser
2025-01-16 23:33     ` Alex Hung [this message]
2025-01-18 13:54       ` Simon Ser
2025-01-15 15:48   ` Simon Ser
2024-12-20  4:33 ` [V7 34/45] drm/amd/display: add shaper and blend colorops for 1D Curve Custom LUT Alex Hung
2025-02-12 23:44   ` Leo Li
2025-02-21 16:28     ` Harry Wentland
2024-12-20  4:33 ` [V7 35/45] drm/amd/display: add 3x4 matrix colorop Alex Hung
2025-02-13 17:16   ` Leo Li
2024-12-20  4:33 ` [V7 36/45] drm/colorop: Add mutliplier type Alex Hung
2025-01-15 15:54   ` Simon Ser
2024-12-20  4:33 ` [V7 37/45] drm/amd/display: add multiplier colorop Alex Hung
2024-12-20  4:33 ` [V7 38/45] drm/amd/display: Swap matrix and multiplier Alex Hung
2024-12-20  4:33 ` [V7 39/45] drm/colorop: Define LUT_1D interpolation Alex Hung
2025-01-20  7:48   ` Simon Ser
2024-12-20  4:33 ` [V7 40/45] drm/colorop: allow non-bypass colorops Alex Hung
2024-12-20  4:33 ` [V7 41/45] drm/colorop: Add 3D LUT supports to color pipeline Alex Hung
2025-01-20 21:16   ` Simon Ser
2024-12-20  4:33 ` [V7 42/45] drm/amd/display: add 3D LUT colorop Alex Hung
2025-02-13 18:21   ` Leo Li
2025-02-21 21:05     ` Harry Wentland
2024-12-20  4:33 ` [V7 43/45] drm/amd/display: Add AMD color pipeline doc Alex Hung
2025-01-17  9:19   ` Pekka Paalanen
2025-01-23 20:52     ` Harry Wentland
2024-12-20  4:33 ` [V7 44/45] drm/colorop: Add kernel doc for data blob Alex Hung
2024-12-20  4:33 ` [V7 45/45] drm/colorop: Add destroy functions for color pipeline Alex Hung

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=4d13fddf-d3d1-4e94-b736-e240a4ba8658@amd.com \
    --to=alex.hung@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=contact@emersion.fr \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=wayland-devel@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