Re: [RFC] Plane color pipeline KMS uAPI
Hi, I'm new to this list and probably can't contribute but interested, I passed your original posting to a friend and have enclosed his thoughts ... old hash or food for thought ??? I ask your forgiveness if you find this inappropriate. (am of the elk * act first, ask for forgiveness afterward) ;-) Steven - start Steven Kucharzyk wrote: > Thought you might find this of interest. Hi, thanks for sending it to me. Unfortunately I don't know enough about the context to say anything specific about it. The best I can do is state the big picture aims I would look for, as someone with a background in display systems electronic design, rendering software development and Color Science. (I apologize in advance if any of this is preaching to the choir!) 1) I would make sure that someone with a strong Color Science background was consulted in the development of the API. 2) I would be measuring the API against its ability to support a "profiling" color management workflow. This workflow allows using the full capability of a display, while also allowing simultaneous display of multiple sources encoded in any colorspace. So the basic architecture is to have a final frame buffer (real or virtual) in the native displays colorspace, and use any graphics hardware color transform and rendering capability to assist with the transformation of data in different source colorspaces into the displays native colorspace. 3) The third thing I would be looking for, is enough standardization that user mode software can be written that will get key benefits of what's available in the hardware, without needing to be customized to lots of different hardware specifics. For instance, I'd make sure that there was a standard display frame buffer to display mode that applied per channel curves that are specified in a standard way. (i.e. make sure that there is an easy to use replacement for XRRCrtcGamma.) Any API that is specific to a type or model of graphics card, will retard development of color management support to a very large degree - the financial and development costs of obtaining, configuring and testing against multiple graphic card makes and models puts this in the too hard basket for anyone other than a corporation. Perhaps little of the above is relevant, if this is a low level API that is to be used by other operating system sub-systems such as display graphics API's like X11 or Wayland, which will choose specific display rendering models and implement them with the hardware capabilities that are available. From a color management point of view, it is the operating system & UI graphics API's that are the ones that are desirable to work with, since they are meant to insulate applications from hardware details. Cheers, Graeme Gill. end On Sat, 6 May 2023 06:40:20 +1000 Dave Airlie wrote: > On Fri, 5 May 2023 at 01:23, Simon Ser 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
Re: [RFC] Plane color pipeline KMS uAPI
On Mon, 08 May 2023 08:58:37 +
Simon Ser wrote:
> On Friday, May 5th, 2023 at 21:53, Daniel Vetter
> wrote:
>
> > On Fri, May 05, 2023 at 04:06:26PM +, Simon Ser wrote:
> > > On Friday, May 5th, 2023 at 17:28, Daniel Vetter
> > > wrote:
> > >
> > > > Ok no comments from me on the actual color operations and
> > > > semantics of all that, because I have simply nothing to bring
> > > > to that except confusion :-)
> > > >
> > > > Some higher level thoughts instead:
> > > >
> > > > - I really like that we just go with graph nodes here. I think
> > > > that was bound to happen sooner or later with kms (we almost
> > > > got there with writeback, and with hindsight maybe should have).
> > >
> > > I'd really rather not do graphs here. We only need linked lists
> > > as Sebastian said. Graphs would significantly add more complexity
> > > to this proposal, and I don't think that's a good idea unless
> > > there is a strong use-case.
> >
> > You have a graph, because a graph is just nodes + links. I did _not_
> > propose a full generic graph structure, the link pointer would be
> > in the class/type specific structure only. Like how we have the
> > plane->crtc or connector->crtc links already like that (which
> > already _is_ is full blown graph).
>
> I really don't get why a pointer in a struct makes plane->crtc a
> full-blown graph. There is only a single parent-child link. A plane
> has a reference to a CRTC, and nothing more.
>
> You could say that anything is a graph. Yes, even an isolated struct
> somewhere is a graph: one with a single node and no link. But I don't
> follow what's the point of explaining everything with a graph when we
> only need a much simpler subset of the concept of graphs?
>
> Putting the graph thing aside, what are you suggesting exactly from a
> concrete uAPI point-of-view? Introducing a new struct type? Would it
> be a colorop specific struct, or a more generic one? What would be
> the fields? Why do you think that's necessary and better than the
> current proposal?
>
> My understanding so far is that you're suggesting introducing
> something like this at the uAPI level:
>
> struct drm_mode_node {
> uint32_t id;
>
> uint32_t children_count;
> uint32_t *children; // list of child object IDs
> };
>
> I don't think this is a good idea for multiple reasons. First, this is
> overkill: we don't need this complexity, and this complexity will
> make it more difficult to reason about the color pipeline. This is a
> premature abstraction, one we don't need right now, and one I
> heaven't heard a potential future use-case for. Sure, one can kill an
> ant with a sledgehammer if they'd like, but that's not the right tool
> for the job.
>
> Second, this will make user-space miserable. User-space already has a
> tricky task to achieve to translate its abstract descriptive color
> pipeline to our proposed simple list of color operations. If we
> expose a full-blown graph, then the user-space logic will need to
> handle arbitrary graphs. This will have a significant cost (on
> implementation and testing), which we will be paying in terms of time
> spent and in terms of bugs.
>
> Last, this kind of generic "node" struct is at odds with existing KMS
> object types. So far, KMS objects are concrete like CRTC, connector,
> plane, etc. "Node" is abstract. This is inconsistent.
>
> Please let me know whether the above is what you have in mind. If
> not, please explain what exactly you mean by "graphs" in terms of
> uAPI, and please explain why we need it and what real-world use-cases
> it would solve.
I'd like to ask if there is a block/flow chart/diagram that has been
created that represent the elements that are being discussed for this
RFC? If so, would you be so kind as to point me to it or send it to me?
Tks, Steven
