Re: [PATCH] drm/xe: Make decision to use Xe2-style blitter instructions a feature flag

["Vivekanandan, Balasubramani" <balasubramani.vivekanandan@intel.com>]

On 07.05.2026 14:00, Matt Roper wrote:
> The blitter engines' MEM_COPY and MEM_SET instructions were added as
> part of the same hardware change that introduced service copy engines
> (i.e., BCS1-BCS8) which is why the driver checks for service copy engine
> presence when deciding whether to use these instructions or the older
> XY_* instructions.  However when making this decision the driver should
> consider which engines are part of the hardware architecture, not which
> engines are present/usable on the current device.  For graphics IP
> versions that architecturally include service copy engines (i.e.,
> everything Xe2 and later, plus PVC's Xe_HPC) we should use MEM_SET and
> MEM_COPY even in if all of the service copy engines wind up getting
> fused off.  I.e., we need to decide based on whether the platform's
> graphics descriptor contains these engines, rather than whether the
> usable engine mask contains them.  This logic got broken when
> gt->info.__engine_mask was removed, although in practice that mistake
> has been harmless so far because there haven't been any hardware
> SKUs that fuse off all of the service copy engines yet.
> 
> Replace the incorrect has_service_copy_support() function with a GT
> feature flag that tracks more accurately whether the new blitter
> instructions are usable.  In addition to fixing incorrect logic if all
> service copies are fused off, the flag also makes it more obvious what
> the calling code is trying to do; previously it wasn't terribly obvious
> why "has service copy engines" was being used as the condition for using
> different instructions on all copy engine types.
> 
> The new feature flag is named 'has_xe2_blt_instructions' because we
> expect this flag to be set for all Xe2 and later platforms (i.e.,
> everything officially supported by the Xe driver).  Technically there's
> also one Xe1-era platform (PVC) that supports these engines/instructions
> and will set this flag, but this still seems to be the most clear and
> understandable name for the flag.
> 
> Fixes: 61549a2ee594 ("drm/xe: Drop __engine_mask")
> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_gt_types.h |  6 ++++++
>  drivers/gpu/drm/xe/xe_migrate.c  | 18 ++----------------
>  drivers/gpu/drm/xe/xe_pci.c      |  9 +++++++++
>  3 files changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_gt_types.h b/drivers/gpu/drm/xe/xe_gt_types.h
> index 7351aadd238e..231555092435 100644
> --- a/drivers/gpu/drm/xe/xe_gt_types.h
> +++ b/drivers/gpu/drm/xe/xe_gt_types.h
> @@ -144,6 +144,12 @@ struct xe_gt {
>  		u8 id;
>  		/** @info.has_indirect_ring_state: GT has indirect ring state support */
>  		u8 has_indirect_ring_state:1;
> +		/**
> +		 * @info.has_xe2_blt: GT supports Xe2-style MEM_SET and MEM_COPY

nitpick: s/has_xe2_blt/has_xe2_blt_instructions

> +		 * blitter functionality.  Note that despite the name, some Xe1
> +		 * platforms may also support this "Xe2-style" feature.
> +		 */
> +		u8 has_xe2_blt_instructions:1;


>  		/**
>  		 * @info.num_geometry_xecore_fuse_regs: Number of 32b-bit fuse
>  		 * registers the geometry XeCore mask spans.
> diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
> index a87fbc1e9fb1..f3c2ef269ba8 100644
> --- a/drivers/gpu/drm/xe/xe_migrate.c
> +++ b/drivers/gpu/drm/xe/xe_migrate.c
> @@ -1525,23 +1525,9 @@ static void emit_clear_main_copy(struct xe_gt *gt, struct xe_bb *bb,
>  	bb->len += len;
>  }
>  
> -static bool has_service_copy_support(struct xe_gt *gt)
> -{
> -	/*
> -	 * What we care about is whether the architecture was designed with
> -	 * service copy functionality (specifically the new MEM_SET / MEM_COPY
> -	 * instructions) so check the architectural engine list rather than the
> -	 * actual list since these instructions are usable on BCS0 even if
> -	 * all of the actual service copy engines (BCS1-BCS8) have been fused
> -	 * off.
> -	 */
> -	return gt->info.engine_mask & GENMASK(XE_HW_ENGINE_BCS8,
> -					      XE_HW_ENGINE_BCS1);
> -}
> -
>  static u32 emit_clear_cmd_len(struct xe_gt *gt)
>  {
> -	if (has_service_copy_support(gt))
> +	if (gt->info.has_xe2_blt_instructions)
>  		return PVC_MEM_SET_CMD_LEN_DW;
>  	else
>  		return XY_FAST_COLOR_BLT_DW;
> @@ -1550,7 +1536,7 @@ static u32 emit_clear_cmd_len(struct xe_gt *gt)
>  static void emit_clear(struct xe_gt *gt, struct xe_bb *bb, u64 src_ofs,
>  		       u32 size, u32 pitch, bool is_vram)
>  {
> -	if (has_service_copy_support(gt))
> +	if (gt->info.has_xe2_blt_instructions)
>  		emit_clear_link_copy(gt, bb, src_ofs, size, pitch);
>  	else
>  		emit_clear_main_copy(gt, bb, src_ofs, size, pitch,
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index d55e5af4f4b7..2ab6d2f483fb 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -850,6 +850,15 @@ static struct xe_gt *alloc_primary_gt(struct xe_tile *tile,
>  	gt->info.num_geometry_xecore_fuse_regs = graphics_desc->num_geometry_xecore_fuse_regs;
>  	gt->info.num_compute_xecore_fuse_regs = graphics_desc->num_compute_xecore_fuse_regs;
>  
> +	/*
> +	 * Even if the service copy engines wind up being fused off, their
> +	 * presence in the IP descriptor indicates that the platform supports
> +	 * Xe2-style MEM_SET and MEM_COPY functionality.
> +	 */
> +	if (graphics_desc->hw_engine_mask & GENMASK(XE_HW_ENGINE_BCS8,
> +						    XE_HW_ENGINE_BCS1))
> +		gt->info.has_xe2_blt_instructions = true;
> +
>  	/*
>  	 * Before media version 13, the media IP was part of the primary GT
>  	 * so we need to add the media engines to the primary GT's engine list.

LGTM.

Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>

Regards,
Bala

> 
> ---
> base-commit: 36eddf6e5c9411ad95c4939b092ed1ea77f13d61
> change-id: 20260507-xe2_copy-90d059dabe75
> 
> Best regards,
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation
>