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

[Emil Velikov]

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?

> >
> > 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 :-)

Thanks
Emil