[RFC] Exposing plane type mask and handling 'all' planes

Wed Jun 26 00:46:42 UTC 2019

On Wed, Jun 19, 2019 at 09:24:56PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 19, 2019 at 06:49:11PM +0100, Emil Velikov wrote:
> > On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
> > <ville.syrjala at linux.intel.com> wrote:
> > >
> > > On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > > > Hi all,
> > > >
> > > > Recently I have been looking at i915 and its rather interesting planes.
> > > >
> > > > In particular newer hardware is capable of using 3 universal planes and
> > > > a separate cursor-only plane. At the same time only 1 top-most plane can
> > > > be enabled - lets calls those plane3 or cursor.
> > > >
> > > > Hence currently the hardware has an extra plane which we do not use.
> > >
> > > Only skl (and derivatives) have that. More modern platforms went back to
> > > the dedicated cursor plane. So IMO no point in exposing this mess at
> > > all.
> > >
> > I suspect you're talking about Ice Lake, correct?
> 
> And glk. The other relevant platform joined the fight club so we don't
> talk about it.
> 
> > 
> > > >
> > > > The current DRM design does not allow us to fully utilise the HW and I
> > > > would love to address that. Here are three approaches that come to mind:
> > > >
> > > > 1) Extend the DRM plane UAPI to:
> > > >  - expose a mask of supported types, and
> > > >  - allow userspace to select the type
> > > >
> > > > 2) Keep the exposed planes as-is and let the driver orchestrate which
> > > >    one gets used.
> > > >  - flip between cursor/plane3 based on the use-case/API used, or
> > > >  - opt for plane3/cursor for atomic and legacy modeset code path, or
> > > >  - other
> > > >
> > > > 3) Expose plane3 and cursor, whereby using one of them "marks" the other
> > > >    as used.
> > > >  - is this allowed by the modeset semantics/policy?
> > > >  - does existing user-space have fallback path?
> > > >
> > > >
> > > > Personally, I would love existing user-space to just work without
> > > > modification. At the same time opting for 2 this will cause a serious
> > > > amount of complication, and in case of 3 the whole thing will be very
> > > > fragile. So my current inclination is towards 1.
> > > >
> > > > Open questions:
> > > >  - Do we know of other hardware with this or related design which does
> > > > not fit the current DRM design?
> > > >  - Vendor KMS specific UAPI, is frowned upon. So if we are to extend the
> > > > UAPI, does the current approach sound useful for other HW?
> > > >  - Does this approach sound reasonable, can other share their view on a
> > > > better approach, that achieves the goal?
> > > >
> > Speaking hypothetically:
> > 
> > If the mutually exclusive design was very common, which of the
> > proposed solutions you think will be the best fit?
> > May I ask you for a mini-brain dump how you foresee that being implemented :-)
> 
> I would go for option 2. Option 1 is pretty much the same thing with a
> slight hint for userspace that maybe the plane can do a bit more than
> just "cursory" things. The problem is that we have no actual definition
> of what these "cursory" things are. It's totally hardware/driver
> specific. Eg. i915 already allows you to do various things with the
> cursor plane that may not work on other hardware. Also I'm sure there's
> plenty of hardware out there with no special purpose cursor planes, so
> those drivers will probably just designate one regular plane as
> "the cursor" anyway.
> 
> So I think we've been pretty much doing option 2 all along. So if some
> userspace wanted to it could just ignore the cursor type hint and try
> to use the plane in any way it sees fit. The usual rule of "try
> CHECK_ONLY and see it you get an error" applies here as well.
> 
> If we did want to go for option 1 then I think it should take the form
> of some better defined plane capabilities. The problem is that there
> are alwayas tons of hardware specific exceptions so you wouldn't be
> able to blindly trust the caps anyway.

PLANE_CURSOR is basically just an indication that that specific plane is
the one that's also hooked up to the legacy cursor ioctls; like Ville
says, it shouldn't directly indicate that the plane is less
feature-capable than other planes.  You can either detect the true
capabilities of the cursor plane by checking for the presence/absence of
other plane properties and/or experimenting with atomic TEST_ONLY
commits to see what's really possible.

The ideal solution for Intel gen9 hardware would have been to just never
have the driver advertise or program the dedicated hardware cursor at
all, but to instead expose the top-most universal plane to userspace,
describe it as PLANE_CURSOR, and route the legacy cursor ioctl's to that
plane instead.  That would allow legacy cursor behavior to work as
usual, but would also allow atomic userspace to use the plane in a more
full-featured manner.  I wrote patches to do exactly this a couple years
ago, but sadly we discovered that the universal planes on gen9 have a
slight alpha blending defect that the dedicated hardware cursor does not
exhibit.  Thus replacing the hardware cursor with the topmost universal
plane led to a slight regression for existing users and we had to scrap
the whole idea.  :-(

For reference, the relevant patch from a few years ago is here:
        https://patchwork.kernel.org/patch/9398571/

Matt

> 
> -- 
> Ville Syrjälä
> Intel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795