On 2025-01-17 04:19, Pekka Paalanen wrote: > On Thu, 19 Dec 2024 21:33:49 -0700 > Alex Hung <alex.hung@xxxxxxx> wrote: > >> From: Harry Wentland <harry.wentland@xxxxxxx> >> >> Add kernel doc for AMD color pipeline. >> >> Signed-off-by: Alex Hung <alex.hung@xxxxxxx> >> Signed-off-by: Harry Wentland <harry.wentland@xxxxxxx> >> --- >> .../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? > AMD HW only supports S2.13 and S3.13 for the CTM coefficients [1] and our driver only ever picks S2.13. The multiplier is programmed as a floating point value instead. [1] https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dc_hw_types.h#L1089 Harry > > 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 >
