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)
next prev 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