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

[Ville Syrjälä]

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.

-- 
Ville Syrjälä
Intel