From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Yang, Fei" <fei.yang@intel.com>,
"Intel-gfx@lists.freedesktop.org"
<Intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Cc: "Roper, Matthew D" <matthew.d.roper@intel.com>,
Chris Wilson <chris.p.wilson@linux.intel.com>
Subject: Re: [Intel-gfx] [RFC 2/2] drm/i915: Remove PAT hack from i915_gem_object_can_bypass_llc
Date: Fri, 14 Jul 2023 11:11:30 +0100 [thread overview]
Message-ID: <999114a1-e334-5de9-065e-9a5d3801e23e@linux.intel.com> (raw)
In-Reply-To: <BYAPR11MB25673D3525AF7C5A5FFB44129A34A@BYAPR11MB2567.namprd11.prod.outlook.com>
On 14/07/2023 06:43, Yang, Fei wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> According to the comment in i915_gem_object_can_bypass_llc the
>> purpose of the function is to return false if the platform/object
>> has a caching mode where GPU can bypass the LLC.
>>
>> So far the only platforms which allegedly can do this are Jasperlake
>> and Elkhartlake, and that via MOCS (not PAT).
>>
>> Instead of blindly assuming that objects where userspace has set the
>> PAT index can (bypass the LLC), question is is there a such PAT index
>> on a platform. Probably starting with Meteorlake since that one is the
>> only one where set PAT extension can be currently used. Or if there is
>> a MOCS entry which can achieve the same thing on Meteorlake.
>>
>> If there is such PAT, now that i915 can be made to understand them
>> better, we can make the check more fine grained. Or if there is a MOCS
>> entry then we probably should apply the blanket IS_METEORLAKE condition.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
>> Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
>> Cc: Fei Yang <fei.yang@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Matt Roper <matthew.d.roper@intel.com>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 ------
>> 1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> index 33a1e97d18b3..1e34171c4162 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -229,12 +229,6 @@ bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj)
>> if (!(obj->flags & I915_BO_ALLOC_USER))
>> return false;
>>
>> - /*
>> - * Always flush cache for UMD objects at creation time.
>> - */
>> - if (obj->pat_set_by_user)
>
> I'm afraid this is going to break MESA. Can we run MESA tests with this patch?
I can't, but question is why it would break Mesa which would need a nice
comment here?
For instance should the check be IS_METEORLAKE?
Or should it be "is wb" && "not has 1-way coherent"?
Or both?
Or, given how Meteorlake does not have LLC, how can anything bypass it
there? Or is it about snooping on Meteorlake and how?
Regards,
Tvrtko
>
>> /*
>> * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
>> * possible for userspace to bypass the GTT caching bits set by the
>> --
>> 2.39.2
next prev parent reply other threads:[~2023-07-14 10:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 15:27 [Intel-gfx] [RFC 1/2] drm/i915: Refactor PAT/object cache handling Tvrtko Ursulin
2023-07-13 15:27 ` [Intel-gfx] [RFC 2/2] drm/i915: Remove PAT hack from i915_gem_object_can_bypass_llc Tvrtko Ursulin
2023-07-14 5:43 ` Yang, Fei
2023-07-14 10:11 ` Tvrtko Ursulin [this message]
2023-07-14 17:38 ` Yang, Fei
2023-07-15 0:20 ` Matt Roper
2023-07-17 10:55 ` Tvrtko Ursulin
2023-07-13 19:38 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling Patchwork
2023-07-13 19:38 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-07-13 19:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-14 0:42 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-07-14 5:36 ` [Intel-gfx] [RFC 1/2] " Yang, Fei
2023-07-14 10:08 ` Tvrtko Ursulin
2023-07-14 18:00 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling (rev2) Patchwork
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=999114a1-e334-5de9-065e-9a5d3801e23e@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=chris.p.wilson@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fei.yang@intel.com \
--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