On Wed, Oct 26, 2016 at 05:30:04PM -0700, Matt Roper wrote: > On Thu, Oct 27, 2016 at 01:15:03AM +0100, Chris Wilson wrote: > > On Wed, Oct 26, 2016 at 03:51:27PM -0700, Matt Roper wrote: > > > Gen9 has a traditional cursor plane that is mutually exclusive with the > > > system's top-most "universal" plane; it seems likely that two planes are really > > > a single shared hardware unit with two different register interfaces. Thus far > > > i915 has exposed a cursor plane to userspace that's hooked up to the old-style > > > cursor registers; we just pretended that the top-most universal plane didn't > > > exist and reported one fewer "sprite/overlay" planes for each pipe than the > > > platform technically has. Let's switch this around so that the cursor exposed > > > to userspace is actually wired up to the previously-unused top-most universal > > > plane registers. With this change we'll still present the same cursor ABI to > > > userspace that we always have, but internally we'll just be programming a > > > different set of registers and doing so in a way that's more consistent with > > > how all the other gen9 planes work --- less cursor-specific special cases > > > throughout the code. > > > > But you still report it as PLANE_TYPE_CURSOR right? Otherwise those that > > both expose all the overlay planes and use the legacy cursor abi will be > > trying to use that plane simultaneously via two different paths (and > > clients). Or is this another cap? > > DRM_CLIENT_CAP_UNIVERSAL_PLANES = no-legacy-cursor-abi > > Right, with this patch it's still reported as PLANE_TYPE_CURSOR so > userspace won't see any difference. The followup work to this will be > to eventually do one of the following: > > * Add a new capability bit "don't need legacy cursor" that disables the > legacy cursor interfaces (-EINVAL) and makes these repurposed planes > flip over to PLANE_TYPE_OVERLAY in the plane list for that specific > client. Clients that don't set it will continue to see > PLANE_TYPE_CURSOR as usual. > > or > > * Always leave the plane as DRM_PLANE_TYPE_CURSOR for all clients, but > add some extra properties to them that hint to userspace that the > plane might be more capable than a traditional cursor in some ways. > Userspace could then do atomic TEST_ONLY to see whether the cursor is > actually featureful enough to meet its general plane needs and just > use it like an extra overlay if that turns out to be true. In this > case userspace should be smart enough to realize it's already using > the cursor as a full-featured plane and not try to also submit > conflicting legacy ioctls against it. Imo userspace can just do a test-only and figure this out. DRM_PLANE_TYPE is _purely_ about uabi backwards compat, if you try to infer anything about what the plane can do you'll get it wrong. Except that such a plane is probably more useful for one of the old legacy use-cases, e.g. primary plane should be able to be used full-screen and unscaled. So yes this is the approach I expect userspace to use. > We actually have some experimental patches on an internal tree that use > the first approach above, but I'm open to either approach going forward. > Either way, I think the first step is to just make sure we're doing our > internal programming via the universal plane registers, regardless of > how the plane gets exposed to userspace. > > Those next steps are probably something to discuss at the general DRM > level; my understanding is that a lot of ARM platforms don't really have > dedicated cursors at all, so *all* of their cursor planes are actually > repurposed sprites that could probably be put to better use in some > use cases. Yup. Aside: There's some serious hacking going on in drm_hwcomposer, and no one from intel participates :( We're running a good risk of ending up with userspace behaviour that's not really great on our hw, instead of defining what good hw should look like ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
