Re: AMD display drivers handling DRM CRTC color mgmt props

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

Attachment: dcn3_cm_drm_current.drawio.png
Description: PNG image


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux