Re: [RFC 0/4] Wire gen9 cursor interface to universal plane registers

From: Matt Roper <matthew.d.roper@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 0/4] Wire gen9 cursor interface to universal plane registers
Date: Wed, 26 Oct 2016 17:30:04 -0700	[thread overview]
Message-ID: <20161027003004.GE5924@intel.com> (raw)
In-Reply-To: <20161027001503.GA7102@nuc-i3427.alporthouse.com>

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.

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.

Matt

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx