From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Performed deferred clflush inside set-cache-level
Date: Tue, 13 Jan 2015 22:23:55 +0200 [thread overview]
Message-ID: <20150113202355.GM10649@intel.com> (raw)
In-Reply-To: <1421155972-4896-1-git-send-email-chris@chris-wilson.co.uk>
On Tue, Jan 13, 2015 at 01:32:52PM +0000, Chris Wilson 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>
> ---
> 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;
Hmm. This would mark the cache dirty even when just moving to the CPU read
domain. A subsequent set_cache_level might then flush a bit needlessly.
But maybe that's rare enoguh to ignore?
I suppose we could follow this up with another patch to fix
kms_pwrite_crc using cache_dirty as well. But actually that would
require doing the clflush even when the cache_level didn't change,
which might aggravate the needless flushing issue somewhat. Or
perhaps we should just add another cache_dirty dependent flush to
i915_gem_object_pin_to_display_plane() to deal with that particular
problem?
> 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
--
Ville Syrjälä
Intel OTC
_______________________________________________
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 20:23 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
2015-01-13 20:23 ` Ville Syrjälä [this message]
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=20150113202355.GM10649@intel.com \
--to=ville.syrjala@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.