> On Dec 10, 2025, at 12:48 PM, Melissa Wen <[email protected]> wrote:
>
>
>
>> On 09/12/2025 15:19, Matthew Schwartz wrote:
>>> On 12/9/25 7:18 AM, Melissa Wen wrote:
>>>
>>> On 09/12/2025 12:12, Harry Wentland wrote:
>>>> On 2025-12-09 09:44, Melissa Wen wrote:
>>>>> On 09/12/2025 11:31, Melissa Wen wrote:
>>>>>> On 08/12/2025 22:34, Matthew Schwartz wrote:
>>>>>>>> On Dec 8, 2025, at 3:48 PM, Melissa Wen <[email protected]> wrote:
>>>>>>>>
>>>>>>>> There are some unexpected banding and shimmer effects when using
>>>>>>>> steamOS/gamescope color pipeline for HDR on DCN32 or newer families.
>>>>>>>> Those problems are not present in Steam Deck (DCN301). It happens on
>>>>>>>> DCN32 because plane shaper LUT uses DCN30 CM3 helper to translate
>>>>>>>> curves
>>>>>>>> instead of DCN10 CM helper. This series identifies the necessary
>>>>>>>> changes
>>>>>>>> on CM3 helper to reduce differences on color transformation made by
>>>>>>>> those two helpers.
>>>>>>>>
>>>>>>>> Patch 1 aims to solve the shimmer/colorful points that looks like a
>>>>>>>> wrong map of black values on red/green/blue colors. Patch 2 extends the
>>>>>>>> delta clamping fix made in commit 27fc10d1095f ("drm/amd/display: Fix
>>>>>>>> the delta clamping for shaper LUT") to solve some banding effects.
>>>>>>>>
>>>>>>>> Banding is not fully solved by any helper and needs further
>>>>>>>> investigation.
>>>>>>>>
>>>>>>>> One easy way to check the current and expected behavior is moving the
>>>>>>>> cursor (doing composition) to get the expected result from GFX. When
>>>>>>>> the
>>>>>>>> cursor disappears, those color transformations are back to be done by
>>>>>>>> the display hw.
>>>>>>> Hi Melissa,
>>>>>>>
>>>>>>> Could you share how you’re testing the gamescope color pipeline with
>>>>>>> HDR on DCN32, i.e display and connection type? Are any extra gamescope
>>>>>>> or kernel patches required?
>>>>>>>
>>>>>>> At least on my own DCN32 setup (AMD 7900XTX) + my primary monitor (an
>>>>>>> LG 45gx950a-b) via DisplayPort or my DCN35 setup + integrated HDR OLED
>>>>>>> screen (Legion Go 2), gamescope always composites when HDR is enabled.
>>>>>>> I applied your patches on top of kernel 6.18, and my kernel is built
>>>>>>> with CONFIG_DRM_AMD_COLOR_STEAMDECK=y (the downstream name of
>>>>>>> AMD_PRIVATE_COLOR for SteamOS), so that shouldn't be an issue. I tried
>>>>>>> everything from 1280x720p -> 5120x2160p, and it does not work on any
>>>>>>> resolution.
>>>>>> Hi Matt,
>>>>>>
>>>>>> You need to hack the DPP color caps to enabled SHAPER/3D and BLEND LUTs
>>>>>> as below:
>>>>>>
>>>>>> diff --git
>>>>>> i/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
>>>>>> w/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
>>>>>> index b276fec3e479..96b4f3239fb1 100644
>>>>>> --- i/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
>>>>>> +++ w/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
>>>>>> @@ -2256,8 +2256,8 @@ static bool dcn32_resource_construct(
>>>>>> dc->caps.color.dpp.gamma_corr = 1;
>>>>>> dc->caps.color.dpp.dgam_rom_for_yuv = 0;
>>>>>>
>>>>>> - dc->caps.color.dpp.hw_3d_lut = 0;
>>>>>> - dc->caps.color.dpp.ogam_ram = 0; // no OGAM in DPP since DCN1
>>>>>> + dc->caps.color.dpp.hw_3d_lut = 1;
>>>>>> + dc->caps.color.dpp.ogam_ram = 1; // no OGAM in DPP since DCN1
>>>>>> // no OGAM ROM on DCN2 and later ASICs
>>>>>> dc->caps.color.dpp.ogam_rom_caps.srgb = 0;
>>>>>> dc->caps.color.dpp.ogam_rom_caps.bt2020 = 0;
>>>>>>
>>>>>> In short, you need to change `caps.color.dpp.hw_3d_lut` and
>>>>>> `caps.color.dpp.ogam_ram` to 1 in the dcnX_resource.c file to say there
>>>>>> is a "plane" color caps.
>>>>>> The thing is that, in DCN32+, these color caps are not part of DPP
>>>>>> anymore, they are MPC capabilities in MCM that can be moved before or
>>>>>> after blending.
>>>>>> But the current kernel implementation checks DPP color caps to expose
>>>>>> plane color proprerties.
>>>>>> Checking MPC and where the MCM is positioned would be more complex, but
>>>>>> not impossible. Something to improve in the future yes.
>>>>> Just found this: dpp_color_caps.hw_3d_lut ||
>>>>> dm->dc->caps.color.mpc.preblend
>>>>> (https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c#L1636)
>>>>>
>>>>> Should be enough for new kernel versions. So you might need only the
>>>>> blend LUT hack.
>>>>>
>>>>>> You need to confirm that your `drm_info` shows all AMD plane color
>>>>>> properties, but gamescope basically checks CTM and BLEND_TF as you can
>>>>>> see here:
>>>>>> https://github.com/ValveSoftware/gamescope/blob/master/src/Backends/DRMBackend.cpp#L3347
>>>>>>
>>>> Are you testing this with AMD_PRIVATE_COLOR, or with the newly merged
>>>> color pipeline API? If it's the former, then the kernel needs to be built
>>>> with an explicit -DAMD_PRIVATE_COLOR for this to work.
>>> I'm testing with cflags, but AFAIU Matthew is using a downstream kernel
>>> version where there is an extra commit that enables AMD_PRIVATE_COLOR via
>>> config option ("CONFIG_DRM_AMD_COLOR_STEAMDECK=y").
>>> Depends on this kernel version, the hack for 3D LUT and BLEND LUT are both
>>> necessary.
>> Thanks, I had such a change locally to add back AMD_PLANE_BLEND_TF but I was
>> seeing some color banding in Ori and the Will of the Wisps menu around the
>> sun in the upper left corner which gave me pause. I see you mentioned
>> something similar in one of the threads [1] though, so we're all on the same
>> page now.
>>
>> I'm not sure if you've also tried this, but gamescopectl
>> drm_debug_disable_output_tf 1 seems to work around the color banding in that
>> case. From what I could tell, this bypasses the hardware LUTs while HDR
>> scanout continues working in gamescope. We lose blending on the MangoHud
>> overlay by disabling that though. I was thinking maybe it's due to the MCM
>> block only doing preblend unlike DPP blending, but I could definitely be on
>> the wrong track here...
> I didn't try it, but you gave an idea to bypass each transfer_func one by one
> to identify in which block the issue comes from.
> Just to let you know that I also see the same banding on Ori with Steam Deck
> OLED if plugged in an external monitor with HDR. Steam Deck hw doesn't have
> the MCM structure.
Interesting, was not aware of banding present in that scenario with OLED Deck
as well so that’s definitely good to know.
>
> I'll try to narrow down this issue a bit more.
> Still, the patches in this series address shaper LUT issues that are present
> in DCN32 but not in DCN301.
Yep, all clear now given the above info. I’ll give it some testing as well.
Thanks!
>
> Melissa
>>
>> [1]:
>> https://lore.kernel.org/amd-gfx/[email protected]/
>>
>>>> Harry
>>>>
>>>>>> Let me know if it works for you.
>>>>>>
>>>>>> BR,
>>>>>>
>>>>>> Melissa
>>>>>>
>>>>>>> Thanks,
>>>>>>> Matt
>>>>>>>
>>>>>>>> Lemme know your thoughts!
>>>>>>>>
>>>>>>>> Melissa
>>>>>>>>
>>>>>>>> Melissa Wen (2):
>>>>>>>> drm/amd/display: fix wrong color value mapping on DCN32 shaper LUT
>>>>>>>> drm/amd/display: extend delta clamping logic to CM3 LUT helper
>>>>>>>>
>>>>>>>> .../amd/display/dc/dcn30/dcn30_cm_common.c | 32 +++++++++++++++----
>>>>>>>> .../display/dc/dwb/dcn30/dcn30_cm_common.h | 2 +-
>>>>>>>> .../amd/display/dc/hwss/dcn30/dcn30_hwseq.c | 9 +++---
>>>>>>>> .../amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 17 ++++++----
>>>>>>>> .../amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 16 ++++++----
>>>>>>>> 5 files changed, 50 insertions(+), 26 deletions(-)
>>>>>>>>
>>>>>>>> --
>>>>>>>> 2.51.0
>>>>>>>>
>
