On Wed, 21 Jun 2023 10:10:22 +0200 Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxx/ > 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:
pgp_sQmJl5KPr.pgp
Description: OpenPGP digital signature
