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@xxxxxxxxx wrote: > >> From: "Yu(Alex) Dai" <yu.dai@xxxxxxxxx> > >> > >> 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer ISG Platform Enabling & Development Intel Corporation (916) 356-2795 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
