Re: How to design a DRM KMS driver exposing 2D compositing?

[Pekka Paalanen <ppaalanen@gmail.com>]

On Mon, 11 Aug 2014 09:32:32 -0400
Rob Clark <robdclark@gmail.com> wrote:

> On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> >> What if I cannot even pick a maximum number of planes, but wanted to
> >> (as the hardware allows) let the 2D compositing scale up basically
> >> unlimited while becoming just slower and slower?
> >>
> >> I think at that point one would be looking at a rendering API really,
> >> rather than a KMS API, so it's probably out of scope. Where is the line
> >> between KMS 2D compositing with planes vs. 2D composite rendering?
> >
> > I think kms should still be real-time compositing - if you have to
> > internally render to a buffer and then scan that one out due to lack of
> > memory bandwidth or so that very much sounds like a rendering api. Ofc
> > stuff like writeback buffers blurry that a bit. But hw writeback is still
> > real-time.
> 
> not really sure how much of this is exposed to the cpu side, vs hidden
> on coproc..
> 
> but I tend to think it would be nice for compositors (userspace) to
> know explicitly what is going on..  ie. if some layers are blended via
> intermediate buffer, couldn't that intermediate buffer be potentially
> re-used on next frame if not damaged?

Very true, and I think that speaks for exposing the HVS explicitly to
user space to be directly used. That way I believe the user space could
track damage and composite only the minimum, rather than everything
every time which I suppose the KMS API approach would imply.

We don't have dirty regions in KMS API/props, do we? But yeah, that is
starting to feel like a stretch to push through KMS.

> >> Should I really be designing a driver-specific compositing API instead,
> >> similar to what the Mesa OpenGL implementations use? Then have user
> >> space maybe use the user space driver part via OpenWFC perhaps?
> >> And when I mention OpenWFC, you probably notice, that I am not aware of
> >> any standard user space API I could be implementing here. ;-)
> >
> > Personally I'd expose a bunch of planes with kms (enough so that you can
> > reap the usual benefits planes bring wrt video-playback and stuff like
> > that). So perhaps something in line with what current hw does in hw and
> > then double it a bit or twice - 16 planes or so. Your driver would reject
> > any requests that need intermediate buffers to store render results. I.e.
> > everything that can't be scanned out directly in real-time at about 60fps.
> > The fun with kms planes is also that right now we have 0 standards for
> > z-ordering and blending. So would need to define that first.
> >
> > Then expose everything else with a separate api. I guess you'll just end
> > up with per-compositor userspace drivers due to the lack of a widespread
> > 2d api. OpenVG is kinda dead, and cairo might not fit.
> 
> I kind of suspect someone should really just design weston2d, an api
> more explicitly for compositing.. model after OpenWFC if that fits
> nicely.  Or not if it doesn't.  Or just use the existing weston
> front-end/back-end split..
> 
> I expect other wayland compositors would want more or less the same
> thing as weston (barring pre-existing layer-cake mess..  cough, cough,
> cogl/clutter/gnome-shell..)
> 
> We could even make a gallium statetracker implementation of weston2d
> to get some usage on desktop..

Yeah. I suppose I should aim for whatever driver-specific
interface we need for the HVS to be used from user space, use that in
Weston, and get a feeling of what might be a nice, driver-agnostic 2D
compositing API.


Thanks,
pq