Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "Dugast, Francois" <francois.dugast@intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH v2 34/50] drm/xe/uapi: Move memory_region masks from GT to engine
Date: Thu, 9 Nov 2023 13:46:03 -0500	[thread overview]
Message-ID: <ZU0o6z5MtoaG8fuZ@intel.com> (raw)
In-Reply-To: <b5252d2f0873bcaebf0ecd1fcd4579020f7821f7.camel@intel.com>

On Thu, Nov 09, 2023 at 04:35:19PM +0000, Souza, Jose wrote:
> On Thu, 2023-11-09 at 08:29 -0800, José Roberto de Souza wrote:
> > On Fri, 2023-11-03 at 14:34 +0000, Francois Dugast wrote:
> > > From: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > 
> > > In the Tiled platforms, the memory is more tied to the Tile
> > > than to the GT.
> > > The distance (near vs far) makes more sense from the Engine
> > > perspective than from the GT perspective.
> > 
> > why not add a uAPI to query tile information?
> > this is duplicating a tile information onto every engine of that tile.
> > we could leave reserved fields in the tile uAPI to include additional information that might be relevant in future.

This is not necessarily a tile information. In PVC, truly the mem_region is tied to the tile,
but we don't want to fix the uapi in only one platform.
Like in the previous, the mem_region was per GT. who knows the future?!

But the engine needs the information on which mem_region could be better,
regardless of if it lives along the same gt, or the same tile, or outside.
So, near and far sounded the most generic and future proof way.

> 
> other issue here and in other patches of this huge patch series.
> 
> a previous patch in this series renamed near_mem_regions, then this one moves it to other struct... please drop the first patch and rename and move it
> into a single patch.

okay, rename and move in the same patch kind of makes sense. and patches
could be squashed together. But when doing the IGT on the side, I felt
that small changes were better, so renames goes with sed commands and
the patch was small and clear. But I don't mind if they get squashed in
the end.

> 
> a series as big as this one will cause reviews in KMD and UMD to take a while...

that's unfortunate indeed. But big patches also don't help much to speed up reviews.

> 
> > 
> > > 
> > > So, let's move this out from the GT and into the engine info.
> > > 
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_query.c | 14 +++++++-------
> > >  include/uapi/drm/xe_drm.h     | 27 ++++++++++++++-------------
> > >  2 files changed, 21 insertions(+), 20 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_query.c b/drivers/gpu/drm/xe/xe_query.c
> > > index aa5743e2e4d0..49a9b36f1193 100644
> > > --- a/drivers/gpu/drm/xe/xe_query.c
> > > +++ b/drivers/gpu/drm/xe/xe_query.c
> > > @@ -217,6 +217,13 @@ static int query_engines(struct xe_device *xe,
> > >  				hwe->logical_instance;
> > >  			hw_engine_info[i].instance.gt_id = gt->info.id;
> > >  			hw_engine_info[i].instance.pad = 0;
> > > +			if (!IS_DGFX(xe))
> > > +				hw_engine_info[i].near_mem_regions = 0x1;
> > > +			else
> > > +				hw_engine_info[i].near_mem_regions =
> > > +					BIT(gt_to_tile(gt)->id) << 1;
> > > +			hw_engine_info[i].far_mem_regions = xe->info.mem_region_mask ^
> > > +				hw_engine_info[i].near_mem_regions;
> > >  			memset(hw_engine_info->reserved, 0, sizeof(hw_engine_info->reserved));
> > >  
> > >  			i++;
> > > @@ -377,13 +384,6 @@ static int query_gt_list(struct xe_device *xe, struct drm_xe_device_query *query
> > >  			gt_list->gt_list[id].type = DRM_XE_QUERY_GT_TYPE_MAIN;
> > >  		gt_list->gt_list[id].gt_id = gt->info.id;
> > >  		gt_list->gt_list[id].clock_freq = gt->info.clock_freq;
> > > -		if (!IS_DGFX(xe))
> > > -			gt_list->gt_list[id].near_mem_regions = 0x1;
> > > -		else
> > > -			gt_list->gt_list[id].near_mem_regions =
> > > -				BIT(gt_to_tile(gt)->id) << 1;
> > > -		gt_list->gt_list[id].far_mem_regions = xe->info.mem_region_mask ^
> > > -			gt_list->gt_list[id].near_mem_regions;
> > >  	}
> > >  
> > >  	if (copy_to_user(query_ptr, gt_list, size)) {
> > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > > index 5164ed150a2e..8e84ef6fd46e 100644
> > > --- a/include/uapi/drm/xe_drm.h
> > > +++ b/include/uapi/drm/xe_drm.h
> > > @@ -228,6 +228,20 @@ struct drm_xe_query_engine_info {
> > >  	/** @instance: The @drm_xe_engine_class_instance */
> > >  	struct drm_xe_engine_class_instance instance;
> > >  
> > > +	/**
> > > +	 * @near_mem_regions: Bit mask of instances from
> > > +	 * drm_xe_query_mem_regions that is near this engine.
> > > +	 */
> > > +	__u64 near_mem_regions;
> > > +	/**
> > > +	 * @far_mem_regions: Bit mask of instances from
> > > +	 * drm_xe_query_mem_regions that is far from this engine.
> > > +	 * In general, it has extra indirections when compared to the
> > > +	 * @near_mem_regions. For a discrete device this could mean system
> > > +	 * memory and memory living in a different Tile.
> > > +	 */
> > > +	__u64 far_mem_regions;
> > > +
> > >  	/** @reserved: Reserved */
> > >  	__u64 reserved[3];
> > >  };
> > > @@ -401,19 +415,6 @@ struct drm_xe_query_gt {
> > >  	__u16 gt_id;
> > >  	/** @clock_freq: A clock frequency for timestamp */
> > >  	__u32 clock_freq;
> > > -	/**
> > > -	 * @near_mem_regions: Bit mask of instances from
> > > -	 * drm_xe_query_mem_regions that is near the current engines of this GT.
> > > -	 */
> > > -	__u64 near_mem_regions;
> > > -	/**
> > > -	 * @far_mem_regions: Bit mask of instances from
> > > -	 * drm_xe_query_mem_regions that is far from the engines of this GT.
> > > -	 * In general, it has extra indirections when compared to the
> > > -	 * @near_mem_regions. For a discrete device this could mean system
> > > -	 * memory and memory living in a different Tile.
> > > -	 */
> > > -	__u64 far_mem_regions;
> > >  	/** @reserved: Reserved */
> > >  	__u64 reserved[8];
> > >  };
> > 
> 

  reply	other threads:[~2023-11-09 18:46 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-03 14:34 [Intel-xe] [PATCH v2 00/50] uAPI Alignment - take 2 Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 01/50] fixup! drm/xe: Correlate engine and cpu timestamps with better accuracy Francois Dugast
2023-11-07 16:26   ` Lucas De Marchi
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 02/50] drm/xe/uapi: Add documentation for query Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 03/50] drm/xe: Extend drm_xe_vm_bind_op Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 04/50] drm/xe: Add uAPI to query micro-controler firmware version Francois Dugast
2023-11-09 15:37   ` Souza, Jose
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 05/50] drm/xe/uapi: Document DRM_XE_DEVICE_QUERY_HWCONFIG Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 06/50] drm/xe: Extend uAPI to query HuC micro-controler firmware version Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 07/50] drm/xe: Remove useless query config num_params Francois Dugast
2023-11-07 15:49   ` Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 08/50] drm/xe/uapi: Add missing DRM_ prefix in uAPI constants Francois Dugast
2023-11-07 14:05   ` Matthew Brost
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 09/50] drm/xe/uapi: Add _FLAG to uAPI constants usable for flags Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 10/50] fixup! drm/xe: Add uAPI to query micro-controler firmware version Francois Dugast
2023-11-07 14:07   ` Matthew Brost
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 11/50] drm/xe/uapi: Make constant comments visible in kernel doc Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 12/50] fixup! drm/xe: Correlate engine and cpu timestamps with better accuracy Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 13/50] drm/xe/uapi: Remove GT_TYPE_REMOTE Francois Dugast
2023-11-03 23:35   ` Matt Roper
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 14/50] drm/xe/uapi: Kill VM_MADVISE IOCTL Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 15/50] drm/xe/uapi: Separate bo_create placement from flags Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 16/50] drm/xe/uapi: Remove unused inaccessible memory region Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 17/50] drm/xe/uapi: Remove unused QUERY_CONFIG_MEM_REGION_COUNT Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 18/50] drm/xe/uapi: Remove unused QUERY_CONFIG_GT_COUNT Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 19/50] drm/xe/uapi: Rename *_mem_regions masks Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 20/50] drm/xe/uapi: Rename query's mem_usage to mem_regions Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 21/50] drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 22/50] drm/xe/uapi: Replace BO with GEM in documentation Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 23/50] drm/xe/pmu: Drop interrupt pmu event Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 24/50] xe/xe_bo: Reject bo creation of unaligned size Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 25/50] fixup! drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 26/50] drm/xe/uapi: Fix indentation issues that sometimes causes build warning Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 27/50] drm/xe/uapi: Order sections Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 28/50] drm/xe/uapi: More uAPI documentation additions and cosmetic updates Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 29/50] drm/xe/uapi: Split xe_sync types from flags Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 30/50] drm/xe/uapi: Standardize the FLAG naming and assignment Francois Dugast
2023-11-09 14:56   ` Matthew Brost
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 31/50] drm/xe/uapi: Differentiate WAIT_OP from WAIT_MASK Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 32/50] drm/xe/uapi: Move xe_exec after xe_exec_queue Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 33/50] fixup! drm/xe/uapi: Split xe_sync types from flags Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 34/50] drm/xe/uapi: Move memory_region masks from GT to engine Francois Dugast
2023-11-09 16:29   ` Souza, Jose
2023-11-09 16:35     ` Souza, Jose
2023-11-09 18:46       ` Rodrigo Vivi [this message]
2023-11-09 19:50         ` Souza, Jose
2023-11-09 21:04           ` Rodrigo Vivi
2023-11-16  3:31             ` Rodrigo Vivi
2023-11-16 16:15               ` Souza, Jose
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 35/50] drm/xe/uapi: Document the memory_region bitmask Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 36/50] drm/xe/uapi: Be more specific about the vm_bind prefetch region Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 37/50] drm/xe/uapi: Convert tile_mask to a pt_placement_hint Francois Dugast
2023-11-08  0:17   ` Welty, Brian
2023-11-09 18:55     ` Rodrigo Vivi
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 38/50] drm/xe/uapi: Rename couple exec_queue items Francois Dugast
2023-11-09 17:14   ` Souza, Jose
2023-11-09 18:40     ` Rodrigo Vivi
2023-11-09 20:02       ` Souza, Jose
2023-11-09 20:56         ` Rodrigo Vivi
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 39/50] drm/xe/uapi: Refactor engine information Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 40/50] drm/xe/uapi: Add link to Xe documentation Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 41/50] drm/xe/uapi: Crystal Reference Clock updates Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 42/50] drm/xe/uapi: Add Tile ID information to the GT info query Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 43/50] squash! drm/xe/uapi: Rename couple exec_queue items Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 44/50] fixup! drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 45/50] drm/xe/uapi: Remove bogus engine list from the wait_user_fence IOCTL Francois Dugast
2023-11-08  0:05   ` Welty, Brian
2023-11-09 18:56     ` Rodrigo Vivi
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 46/50] drm/xe/uapi: Align on a common way to return arrays (memory regions) Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 47/50] drm/xe/uapi: Align on a common way to return arrays (gt) Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 48/50] drm/xe/uapi: Align on a common way to return arrays (engines) Francois Dugast
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 49/50] drm/xe/uapi: Add block diagram of a device Francois Dugast
2023-11-09 15:35   ` Souza, Jose
2023-11-03 14:34 ` [Intel-xe] [PATCH v2 50/50] drm/xe/uapi: Add examples of user space code Francois Dugast
2023-11-03 14:38 ` [Intel-xe] ✓ CI.Patch_applied: success for uAPI Alignment - take 2 Patchwork
2023-11-03 14:39 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-11-03 14:40 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-11-03 14:47 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-11-03 14:48 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
2023-11-03 14:49 ` [Intel-xe] ✓ CI.checksparse: success " Patchwork
2023-11-03 15:24 ` [Intel-xe] ✗ CI.BAT: 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=ZU0o6z5MtoaG8fuZ@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=francois.dugast@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jose.souza@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox