On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
