Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
On 2025-05-15 13:19, Daniel Stone wrote: > Hi, > > On Thu, 15 May 2025 at 15:11, Harry Wentland wrote: >> On 2025-05-15 05:45, Simon Ser wrote: >>> I've reviewed all of the core DRM patches :) >>> >>> Have there been updates from user-space implementations? >> >> I know Leandro has been working on Weston to make use of >> this and last year Xaver had a prototype in kwin. > > Yeah, the Weston patches are marching on. We've still been doing a > little bit of cleanup and prep work in the background to land them, > but we also can't land them until the kernel lands. None of that work > is material to the uAPI though: as said previously, the uAPI looks > completely solid and it's something we can definitely beneficially use > in Weston. (Even if we do need the obvious follow-ons for > post-blending as well ...) > We can't merge kernel uAPI without canonical userspace that uses it. To move forward we'll need a userspace to at least publish a branch that shows the use of this new uAPI. Do you have a public branch for the Weston work for this? Harry > Cheers, > Daniel
Re: [PATCH V9 03/43] drm/doc/rfc: Describe why prescriptive color pipeline is needed
Reviewed-by: Simon Ser
Re: [PATCH V9 40/43] drm/colorop: allow non-bypass colorops
Reviewed-by: Simon Ser
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
I've reviewed all of the core DRM patches :) Have there been updates from user-space implementations?
Re: [PATCH V9 31/43] drm/colorop: add BT2020/BT709 OETF and Inverse OETF
Reviewed-by: Simon Ser
Re: [PATCH V9 13/43] drm/colorop: Add destroy functions for color pipeline
Reviewed-by: Simon Ser
Re: [PATCH V9 26/43] drm/amd/display: Add support for sRGB EOTF in DEGAM block
On Tue, 13 May 2025 16:39:51 -0400
Harry Wentland wrote:
> On 2025-05-13 11:36, Melissa Wen wrote:
> > On 05/13, Pekka Paalanen wrote:
> >> On Mon, 12 May 2025 15:50:17 -0300
> >> Melissa Wen wrote:
> >>
> >>> On 04/29, Alex Hung wrote:
> Expose one 1D curve colorop with support for
> DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> the sRGB transform when the colorop is not in bypass.
>
> With this change the following IGT test passes:
> kms_colorop --run plane-XR30-XR30-srgb_eotf
>
> The color pipeline now consists of a single colorop:
> 1. 1D curve colorop w/ sRGB EOTF
>
> Signed-off-by: Alex Hung
> Co-developed-by: Harry Wentland
> Signed-off-by: Harry Wentland
> Reviewed-by: Daniel Stone
> ---
> V9:
> - Update function names by _plane_ (Chaitanya Kumar Borah)
> - Update replace cleanup code by drm_colorop_pipeline_destroy (Simon
> Ser)
>
> v8:
> - Fix incorrect && by || in __set_colorop_in_tf_1d_curve (Leo Li)
>
> v7:
> - Fix checkpatch warnings
> - Change switch "{ }" position
> - Delete double ";"
> - Delete "{ }" for single-line if-statement
> - Add a new line at EOF
> - Change SPDX-License-Identifier: GPL-2.0+ from // to /* */
>
> v6:
> - cleanup if colorop alloc or init fails
>
> .../gpu/drm/amd/display/amdgpu_dm/Makefile| 3 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 86 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 69 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_colorop.h | 34
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 10 +++
> 5 files changed, 201 insertions(+), 1 deletion(-)
> create mode 100644
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
> create mode 100644
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.h
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
> b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
> index ab2a97e354da..46158d67ab12 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
> @@ -38,7 +38,8 @@ AMDGPUDM = \
> amdgpu_dm_pp_smu.o \
> amdgpu_dm_psr.o \
> amdgpu_dm_replay.o \
> -amdgpu_dm_wb.o
> +amdgpu_dm_wb.o \
> +amdgpu_dm_colorop.o
>
> ifdef CONFIG_DRM_AMD_DC_FP
> AMDGPUDM += dc_fpu.o
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index ebabfe3a512f..0b513ab5050f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -668,6 +668,18 @@ amdgpu_tf_to_dc_tf(enum amdgpu_transfer_function tf)
> }
> }
>
> +static enum dc_transfer_func_predefined
> +amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type tf)
> +{
> +switch (tf) {
> +case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
> +case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
> +return TRANSFER_FUNCTION_SRGB;
> +default:
> +return TRANSFER_FUNCTION_LINEAR;
> +}
> +}
> +
> static void __to_dc_lut3d_color(struct dc_rgb *rgb,
> const struct drm_color_lut lut,
> int bit_precision)
> @@ -1137,6 +1149,59 @@ __set_dm_plane_degamma(struct drm_plane_state
> *plane_state,
> return 0;
> }
>
> +static int
> +__set_colorop_in_tf_1d_curve(struct dc_plane_state *dc_plane_state,
> + struct drm_colorop_state *colorop_state)
> +{
> +struct dc_transfer_func *tf = &dc_plane_state->in_transfer_func;
> +struct drm_colorop *colorop = colorop_state->colorop;
> +struct drm_device *drm = colorop->dev;
> +
> +if (colorop->type != DRM_COLOROP_1D_CURVE ||
> +colorop_state->curve_1d_type !=
> DRM_COLOROP_1D_CURVE_SRGB_EOTF)
> +return -EINVAL;
> +
> +if (colorop_state->bypass) {
> +tf->type = TF_TYPE_BYPASS;
> +tf->tf = TRANSFER_FUNCTION_LINEAR;
> +return 0;
> +}
> +
> +drm_dbg(drm, "Degamma colorop with ID: %d\n", colorop->base.id);
> +
> +tf->type = TF_TYPE_PREDEFINED;
> +tf->tf =
> amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
> +
> +return 0;
> +}
> +
> +static int
> +__set_dm_plane_colorop_degamma(stru
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
On 2025-05-15 05:45, Simon Ser wrote: > I've reviewed all of the core DRM patches :) > > Have there been updates from user-space implementations? I know Leandro has been working on Weston to make use of this and last year Xaver had a prototype in kwin. Ideally we'd have gamescope adopt it and switch off the "temporary" AMD private properties and show that it behaves the same without breaking things. I added/moved the relevant folks into the "To" field. Harry
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
On Thursday, May 15th, 2025 at 16:11, Harry Wentland wrote: > > Have there been updates from user-space implementations? > > I know Leandro has been working on Weston to make use of > this and last year Xaver had a prototype in kwin. Cool! > Ideally we'd have gamescope adopt it and switch off the > "temporary" AMD private properties and show that it > behaves the same without breaking things. Right, I've started working on this a long time ago [1], but didn't manage to finish. I will not be able to continue this work, feel free to continue the work, pick apart useful bits or start from scratch, as you prefer. Ideally I'd like to add support in libliftoff/wlroots as well. [1]: https://github.com/ValveSoftware/gamescope/pull/1309
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
Hi, On Thu, 15 May 2025 at 15:11, Harry Wentland wrote: > On 2025-05-15 05:45, Simon Ser wrote: > > I've reviewed all of the core DRM patches :) > > > > Have there been updates from user-space implementations? > > I know Leandro has been working on Weston to make use of > this and last year Xaver had a prototype in kwin. Yeah, the Weston patches are marching on. We've still been doing a little bit of cleanup and prep work in the background to land them, but we also can't land them until the kernel lands. None of that work is material to the uAPI though: as said previously, the uAPI looks completely solid and it's something we can definitely beneficially use in Weston. (Even if we do need the obvious follow-ons for post-blending as well ...) Cheers, Daniel
Re: [PATCH V9 00/43] Color Pipeline API w/ VKMS
Hi, On Thu, 15 May 2025 at 19:02, Harry Wentland wrote: > On 2025-05-15 13:19, Daniel Stone wrote: > > Yeah, the Weston patches are marching on. We've still been doing a > > little bit of cleanup and prep work in the background to land them, > > but we also can't land them until the kernel lands. None of that work > > is material to the uAPI though: as said previously, the uAPI looks > > completely solid and it's something we can definitely beneficially use > > in Weston. (Even if we do need the obvious follow-ons for > > post-blending as well ...) > > We can't merge kernel uAPI without canonical userspace that uses it. > To move forward we'll need a userspace to at least publish a branch > that shows the use of this new uAPI. > > Do you have a public branch for the Weston work for this? Yeah, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1702 has been around for a little while now. There are some driver bugs that Leandro commented on, but they don't seem material to the uAPI as such? Cheers, Daniel
