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. Thanks, pq
Attachment:
pgpJnrBsGjCVM.pgp
Description: OpenPGP digital signature
