All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.