Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Mon, Apr 03, 2023 at 09:35:32AM -0700, Matt Roper wrote:
> On Mon, Apr 03, 2023 at 07:02:08PM +0300, Ville Syrjälä wrote:
> > On Fri, Mar 31, 2023 at 11:38:30PM -0700, fei.yang@intel.com wrote:
> > > From: Fei Yang <fei.yang@intel.com>
> > > 
> > > To comply with the design that buffer objects shall have immutable
> > > cache setting through out its life cycle, {set, get}_caching ioctl's
> > > are no longer supported from MTL onward. With that change caching
> > > policy can only be set at object creation time. The current code
> > > applies a default (platform dependent) cache setting for all objects.
> > > However this is not optimal for performance tuning. The patch extends
> > > the existing gem_create uAPI to let user set PAT index for the object
> > > at creation time.
> > 
> > This is missing the whole justification for the new uapi.
> > Why is MOCS not sufficient?
> 
> PAT and MOCS are somewhat related, but they're not the same thing.  The
> general direction of the hardware architecture recently has been to
> slowly dumb down MOCS and move more of the important memory/cache
> control over to the PAT instead.  On current platforms there is some
> overlap (and MOCS has an "ignore PAT" setting that makes the MOCS "win"
> for the specific fields that both can control), but MOCS doesn't have a
> way to express things like snoop/coherency mode (on MTL), or class of
> service (on PVC).  And if you check some of the future platforms, the
> hardware design starts packing even more stuff into the PAT (not just
> cache behavior) which will never be handled by MOCS.

Sigh. So the hardware designers screwed up MOCS yet again and
instead of getting that fixed we are adding a new uapi to work
around it?

The IMO sane approach (which IIRC was the situation for a few
platform generations at least) is that you just shove the PAT
index into MOCS (or tell it to go look it up from the PTE).
Why the heck did they not just stick with that?

> 
> Also keep in mind that MOCS generally applies at the GPU instruction
> level; although a lot of instructions have a field to provide a MOCS
> index, or can use a MOCS already associated with a surface state, there
> are still some that don't. PAT is the source of memory access
> characteristics for anything that can't provide a MOCS directly.

So what are the things that don't have MOCS and where we need
some custom cache behaviour, and we already know all that at
buffer creation time?

-- 
Ville Syrjälä
Intel