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

[Matt Roper]

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
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.


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