On 2025-11-28 14:09, Melissa Wen wrote:
>
>
> On 27/11/2025 17:39, Harry Wentland wrote:
>>
>> On 2025-11-25 19:45, Melissa Wen wrote:
>>> The usage of DCN30 CM helper creates some unexpected shimmer points on
>>> PQ shaper TF in the steamOS HDR color pipeline. Fix it by using the same
>>> DCN10 color mgmt helper of previous hw versions to translate plane
>>> shaper func to hw format in DCN32 hw family.
>>>
>>> Signed-off-by: Melissa Wen <[email protected]>
>>> ---
>>>
>>> Hi,
>>>
>>> Commit a953cd8cac6b ("drm/amd/display: Fix MPCC 1DLUT programming")
>>> mentions some visible artifacts when using DCN10 CM helper on DCN32
>>> shaper and blend LUTs. On the other hand, using DCN30 CM helper creates
>>> some shimmer points on steamOS HDR pipeline. We didn't noticed any
>>> visible artifacts so far, but I'd like to know more about what kind of
>>> artifacts were visible at the time this helper for shaper func was
>>> switched in the afore-mentioned commit for further investigation.
>>>
>> Thanks for the debug.
>>
>> Do you have more info on the unexpected shimmer points with SteamOS?
>> Ideally a video and a description on what to look for and why it's
>> wrong, or a comparison to a GFX-transformed example that shows the
>> correct visuals?
> Hi Harry,
>
> I took some pictures of clear unexpected scenes in HDR games.
>
> 1.
> https://people.igalia.com/mwen/hdr-dcn321-pics/HDR-DCN321-split-fiction-game-black-loading-bkg.jpg
>
> Just loading Split Fiction after having turning on HDR in this game options
> (Options > Graphics > HDR).
> We expected a black background with the Loading <icon> in the bottom right,
> this background is full of bright spots.
> Friend pass is enough to reproduce the issue without having the game.
>
> 2.
> https://people.igalia.com/mwen/hdr-dcn321-pics/HDR-DCN321-god-of-war-ragnarok-menu.jpg
>
> Colorful-bright points around the margin/corner of the God of War Ragnarok
> game menu.
>
> 3. God of War Ragnarok game intro:
>
> -
> https://people.igalia.com/mwen/hdr-dcn321-pics/HDR-DCN321-god-of-war-ragnarok-intro1.jpg
> -
> https://people.igalia.com/mwen/hdr-dcn321-pics/HDR-DCN321-god-of-war-ragnarok-intro2.jpg
> -
> https://people.igalia.com/mwen/hdr-dcn321-pics/HDR-DCN321-god-of-war-ragnarok-intro3.jpg
> -
> https://people.igalia.com/mwen/hdr-dcn321-pics/HDR-DCN321-god-of-war-ragnarok-PS-logo.jpg
>
> Same random shimmer distortions.
> I think those images are good examples, but still pending screenshot/GFX
> examples for comparison.
> I'll take it and reply here later.
>
Thanks, that would still be helpful, but even as-is these images
quite highlight the issue. It's more severe than I expected.
>>
>> Obviously we don't want to simply switch back to DCN10 helpers
>> without understand why, and potentially regressing other use-cases.
>> At least we should look at what the differences are between the
>> two versions of that function, and which part of the curve programming
>> causes the undesirable results.
>>
>> The original bug that was solved by that commit was a regression that
>> sent bright values in an HDR video to black or red, so basically
>> something really messed up bright PQ values. At least I suspect
>> it was a PQ HDR video. The ticket doesn't state that.
> I see. Looks like now we have somehow the same problem but in reverse (?)
> like black values mapped into bright values (?)
Yeah, if I understand your screenshots the issue seems to happen
(mainly) with dark values?
>>
>> When looking at the diff between the two functions I notice that
>> the cm3_ version is missing the dc_fixpt_clamp_u0d10 for the
>> delta_<color>_reg assignments, toward the bottom of the function.
>> I remember I had to add that to the cm_ version since it caused
>> issues with SteamOS HDR. Can we try that on the cm3_ function?
> Yes, I remember this issue.
>
> I've already tried the same changes from this commit
> (https://gitlab.freedesktop.org/agd5f/linux/-/commit/27fc10d1095f) to
> cm3_helper, but it doesn't help... probably because the commit was addressing
> a different behaviors.
>
> I also noticed on cm3_ they consider a different range of hw points, as in
> this comment:
> "
> // DCN3+ have 257 pts in lieu of no separate slope registers
> // Prior HW had 256 base+slope pairs
> "
>
> Can it be related to this problem?
>
Possibly. The point distribution is one potential culprit.
How I would debug this is to look at the diff between the two
functions and try each diff one at a time to see whether one
(or two) small changes fixes this. Then look at what that change
was and what it does. That can then give us a guide on how to
properly fix it without affecting other use-cases.
The other thing to understand is why we didn't see issues with
the Color Pipeline API tests in IGT.
Harry
> Thanks,
>
> Melissa
>
>>
>> Cheers,
>> Harry
>>
>>> Thanks in advance,
>>>
>>> Melissa
>>>
>>>
>>> drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
>>> b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
>>> index bf19ba65d09a..a28560caa1c0 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
>>> @@ -501,9 +501,9 @@ bool dcn32_set_mcm_luts(
>>> lut_params = &plane_state->in_shaper_func.pwl;
>>> else if (plane_state->in_shaper_func.type ==
>>> TF_TYPE_DISTRIBUTED_POINTS) {
>>> // TODO: dpp_base replace
>>> - ASSERT(false);
>>> -
>>> cm3_helper_translate_curve_to_hw_format(&plane_state->in_shaper_func,
>>> - &dpp_base->shaper_params, true);
>>> + cm_helper_translate_curve_to_hw_format(plane_state->ctx,
>>> + &plane_state->in_shaper_func,
>>> + &dpp_base->shaper_params, true);
>>> lut_params = &dpp_base->shaper_params;
>>> }
>>>
>
