[Intel-xe] [PATCH 02/26] drm/xe: Introduce xe_tile

Matt Roper matthew.d.roper at intel.com
Fri May 12 16:27:03 UTC 2023


On Fri, May 12, 2023 at 11:03:22AM +0530, Iddamsetty, Aravind wrote:
> 
> 
> On 11-05-2023 09:16, Matt Roper wrote:
> > Create a new xe_tile structure to begin separating the concept of "tile"
> > from "GT."  A tile is effectively a complete GPU, and a GT is just one
> > part of that.  On platforms like MTL, there's only a single full GPU
> > (tile) which has its IP blocks provided by two GTs.  In contrast, a
> > "multi-tile" platform like PVC is basically multiple complete GPUs
> > packed behind a single PCI device.
> > 
> > For now, just create xe_tile as a simple wrapper around xe_gt.  The
> > items in xe_gt that are truly tied to the tile rather than the GT will
> > be moved in future patches.  Support for multiple GTs per tile (i.e.,
> > the MTL standalone media case) will also be re-introduced in a future
> > patch.
> > 
> > Signed-off-by: Matt Roper <matthew.d.roper at intel.com>
> > ---
> >  drivers/gpu/drm/xe/xe_device.h       | 11 +++++---
> >  drivers/gpu/drm/xe/xe_device_types.h | 40 +++++++++++++++++++++++++---
> >  drivers/gpu/drm/xe/xe_gt_types.h     | 15 +++++++----
> >  drivers/gpu/drm/xe/xe_mmio.c         | 13 ++++-----
> >  drivers/gpu/drm/xe/xe_pci.c          |  5 +++-
> >  drivers/gpu/drm/xe/xe_vm.c           |  2 +-
> >  drivers/gpu/drm/xe/xe_vm_types.h     |  8 +++---
> >  7 files changed, 71 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
> > index cbae480a2092..f7acaf51a1fc 100644
> > --- a/drivers/gpu/drm/xe/xe_device.h
> > +++ b/drivers/gpu/drm/xe/xe_device.h
> > @@ -48,12 +48,17 @@ static inline struct xe_file *to_xe_file(const struct drm_file *file)
> >  	return file->driver_priv;
> >  }
> >  
> > +static inline struct xe_tile *xe_device_get_root_tile(struct xe_device *xe)
> > +{
> > +	return &xe->tiles[0];
> > +}
> > +
> >  static inline struct xe_gt *xe_device_get_gt(struct xe_device *xe, u8 gt_id)
> >  {
> >  	struct xe_gt *gt;
> >  
> > -	XE_BUG_ON(gt_id > XE_MAX_GT);
> > -	gt = xe->gt + gt_id;
> > +	XE_BUG_ON(gt_id > XE_MAX_TILES_PER_DEVICE);
> 
> why do we expect the number of GTs to be less than tiles

Patch #1 of the series completely disabled media GT support for MTL
since it didn't work at all.  Easier to clear out the rubble, do a bunch
of fundamental refactoring, and then re-add the media GT support at the
end of the series once all of the prerequisite design is in place.

> > +	gt = &xe->tiles[gt_id].primary_gt;
> 
> some how this doesn't look correct to me, if GT is per tile, using GT_ID
> to reference tile might not be right.
> 
> also through this routine we always return primary_gt but the GT ID can
> correspond to other GTs as well.

So at this point in the series, there's only a single primary GT per
tile.  This code will change later as other refactors land and we
eventually re-add media GT support.

> 
> please check below.
> 
...
> > diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> > index bf2c234c4f6e..e79b16d8bf7f 100644
> > --- a/drivers/gpu/drm/xe/xe_pci.c
> > +++ b/drivers/gpu/drm/xe/xe_pci.c
> > @@ -525,7 +525,10 @@ static int xe_info_init(struct xe_device *xe,
> >  	xe->info.step = xe_step_get(xe);
> >  
> >  	for (id = 0; id < xe->info.tile_count; ++id) {
> > -		gt = xe->gt + id;
> > +		xe->tiles[id].xe = xe;
> > +		xe->tiles[id].id = id;
> > +
> > +		gt = &xe->tiles[id].primary_gt;
> >  		gt->info.id = id;
> 
> since GT is per tile, shouldn't it's numbering also start from 0
> 
> Thanks,
> Aravind.

At the moment GTs are still exposed at the UAPI level, so each GT still
needs a unique ID.  At the end of this series you'd have:

 * PVC:  0 = root tile primary, 1 = remote tile primary
 * MTL:  0 = root tile primary, 1 = root tile media
 * everything else:  only has GT0

We might have platforms in the future that are both multi-tile and have
separate graphics/media GTs, so it's undecided how we'll number those
cases.  We could go primary-media-primary-media or
primary-primary-media-media.  Although there's a larger discussion here
too --- do we actually still want to expose GTs through the uapi or
should the UAPI be updated to only expose tiles (and keep the graphics
vs media separation an internal kernel driver detail that userspace
doesn't need to worry about)?  If userspace stops seeing the individual
GTs and only sees the tiles, we may be able to eliminate GT IDs
entirely.


Matt

> >  		gt->xe = xe;
> >  
> > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> > index 0a4becdf4675..fe6abb6ed6ca 100644
> > --- a/drivers/gpu/drm/xe/xe_vm.c
> > +++ b/drivers/gpu/drm/xe/xe_vm.c
> > @@ -3347,7 +3347,7 @@ int xe_vm_invalidate_vma(struct xe_vma *vma)
> >  	struct xe_device *xe = vma->vm->xe;
> >  	struct xe_gt *gt;
> >  	u32 gt_needs_invalidate = 0;
> > -	int seqno[XE_MAX_GT];
> > +	int seqno[XE_MAX_TILES_PER_DEVICE];
> >  	u8 id;
> >  	int ret;
> >  
> > diff --git a/drivers/gpu/drm/xe/xe_vm_types.h b/drivers/gpu/drm/xe/xe_vm_types.h
> > index fada7896867f..203ba9d946b8 100644
> > --- a/drivers/gpu/drm/xe/xe_vm_types.h
> > +++ b/drivers/gpu/drm/xe/xe_vm_types.h
> > @@ -159,7 +159,7 @@ struct xe_vm {
> >  	struct kref refcount;
> >  
> >  	/* engine used for (un)binding vma's */
> > -	struct xe_engine *eng[XE_MAX_GT];
> > +	struct xe_engine *eng[XE_MAX_TILES_PER_DEVICE];
> >  
> >  	/** Protects @rebind_list and the page-table structures */
> >  	struct dma_resv resv;
> > @@ -167,9 +167,9 @@ struct xe_vm {
> >  	u64 size;
> >  	struct rb_root vmas;
> >  
> > -	struct xe_pt *pt_root[XE_MAX_GT];
> > -	struct xe_bo *scratch_bo[XE_MAX_GT];
> > -	struct xe_pt *scratch_pt[XE_MAX_GT][XE_VM_MAX_LEVEL];
> > +	struct xe_pt *pt_root[XE_MAX_TILES_PER_DEVICE];
> > +	struct xe_bo *scratch_bo[XE_MAX_TILES_PER_DEVICE];
> > +	struct xe_pt *scratch_pt[XE_MAX_TILES_PER_DEVICE][XE_VM_MAX_LEVEL];
> >  
> >  	/** @flags: flags for this VM, statically setup a creation time */
> >  #define XE_VM_FLAGS_64K			BIT(0)

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


More information about the Intel-xe mailing list