On Fri, 20 Oct 2023 16:22:56 +0200 Sebastian Wick <sebastian.wick@xxxxxxxxxx> wrote: > Thanks for continuing to work on this! > > On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote: > > v2: > > - Update colorop visualizations to match reality (Sebastian, Alex Hung) > > - Updated wording (Pekka) > > - Change BYPASS wording to make it non-mandatory (Sebastian) > > - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property > > section (Pekka) > > - Use PQ EOTF instead of its inverse in Pipeline Programming example (Melissa) > > - Add "Driver Implementer's Guide" section (Pekka) > > - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka) > > ... > > +Driver Forward/Backward Compatibility > > +===================================== > > + > > +As this is uAPI drivers can't regress color pipelines that have been > > +introduced for a given HW generation. New HW generations are free to > > +abandon color pipelines advertised for previous generations. > > +Nevertheless, it can be beneficial to carry support for existing color > > +pipelines forward as those will likely already have support in DRM > > +clients. > > + > > +Introducing new colorops to a pipeline is fine, as long as they can be > > +disabled or are purely informational. DRM clients implementing support > > +for the pipeline can always skip unknown properties as long as they can > > +be confident that doing so will not cause unexpected results. > > + > > +If a new colorop doesn't fall into one of the above categories > > +(bypassable or informational) the modified pipeline would be unusable > > +for user space. In this case a new pipeline should be defined. > > How can user space detect an informational element? Should we just add a > BYPASS property to informational elements, make it read only and set to > true maybe? Or something more descriptive? Read-only BYPASS set to true would be fine by me, I guess. I think we also need a definition of "informational". Counter-example 1: a colorop that represents a non-configurable YUV<->RGB conversion. Maybe it determines its operation from FB pixel format. It cannot be set to bypass, it cannot be configured, and it will alter color values. Counter-example 2: image size scaling colorop. It might not be configurable, it is controlled by the plane CRTC_* and SRC_* properties. You still need to understand what it does, so you can arrange the scaling to work correctly. (Do not want to scale an image with PQ-encoded values as Josh demonstrated in XDC.) Counter-example 3: image sampling colorop. Averages FB originated color values to produce a color sample. Again do not want to do this with PQ-encoded values. Thanks, pq
Attachment:
pgpcf9ogiREx3.pgp
Description: OpenPGP digital signature
