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
next prev parent 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 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.