Re: [PATCH v2 0/5] better LUT segmentation for EOTFs

[Melissa Wen]

On 31/05/2026 19:15, Harry Wentland wrote:

On 2026-05-21 10:50, Melissa Wen wrote:

On 06/05/2026 21:11, 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.

Hello,

Can someone review this series - and merge it, if everything is okay?

Series is
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Hey Harry,

Thanks for reviewing.
Was this series applied to AMD's branch?

Melissa

Harry

Thanks,

Melissa

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/20260330153451.99472-8- harry.wentl...@amd.com/

[v1] https://lore.kernel.org/dri-devel/20260414220237.184289-1- m...@igalia.com/

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

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(-)