Re: [RFC] Plane color pipeline KMS uAPI

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]

On Thu, 11 May 2023 19:29:27 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Thursday, May 11th, 2023 at 18:56, Joshua Ashton <joshua@froggi.es> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]