public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: fei.yang@intel.com, intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv
Date: Fri, 18 Mar 2022 14:38:44 +0000	[thread overview]
Message-ID: <8d283c4b-6f16-a235-7c57-ad8a67252ca9@linux.intel.com> (raw)
In-Reply-To: <20220318052619.3429370-1-fei.yang@intel.com>


On 18/03/2022 05:26, fei.yang@intel.com wrote:
> From: Fei Yang <fei.yang@intel.com>
> 
> GPU hangs have been observed when multiple engines write to the
> same aux_inv register at the same time. To avoid this each engine
> should only invalidate its own auxiliary table. The function
> gen12_emit_flush_xcs() currently invalidate the auxiliary table for
> all engines because the rq->engine is not necessarily the engine
> eventually carrying out the request, and potentially the engine
> could even be a virtual one (with engine->instance being -1).
> With the MMIO remap feature, we can actually set bit 17 of MI_LRI
> instruction and let the hardware to figure out the local aux_inv
> register at runtime to avoid invalidating auxiliary table for all
> engines.
> 
> Bspec: 45728
> 
> Cc: Stuart Summers <stuart.summers@intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
> Signed-off-by: Fei Yang <fei.yang@intel.com>
> ---
>   drivers/gpu/drm/i915/gt/gen8_engine_cs.c     | 42 +++++---------------
>   drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
>   2 files changed, 11 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 36148887c699..d440c5dfb6b7 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -165,30 +165,6 @@ static u32 preparser_disable(bool state)
>   	return MI_ARB_CHECK | 1 << 8 | state;
>   }
>   
> -static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
> -{
> -	static const i915_reg_t vd[] = {
> -		GEN12_VD0_AUX_NV,
> -		GEN12_VD1_AUX_NV,
> -		GEN12_VD2_AUX_NV,
> -		GEN12_VD3_AUX_NV,
> -	};
> -
> -	static const i915_reg_t ve[] = {
> -		GEN12_VE0_AUX_NV,
> -		GEN12_VE1_AUX_NV,
> -	};
> -
> -	if (engine->class == VIDEO_DECODE_CLASS)
> -		return vd[engine->instance];
> -
> -	if (engine->class == VIDEO_ENHANCEMENT_CLASS)
> -		return ve[engine->instance];
> -
> -	GEM_BUG_ON("unknown aux_inv reg\n");
> -	return INVALID_MMIO_REG;
> -}
> -
>   static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
>   {
>   	*cs++ = MI_LOAD_REGISTER_IMM(1);
> @@ -296,7 +272,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
>   		if (!HAS_FLAT_CCS(rq->engine->i915)) {
>   			aux_inv = rq->engine->mask & ~BIT(BCS0);
>   			if (aux_inv)
> -				cmd += 2 * hweight32(aux_inv) + 2;
> +				cmd += 4;
>   		}
>   	}
>   
> @@ -329,14 +305,16 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
>   	*cs++ = 0; /* value */
>   
>   	if (aux_inv) { /* hsdes: 1809175790 */
> -		struct intel_engine_cs *engine;
> -		unsigned int tmp;
> -
> -		*cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
> -		for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
> -			*cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
> -			*cs++ = AUX_INV;
> +		*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;

Cool, I didn't know this exists. First Bspec link I found did not 
mention these register, but second did. That one however (29545) has a 
worrying "removed by" tag which seems to point to a story suggesting the 
remapping table might be gone on machines with flat ccs?! Could you 
double check please?

> +		if (rq->engine->class == VIDEO_DECODE_CLASS) {
> +			*cs++ = i915_mmio_reg_offset(GEN12_VD0_AUX_NV);
> +		} else if (rq->engine->class == VIDEO_ENHANCEMENT_CLASS) {
> +			*cs++ = i915_mmio_reg_offset(GEN12_VE0_AUX_NV);
> +		} else {
> +			GEM_BUG_ON("unknown aux_inv reg\n");
> +			*cs++ = i915_mmio_reg_offset(INVALID_MMIO_REG);

I'd consider not emitting the LRI if we don't know what to put in unless 
there is some hidden point to do it?

>   		}
> +		*cs++ = AUX_INV;
>   		*cs++ = MI_NOOP;
>   	}
>   
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index d112ffd56418..2d150eec5c65 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -144,6 +144,7 @@
>   #define MI_LOAD_REGISTER_IMM(x)	MI_INSTR(0x22, 2*(x)-1)
>   /* Gen11+. addr = base + (ctx_restore ? offset & GENMASK(12,2) : offset) */
>   #define   MI_LRI_LRM_CS_MMIO		REG_BIT(19)
> +#define   MI_LRI_MMIO_REMAP_EN		(1 << 17)
>   #define   MI_LRI_FORCE_POSTED		(1<<12)

Passing observation - three bits, three flavours of expressing them, sigh...

Regards,

Tvrtko

>   #define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
>   #define MI_STORE_REGISTER_MEM        MI_INSTR(0x24, 1)

  parent reply	other threads:[~2022-03-18 14:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-18  5:26 [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv fei.yang
2022-03-18  6:42 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: avoid concurrent writes to aux_inv (rev7) Patchwork
2022-03-18 14:38 ` Tvrtko Ursulin [this message]
2022-03-18 18:12   ` [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv Yang, Fei
  -- strict thread matches above, loose matches on Subject: below --
2022-03-28 17:16 fei.yang
2022-03-29  7:51 ` Tvrtko Ursulin
2022-03-28  3:16 fei.yang
2022-03-28  8:37 ` Tvrtko Ursulin
2022-03-28 17:58   ` Yang, Fei
2022-03-18 18:08 fei.yang
2022-03-21 13:41 ` Tvrtko Ursulin
2022-03-18  5:12 fei.yang
2022-03-04 22:14 fei.yang
2022-03-16  4:43 ` Summers, Stuart
2022-03-16  5:54   ` Yang, Fei
2022-03-16  7:19     ` Yang, Fei
2022-03-16 10:03 ` Tvrtko Ursulin
2022-03-16 18:25   ` Yang, Fei
2022-03-04 22:04 fei.yang
2022-03-02 18:26 fei.yang
2022-03-02 20:50 ` Chris Wilson
2022-02-26  7:11 fei.yang
2022-02-26  1:50 fei.yang

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=8d283c4b-6f16-a235-7c57-ad8a67252ca9@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fei.yang@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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