On 2022-04-21 10:37, Melissa Wen wrote:
> Hi all,
> 
> I'm examining how DRM color management properties (degamma, ctm, gamma)
> are applied to AMD display drivers. As far I could understand thanks
> Nicholas documentation on amdgpu_dm/amdgpu_dm_color, DC drivers have
> per-plane color correction features:
> 

DC programs some of the color correction features pre-blending but
DRM/KMS has not per-plane color correction properties.

See this series from Uma Shankar for an RFC on how to introduce those 
properties for 1D LUTs and CSC matrix:
https://patchwork.freedesktop.org/series/90826/

Bhanuprakash has a series of IGT tests for these properties: 
https://patchwork.freedesktop.org/series/96895/

I've rebased these on amd-staging-drm-next and maintain a kernel and IGT 
branch with these patches:
https://gitlab.freedesktop.org/hwentland/linux/-/tree/color-and-hdr
https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/color-and-hdr

We've had many discussions with Weston guys on this. In order to merge 
the kernel properties we need a canonical userspace implementation that 
are using it. Weston guys are working towards that but if you want to 
suggest a different userspace to serve as that vehicle I'd be all ears. :)

Note that in order to show this all working we also need a Wayland 
Protocol update.

See
https://gitlab.freedesktop.org/pq/color-and-hdr
https://gitlab.freedesktop.org/swick/wayland-protocols
https://gitlab.freedesktop.org/wayland/weston/-/issues/467

> * - Input gamma LUT (de-normalized)
> * - Input CSC (normalized)
> * - Surface degamma LUT (normalized)
> * - Surface CSC (normalized)
> * - Surface regamma LUT (normalized)
> * - Output CSC (normalized)
>                               
> so DM is "adapting" those DRM per-CRTC properties to fit into three of
> these color correction stages, which I guess are the surface stages:
> 
> * - Surface degamma LUT (normalized)
> * - Surface CSC (normalized)
> * - Surface regamma LUT (normalized)
> 
> I'm trying to understand what this mapping is doing. A comment mentions
> that is not possible to do these color corrections after blending, so,
> the same color correction pipe is performed on every plane before
> blending?  (is the surface the plane?) Does this adaptation affect the
> expected output?  Moreover, is there something that I misunderstood? :)
> 

What's possible to do before and after blending has changed quite a bit
between DCN generations. We program the CRTC Gamma and CTM after 
blending. See attached picture for a view relating the color bits 
between the DRM interface, DC interface and DCN 3.0 HW blocks.

> That said, if the DRM color mgmt supports per-CRTC 3D LUT as the last

Where do you see 3D LUT support in DRM? Is there a new proposal that 
I've missed?

I'm thinking of putting a 3D LUT proposal together but haven't gotten 
around to it yet. We'll want a pre-blending 3D LUT, and possible a 
programmable post-blending one as well.

Thanks,
Harry

> step of color correction, I don't see how to accommodate it in the
> mapping above, but I see DC already supports programming 3D LUT on DPP.
> Once DRM has the 3D LUT interface and DM mapped it as a DPP property,
> the 3D LUT will be at the end of the color correction pipeline? Is there
> anything I need to worry about mapping DRM 3D LUT support? Or any
> advice?
> 
> Thanks in advance,
> 
> Melissa