On 5/6/26 12:11 PM, Melissa Wen wrote:
> Hi,
>
> With an external HDR monitor, we can see gradient banding around the sun
> in the intro of Ori and the Will of the Wisps game on steamOS/Gamescope.
> Gamescope uses AMD predefined transfer functions for degamma,
> shaper/pre-3D-LUT and blend/post-3D-LUT plus CRTC regamma, however, only
> degamma block has hardware curves. Shaper, blend, regamma predefined TFs
> are software-computed by AMD color module into PWL LUTs. In addition, we
> cannot use hardware curves on PRE_DEGAM with subsampled format, so that,
> predefined TFs are also translated to LUTs in this situation, using
> GAMCOR block instead. For this translation, the driver originally used
> the same helper for EOTFs and inverse EOTFs, even though they differ in
> input domain, number of regions and number of TF points per region.
>
> Baring this in mind, patch 1 maps degamma predefined curves as LUT using
> GAMCOR block for AMD driver-specific property that are still in use by
> current gamescope. This was inspired by a similar patch from Harry for
> colorop [1]. Patch 2 reverts commit 8b89acc0b2ba ("drm/amd/display:
> Remove unused cm3_helper_translate_curve_to_degamma_hw_format") to
> reintroduce cm3_helper_translate_curve_to_degamma_hw_format() and patch
> 3 wire it up for encoded -> linear-light LUTs (degamma/blend). With 16
> samples per region across 12 regions for blend LUT (where hardware
> fixed-function curves are not available and predefined TFs are
> software-computed into LUTs), banding becomes almost imperceptible.
>
> Patch 4 and 5 increase precision in the brightest half, where PQ/SRGB
> EOTFs are steeper, by enabling up to 256 samples per region and halving
> the per-region point count across 9 regions (128 in [0.5, 1], 64 in
> [0.25, 0.5], …). This better matches the shape of PQ/SRGB EOTFs.
> Although patches 4 and 5 seem conceptually correct to me, I couldn't see
> clear improvement in the bright end with or without them.
>
> This series targets DCN3+ hw families. With this series:
> - degamma and blend LUTs use
> cm3_helper_translate_curve_to_degamma_hw_format(): encoded input,
> non-zero end slope, up to 256 points linearly interpolated between
> adjacent TF pts, fitting [0,1] encoded input range.
> - shaper and regamma LUTs continue using
> cm3_helper_translate_curve_to_hw_format(): linear-light input, zero
> end slope, 16 points per region across 32 regions.
>
> [1]
> https://lore.kernel.org/dri-devel/[email protected]/
>
> [v1]
> https://lore.kernel.org/dri-devel/[email protected]/
> Changes:
> - new patch for GAMCOR usage in case of degamma predefined TF with subsampled
> formats
> - fix misleading information regarding degamma hw curves (Kruno)
> - clarify LUT segmentation choice using 8-bit sRGB as a reference (Kruno)
>
> Best Regards,
>
> Melissa
I tested this on a DCN35 device with an internal HDR panel that was affected by
the gradient issue. I cannot see any banding present with this series applied
on top of amd-staging-drm-next with AMD private color properties enabled.
Tested-by: Matthew Schwartz <[email protected]>
for the series.
Thanks,
Matt
>
> Melissa Wen (5):
> drm/amd/display: use GAMCOR for degamma private props in subsampled
> format
> Revert "drm/amd/display: Remove unused
> cm3_helper_translate_curve_to_degamma_hw_format"
> drm/amd/display: use a separate helper to translate degamma curves
> drm/amd/display: support up to 256 samples per region in degamma/blend
> LUT
> drm/amd/display: use halving distribution for PQ/sRGB linearizing LUT
>
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 16 +-
> .../amd/display/dc/dcn30/dcn30_cm_common.c | 184 ++++++++++++++++++
> .../display/dc/dwb/dcn30/dcn30_cm_common.h | 4 +
> .../amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 10 +-
> 4 files changed, 204 insertions(+), 10 deletions(-)
>
