Re: [Mesa-dev] [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 01:33:23PM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 10:59:36PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > > > > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > > > > 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
> > > > > > > > > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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?
> > > > >
> > > > > Who is "we" here?
> > > >
> > > > We who care about the performance of the system.
> > > >
> > > > > The MOCS table is a pre-defined set of per-platform
> > > > > magic numbers. The software teams don't get to decide what the values
> > > > > are, we just program the hardware with the per-platform numbers that
> > > > > have been agreed upon as part of a platform-wide stack (everything
> > > > > from
> > > > > low-level firmware to high level userspace should be working from the
>
Re: [Mesa-dev] [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 10:59:36PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> > On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > > > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > > > 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
> > > > > > > > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 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?
> > > >
> > > > Who is "we" here?
> > >
> > > We who care about the performance of the system.
> > >
> > > > The MOCS table is a pre-defined set of per-platform
> > > > magic numbers. The software teams don't get to decide what the values
> > > > are, we just program the hardware with the per-platform numbers that
> > > > have been agreed upon as part of a platform-wide stack (everything from
> > > > low-level firmware to high level userspace should be working from the
> > > > same table, defined in the bspec).
> > >
> > > The magic numbers must be based on something. If that something is
> > > purely Windows behaviour/performance then we might be shooting
> > > ourselves in the foot here.
> >
> > That's not how MOCS
Re: [Mesa-dev] [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > > 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
> > > > > > > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > > > > > > >
> > > > > > > > > > > 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?
> > >
> > > Who is "we" here?
> >
> > We who care about the performance of the system.
> >
> > > The MOCS table is a pre-defined set of per-platform
> > > magic numbers. The software teams don't get to decide what the values
> > > are, we just program the hardware with the per-platform numbers that
> > > have been agreed upon as part of a platform-wide stack (everything from
> > > low-level firmware to high level userspace should be working from the
> > > same table, defined in the bspec).
> >
> > The magic numbers must be based on something. If that something is
> > purely Windows behaviour/performance then we might be shooting
> > ourselves in the foot here.
>
> That's not how MOCS works. The MOCS tables define every meaningful
> combination of settings somewhere in the table. The *types* of settings
> that can be expressed change from platform to platform (e.g.,
> "PAGETABLE" setting simply doesn't exist anymore hardware-wise) so the
> tables themselves differ between platforms and you may need to use
> different indices to get the same behavior
Re: [Mesa-dev] [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > 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
> > > > > > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > > > > > >
> > > > > > > > > > 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?
> >
> > Who is "we" here?
>
> We who care about the performance of the system.
>
> > The MOCS table is a pre-defined set of per-platform
> > magic numbers. The software teams don't get to decide what the values
> > are, we just program the hardware with the per-platform numbers that
> > have been agreed upon as part of a platform-wide stack (everything from
> > low-level firmware to high level userspace should be working from the
> > same table, defined in the bspec).
>
> The magic numbers must be based on something. If that something is
> purely Windows behaviour/performance then we might be shooting
> ourselves in the foot here.
That's not how MOCS works. The MOCS tables define every meaningful
combination of settings somewhere in the table. The *types* of settings
that can be expressed change from platform to platform (e.g.,
"PAGETABLE" setting simply doesn't exist anymore hardware-wise) so the
tables themselves differ between platforms and you may need to use
different indices to get the same behavior between platforms. But if
you're actually paying attention to the tables and choosing the right
entries, you're not going to leave any performance on the table.
>
> >
> > Once we know what the per-platform magic numbers are, we're supposed to
> > pick the table entry that
Re: [Mesa-dev] [Intel-gfx] [PATCH] drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > 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
> > > > > > > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > > > > >
> > > > > > > > > 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?
>
> Who is "we" here?
We who care about the performance of the system.
> The MOCS table is a pre-defined set of per-platform
> magic numbers. The software teams don't get to decide what the values
> are, we just program the hardware with the per-platform numbers that
> have been agreed upon as part of a platform-wide stack (everything from
> low-level firmware to high level userspace should be working from the
> same table, defined in the bspec).
The magic numbers must be based on something. If that something is
purely Windows behaviour/performance then we might be shooting
ourselves in the foot here.
>
> Once we know what the per-platform magic numbers are, we're supposed to
> pick the table entry that matches the behavior we're trying to
> accomplish. If you want some specific level of cacheability, then you
> select a table row that gives you that. Maybe 61 isn't the best
> setting, I don't know; userspace can pick whichever defined setting is
> actually best, using the data from the table. But table row #1 is
> already well-documented as reserved/dontuse across the full stack; the
> fact that row #1 had values similar to PTE on Icelake hardware doesn't
> carry forward to any post-gen11 platform.
The only way you can get LLC cacheability for an external BO (window
back buffers and such) is by using a MOCS entry that directs the hardware
to consult the PTEs. Otherwise the client doing the rendering would have
to know ahead of time whether the buffer is going to be directly scanned
out by the compositor or not, for which there is no protocol in
X
