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

[Matt Roper]

On Thu, Feb 27, 2014 at 02:36:06PM -0800, Yu Dai wrote:
> On 14-02-25 04:19 PM, Matt Roper wrote:
> 
> >On Thu, Feb 20, 2014 at 04:11:14PM -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.
> >>
> >>Signed-off-by: Yu(Alex) Dai <yu.dai at intel.com>
> >It seems like this is pretty VLV-specific at the moment.  Aren't you
> >going to be writing bogus register values if you try to set this
> >property on a non-VLV platform?
> >
> >I'm not sure if any of the other non-VLV platforms supported by i915
> >today can change plane z-orders or not, but this is likely to be
> >possible and useful on future platforms (or non-Intel platforms) as
> >well, which may have a different number of overall planes and different
> >ways of programming them.
> 
> Yes, this is for VLV. New patch-set V3 was submitted.
> 
> >Would it make more sense to move the z-order value to a plane property
> >so that the interface scales to any number of planes?  If you just set
> >an integer value as a per-plane zorder-value, the code that actually
> >programs the hardware can go collect the values for each plane, sort
> >them to determine an order, and figure out what that translates to in
> >terms of platform-specific register programming.  This would lend itself
> >nicely to the "check/calculate" step of the atomic/nuclear operation
> >once those interfaces land.
> 
> The z-order of a plane really has no meaning until the actual composition is
> triggered. In Android, the order is determined by HWC when there are changes
> in layers. Breaking up this into plane property will evoke more drm IOCTL
> calls from user. The current "one-shot" call limits the flexibility but makes
> it simple.

That's true today where we only really have the ability to set
properties one by one.  But I believe the end goal is to handle this
kind of functionality via the atomic/nuclear API's, where you wind up
shoving all the various things you want to change/program into a
property set (which happens in libdrm userspace) and then issue a single
ioctl which hands that property set to the kernel to be processed in a
sort of transactional model.

Without the atomic/nuclear operations, I'm not sure how well z-order
property will really work in practice.  If your compositor decides that
the next frame of content uses multiple hardware planes to display
various buffers, you really need to make sure that the z-order register
programming happens within the same vblank that the flips on each of
those planes take effect, otherwise things aren't going to look good to
the end user.  With the non-atomic API's, I don't think there's really
any way to guarantee this.


Matt

> 
> This patch is pretty much a straight copy from internal tree. The only change
> is that it uses property rather than a private i915 IOCTL.
> 
> Thanks,
> 
> Alex
> 

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