[RFC] Plane color pipeline KMS uAPI

[Sebastian Wick]

On Fri, May 5, 2023 at 10:40 PM Dave Airlie <airlied at gmail.com> wrote:
>
> On Fri, 5 May 2023 at 01:23, Simon Ser <contact at emersion.fr> wrote:
> >
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> > framebuffer and before it's blended with other planes. With this new uAPI we
> > aim to reduce the battery life impact of color management and HDR on mobile
> > devices, to improve performance and to decrease latency by skipping
> > composition on the 3D engine. This proposal is the result of discussions at
> > the Red Hat HDR hackfest [1] which took place a few days ago. Engineers
> > familiar with the AMD, Intel and NVIDIA hardware have participated in the
> > discussion.
> >
> > This proposal takes a prescriptive approach instead of a descriptive approach.
> > Drivers describe the available hardware blocks in terms of low-level
> > mathematical operations, then user-space configures each block. We decided
> > against a descriptive approach where user-space would provide a high-level
> > description of the colorspace and other parameters: we want to give more
> > control and flexibility to user-space, e.g. to be able to replicate exactly the
> > color pipeline with shaders and switch between shaders and KMS pipelines
> > seamlessly, and to avoid forcing user-space into a particular color management
> > policy.
>
> I'm not 100% sold on the prescriptive here, let's see if someone can
> get me over the line with some questions later.
>
> My feeling is color pipeline hw is not a done deal, and that hw
> vendors will be revising/evolving/churning the hw blocks for a while
> longer, as there is no real standards in the area to aim for, all the
> vendors are mostly just doing whatever gets Windows over the line and
> keeps hw engineers happy. So I have some concerns here around forwards
> compatibility and hence the API design.
>
> I guess my main concern is if you expose a bunch of hw blocks and
> someone comes up with a novel new thing, will all existing userspace
> work, without falling back to shaders?
> Do we have minimum guarantees on what hardware blocks have to be
> exposed to build a useable pipeline?
> If a hardware block goes away in a new silicon revision, do I have to
> rewrite my compositor? or will it be expected that the kernel will
> emulate the old pipelines on top of whatever new fancy thing exists.

I think there are two answers to those questions.

The first one is that right now KMS already doesn't guarantee that
every property is supported on all hardware. The guarantee we have is
that properties that are supported on a piece of hardware on a
specific kernel will be supported on the same hardware on later
kernels. The color pipeline is no different here. For a specific piece
of hardware a newer kernel might only change the pipelines in a
backwards compatible way and add new pipelines.

So to answer your question: if some hardware with a novel pipeline
will show up it might not be supported and that's fine. We already
have cases where some hardware does not support the gamma lut property
but only the CSC property and that breaks night light because we never
bothered to write a shader fallback. KMS provides ways to offload work
but a generic user space always has to provide a fallback and this
doesn't change. Hardware specific user space on the other hand will
keep working with the forward compatibility guarantees we want to
provide.

The second answer is that we want to provide a user space library
which takes a description of a color pipeline and tries to map that to
the available KMS color pipelines. If there is a novel color
operation, adding support in this library would then make it possible
to offload compatible color pipelines on this new hardware for all
consumers of the library. Obviously there is no guarantee that
whatever color pipeline compositors come up with can actually be
realized on specific hardware but that's just an inherent hardware
issue.

> We are not Android, or even Steam OS on a Steamdeck, we have to be
> able to independently update the kernel for new hardware and not
> require every compositor currently providing HDR to need to support
> new hardware blocks and models at the same time.
>
> Dave.
>