From: Ben Widawsky <benjamin.widawsky@intel.com>
To: Intel GFX <intel-gfx@lists.freedesktop.org>
Cc: Ben Widawsky <ben@bwidawsk.net>,
Ben Widawsky <benjamin.widawsky@intel.com>
Subject: [PATCH 5/6] drm/i915: Extract checking the necessity of flush
Date: Mon, 9 Feb 2015 13:54:18 -0800 [thread overview]
Message-ID: <1423518859-6199-6-git-send-email-benjamin.widawsky@intel.com> (raw)
In-Reply-To: <1423518859-6199-1-git-send-email-benjamin.widawsky@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
drivers/gpu/drm/i915/i915_gem.c | 53 +++++++++++++++++++++++------------------
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5bfb332..4d5a69d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -69,6 +69,35 @@ static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
return obj->pin_display;
}
+static bool
+is_cpu_flush_required(struct drm_i915_gem_object *obj)
+{
+ /* If we don't have a page list set up, then we're not pinned
+ * to GPU, and we can ignore the cache flush because it'll happen
+ * again at bind time.
+ */
+ if (obj->pages == NULL)
+ return false;
+
+ /*
+ * Stolen memory is always coherent with the GPU as it is explicitly
+ * marked as wc by the system, or the system is cache-coherent.
+ */
+ if (obj->stolen || obj->phys_handle)
+ return false;
+
+ /* If the GPU is snooping the contents of the CPU cache,
+ * we do not need to manually clear the CPU cache lines. However,
+ * the caches are only snooped when the render cache is
+ * flushed/invalidated. As we always have to emit invalidations
+ * and flushes when moving into and out of the RENDER domain, correct
+ * snooping behaviour occurs naturally as the result of our domain
+ * tracking.
+ */
+ return !cpu_cache_is_coherent(obj->base.dev, obj->cache_level);
+}
+
+
static inline void i915_gem_object_fence_lost(struct drm_i915_gem_object *obj)
{
if (obj->tiling_mode)
@@ -3615,29 +3644,7 @@ bool
i915_gem_clflush_object(struct drm_i915_gem_object *obj,
bool force)
{
- /* If we don't have a page list set up, then we're not pinned
- * to GPU, and we can ignore the cache flush because it'll happen
- * again at bind time.
- */
- if (obj->pages == NULL)
- return false;
-
- /*
- * Stolen memory is always coherent with the GPU as it is explicitly
- * marked as wc by the system, or the system is cache-coherent.
- */
- if (obj->stolen || obj->phys_handle)
- return false;
-
- /* If the GPU is snooping the contents of the CPU cache,
- * we do not need to manually clear the CPU cache lines. However,
- * the caches are only snooped when the render cache is
- * flushed/invalidated. As we always have to emit invalidations
- * and flushes when moving into and out of the RENDER domain, correct
- * 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 && !is_cpu_flush_required(obj)) {
obj->cache_dirty = true;
return false;
}
--
2.3.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-02-09 21:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 21:54 [PATCH 0/6] Prefer wbinvd() where appropriate Ben Widawsky
2015-02-09 21:54 ` [PATCH 1/6] drm/i915: Remove the useless flush_chipset Ben Widawsky
2015-02-10 9:18 ` Chris Wilson
2015-02-09 21:54 ` [PATCH 2/6] drm/i915: Pass eb_vmas to execbuffer implementations Ben Widawsky
2015-02-10 9:19 ` Chris Wilson
2015-02-09 21:54 ` [PATCH 3/6] drm/i915: Opportunistically reduce flushing at execbuf Ben Widawsky
2015-02-10 9:21 ` Chris Wilson
2015-02-09 21:54 ` [PATCH 4/6] drm/i915: Add debugfs knobs for wbinvd threshold Ben Widawsky
2015-02-09 21:54 ` Ben Widawsky [this message]
2015-02-09 21:54 ` [PATCH 6/6] drm/i915: obey wbinvd threshold in more places Ben Widawsky
2015-02-10 9:28 ` Chris Wilson
2015-02-10 20:49 ` shuang.he
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=1423518859-6199-6-git-send-email-benjamin.widawsky@intel.com \
--to=benjamin.widawsky@intel.com \
--cc=ben@bwidawsk.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox