AMD display drivers handling DRM CRTC color mgmt props
Harry Wentland
harry.wentland at amd.com
Thu Apr 21 15:53:47 UTC 2022
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcn3_cm_drm_current.drawio.png
Type: image/png
Size: 336117 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20220421/cef38d7e/attachment-0001.png>
More information about the amd-gfx
mailing list