[Intel-gfx] [PATCH v3] drm/i915: add immutable zpos plane properties
contact at emersion.fr
Wed Apr 17 20:35:28 UTC 2019
On Tuesday, April 16, 2019 10:04 PM, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> On Tue, Apr 16, 2019 at 08:13:12PM +0200, Maarten Lankhorst wrote:
> > Op 16-04-2019 om 15:42 schreef Ville Syrjälä:
> > > On Tue, Apr 16, 2019 at 03:28:15PM +0200, Maarten Lankhorst wrote:
> > >
> > > > Op 16-04-2019 om 15:20 schreef Ville Syrjälä:
> > > >
> > > > > On Sat, Apr 13, 2019 at 11:13:27AM +0000, Simon Ser wrote:
> > > > >
> > > > > > From: Ville Syrjälä ville.syrjala at linux.intel.com
> > > > > > This adds basic immutable support for the zpos property. The zpos increases
> > > > > > from bottom to top: primary, sprites, cursor.
> > > > > > I was thinking a bit about how we might go about testing this.
> > > > >
> > > > > We probably want a basic test that just checks that if any
> > > > > plane has a zpos prop then all planes should have it.
> > > > > This would be a good test for BAT.
> > > > > A functional test would stack the planes up in some way and
> > > > > compare against a software rendered reference. IIRC there was
> > > > > a zpos test case floating around but that depended on alpha
> > > > > blending which we don't necessarily have.
> > > > > But with semi-overlapping planes you would accomplish the same, without alpha dependency.
> > > >
> > > > Something like this?
> > > > [BG] [Sprite 1] [Cursor]
> > > > [Primary] [Sprite 2]
> > > > Should probably be good enough. Though I was pondering is there a
> > > > way to position an arbitraty number of planes such that the
> > > > resulting picture has a visible region for every possible
> > > > combination of planes?
> > n planes, width = width / (n + 1)
> > position = n * 3/4 * plane_width ? or something
> > If each plane has its own color, then it would work..
> That's not going to hit all the combinations.
> Three is easy, you just position the planes in a triangular sort
> of shape. But four already seems hard. Or maybe I'm just not smart
> enough. Probably needs some graph theory math proof or something.
> I suppose you could do thatr staircase type approach you suggested,
> and them swap the planes around a bit. I think that should cover
> everything eventually. But I was hoping for a cool way to check
> everything from a single frame :)
That's an interesting problem.
Goal: an image which contains, for each pair of planes (P1, P2), a
region with these two planes overlapping (and only these two planes).
In terms of graphs, if a plane is a node and a two-plane overlap is an
edge, it means we want a complete graph (each node has an edge to all
other nodes). If we only have square planes, it's already impossible to
get a solution for 4 planes (the graph contains an edge that crosses
another edge ).
However if we get non-square planes (ie. we have an alpha channel) it
becomes possible. If n is the number of planes, I can imagine to draw
(n - 1) little squares on each plane (the rest being totally
transparent), each of them intersecting with one of the others planes'
squares. This would mean we'd have n * (n - 1) little squares total,
and n * (n - 1) / 2 couple of squares that intersect (this matches the
number of edges of a complete graph).
Thoughts? Is this clear enough? Is it acceptable to require an alpha
channel? Am I mistaken?
More information about the Intel-gfx