Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Shekhar Chauhan <shekhar.chauhan@intel.com>,
	Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>,
	Tejas Upadhyay <tejas.upadhyay@intel.com>,
	Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>,
	S A Muqthyar Ahmed <syed.abdul.muqthyar.ahmed@intel.com>
Subject: Re: [PATCH v3 21/24] drm/xe/xe3p_xpc: Add support for compute walker for non-MSIx
Date: Fri, 17 Oct 2025 10:04:35 -0700	[thread overview]
Message-ID: <20251017170435.GU5409@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <20251016-xe3p-v3-21-3dd173a3097a@intel.com>

On Thu, Oct 16, 2025 at 07:26:40PM -0700, Lucas De Marchi wrote:
> Current implementation of compute walker has dependency on GPU/SW Stack
> which requires SW/UMD to wait for event from KMD to indicate
> PIPE_CONTROL interrupt was done. This created latency on SW stack.
> 
> This feature adds support to generate completion interrupt from GPGPU
> walker which does not support MSIx and avoid software using Pipe control
> drain/idle latency.
> 
> The only thing needed for the kernel driver to do here is to wakeup the
> thread waiting on the ufence, which is already handled by the irq
> handler.
> 
> Suggested-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> Signed-off-by: S A Muqthyar Ahmed <syed.abdul.muqthyar.ahmed@intel.com>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

Digging into this more, I think the implementation is correct, but I
think we could still expand the commit message a little bit more to
explain how/when this winds up getting used.  The description above left
me uncertain whether these new interrupts are opt-in on a per-walker
basis, or whether the hardware was going to start unconditionally
generating interrupts for every walker's completion.  After looking
through the bspec, it looks like the interrupts here are only generated
for COMPUTE_WALKER_2 instructions (not COMPUTE_WALKER) if specifically
requested via the flag in the POST_SYNC_DATA_2 substructure's dw0[3].

So with a minor clarification to the commit message that the interrupts
we're enabling here are something userspace can opt into on a per-walker
basis,

        Bspec: 62346, 74334
        Reviewed-by: Matt Roper <matthew.d.roper@intel.com>


Matt

> ---
> v2: Rebase on split mask per engine class
> ---
>  drivers/gpu/drm/xe/regs/xe_irq_regs.h | 1 +
>  drivers/gpu/drm/xe/xe_irq.c           | 6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/regs/xe_irq_regs.h b/drivers/gpu/drm/xe/regs/xe_irq_regs.h
> index 815d5e3d22099..2f97662d958de 100644
> --- a/drivers/gpu/drm/xe/regs/xe_irq_regs.h
> +++ b/drivers/gpu/drm/xe/regs/xe_irq_regs.h
> @@ -85,6 +85,7 @@
>  #define   GSC_ER_COMPLETE			REG_BIT(5)
>  #define   GT_FLUSH_COMPLETE_INTERRUPT	REG_BIT(4)
>  #define   GT_CS_MASTER_ERROR_INTERRUPT		REG_BIT(3)
> +#define   GT_COMPUTE_WALKER_INTERRUPT		REG_BIT(2)
>  #define   GT_MI_USER_INTERRUPT			REG_BIT(0)
>  
>  /* irqs for OTHER_KCR_INSTANCE */
> diff --git a/drivers/gpu/drm/xe/xe_irq.c b/drivers/gpu/drm/xe/xe_irq.c
> index 8f2c8d3ae5f8a..e5ed0242f7b1d 100644
> --- a/drivers/gpu/drm/xe/xe_irq.c
> +++ b/drivers/gpu/drm/xe/xe_irq.c
> @@ -149,6 +149,12 @@ void xe_irq_enable_hwe(struct xe_gt *gt)
>  	if (xe_device_uc_enabled(xe)) {
>  		common_mask = GT_MI_USER_INTERRUPT |
>  			      GT_FLUSH_COMPLETE_INTERRUPT;
> +
> +		/* Enable Compute Walker Interrupt for non-MSIX platforms */
> +		if (GRAPHICS_VERx100(xe) >= 3511 && !xe_device_has_msix(xe)) {
> +			rcs_mask |= GT_COMPUTE_WALKER_INTERRUPT;
> +			ccs_mask |= GT_COMPUTE_WALKER_INTERRUPT;
> +		}
>  	} else {
>  		common_mask = GT_MI_USER_INTERRUPT |
>  			      GT_CS_MASTER_ERROR_INTERRUPT |
> 
> -- 
> 2.51.0
> 

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

  reply	other threads:[~2025-10-17 17:04 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17  2:26 [PATCH v3 00/24] drm/xe: Add Xe3p support Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 01/24] drm/xe/xe3: Add support for graphics IP versions 30.04 & 30.05 Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 02/24] drm/xe/xe3p: Add support for media IP versions 35.00 & 35.03 Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 03/24] drm/xe: Drop CTC_MODE register read Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 04/24] drm/xe: Add GT_VER() to check version specific to gt type Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 05/24] drm/xe/xe3p_lpm: Skip disabling NOA on unsupported IPs Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 06/24] drm/xe/xe3p_lpm: Handle MCR steering Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 07/24] drm/xe/xe3p: Stop programming RCU_MODE's fixed slice mode setting Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 08/24] drm/xe/xe3p: Determine service copy availability from fuse Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 09/24] drm/xe: Dump CURRENT_LRCA register Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 10/24] drm/xe/xe3p: Dump CSMQDEBUG register Lucas De Marchi
2025-10-17 15:55   ` Matt Roper
2025-10-21 16:02   ` Summers, Stuart
2025-10-17  2:26 ` [PATCH v3 11/24] drm/xe/nvl: Define NVL-S platform Lucas De Marchi
2025-10-17 13:05   ` Gustavo Sousa
2025-10-17  2:26 ` [PATCH v3 12/24] drm/xe/nvls: Define GuC firmware for NVL-S Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 13/24] drm/xe/nvls: Attach MOCS table " Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 14/24] drm/xe/xe3p_xpc: Add Xe3p_XPC IP definition Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 15/24] drm/xe/xe3p_xpc: Add L3 bank mask Lucas De Marchi
2025-10-17 17:51   ` Matt Roper
2025-10-18  3:18     ` Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 16/24] drm/xe/xe3p_xpc: Add MCR steering Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 17/24] drm/xe/irq: Rename fuse mask variables Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 18/24] drm/xe/irq: Split irq mask per engine class Lucas De Marchi
2025-10-17 16:03   ` Matt Roper
2025-10-17  2:26 ` [PATCH v3 19/24] drm/xe/irq: Rename bits used with all engines Lucas De Marchi
2025-10-17 16:05   ` Matt Roper
2025-10-17  2:26 ` [PATCH v3 20/24] drm/xe/irq: Check fuse mask for media engines Lucas De Marchi
2025-10-17 16:07   ` Matt Roper
2025-10-17  2:26 ` [PATCH v3 21/24] drm/xe/xe3p_xpc: Add support for compute walker for non-MSIx Lucas De Marchi
2025-10-17 17:04   ` Matt Roper [this message]
2025-10-17  2:26 ` [PATCH v3 22/24] drm/xe/xe3p_xpc: Skip compression tuning on platforms without flatccs Lucas De Marchi
2025-10-17  2:26 ` [PATCH v3 23/24] drm/xe/xe3p_xpc: Setup PAT table Lucas De Marchi
2025-10-17 11:05   ` Ville Syrjälä
2025-10-17 17:18     ` Matt Roper
2025-10-17 18:09       ` Ville Syrjälä
2025-10-17 20:33         ` Matt Roper
2025-10-17  2:26 ` [PATCH v3 24/24] drm/xe/xe3p: Add xe3p EU stall data format Lucas De Marchi
2025-10-17  2:35 ` ✗ CI.checkpatch: warning for drm/xe: Add Xe3p support (rev3) Patchwork
2025-10-17  2:36 ` ✓ CI.KUnit: success " Patchwork
2025-10-17  3:23 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-18  1:56 ` ✗ Xe.CI.Full: failure " Patchwork
2025-10-19  2:55 ` [PATCH v3 00/24] drm/xe: Add Xe3p support Lucas De Marchi

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=20251017170435.GU5409@mdroper-desk1.amr.corp.intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=balasubramani.vivekanandan@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=shekhar.chauhan@intel.com \
    --cc=syed.abdul.muqthyar.ahmed@intel.com \
    --cc=tejas.upadhyay@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