All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Souza, Jose" <jose.souza@intel.com>
To: "Roper, Matthew D" <matthew.d.roper@intel.com>
Cc: "De Marchi, Lucas" <lucas.demarchi@intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH v2] drm/xe: Add fake workaround to maintain backward compatible in MI_BATCH_BUFFER_START
Date: Mon, 30 Jan 2023 18:04:25 +0000	[thread overview]
Message-ID: <7c9f39e8eb4ad81926af9b91f45509a5a5a9d347.camel@intel.com> (raw)
In-Reply-To: <Y9f7O86ki5W4Qv1C@mdroper-desk1.amr.corp.intel.com>

On Mon, 2023-01-30 at 09:15 -0800, Matt Roper wrote:
> On Mon, Jan 30, 2023 at 08:17:23AM -0800, José Roberto de Souza wrote:
> > i915 has the same fake workaround to return MI_BATCH_BUFFER_START
> > nested batch buffer behavior in DG2 and newer platforms to the same
> > behavior as older platforms.
> > 
> > So here cleaning up TGL_NESTED_BB_EN in MI_MODE to disable third level
> > chained batch buffer level.
> 
> I was kind of assuming we'd just drop this setting for the Xe driver.  I
> believe hardware will be removing the option to turn off nested
> batchbuffers in an upcoming platform, so userspace is going to have to
> adapt to the new behavior soon anyway; doing it while moving to a new
> KMD seems like the easiest time to make that happen since the UMDs are
> already updating their programming models.

This would bring even more changes to track when debugging issues in Xe KMD port.
Better do this after Xe KMD is stabilized and with better CI coverage in UMDs and KMDs.

> 
> 
> Matt
> 
> > 
> > v2:
> > - replace IP_VERSION_FOREVER by XE_RTP_END_VERSION_UNDEFINED
> > - move fake workaround to lrc_additional_programming table
> > 
> > Bspec: 45974, 45718
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Cc: Matt Roper <matthew.d.roper@intel.com>
> > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > ---
> >  drivers/gpu/drm/xe/xe_gt.c |  1 +
> >  drivers/gpu/drm/xe/xe_wa.c | 28 ++++++++++++++++++++++++++++
> >  drivers/gpu/drm/xe/xe_wa.h |  1 +
> >  3 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> > index 84a73eeccd297..5d07e1e7bd506 100644
> > --- a/drivers/gpu/drm/xe/xe_gt.c
> > +++ b/drivers/gpu/drm/xe/xe_gt.c
> > @@ -311,6 +311,7 @@ int xe_gt_record_default_lrcs(struct xe_gt *gt)
> >  
> >  		xe_reg_sr_init(&hwe->reg_lrc, "LRC", xe);
> >  		xe_wa_process_lrc(hwe);
> > +		xe_wa_process_lrc_additional_programming(hwe);
> >  
> >  		default_lrc = drmm_kzalloc(&xe->drm,
> >  					   xe_lrc_size(xe, hwe->class),
> > diff --git a/drivers/gpu/drm/xe/xe_wa.c b/drivers/gpu/drm/xe/xe_wa.c
> > index 3325de3edf691..744b7d0982683 100644
> > --- a/drivers/gpu/drm/xe/xe_wa.c
> > +++ b/drivers/gpu/drm/xe/xe_wa.c
> > @@ -288,6 +288,21 @@ static const struct xe_rtp_entry lrc_was[] = {
> >  	{}
> >  };
> >  
> > +static const struct xe_rtp_entry lrc_additional_programming[] = {
> > +	{ XE_RTP_NAME("FakeWaDisableNestedBBMode"),
> > +	  /*
> > +	   * This is a "fake" workaround defined by software to ensure we
> > +	   * maintain reliable, backward-compatible behavior for userspace with
> > +	   * regards to how nested MI_BATCH_BUFFER_START commands are handled.
> > +	   */
> > +	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1255, XE_RTP_END_VERSION_UNDEFINED)),
> > +	  XE_RTP_CLR(RING_MI_MODE(0),
> > +		     TGL_NESTED_BB_EN,
> > +		     XE_RTP_FLAG(MASKED_REG, ENGINE_BASE))
> > +	},
> > +	{}
> > +};
> > +
> >  static const struct xe_rtp_entry register_whitelist[] = {
> >  	{ XE_RTP_NAME("WaAllowPMDepthAndInvocationCountAccessFromUMD, 1408556865"),
> >  	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1200, 1210), ENGINE_CLASS(RENDER)),
> > @@ -362,6 +377,19 @@ void xe_wa_process_lrc(struct xe_hw_engine *hwe)
> >  	xe_rtp_process(lrc_was, &hwe->reg_lrc, hwe->gt, hwe);
> >  }
> >  
> > +/**
> > + * xe_wa_process_lrc_additional_programming - process additional LRC programming
> > + * table
> > + * @hwe: engine instance to process workarounds for
> > + *
> > + * Process additional context programming table for this platform, saving in
> > + * @hwe all the registers changes that need to be applied on context restore.
> > + */
> > +void xe_wa_process_lrc_additional_programming(struct xe_hw_engine *hwe)
> > +{
> > +	xe_rtp_process(lrc_additional_programming, &hwe->reg_lrc, hwe->gt, hwe);
> > +}
> > +
> >  /**
> >   * xe_reg_whitelist_process_engine - process table of registers to whitelist
> >   * @hwe: engine instance to process whitelist for
> > diff --git a/drivers/gpu/drm/xe/xe_wa.h b/drivers/gpu/drm/xe/xe_wa.h
> > index 1a0659690a320..872f3e4ddc73c 100644
> > --- a/drivers/gpu/drm/xe/xe_wa.h
> > +++ b/drivers/gpu/drm/xe/xe_wa.h
> > @@ -12,6 +12,7 @@ struct xe_hw_engine;
> >  void xe_wa_process_gt(struct xe_gt *gt);
> >  void xe_wa_process_engine(struct xe_hw_engine *hwe);
> >  void xe_wa_process_lrc(struct xe_hw_engine *hwe);
> > +void xe_wa_process_lrc_additional_programming(struct xe_hw_engine *hwe);
> >  
> >  void xe_reg_whitelist_process_engine(struct xe_hw_engine *hwe);
> >  void xe_reg_whitelist_apply(struct xe_hw_engine *hwe);
> > -- 
> > 2.39.1
> > 
> 


  reply	other threads:[~2023-01-30 18:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 16:17 [Intel-xe] [PATCH v2] drm/xe: Add fake workaround to maintain backward compatible in MI_BATCH_BUFFER_START José Roberto de Souza
2023-01-30 16:31 ` Lucas De Marchi
2023-01-30 17:15 ` Matt Roper
2023-01-30 18:04   ` Souza, Jose [this message]
2023-01-30 19:27     ` Lucas De Marchi
2023-01-30 19:43       ` Souza, Jose
2023-02-01 21:20         ` Rodrigo Vivi
2023-02-02 14:02           ` Souza, Jose
2023-02-02 23:14             ` Matt Roper
2023-02-06 22:09               ` Rodrigo Vivi
2023-01-31  7:24 ` Jani Nikula
2023-01-31 13:50   ` Souza, Jose
2023-01-31 14:04     ` Jani Nikula
2023-01-31 15:31       ` 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=7c9f39e8eb4ad81926af9b91f45509a5a5a9d347.camel@intel.com \
    --to=jose.souza@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.