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. 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. Matt > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
