On Thu, 11 May 2023 19:29:27 +0000 Simon Ser <contact@xxxxxxxxxxx> wrote: > On Thursday, May 11th, 2023 at 18:56, Joshua Ashton <joshua@xxxxxxxxx> wrote: > > > When we are talking about being 'prescriptive' in the API, are we > > outright saying we don't want to support arbitrary 3D LUTs, or are we > > just offering certain algorithms to be 'executed' for a plane/crtc/etc > > in the atomic API? I am confused... > > From a kernel PoV: > > - Prescriptive = here are the available hardware blocks, feel free to > configure each as you like > - Descriptive = give me the source and destination color-spaces and I > take care of everything > > This proposal is a prescriptive API. We haven't explored _that_ much > how a descriptive API would look like, probably it can include some way > to do Night Light and similar features but not sure how high-level > they'd look like. A descriptive API is inherently more restrictive than > a prescriptive API. Right. Just like Jonas said, an arbitrary 3D LUT is a well-defined mathematical operation with no semantics at all, therefore it is a prescriptive element. A 3D LUT does not fit well in a descriptive API design, one would need to jump through lots of hoops to turn it into something descriptive'ish (like ICC does). I think Joshua mixed up the definitions of "descriptive" and "prescriptive". If Gamescope was using a descriptive KMS UAPI, then it would have very little or no say in what color operations are done and how. If Gamescope is using prescriptive KMS UAPI, then Gamescope has to know exactly what it wants to do, how it wants to achieve that, and map that to the available mathematical processing blocks. A descriptive UAPI would mean all color policy is in the kernel. A prescriptive UAPI means all policy is in userspace. Wayland uses the opposite design principle of KMS UAPI. Wayland is descriptive, KMS is prescriptive. This puts the color policy into a Wayland compositor. If we have a library converting descriptive to prescriptive, then that library contains a policy. Going from descriptive to prescriptive is easy, just add policy. Going from prescriptive to descriptive is practically impossible, because you'd have to "subtract" any policy that has already been applied, in order to understand what the starting point was. Coming back to KMS, the color transformations must be prescriptive, but then we also need to be able to send descriptive information to video sinks so that video sinks understand what our pixel values mean. Thanks, pq
Attachment:
pgpQAl_K9iGmY.pgp
Description: OpenPGP digital signature
