On 2023-10-20 06:36, Pekka Paalanen wrote: > On Thu, 19 Oct 2023 10:56:40 -0400 > Harry Wentland <harry.wentland@xxxxxxx> wrote: > >> On 2023-10-10 12:13, Melissa Wen wrote: >>> O 09/08, Harry Wentland wrote: >>>> Signed-off-by: Harry Wentland <harry.wentland@xxxxxxx> > > ... > >>> 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
