This series reworks i915's internal handling of slice/subslice/EU (SSEU)
data to represent platforms like Xe_HP in a more natural manner and to
prepare for future platforms where the masks will need to grow in size.
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.
Another key point here is that we're reaching the point where subslice
(DSS) masks will soon not fit within simple u32/u64 integer values.
Xe_HP SDV and DG2 platforms today have subslice (DSS) masks that are 32
bits, which maxes out the current storage of a u32. With PVC the masks
are represented by a pair of 32-bit registers, requiring a bump up to at
least 64-bits of storage internally. We could switch to u64 for that in
the short term, but since we already know that upcoming architectures
intend to provide DSS fuse bits via three or more registers it's best to
switch to a representation that's more future-proof but still easy to
work with in the driver code. To accomodate this, we start storing our
subslice mask for Xe_HP and beyond 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 (on PVC), 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@xxxxxxxxxxxxxxx>
Matt Roper (6):
drm/i915/xehp: Use separate sseu init function
drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
drm/i915/sseu: Simplify gen11+ SSEU handling
drm/i915/sseu: Don't try to store EU mask internally in UAPI format
drm/i915/sseu: Disassociate internal subslice mask representation from
uapi
drm/i915/pvc: Add SSEU changes
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 428 ++++++++++++-------
drivers/gpu/drm/i915/gt/intel_sseu.h | 90 ++--
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_getparam.c | 11 +-
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_query.c | 16 +-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
13 files changed, 376 insertions(+), 251 deletions(-)
--
2.35.3
