From: Matt Roper <matthew.d.roper@intel.com> To: intel-gfx@lists.freedesktop.org Cc: tvrtko.ursulin@linux.intel.com, dri-devel@lists.freedesktop.org Subject: [PATCH 0/5] i915: SSEU handling updates Date: Wed, 27 Apr 2022 16:07:42 -0700 [thread overview] Message-ID: <20220427230747.906625-1-matthew.d.roper@intel.com> (raw) This series makes a handful of updates to i915's internal handling of slice/subslice/EU (SSEU) data to handle recent platforms like Xe_HP in a more natural manner and to prepare for some additional upcoming platforms we have in the pipeline (the first of which I'll probably start sending patches for in the next week or two). One key idea of this series is that although we have a fixed ABI to convey SSEU data to userspace (i.e., multiple u8[] arrays with data stored at different strides), we don't need to use this cumbersome format for the driver's own internal storage. As long as we can convert into the uapi form properly when responding to the I915_QUERY ioctl, it's preferable to use an internal storage format that's easier for the driver to work with. Doing so can also save us some storage space on modern platforms since we don't always need to replicate a bunch of data that's architecturally guaranteed to be identical. Another key point here is that Xe_HP platforms today have subslice (DSS) masks that are 32 bits, which maxes out the storage of a u32. On future platforms the architecture design is going to start spreading their DSS masks over multiple 32-bit fuse registers. So even for platforms where the total number of DSS doesn't actually go up, we're going to need larger storage than just a u32 to express the mask properly. To accomodate this, we start storing our subslice mask in a new typedef that can be processed by the linux/bitmap.h operations. Finally, since no userspace for Xe_HP or beyond is using the legacy I915_GETPARAM ioctl lookups for I915_PARAM_SLICE_MASK and I915_PARAM_SUBSLICE_MASK (since they've migrated to the more flexible I915_QUERY ioctl that can return more than a simple u32 value), we take the opportunity to officially drop support for those GETPARAM lookups on modern platforms. Maintaining support for these GETPARAM lookups don't make sense for a number of reasons: * Traditional slices no longer exist, and newer ideas like gslices, cslices, mslices, etc. aren't something userspace needs to query since it can be inferred from other information. * The GETPARAM ioctl doesn't have a way to distinguish between geometry subslice masks and compute subslice masks, which are distinct on Xe_HP and beyond. * The I915_GETPARAM ioctl is limited to returning a 32-bit value, so when subslice masks begin to exceed 32-bits, it simply can't return the entire mask. * The GETPARAM ioctl doesn't have a way to give sensible information for multi-tile devices. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Matt Roper (5): drm/i915/sseu: Don't try to store EU mask internally in UAPI format drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK drm/i915/xehp: Use separate sseu init function drm/i915/sseu: Simplify gen11+ SSEU handling drm/i915/sseu: Disassociate internal subslice mask representation from uapi drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c | 14 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 371 +++++++++++-------- drivers/gpu/drm/i915/gt/intel_sseu.h | 69 ++-- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 28 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 28 +- drivers/gpu/drm/i915/i915_getparam.c | 10 +- drivers/gpu/drm/i915/i915_query.c | 16 +- 9 files changed, 323 insertions(+), 219 deletions(-) -- 2.35.1
WARNING: multiple messages have this Message-ID (diff)
From: Matt Roper <matthew.d.roper@intel.com> To: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Subject: [Intel-gfx] [PATCH 0/5] i915: SSEU handling updates Date: Wed, 27 Apr 2022 16:07:42 -0700 [thread overview] Message-ID: <20220427230747.906625-1-matthew.d.roper@intel.com> (raw) This series makes a handful of updates to i915's internal handling of slice/subslice/EU (SSEU) data to handle recent platforms like Xe_HP in a more natural manner and to prepare for some additional upcoming platforms we have in the pipeline (the first of which I'll probably start sending patches for in the next week or two). One key idea of this series is that although we have a fixed ABI to convey SSEU data to userspace (i.e., multiple u8[] arrays with data stored at different strides), we don't need to use this cumbersome format for the driver's own internal storage. As long as we can convert into the uapi form properly when responding to the I915_QUERY ioctl, it's preferable to use an internal storage format that's easier for the driver to work with. Doing so can also save us some storage space on modern platforms since we don't always need to replicate a bunch of data that's architecturally guaranteed to be identical. Another key point here is that Xe_HP platforms today have subslice (DSS) masks that are 32 bits, which maxes out the storage of a u32. On future platforms the architecture design is going to start spreading their DSS masks over multiple 32-bit fuse registers. So even for platforms where the total number of DSS doesn't actually go up, we're going to need larger storage than just a u32 to express the mask properly. To accomodate this, we start storing our subslice mask in a new typedef that can be processed by the linux/bitmap.h operations. Finally, since no userspace for Xe_HP or beyond is using the legacy I915_GETPARAM ioctl lookups for I915_PARAM_SLICE_MASK and I915_PARAM_SUBSLICE_MASK (since they've migrated to the more flexible I915_QUERY ioctl that can return more than a simple u32 value), we take the opportunity to officially drop support for those GETPARAM lookups on modern platforms. Maintaining support for these GETPARAM lookups don't make sense for a number of reasons: * Traditional slices no longer exist, and newer ideas like gslices, cslices, mslices, etc. aren't something userspace needs to query since it can be inferred from other information. * The GETPARAM ioctl doesn't have a way to distinguish between geometry subslice masks and compute subslice masks, which are distinct on Xe_HP and beyond. * The I915_GETPARAM ioctl is limited to returning a 32-bit value, so when subslice masks begin to exceed 32-bits, it simply can't return the entire mask. * The GETPARAM ioctl doesn't have a way to give sensible information for multi-tile devices. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Matt Roper (5): drm/i915/sseu: Don't try to store EU mask internally in UAPI format drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK drm/i915/xehp: Use separate sseu init function drm/i915/sseu: Simplify gen11+ SSEU handling drm/i915/sseu: Disassociate internal subslice mask representation from uapi drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c | 14 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 371 +++++++++++-------- drivers/gpu/drm/i915/gt/intel_sseu.h | 69 ++-- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 28 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 28 +- drivers/gpu/drm/i915/i915_getparam.c | 10 +- drivers/gpu/drm/i915/i915_query.c | 16 +- 9 files changed, 323 insertions(+), 219 deletions(-) -- 2.35.1
next reply other threads:[~2022-04-27 23:08 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-27 23:07 Matt Roper [this message] 2022-04-27 23:07 ` [Intel-gfx] [PATCH 0/5] i915: SSEU handling updates Matt Roper 2022-04-27 23:07 ` [PATCH 1/5] drm/i915/sseu: Don't try to store EU mask internally in UAPI format Matt Roper 2022-04-27 23:07 ` [Intel-gfx] " Matt Roper 2022-04-27 23:07 ` [PATCH 2/5] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK Matt Roper 2022-04-27 23:07 ` [Intel-gfx] " Matt Roper 2022-04-27 23:07 ` [PATCH 3/5] drm/i915/xehp: Use separate sseu init function Matt Roper 2022-04-27 23:07 ` [Intel-gfx] " Matt Roper 2022-04-27 23:07 ` [PATCH 4/5] drm/i915/sseu: Simplify gen11+ SSEU handling Matt Roper 2022-04-27 23:07 ` [Intel-gfx] " Matt Roper 2022-04-27 23:07 ` [PATCH 5/5] drm/i915/sseu: Disassociate internal subslice mask representation from uapi Matt Roper 2022-04-27 23:07 ` [Intel-gfx] " Matt Roper 2022-04-28 12:18 ` Tvrtko Ursulin 2022-04-28 12:18 ` [Intel-gfx] " Tvrtko Ursulin 2022-05-06 23:34 ` Matt Roper 2022-05-06 23:34 ` [Intel-gfx] " Matt Roper 2022-05-09 14:18 ` Tvrtko Ursulin 2022-05-09 14:18 ` [Intel-gfx] " Tvrtko Ursulin 2022-04-27 23:26 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: SSEU handling updates Patchwork 2022-04-27 23:26 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2022-04-27 23:55 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork 2022-04-28 0:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: SSEU handling updates (rev2) Patchwork 2022-04-28 0:42 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2022-04-28 1:11 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-04-28 2:34 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220427230747.906625-1-matthew.d.roper@intel.com \ --to=matthew.d.roper@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=tvrtko.ursulin@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.