AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Louis Chauvet <louis.chauvet@bootlin.com>
To: Harry Wentland <harry.wentland@amd.com>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org,
	Alex Hung <alex.hung@amd.com>
Subject: Re: [PATCH v5 14/44] drm/vkms: Add enumerated 1D curve colorop
Date: Tue, 27 Aug 2024 19:49:48 +0200	[thread overview]
Message-ID: <Zs4RvNMce3rdgO2O@louis-chauvet-laptop> (raw)
In-Reply-To: <20240819205714.316380-15-harry.wentland@amd.com>

Le 19/08/24 - 16:56, Harry Wentland a écrit :

> +static int vkms_initialize_color_pipeline(struct drm_plane *plane, struct drm_prop_enum_list *list)
> +{
> +
> +	struct drm_colorop *op, *prev_op;
> +	struct drm_device *dev = plane->dev;
> +	int ret;
> +
> +	/* 1st op: 1d curve */
> +	op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
> +	if (!op) {
> +		DRM_ERROR("KMS: Failed to allocate colorop\n");
> +		return -ENOMEM;
> +	}
> +
> +	ret = drm_colorop_curve_1d_init(dev, op, plane, supported_tfs);
> +	if (ret)
> +		return ret;
> +
> +	list->type = op->base.id;
> +	list->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", op->base.id);
> +
> +	prev_op = op;
> +
> +	/* 2nd op: 1d curve */
> +	op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
> +	if (!op) {
> +		DRM_ERROR("KMS: Failed to allocate colorop\n");
> +		return -ENOMEM;
> +	}

There is no need to cleanup previously created colorop here?

> +	ret = drm_colorop_curve_1d_init(dev, op, plane, supported_tfs);
> +	if (ret)
> +		return ret;

ditto?

> +	drm_colorop_set_next_property(prev_op, op);
> +
> +	return 0;
> +}
> +
> +int vkms_initialize_colorops(struct drm_plane *plane)
> +{
> +	struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
> +	int len = 0;
> +	int ret;
> +
> +	/* Add color pipeline */
> +	ret = vkms_initialize_color_pipeline(plane, &(pipelines[len]));
> +	if (ret)
> +		return ret;
> +	len++;

The usage of len is not very clear, can you maybe remove it? Or do you 
plan to use it for instanciating multiple pipelines?

	struct drm_prop_enum_list pipeline;
	ret = vkms_initialize_color_pipeline(plane, &pipeline);
	drm_plane_create_color_pipeline_property(plane, &pipeline, 1);

> +	/* Create COLOR_PIPELINE property and attach */
> +	drm_plane_create_color_pipeline_property(plane, pipelines, len);

This function can fail, can you also test the result here?

> +
> +	return 0;
> +}
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c
> index 3ecda70c2b55..bc116d16e378 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -12,6 +12,7 @@
>  #include <linux/minmax.h>
>  
>  #include "vkms_drv.h"
> +#include "vkms_luts.h"
>  
>  static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
>  {
> @@ -163,6 +164,53 @@ static void apply_lut(const struct vkms_crtc_state *crtc_state, struct line_buff
>  	}
>  }
>  
> +static void apply_colorop(struct pixel_argb_u16 *pixel, struct drm_colorop *colorop)
> +{
> +	struct drm_colorop_state *colorop_state = colorop->state;
> +
> +	if (colorop->type == DRM_COLOROP_1D_CURVE) {
> +		switch (colorop_state->curve_1d_type) {
> +			case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
> +				pixel->r = apply_lut_to_channel_value(&srgb_inv_eotf, pixel->r, LUT_RED);
> +				pixel->g = apply_lut_to_channel_value(&srgb_inv_eotf, pixel->g, LUT_GREEN);
> +				pixel->b = apply_lut_to_channel_value(&srgb_inv_eotf, pixel->b, LUT_BLUE);
> +				break;
> +			case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
> +				pixel->r = apply_lut_to_channel_value(&srgb_eotf, pixel->r, LUT_RED);
> +				pixel->g = apply_lut_to_channel_value(&srgb_eotf, pixel->g, LUT_GREEN);
> +				pixel->b = apply_lut_to_channel_value(&srgb_eotf, pixel->b, LUT_BLUE);
> +				break;
> +			default:
> +				DRM_DEBUG_DRIVER("unkown colorop 1D curve type %d\n", colorop_state->curve_1d_type);

Maybe add a ONCE/RATELIMITED here, this function is called for every 
pixel.

> +				break;
> +		}
> +	}
> +
> +}
> +
> +static void pre_blend_color_transform(const struct vkms_plane_state *plane_state, struct line_buffer *output_buffer)
> +{
> +	struct drm_colorop *colorop = plane_state->base.base.color_pipeline;
> +
> +	while (colorop) {
> +		struct drm_colorop_state *colorop_state;
> +
> +		if (!colorop)
> +			return;
> +
> +		colorop_state = colorop->state;
> +
> +		if (!colorop_state)
> +			return;
> +
> +		for (size_t x = 0; x < output_buffer->n_pixels; x++)
> +			if (!colorop_state->bypass)

Maybe we can swap the for and the if? I don't know the performance impact 
is huge, but it feel more logical to check bypass before iterating.

> +				apply_colorop(&output_buffer->pixels[x], colorop);
> +
> +		colorop = colorop->next;
> +	}
> +}
> +
>  /**
>   * blend - blend the pixels from all planes and compute crc
>   * @wb: The writeback frame buffer metadata
> @@ -200,6 +248,9 @@ static void blend(struct vkms_writeback_job *wb,
>  				continue;
>  
>  			vkms_compose_row(stage_buffer, plane[i], y_pos);
> +
> +			pre_blend_color_transform(plane[i], stage_buffer);
> +
>  			pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
>  					    output_buffer);
>  		}

[...]

> diff --git a/drivers/gpu/drm/vkms/vkms_luts.c b/drivers/gpu/drm/vkms/vkms_luts.c
> new file mode 100644
> index 000000000000..6553d6d442b4
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/vkms_luts.c
> @@ -0,0 +1,802 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +
> +#include <drm/drm_mode.h>
> +
> +#include "vkms_drv.h"
> +#include "vkms_luts.h"
> +
> +static struct drm_color_lut linear_array[LUT_SIZE] = {
> +	{ 0x0, 0x0, 0x0, 0 },
> +	{ 0x101, 0x101, 0x101, 0 },
> +	{ 0x202, 0x202, 0x202, 0 },
> +	{ 0x303, 0x303, 0x303, 0 },
> +	{ 0x404, 0x404, 0x404, 0 },

For this LUT and the other, can you add a comment to explain how the 
values were generated/found?

[...]

Thanks,
Louis Chauvet

  reply	other threads:[~2024-08-27 17:50 UTC|newest]

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

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=Zs4RvNMce3rdgO2O@louis-chauvet-laptop \
    --to=louis.chauvet@bootlin.com \
    --cc=alex.hung@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --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