[Intel-gfx] [PATCH v4] drm/i915: add support for Z-order of planes for VLV.

[Matt Roper]

On Tue, Mar 04, 2014 at 05:37:39PM -0800, Yu Dai wrote:
> Chris,
> 
> This looks like a hw specific value which is difficult to
> understand. However, the definition of these values are just a list
> of available options of z-order. On Intel VLV, there is only 6
> options for the three planes Primary, Sprite A and Sprite B. Cursor
> is always on top. For example, "P1S1S2C1" means z-order (from bottom
> to top) of Primary -> Sprite A -> Sprite B -> Cursor.
> 
> #define P1S1S2C1        0
> #define P1S2S1C1        8
> #define S2P1S1C1        1
> #define S2S1P1C1        9
> #define S1P1S2C1        4
> #define S1S2P1C1        6
> 
> In theory, if hw supports, each CRTC may have their own plane
> z-order if user intentionally wants that happens. The pipe info (0
> or 1) is packed into z-order value with extra bit (bit 31).
> 
> Thanks,
> Alex

If you want this to go into the upstream kernel, then it winds up being
an interface that pretty much has to be supported forever.  A
userspace-facing encoding like this is very closely tied to the specific
number of pipes and planes, so it isn't going to work in a consistent
manner across different Intel hardware platforms (current and future).
Ideally we'd like to have an interface that we can share with drivers
for other vendors' hardware as well so that general purpose userspace
(e.g., a Weston wayland compositor) can make use of this without having
to worry too much about what kind of hardware it's running on.  As Ville
mentioned earlier, if you want userspace to program a specific encoding
like this, you need to advertise a list of enum values that are valid
for that hardware, and the enum list has to be somehow
parseable/understandable by userspace.

Personally I still prefer the approach of giving every plane its own
z-order rank property and then letting the platform-specific code that
actually writes the registers sort all the planes' zorders and figure
out what the appropriate register values should be.  Granted, this kind
of assumes that we've fully moved to the atomic flip API, but then the
"check/calculate" step of the process would catch any illegal plane
orderings (e.g., two planes listed with the same z-order rank, or an
overall ordering that the hardware simply can't support) and compute the
appropriate z-order bits for the CRTC.  I have a patchset under progress
on dri-devel that unifies the plane interface (exposing primary and
cursor planes in the same manner sprite/overlay planes are today), so
primary and cursor would also have a zorder rank value and could be
sorted along with the sprites.

The main obstacle I see with the per-plane rank approach is that the
display server or compositor still needs a way to figure out which plane
orderings are actually valid.  It's possible to quickly submit a few
possible orderings that the compositor might be interested in using to
the atomic flip API at compositor startup with the "test only" flag set
to figure out which ones are possible.  However this does add a small
amount of startup overhead which may be undesirable in some settings.


Matt

> On 14-03-04 12:20 AM, Chris Wilson wrote:
> >On Mon, Mar 03, 2014 at  02:12:28PM -0800, yu.dai at intel.com wrote:
> >> From: "Yu(Alex) Dai" <yu.dai at intel.com>
> >>
> >> Add "zorder" property to crtc to control Z-order of sprite and
> >> primary planes. The alpha channel of the planes can be enabled or
> >> disabled during Z-order change.
> >
> > Can I just say that is an abonimal user interface. You expect the
> > client to encode a hw specific value into a CRTC property that
> > affects global state. and given the two properties on the two CRTCs,
> > which should userspace believe? -Chris
> >
> 
> 

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Matt Roper
Graphics Software Engineer
ISG Platform Enabling & Development
Intel Corporation
(916) 356-2795