[PATCH i-g-t 0/7] Future-proof GT ID handling for Xe

[Matthew Brost]

On Wed, Jul 02, 2025 at 12:36:55PM -0700, Matt Roper wrote:
> On Tue, Jul 01, 2025 at 05:35:46PM -0700, Matthew Brost wrote:
> > On Mon, Jun 30, 2025 at 09:35:30AM -0700, Matt Roper wrote:
> > > Current Intel platforms fall into one of three cases:
> > >  * Single tile, single GT (primary)
> > >  * Multiple tiles, one GT each (primary)
> > >  * Single tile, two GTs (primary+media)
> > > 
> > > In all three cases, the GTs are always consecutive (0 and 1) and the
> > > GT's uapi ID matches its index in the xe_query GT list.  Future
> > > platforms could potentially have multiple tiles with multiple GTs each,
> > > and/or could introduce new types of GTs.  In either case, it's possible
> > > that there might be "holes" in the set of GT IDs returned by the GT
> > > query (e.g., 0, 2, 3 if a multi-tile platform only media on the second
> > > tile; or 0, 2 if a single-tile platform introduced a new type of GT, but
> > > lacked media).
> > > 
> > 
> > I think in the future we may logically remap GTs too for various
> > reasons. For this to work, the gt_id returned to user space really just
> > needs to be an opaque handle which the KMD can assign whatever value to.
> > 
> > I haven't looked through this series (or KMD) but it seems like step in
> > the right direction for logical remapping, right?
> 
> Yeah, although at the moment there's still an assumption that we don't
> have GT IDs above 63, since we're relying on a uint64_t bitmask to track

I don't think anytime soon we will need a GT ID above 63.

> which GTs are/aren't present.  But this series (and the kernel one too)
> are eliminating a lot of the assumptions we have today about GT IDs
> always being consecutive, GT's always showing up at a specific place in
> the uapi query, etc.
> 

Great. I was asked potential logical remapping for some future scaling
cases, thought it was doable but we'd have to do a bit of KMD / IGT
work. I guess I'll take a deep look at these patches.

Matt

> 
> Matt
> 
> > 
> > Matt
> > 
> > > We need to break IGT's assumption that the uapi ID used to represent a
> > > GT always matches its index in the GT query.  This series shouldn't have
> > > any functional impact on today's Intel platforms; the goal is to just
> > > future-proof the code for new types of platforms that could show up in
> > > the future.  Similar refactoring and cleanup is happening on the xe.ko
> > > side at https://patchwork.freedesktop.org/series/150192/  although this
> > > series does not depend on the kernel work.
> > > 
> > > 
> > > Matt Roper (7):
> > >   lib/xe: Track valid GT IDs
> > >   lib/xe: Don't assume GT ID matches location in GT query list
> > >   lib/xe: Populate vram_size[] and visible_vram_size[] by GT ID
> > >   lib/xe: Ensure GT loops iterate over all GTs properly
> > >   tests/intel/xe_query: Look up GT reference clock correctly
> > >   lib/xe: Add xe_dev_max_gt()
> > >   tests/xe: Don't assume max GT ID is num_gt - 1
> > > 
> > >  lib/xe/xe_query.c        | 78 ++++++++++++++++++++++++++++++----------
> > >  lib/xe/xe_query.h        | 10 ++++--
> > >  lib/xe/xe_util.c         |  7 ++--
> > >  tests/intel/xe_compute.c | 47 ++++++++++++------------
> > >  tests/intel/xe_gt_freq.c |  8 ++---
> > >  tests/intel/xe_query.c   | 13 +++----
> > >  6 files changed, 103 insertions(+), 60 deletions(-)
> > > 
> > > -- 
> > > 2.49.0
> > > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation