[Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers

[Daniel Vetter]

On Wed, Oct 26, 2016 at 05:30:04PM -0700, Matt Roper wrote:
> On Thu, Oct 27, 2016 at 01:15:03AM +0100, Chris Wilson wrote:
> > On Wed, Oct 26, 2016 at 03:51:27PM -0700, Matt Roper wrote:
> > > Gen9 has a traditional cursor plane that is mutually exclusive with the
> > > system's top-most "universal" plane; it seems likely that two planes are really
> > > a single shared hardware unit with two different register interfaces.  Thus far
> > > i915 has exposed a cursor plane to userspace that's hooked up to the old-style
> > > cursor registers; we just pretended that the top-most universal plane didn't
> > > exist and reported one fewer "sprite/overlay" planes for each pipe than the
> > > platform technically has.  Let's switch this around so that the cursor exposed
> > > to userspace is actually wired up to the previously-unused top-most universal
> > > plane registers.  With this change we'll still present the same cursor ABI to
> > > userspace that we always have, but internally we'll just be programming a
> > > different set of registers and doing so in a way that's more consistent with
> > > how all the other gen9 planes work --- less cursor-specific special cases
> > > throughout the code.
> > 
> > But you still report it as PLANE_TYPE_CURSOR right? Otherwise those that
> > both expose all the overlay planes and use the legacy cursor abi will be
> > trying to use that plane simultaneously via two different paths (and
> > clients). Or is this another cap?
> > 	DRM_CLIENT_CAP_UNIVERSAL_PLANES = no-legacy-cursor-abi
> 
> Right, with this patch it's still reported as PLANE_TYPE_CURSOR so
> userspace won't see any difference.  The followup work to this will be
> to eventually do one of the following:
> 
>  * Add a new capability bit "don't need legacy cursor" that disables the
>    legacy cursor interfaces (-EINVAL) and makes these repurposed planes
>    flip over to PLANE_TYPE_OVERLAY in the plane list for that specific
>    client.  Clients that don't set it will continue to see
>    PLANE_TYPE_CURSOR as usual.
> 
> or
> 
>  * Always leave the plane as DRM_PLANE_TYPE_CURSOR for all clients, but
>    add some extra properties to them that hint to userspace that the
>    plane might be more capable than a traditional cursor in some ways.
>    Userspace could then do atomic TEST_ONLY to see whether the cursor is
>    actually featureful enough to meet its general plane needs and just
>    use it like an extra overlay if that turns out to be true.  In this
>    case userspace should be smart enough to realize it's already using
>    the cursor as a full-featured plane and not try to also submit
>    conflicting legacy ioctls against it.

Imo userspace can just do a test-only and figure this out. DRM_PLANE_TYPE
is _purely_ about uabi backwards compat, if you try to infer anything
about what the plane can do you'll get it wrong. Except that such a plane
is probably more useful for one of the old legacy use-cases, e.g. primary
plane should be able to be used full-screen and unscaled.

So yes this is the approach I expect userspace to use.

> We actually have some experimental patches on an internal tree that use
> the first approach above, but I'm open to either approach going forward.
> Either way, I think the first step is to just make sure we're doing our
> internal programming via the universal plane registers, regardless of
> how the plane gets exposed to userspace.
> 
> Those next steps are probably something to discuss at the general DRM
> level; my understanding is that a lot of ARM platforms don't really have
> dedicated cursors at all, so *all* of their cursor planes are actually
> repurposed sprites that could probably be put to better use in some
> use cases.

Yup. Aside: There's some serious hacking going on in drm_hwcomposer, and
no one from intel participates :( We're running a good risk of ending up
with userspace behaviour that's not really great on our hw, instead of
defining what good hw should look like ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch