From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Performed deferred clflush inside set-cache-level
Date: Tue, 13 Jan 2015 17:21:50 +0200 [thread overview]
Message-ID: <87387e3dv5.fsf@intel.com> (raw)
In-Reply-To: <1421155972-4896-1-git-send-email-chris@chris-wilson.co.uk>
On Tue, 13 Jan 2015, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Currently we are hitting the WARN inside
> i915_gem_object_set_cache_level() as we can now have an unbound object
> in the GTT write domain (due to 43566dedde54f9 "drm/i915: Broaden
> application of set-domain(GTT)"). To avoid the warning, we need to track
> when we elided the clflush on a cacheable object and then evict the
> cache for the object when we move the object out of a cacheable domain.
>
> Reported-by: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
I saw the warn when unplugging DP from a DP+eDP configuration.
Tested-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 32 +++++++++-----------------------
> 2 files changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bf18a5238887..7070482000cd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1998,6 +1998,7 @@ struct drm_i915_gem_object {
> */
> unsigned long gt_ro:1;
> unsigned int cache_level:3;
> + unsigned int cache_dirty:1;
>
> unsigned int has_dma_mapping:1;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9bafe50d3df7..aa089e7c31bf 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3639,11 +3639,14 @@ i915_gem_clflush_object(struct drm_i915_gem_object *obj,
> * snooping behaviour occurs naturally as the result of our domain
> * tracking.
> */
> - if (!force && cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
> + if (!force && cpu_cache_is_coherent(obj->base.dev, obj->cache_level)) {
> + obj->cache_dirty = true;
> return false;
> + }
>
> trace_i915_gem_object_clflush(obj);
> drm_clflush_sg(obj->pages);
> + obj->cache_dirty = false;
>
> return true;
> }
> @@ -3826,28 +3829,11 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
> vma->node.color = cache_level;
> obj->cache_level = cache_level;
>
> - if (cpu_write_needs_clflush(obj)) {
> - u32 old_read_domains, old_write_domain;
> -
> - /* If we're coming from LLC cached, then we haven't
> - * actually been tracking whether the data is in the
> - * CPU cache or not, since we only allow one bit set
> - * in obj->write_domain and have been skipping the clflushes.
> - * Just set it to the CPU cache for now.
> - */
> - i915_gem_object_retire(obj);
> - WARN_ON(obj->base.write_domain & ~I915_GEM_DOMAIN_CPU);
> -
> - old_read_domains = obj->base.read_domains;
> - old_write_domain = obj->base.write_domain;
> -
> - obj->base.read_domains = I915_GEM_DOMAIN_CPU;
> - obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> -
> - trace_i915_gem_object_change_domain(obj,
> - old_read_domains,
> - old_write_domain);
> - }
> + if (obj->cache_dirty &&
> + obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
> + cpu_write_needs_clflush(obj) &&
> + i915_gem_clflush_object(obj, true))
> + i915_gem_chipset_flush(obj->base.dev);
>
> return 0;
> }
> --
> 2.1.4
>
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-01-13 15:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 13:32 [PATCH] drm/i915: Performed deferred clflush inside set-cache-level Chris Wilson
2015-01-13 15:21 ` Jani Nikula [this message]
2015-01-13 20:23 ` Ville Syrjälä
2015-01-13 20:34 ` Chris Wilson
2015-01-13 21:12 ` shuang.he
2015-01-14 19:46 ` Daniel Vetter
2015-01-15 8:54 ` Chris Wilson
2015-01-21 9:31 ` Chris Wilson
2015-01-21 12:26 ` Daniel Vetter
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=87387e3dv5.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.