Re: [Intel-gfx] [PATCH] drm/i915: Set all undefined MOCS entries to follow PTE

[Francisco Jerez <currojerez@riseup.net>]

[-- Attachment #1.1: Type: text/plain, Size: 2012 bytes --]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> On Thu, May 04, 2017 at 10:56:54AM -0700, Francisco Jerez wrote:
>> David Weinehall <david.weinehall@linux.intel.com> writes:
>> 
>> > On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
>> >> A good default for garbage entries from the user is to follow the
>> >> default setting of the object (i.e. the PTE). Currently they use the
>> >> uncached entry, and now the only way to accidentally hit uncached
>> >> performance is via explicit use of the uncached MOCS or setting the
>> >> object to uncached. Note that these entries are currently undefined in
>> >> the ABI and we reserve the right to change them. We originally chose
>> >> uncached to eliminate any problem with reducing the caching level in
>> >> future, but the object is a much better definition of the minimum
>> >> caching level.
>> >> 
>> 
>> NAK.  The reason for the default being UC is that it's the only setting
>> that guarantees full forwards compatibility with any other entry that
>> might be added in the future.  If you default to PTE on (e)LLC and WB on
>> L3, userspace will no longer be able to use any newly introduced entry
>> with stricter coherency guarantees than that (e.g. any L3-uncached
>> entry) in a backwards-compatible way.  Attempting to do so may break
>> memory coherency assumptions of the application and lead to misrendering
>> when run on older kernel versions (which to my judgment is a scarier
>> failure mode than reduced performance).
>
> You can't use a weaker coherency model in mocs than that specified for
> the object as you can't control other uses of the object (even just
> memory pressure will break your assumptions).

Exactly, but you can use a stronger coherency model than the application
requested, which is why falling back to UC should generally work for
unknown entries but falling back to PTE+WB isn't guaranteed to.

> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 212 bytes --]