AMD display drivers handling DRM CRTC color mgmt props

[Melissa Wen]

On 04/21, Harry Wentland wrote:
> 
> 
> 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:
> > 
Hi Harry,

Wow, thanks so much for all details!
> 
> 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

So, I've followed these discussions (until the issue on naming) because
initially I considered it addresses our current goals for color
correction. But after some discussions, what we are targeting is a 3D
LUT after blending (per-CRTC). I found past proposals on dri-devel
[1][2] to extend the DRM CRTC color management properties, but they
didn't move forward and were never applied.

> 
> > * - 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.

This picture is really enlightening, thanks!
You said it changes between generations, therefore, I can't consider the
DCN 2.x family follow the same mapping, right? If so, can you share the
main differences for a DCN 2.x regarding per-CRTC properties?

> 
> > 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?

So, it's exactly what I aim to work: a proposal to add 3D LUT to the
current range of DRM per-CRTC color properties. But I also need to
understand how this property will be mapped to AMD display once it
exists in the DRM framework.

One of the things that caught my attention after seeing the attached
picture is the position of 3D LUT. I was expecting to see the 3D LUT
correction after gamma correction. Is this position a particularity of
DCN 3.0 (that varies between hw) or was I expecting a wrong color
correction pipeline at all?

Melissa

[1] https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+renesas@ideasonboard.com/
[2] https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69
> 
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20220421/86b96896/attachment.sig>