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

[Harry Wentland]

On 2023-10-20 06:36, Pekka Paalanen wrote:
> On Thu, 19 Oct 2023 10:56:40 -0400
> Harry Wentland <harry.wentland at 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 at 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.
> 

I hear you but I'm also somewhat shying away from defining this at this point.
There are already too many things that need to happen and I will focus on the
actual color blocks (LUTs, matrices) first. We'll always be able to add a new
(read-only) colorop type to define scaling and tap behavior at any point and
a client is free to ignore a color pipeline if it doesn't find any tap/scale
info in it.

Harry

> 
> Thanks,
> pq