Re: [v4] drm: two planes with the same zpos have undefined ordering

From: Daniel Vetter <daniel@ffwll.ch>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Simon Ser <contact@emersion.fr>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"james qian wang (Arm Technology China)"
	<james.qian.wang@arm.com>, Daniel Vetter <daniel.vetter@ffwll.ch>,
	nd <nd@arm.com>, Marius Vlad <marius.vlad@collabora.com>
Subject: Re: [v4] drm: two planes with the same zpos have undefined ordering
Date: Tue, 8 Oct 2019 11:59:04 +0200	[thread overview]
Message-ID: <20191008095904.GL16989@phenom.ffwll.local> (raw)
In-Reply-To: <20190930100707.178723d1@eldfell.localdomain>

On Mon, Sep 30, 2019 at 10:07:07AM +0300, Pekka Paalanen wrote:
> On Sun, 29 Sep 2019 20:30:44 +0000
> Simon Ser <contact@emersion.fr> wrote:
> 
> > Hi,
> > 
> > > On Mon, Sep 23, 2019 at 12:39:20PM +0000, Simon Ser wrote:  
> > > > Currently the property docs don't specify whether it's okay for two planes to
> > > > have the same zpos value and what user-space should expect in this case.
> > > >
> > > > The rule mentionned in the past was to disambiguate with object IDs. However
> > > > some drivers break this rule (that's why the ordering is documented as
> > > > unspecified in case the zpos property is missing). Additionally it doesn't
> > > > really make sense for a driver to user identical zpos values if it knows their
> > > > relative position: the driver can just pick different values instead.
> > > >
> > > > So two solutions would make sense: either disallow completely identical zpos
> > > > values for two different planes, either make the ordering unspecified. To allow
> > > > drivers that don't know the relative ordering between two planes to still
> > > > expose the zpos property, choose the latter solution.  
> > >
> > > Some Arm's usage cases about two planes with same zpos.
> > >
> > > - "Smart layer"
> > > which can accepts 4 different fbs with different src/display rect,
> > > but this smart layer has one restriction:
> > >
> > > 4 display rects must have no overlaps in V direction
> > > (A optimization for android window like Toolbar/Navigation bar)
> > >
> > > So when map this Smart-layer to drm world, it might be 4 different
> > > drm-planes, but with same zorder to indicate that these 4 planes are
> > > smart-laye planes.
> > >
> > > - "VR-Layer"
> > > One VR-layer comprises two different viewports which can be configured
> > > with totoally different fbs, src/display rect.
> > > we use two differernt drm-planes to drive on HW "VR-Layer", and these
> > > two drm-planes must be configured with same zpos.  
> > 
> > Thanks a lot for your feedback James, that's exactly what I was looking for.
> > Both of these use-cases make sense to me.
> > 
> > I think user-space should be prepared to handle identical immutable zpos values.
> > Pekka and Daniel, thoughts?
> 
> Hi,
> 
> given those explained use cases, sure, I agree.
> 
> > In any case, this doesn't change the patch itself. Probably something worth
> > mentionning in the commit message.
> 
> Yes, recording these use cases would be very nice.

There's a lot more hw that does the same tricks (qualcom is one for sure).
Imo before we encode this we should make sure that:
a) everyone is happy with this new uapi
b) drivers are consistent
c) maybe even testcases in igt
d) definitely an open source user
e) no breaking of existing userspace

I.e. definitely a separate patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel