Re: [Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers
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 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/4] Wire gen9 cursor interface to universal plane registers
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. Aside from making the code a bit simpler (fewer cursor-specific special cases), this will also pave the way to eventually exposing the top-most plane in a more full-featured manner to userspace clients that don't need a traditional cursor and wish to opt into having access to an additional sprite/overlay-style plane instead. It's worth noting that a lot of the special-cased cursor-specific code was in the gen9 watermark programming. It's good to simplify that code, but we should keep an eye out for any unwanted side effects of this patch; since sprites/overlays tend to get used less than cursors, it's possible that this could help us uncover additional underruns that nobody had run across yet. Or it could have the opposite effect and eliminate some of the underruns that we haven't been able to get rid of yet. This is just an RFC at this point; we should probably land all of the in-flight watermark work before this so that those series don't need additional rebasing. There's also still one known problem I need to track down --- it seems the color correction of the plane is slightly different when programming the universal registers vs the legacy cursor registers, so IGT tests like kms_cursor_crc report CRC mismatches, even though the results look correct visually. Note that patches #1 and 2 are trivial renaming patches and could probably be merged immediately if nobody has concerns with them. Matt Roper (4): drm/i915: Rename for_each_plane -> for_each_universal_plane drm/i915: Use macro in place of open-coded for_each_universal_plane loop drm/i915/gen9: Expose top-most universal plane as cursor drm/i915/gen9: Skip debugfs cursor output for universal plane platforms drivers/gpu/drm/i915/i915_debugfs.c | 32 ++- drivers/gpu/drm/i915/i915_drv.h | 13 - drivers/gpu/drm/i915/intel_device_info.c | 38 drivers/gpu/drm/i915/intel_display.c | 99 drivers/gpu/drm/i915/intel_drv.h | 16 +++--- drivers/gpu/drm/i915/intel_pm.c | 89 drivers/gpu/drm/i915/intel_sprite.c | 6 +- 7 files changed, 116 insertions(+), 177 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
