public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>,
	<intel-gfx@lists.freedesktop.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 12/13] drm/i915/xehp: Add compute workarounds
Date: Tue, 1 Mar 2022 11:31:44 -0800	[thread overview]
Message-ID: <454fde98-2ebe-dc12-78ed-6493712139cb@intel.com> (raw)
In-Reply-To: <20220228174245.1569581-13-matthew.d.roper@intel.com>



On 2/28/2022 9:42 AM, Matt Roper wrote:
> Additional workarounds are required once we start exposing CCS engines.
>
> Note that we have a number of workarounds that update registers in the
> shared render/compute reset domain.  Historically we've just added such
> registers to the RCS engine's workaround list.  But going forward we
> should be more careful to place such workarounds on a wa_list for an
> engine that definitely exists and is not fused off (e.g., a platform
> with no RCS would never apply the RCS wa_list).  We'll keep
> rcs_engine_wa_init() focused on RCS-specific workarounds that only need
> to be applied if the RCS engine is present.  A separate
> general_render_compute_wa_init() function will be used to define
> workarounds that touch registers in the shared render/compute reset
> domain and that we need to apply regardless of what render and/or
> compute engines actually exist.  Any workarounds defined in this new
> function will internally be added to the first present RCS or CCS
> engine's workaround list to ensure they get applied (and only get
> applied once rather than being needlessly re-applied several times).
>
> Co-author: Srinivasan Shanmugam
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>   drivers/gpu/drm/i915/gt/intel_gt_regs.h     |  1 +
>   drivers/gpu/drm/i915/gt/intel_lrc.c         |  6 +++
>   drivers/gpu/drm/i915/gt/intel_workarounds.c | 47 +++++++++++++++++++++
>   3 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index e629443e07ae..19cd34f24263 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1060,6 +1060,7 @@
>   #define   FLOW_CONTROL_ENABLE			REG_BIT(15)
>   #define   UGM_BACKUP_MODE			REG_BIT(13)
>   #define   MDQ_ARBITRATION_MODE			REG_BIT(12)
> +#define   SYSTOLIC_DOP_CLOCK_GATING_DIS		REG_BIT(10)
>   #define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE	REG_BIT(8)
>   #define   STALL_DOP_GATING_DISABLE		REG_BIT(5)
>   #define   THROTTLE_12_5				REG_GENMASK(4, 2)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index d333400d29fe..e9ea576b96a4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1217,6 +1217,12 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context *ce, u32 *cs)
>   	cs = gen12_emit_timestamp_wa(ce, cs);
>   	cs = gen12_emit_restore_scratch(ce, cs);
>   
> +	/* Wa_16013000631:dg2 */
> +	if (IS_DG2_GRAPHICS_STEP(ce->engine->i915, G10, STEP_B0, STEP_C0) ||
> +	    IS_DG2_G11(ce->engine->i915))
> +		if (ce->engine->class == COMPUTE_CLASS)
> +			cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE, 0);
> +
>   	return cs;
>   }
>   
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 0471d475e680..0b9435d62808 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1921,6 +1921,11 @@ static void dg2_whitelist_build(struct intel_engine_cs *engine)
>   					  RING_FORCE_TO_NONPRIV_RANGE_4);
>   
>   		break;
> +	case COMPUTE_CLASS:
> +		/* Wa_16011157294:dg2_g10 */
> +		if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_A0, STEP_B0))
> +			whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
> +		break;
>   	default:
>   		break;
>   	}
> @@ -2581,6 +2586,40 @@ xcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
>   	}
>   }
>   
> +/*
> + * The workarounds in this function apply to shared registers in
> + * the general render reset domain that aren't tied to a
> + * specific engine.  Since all render+compute engines get reset
> + * together, and the contents of these registers are lost during
> + * the shared render domain reset, we'll define such workarounds
> + * here and then add them to just a single RCS or CCS engine's
> + * workaround list (whichever engine has the XXXX flag).
> + */
> +static void
> +general_render_compute_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
> +{
> +	struct drm_i915_private *i915 = engine->i915;
> +
> +	if (IS_XEHPSDV(i915)) {
> +		/* Wa_1409954639 */
> +		wa_masked_en(wal,
> +			     GEN8_ROW_CHICKEN,
> +			     SYSTOLIC_DOP_CLOCK_GATING_DIS);
> +
> +		/* Wa_1607196519 */
> +		wa_masked_en(wal,
> +			     GEN9_ROW_CHICKEN4,
> +			     GEN12_DISABLE_GRF_CLEAR);
> +
> +		/* Wa_14010670810:xehpsdv */
> +		wa_write_or(wal, XEHP_L3NODEARBCFG, XEHP_LNESPARE);

These 2 WAs are also implemented for DG2 (with different IDs). Are you 
planning to move them over to this function as a follow up?
All the WA implementations match the specs, so as long as there is a 
plan for DG2 this is:

Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>

Daniele


> +
> +		/* Wa_14010449647:xehpsdv */
> +		wa_masked_en(wal, GEN7_HALF_SLICE_CHICKEN1,
> +			     GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
> +	}
> +}
> +
>   static void
>   engine_init_workarounds(struct intel_engine_cs *engine, struct i915_wa_list *wal)
>   {
> @@ -2589,6 +2628,14 @@ engine_init_workarounds(struct intel_engine_cs *engine, struct i915_wa_list *wal
>   
>   	engine_fake_wa_init(engine, wal);
>   
> +	/*
> +	 * These are common workarounds that just need to applied
> +	 * to a single RCS/CCS engine's workaround list since
> +	 * they're reset as part of the general render domain reset.
> +	 */
> +	if (engine->class == RENDER_CLASS)
> +		general_render_compute_wa_init(engine, wal);
> +
>   	if (engine->class == RENDER_CLASS)
>   		rcs_engine_wa_init(engine, wal);
>   	else


  reply	other threads:[~2022-03-01 19:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 17:42 [Intel-gfx] [PATCH v2 00/13] i915: Prepare for Xe_HP compute engines Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 01/13] drm/i915/xehp: Define compute class and engine Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 02/13] drm/i915/xehp: CCS shares the render reset domain Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 03/13] drm/i915/xehp: Add Compute CS IRQ handlers Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 04/13] drm/i915/xehp: compute engine pipe_control Matt Roper
2022-03-01  6:54   ` Lucas De Marchi
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 05/13] drm/i915/xehp: CCS should use RCS setup functions Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 06/13] drm/i915: Move context descriptor fields to intel_lrc.h Matt Roper
2022-03-01  6:57   ` Lucas De Marchi
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 07/13] drm/i915/xehp: Define context scheduling attributes in lrc descriptor Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 08/13] drm/i915/xehp/guc: enable compute engine inside GuC Matt Roper
2022-03-01 18:55   ` Ceraolo Spurio, Daniele
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 09/13] drm/i915/xehp: Enable ccs/dual-ctx in RCU_MODE Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 10/13] drm/i915/xehp: Don't support parallel submission on compute / render Matt Roper
2022-03-01 19:04   ` Ceraolo Spurio, Daniele
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 11/13] drm/i915/xehp: handle fused off CCS engines Matt Roper
2022-03-01 22:54   ` Matt Roper
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 12/13] drm/i915/xehp: Add compute workarounds Matt Roper
2022-03-01 19:31   ` Ceraolo Spurio, Daniele [this message]
2022-02-28 17:42 ` [Intel-gfx] [PATCH v2 13/13] drm/i915/xehpsdv: Move render/compute engine reset domains related workarounds Matt Roper
2022-02-28 22:48 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Prepare for Xe_HP compute engines Patchwork
2022-02-28 22:49 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-28 23:21 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-01  9:38 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=454fde98-2ebe-dc12-78ed-6493712139cb@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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