drm/amd/display: fix wrong color value mapping on MCM shaper LUT

Some shimmer/colorful points appears when using the steamOS color
pipeline for HDR on gaming with DCN32. These points look like black
values being wrongly mapped to red/blue/green values. It was caused
because the number of hw points in regular LUTs and in a shaper LUT was
treated as the same.

DCN3+ regular LUTs have 257 bases and implicit deltas (i.e. HW
calculates them), but shaper LUT is a special case: it has 256 bases and
256 deltas, as in DCN1-2 regular LUTs, and outputs 14-bit values.

Fix that by setting by decreasing in 1 the number of HW points computed
in the LUT segmentation so that shaper LUT (i.e. fixpoint == true) keeps
the same DCN10 CM logic and regular LUTs go with `hw_points + 1`.

CC: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Fixes: 4d5fd3d08e ("drm/amd/display: PQ tail accuracy")
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5006505b19)
This commit is contained in:
Melissa Wen
2026-01-22 12:20:29 -03:00
committed by Alex Deucher
parent 243b467dea
commit 8f959d37c1

View File

@@ -163,6 +163,11 @@ bool cm3_helper_translate_curve_to_hw_format(
hw_points += (1 << seg_distr[k]);
}
// DCN3+ have 257 pts in lieu of no separate slope registers
// Prior HW had 256 base+slope pairs
// Shaper LUT (i.e. fixpoint == true) is still 256 bases and 256 deltas
hw_points = fixpoint ? (hw_points - 1) : hw_points;
j = 0;
for (k = 0; k < (region_end - region_start); k++) {
increment = NUMBER_SW_SEGMENTS / (1 << seg_distr[k]);
@@ -223,8 +228,6 @@ bool cm3_helper_translate_curve_to_hw_format(
corner_points[1].green.slope = dc_fixpt_zero;
corner_points[1].blue.slope = dc_fixpt_zero;
// DCN3+ have 257 pts in lieu of no separate slope registers
// Prior HW had 256 base+slope pairs
lut_params->hw_points_num = hw_points + 1;
k = 0;