On 08/12/2025 20:59, Melissa Wen wrote:
On 28/11/2025 18:36, Harry Wentland wrote:
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.
Hi Harry,
Sorry for the delay. I got swamped with another debugging.
I identified to different problems on plane shaper LUT when using the
cm3 helper: those dark values wrong mapping and banding on some light
values.
^^^ two
I followed your suggestion and found the necessary changes to address
both issues, I just sent two RFC patches , so we can discuss it better
there.
https://lore.kernel.org/amd-gfx/[email protected]/
I still see a gradient banding on the game menu of Ori, but it's
present with the DCN10 CM helper too.
Thanks for taking a look at these problems.
Melissa
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;
}
