[V7 43/45] drm/amd/display: Add AMD color pipeline doc

[Pekka Paalanen]

On Thu, 19 Dec 2024 21:33:49 -0700
Alex Hung <alex.hung at amd.com> wrote:

> From: Harry Wentland <harry.wentland at amd.com>
> 
> Add kernel doc for AMD color pipeline.
> 
> Signed-off-by: Alex Hung <alex.hung at amd.com>
> Signed-off-by: Harry Wentland <harry.wentland at amd.com>
> ---
>  .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 122 +++++++++++++++---
>  1 file changed, 102 insertions(+), 20 deletions(-)
> 
> 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 5e8c5c0657c4..56fb0870a2fc 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

...

> + * AMD plane color pipeline
> + * ------------------------
> + *
> + * The AMD &drm_plane color pipeline is advertised for DCN generations
> + * 3.0 and newer. It exposes these elements in this order:
> + *
> + * 1. 1D curve colorop
> + * 2. Multiplier
> + * 3. 3x4 CTM
> + * 4. 1D curve colorop
> + * 5. 1D LUT
> + * 6. 3D LUT
> + * 7. 1D curve colorop
> + * 8. 1D LUT
> + *
> + * The multiplier (#2) is a simple multiplier that is applied to all
> + * channels.
> + *
> + * The 3x4 CTM (#3) is a simple 3x4 matrix.

Hi,

I'm curious of why does the multiplier exist? Under what conditions is
it not feasible to precompute the multiplier into the CTM coefficients
and must instead be programmed as a separate colorop?


Thanks,
pq

>   *
> - * The pipe blending also happens after these blocks so we don't actually
> - * support any CRTC props with correct blending with multiple planes - but we
> - * can still support CRTC color management properties in DM in most single
> - * plane cases correctly with clever management of the DC interface in DM.
> + * #1, and #7 are non-linear to linear curves. #4 is a linear to
> + * non-linear curve. They support sRGB, PQ, and BT.709/BT.2020 EOTFs or
> + * their inverse.
>   *
> - * As per DRM documentation, blocks should be in hardware bypass when their
> - * respective property is set to NULL. A linear DGM/RGM LUT should also
> - * considered as putting the respective block into bypass mode.
> + * The 1D LUTs (#5 and #8) are plain 4096 entry LUTs.
>   *
> - * This means that the following
> - * configuration is assumed to be the default:
> + * The 3DLUT (#6) is a tetrahedrally interpolated 17 cube LUT.
>   *
> - * Plane DGM Bypass -> Plane CTM Bypass -> Plane RGM Bypass -> ...
> - * CRTC DGM Bypass -> CRTC CTM Bypass -> CRTC RGM Bypass
>   */
>  
>  #define MAX_DRM_LUT_VALUE 0xFFFF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20250117/044a5e84/attachment-0001.sig>