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

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: intel-gfx@lists.freedesktop.org,
	Miguel Casas-Sanchez <mcasas@chromium.org>,
	dri-devel@lists.freedesktop.org,
	Alexandros Frantzis <alexandros.frantzis@collabora.com>
Subject: Re: [RFC] Exposing plane type mask and handling 'all' planes
Date: Wed, 19 Jun 2019 19:33:27 +0300	[thread overview]
Message-ID: <20190619163327.GC5942@intel.com> (raw)
In-Reply-To: <20190619160353.GE1896@arch-x1c3>

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.

> 
> 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?
> 
> Input and ideas from the Intel team and DRM community are very much
> appreciated.
> 
> Thanks
> Emil
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx