Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

From: Pekka Paalanen <ppaalanen@gmail.com>
To: Harry Wentland <harry.wentland@amd.com>
Cc: Deepak.Sharma@amd.com, amd-gfx@lists.freedesktop.org,
	mcasas@google.com, Shashank.Sharma@amd.com,
	dri-devel@lists.freedesktop.org, Shirish.S@amd.com,
	Sebastian Wick <sebastian@sebastianwick.net>,
	Krunoslav.Kovac@amd.com, hersenxs.wu@amd.com,
	Vitaly Prosyak <vitaly.prosyak@amd.com>,
	laurentiu.palcu@oss.nxp.com, Bhawanpreet.Lakha@amd.com,
	Nicholas.Kazlauskas@amd.com
Subject: Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes
Date: Wed, 19 May 2021 13:02:39 +0300	[thread overview]
Message-ID: <20210519130239.370c7e47@eldfell> (raw)
In-Reply-To: <20210519115337.3194fa11@eldfell>

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

On Wed, 19 May 2021 11:53:37 +0300
Pekka Paalanen <ppaalanen@gmail.com> wrote:

...

> TL;DR:
> 
> I would summarise my comments so far into these:
> 
> - Telling the kernel the color spaces and letting it come up with
>   whatever color transformation formula from those is not enough,
>   because it puts the render intent policy decision in the kernel.
> 
> - Telling the kernel what color transformations need to be done is
>   good, if it is clearly defined.
> 
> - Using an enum-based UAPI to tell the kernel what color
>   transformations needs to be done (e.g. which EOTF or EOTF^-1 to apply
>   at a step in the abstract pipeline) is very likely ok for many
>   Wayland compositors in most cases, but may not be sufficient for all
>   use cases. Of course, one is always bound by what hardware can do, so
>   not a big deal.
> 
> - You may need to define mutually exclusive KMS properties (referring
>   to my email in another branch of this email tree).
> 
> - I'm not sure I (we?) can meaningfully review things like "SDR boost"
>   property until we know ourselves how to composite different types of
>   content together. Maybe someone else could.
> 
> Does this help or raise thoughts?
> 
> The work on Weston CM&HDR right now is aiming to get it up to a point
> where we can start nicely testing different compositing approaches and
> methods and parameters, and I expect that will also feed back into the
> Wayland CM&HDR protocol design as well.

I have forgot to mention one important thing:

Generic Wayland compositors will be using KMS planes opportunistically.
The compositor will be switching between GL and KMS compositing
on-demand, refresh by refresh. This means that both GL and KMS
compositing must produce identical results, or users will be seeing
"color flicks" on switch.

This is a practical reason why we really want to know in full detail
how the KMS pipeline processes pixels.

Thanks,
pq

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