From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Intel-gfx@lists.freedesktop.org,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
Imre Deak <imre.deak@intel.com>
Subject: Re: [PATCH] drm/i915: Avoid snooping with userptr where not supported
Date: Tue, 1 Mar 2016 17:21:49 +0000 [thread overview]
Message-ID: <56D5CFAD.2030309@linux.intel.com> (raw)
In-Reply-To: <20160301171442.GF29985@nuc-i3427.alporthouse.com>
On 01/03/16 17:14, Chris Wilson wrote:
> On Tue, Mar 01, 2016 at 04:29:35PM +0000, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> commit e5756c10d841ddb448293c849392f3d6b809561f
>> Author: Imre Deak <imre.deak@intel.com>
>> Date: Fri Aug 14 18:43:30 2015 +0300
>>
>> drm/i915/bxt: don't allow cached GEM mappings on A stepping
>>
>> Added an exception of disallowing snooping for Broxton A
>> stepping hardware but userptr was still enabling it regardless.
>>
>> Move the check to HAS_SNOOP now that it is used from multiple
>> call sites and use it.
>>
>> Idea is that userspace which relies on userptr snooping, for
>> example for fine grained buffered SVM, can query the caching
>> mode on a created userptr object to determine whether coherency
>> is supported or not.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Imre Deak <imre.deak@intel.com>
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> drivers/gpu/drm/i915/i915_gem.c | 2 +-
>> drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
>> 3 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> index 671295523317..73f0db17b990 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2629,6 +2629,7 @@ struct drm_i915_cmd_table {
>> #define HAS_LLC(dev) (INTEL_INFO(dev)->has_llc)
>> #define HAS_WT(dev) ((IS_HASWELL(dev) || IS_BROADWELL(dev)) && \
>> __I915__(dev)->ellc_size)
>> +#define HAS_SNOOP(dev) (!IS_BXT_REVID(dev, 0, BXT_REVID_A1))
>> #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
>>
>> #define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> index 3d31d3ac589e..1c6e8fb9d392 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -3949,7 +3949,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>> * cacheline, whereas normally such cachelines would get
>> * invalidated.
>> */
>> - if (IS_BXT_REVID(dev, 0, BXT_REVID_A1))
>> + if (!HAS_SNOOP(dev))
>
> if (!HAS_LLC && !HAS_SNOOP)
>
> and HAS_SNOOP should be true for everything that is not llc, with the
> exception above. So make a dev_info->has_snoop feature bit (or
> uses_snoop?) and then clear the copy inside the struct for the special
> case.
Sure I can do that, but isn't it the same as this patch? Unless
something with LLC and no snooping appears?
>> return -ENODEV;
>>
>> level = I915_CACHE_LLC;
>> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
>> index 4b09c840d493..48aaff019b42 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
>> @@ -782,7 +782,7 @@ i915_gem_userptr_ioctl(struct drm_device *dev, void *data, struct drm_file *file
>>
>> drm_gem_private_object_init(dev, &obj->base, args->user_size);
>> i915_gem_object_init(obj, &i915_gem_userptr_ops);
>> - obj->cache_level = I915_CACHE_LLC;
>> + obj->cache_level = HAS_SNOOP(dev) ? I915_CACHE_LLC : I915_CACHE_NONE;
>
> This should be
> if (!HAS_SNOOP && !HAS_LLC)
> return -ENODEV;
>
> as we can not support a coherent pointer shared between memory and the GPU
> in this case.
Hm interesting, why not? I mean, what is the difference compared to
normal BOs which will be uncached on !LLC?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-01 17:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 16:29 [PATCH] drm/i915: Avoid snooping with userptr where not supported Tvrtko Ursulin
2016-03-01 16:56 ` ✗ Fi.CI.BAT: failure for " Patchwork
2016-03-01 17:14 ` [PATCH] " Chris Wilson
2016-03-01 17:21 ` Tvrtko Ursulin [this message]
2016-03-01 17:36 ` Chris Wilson
2016-03-02 10:16 ` [PATCH v2] " Tvrtko Ursulin
2016-03-02 11:30 ` Chris Wilson
2016-03-02 12:10 ` [PATCH v3] " Tvrtko Ursulin
2016-03-02 10:55 ` ✗ Fi.CI.BAT: warning for drm/i915: Avoid snooping with userptr where not supported (rev2) Patchwork
2016-03-02 12:31 ` ✗ Fi.CI.BAT: failure for drm/i915: Avoid snooping with userptr where not supported (rev3) Patchwork
2016-03-02 13:49 ` Tvrtko Ursulin
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=56D5CFAD.2030309@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=chris@chris-wilson.co.uk \
--cc=imre.deak@intel.com \
--cc=tvrtko.ursulin@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