Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: Ayaz A Siddiqui <ayaz.siddiqui@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
Date: Thu, 9 Sep 2021 18:09:55 +0300	[thread overview]
Message-ID: <YTojw4z1JkfBoI+q@intel.com> (raw)
In-Reply-To: <20210909150002.GA461228@mdroper-desk1.amr.corp.intel.com>

On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 07:29:33AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 04:58:50PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 07, 2021 at 11:19:29AM -0700, Matt Roper wrote:
> > > > > On Tue, Sep 07, 2021 at 08:41:06PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Sep 07, 2021 at 10:27:28AM -0700, Matt Roper wrote:
> > > > > > > On Tue, Sep 07, 2021 at 10:46:39PM +0530, Ayaz A Siddiqui wrote:
> > > > > > > > MOCS table of TGL/RKL has MOCS[1] set to L3_UC.
> > > > > > > > While for other gen12 devices we need to set MOCS[1] as L3_WB,
> > > > > > > > So adding a new MOCS table for other gen 12 devices eg. ADL.
> > > > > > > > 
> > > > > > > > Fixes: cfbe5291a189 ("drm/i915/gt: Initialize unused MOCS entries with device specific values")
> > > > > > > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > > > > > > Signed-off-by: Ayaz A Siddiqui <ayaz.siddiqui@intel.com>
> > > > > > > 
> > > > > > > Yep, we overlooked that the TGL table still had an explicit entry for
> > > > > > > I915_MOCS_PTE and wasn't just using an implicit 'unused_entries' lookup
> > > > > > > for MOCS[1].  The new table is the same as the TGL table, just with
> > > > > > > I915_MOCS_PTE (1) removed.
> > > > > > 
> > > > > > And just how are people planning on handling display cacheability
> > > > > > control without a PTE MOCS entry? Is Mesa/etc. already making all
> > > > > > external bos uncached on these platforms just in case we might
> > > > > > scan out said bo?
> > > > > 
> > > > > MOCS entry 1 has never been considered a valid MOCS table entry on gen12
> > > > > platforms (despite the old #define, it's not actually related to PTE,
> > > > > display, etc. anymore).
> > > > 
> > > > So can someone finally explain to me how we're supposed to cache
> > > > anything that might become a scanout buffer later (eg. window system
> > > > buffers)? Or are we just making everything like that UC now, and is
> > > > everyone happy with that? Is userspace actually following that?
> > > 
> > > Table entry #1 has never had anything to do with scanout on gen12+.  I
> > > would assume that UMDs are either using the display entry in the MOCS
> > > table (which is 61 on gen12+) or some other UC entry.
> > 
> > If 61 is meant to to be the new PTE entry wy hasn't it been defines as
> > such in the code? And I know for a fact that userspace (Mesa) is not
> 
> There is no "PTE" entry anymore.  But 61 is already documented as
> "displayable" in both the spec and the code:
> 
>         /* HW Special Case (Displayable) */                                      
>         MOCS_ENTRY(61,                             

Why is it called a "HW special case"? I don't think there's any hw
magic in there?

And why aren't we setting it to PTE to get some cacheability for
window back buffers and such?

> 
> > using entry 61. I think there is a massive communication gap here
> > where everyone just seems to assume the other side is doing something.
> > 
> > Could someone actually come up with a clear abi definition for this
> > and get all the stakeholders to sign off on it?
> 
> The agreement between the i915 team, various userspace teams, Windows
> driver team, hardware architects, software architects, and bspec writers
> was just completed; that's what triggered the kernel updates here (and
> I'm guessing is triggering similar work on the UMD side).  It's also why
> we held off on removing the force_probe flag on ADL until now since we
> couldn't consider enablement of the platform complete until the
> agreement and definitions here was finalized.

Can we get that agreement visible on the mailing list? Since MOCS is
abi I don't see why we shouldn't follow the normal abi rules for these,
ie. post to dri-devel, get acks from relevant people, links to agreed
userspace changes, etc.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2021-09-09 15:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 17:16 [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL Ayaz A Siddiqui
2021-09-07 17:27 ` Matt Roper
2021-09-07 17:41   ` Ville Syrjälä
2021-09-07 18:19     ` Matt Roper
2021-09-09 13:58       ` Ville Syrjälä
2021-09-09 14:29         ` Matt Roper
2021-09-09 14:39           ` Ville Syrjälä
2021-09-09 15:00             ` Matt Roper
2021-09-09 15:09               ` Ville Syrjälä [this message]
2021-09-09 17:15                 ` Matt Roper
2021-09-09 17:20                   ` Matt Roper
2021-09-09 17:42                   ` Ville Syrjälä
2021-09-09 18:14                     ` Matt Roper
2021-09-09 19:59                       ` Ville Syrjälä
2021-09-09 20:33                         ` Matt Roper
2021-09-09 21:28                           ` Ville Syrjälä
2021-09-07 20:55 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-09-07 21:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-09-08  0:41 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-09-08  2:40   ` Matt Roper

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=YTojw4z1JkfBoI+q@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=ayaz.siddiqui@intel.com \
    --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