Re: [RFC 0/9] drm: rcar-du: cmm: Enable 3D LUT support

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3919 bytes --]

On Wed, 21 Jun 2023 10:10:22 +0200
Jacopo Mondi <jacopo.mondi@ideasonboard.com> wrote:

> Hello, this series is based on the RFC sent by Melssa Wen:
> "[RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface"
> https://lore.kernel.org/dri-devel/20230109143846.1966301-1-mwen@igalia.com/
> that introduces CRTC properties to control 3D LUT operations.
> 
> The R-Car DU peripheral has a post-blending color management pipeline (CMM)
> composed by (in order of processing) a 3D LUT a 1D LUT and a Color conversion
> unit.
> 
> The CMM driver already supported operating the 1D LUT, this series add support
> for the cubic LUT (named CLU).
> 
> I've been made aware by Melissa and Pekka that the focus of upstream for
> color management properties is now on the definition of the "Plane color
> pipeline" properties
> https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/
> 
> Unfortunately the model there proposed doesn't match the R-Car DU hardware which
> has color management at the post-blending level and not per plane (I've cc-ed
> all the receivers of that series, just in case).

Hi,

what are the actual use cases for post-blending color pipelines?

The pre-blending per-plane color pipelines are important for future
Wayland compositors, and post-blending is probably mostly about just
encoding for the sink (applying some inverse EOTF), so I've been
wondering why the post-blending color hardware seems to be so prevalent
and well-developed compared to pre-blending.

Is the idea that composition happens in a standard fixed color space,
and the post-blending color pipeline converts that to sink-native color
space?

If so, how do systems get their input content into the composition
space first?

Or is all this just a side-effect of caring about color on a single
plane, and not care at all how other planes with other kinds of content
will look? (e.g. TV broadcast vs. sub-titles, program guide, OSD)


Thanks,
pq

> The user-space interface has been validated with dedicated unit tests for
> the R-Car DU test suite (kms-test) which are available at:
> https://git.sr.ht/~jmondi_/kms-test
> 
> The series validates the usage of the HW interface in the hope of re-starting
> discussions and interests in the definition of CRTC color management
> properties.
> 
> Thanks
>    j
> 
> Alex Hung (1):
>   drm: Add 3D LUT mode and its attributes
> 
> Jacopo Mondi (1):
>   drm: rcar-du: crtc: Enable 3D LUT
> 
> Kieran Bingham (2):
>   drm: rcar-du: cmm: Provide 3D-CLU support
>   drm: rcar-du: kms: Configure the CLU
> 
> Laurent Pinchart (1):
>   drm: rcar-du: cmm: Refactor LUT configuration
> 
> Melissa Wen (4):
>   drm/drm_color_mgmt: add shaper LUT to color mgmt properties
>   drm/drm_color_mgmt: add 3D LUT props to DRM color mgmt
>   drm/drm_color_mgmt: add function to create 3D LUT modes supported
>   drm/drm_color_mgmt: add function to attach 3D LUT props
> 
>  drivers/gpu/drm/drm_atomic_state_helper.c |   7 ++
>  drivers/gpu/drm/drm_atomic_uapi.c         |  24 ++++
>  drivers/gpu/drm/drm_color_mgmt.c          | 113 +++++++++++++++++++
>  drivers/gpu/drm/drm_fb_helper.c           |   5 +
>  drivers/gpu/drm/drm_mode_config.c         |  21 ++++
>  drivers/gpu/drm/rcar-du/rcar_cmm.c        | 127 ++++++++++++++++------
>  drivers/gpu/drm/rcar-du/rcar_cmm.h        |  36 +++++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c    |  68 +++++++++---
>  include/drm/drm_color_mgmt.h              |   7 ++
>  include/drm/drm_crtc.h                    |  32 +++++-
>  include/drm/drm_mode_config.h             |  25 +++++
>  include/drm/drm_mode_object.h             |   2 +-
>  include/uapi/drm/drm_mode.h               |  17 +++
>  13 files changed, 428 insertions(+), 56 deletions(-)
> 
> --
> 2.40.1
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]