Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Pekka Paalanen <ppaalanen@gmail.com>]

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

On Thu, 19 Oct 2023 10:56:40 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2023-10-10 12:13, Melissa Wen wrote:
> > O 09/08, Harry Wentland wrote:  
> >> Signed-off-by: Harry Wentland <harry.wentland@amd.com>

...

> > Also, with this new plane API in place, I understand that we will
> > already need think on how to deal with the mixing between old drm color
> > properties (color encoding and color range) and these new way of setting
> > plane color properties. IIUC, Pekka asked a related question about it
> > when talking about CRTC automatic RGB->YUV (?) 
> >   
> 
> We'll still need to confirm whether we'll want to deprecate these
> existing properties. If we do that we'd want a client prop. Things
> should still work without deprecating them, if drivers just pick up
> after the initial encoding and range CSC.
> 
> But realistically it might be better to deprecate them and turn them
> into explicit colorops.

The existing properties would need to be explicitly reflected in the
new pipelines anyway, otherwise there would always be doubt at which
point of a pipeline the old properties apply, and they might even
need to change positions between pipelines.

I think it is simply easier to just hide all old color related
properties when userspace sets the client-cap to enable pipelines. The
problem is to make sure to hide all old properties on all drivers that
support the client-cap.

As a pipeline must be complete (describe everything that happens to
pixel values), it's going to be a flag day per driver.

Btw. the plane FB YUV->RGB conversion needs a colorop in every pipeline
as well. Maybe it's purely informative and non-configurable, keyed by
FB pixel format, but still.

We also need a colorop to represent sample filtering, e.g. bilinear,
like I think Sebastian may have mentioned in the past. Everything
before the sample filter happens "per tap" as Joshua Ashton put it, and
everything after it happens on the sample that was computed as a
weighted average of the filter tap inputs (texels).

There could be colorops other than sample filtering that operate on
more than one sample at a time, like blur or sharpness. There could
even be colorops that change the image size like adding padding that
the following colorop hardware requires, and then yet another colorop
that clips that padding away. For an example, see
https://lists.freedesktop.org/archives/dri-devel/2023-October/427015.html

If that padding and its color can affect the pipeline results of the
pixels near the padding (e.g. some convolution is applied with them,
which may be the reason why padding is necessary to begin with), then
it would be best to model it.


Thanks,
pq

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