From: Kenneth Graunke <kenneth@whitecape.org>
To: intel-gfx@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org, Kenneth Graunke <kenneth@whitecape.org>
Subject: [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.
Date: Fri, 10 Mar 2017 17:14:32 -0800 [thread overview]
Message-ID: <20170311011432.28962-1-kenneth@whitecape.org> (raw)
On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has
had the surprising behavior of doing a synchronized GTT mapping.
This is obviously not what the user of the API wanted.
Eric left a comment indicating a valid concern: if the CPU and GPU
caches are incoherent, we don't keep track of where the user last
mapped the buffer, and what caches might contain relevant data.
Modern Atom systems still don't have LLC, but they do offer snooping,
which effectively makes the caches coherent. The kernel appears to
set up the PTE/PPAT to enable snooping for everything where the cache
level is not I915_CACHE_NONE. As far as I know, only scanout buffers
are marked as uncached.
Any buffers used by scanout should be flagged as non-reusable with
drm_intel_bo_disable_reuse(), prime export, or flink. So, we can
assume that any reusable buffer should be snooped.
This patch enables unsynchronized mappings for reusable buffers
on all Gen6+ hardware (which have either LLC or snooping).
On Broxton, this improves the performance of Unigine Valley 1.0
on Low settings at 1280x720 by about 45%, and Unigine Heaven 4.0
(same settings) by about 53%.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: mesa-dev@lists.freedesktop.org
---
intel/intel_bufmgr_gem.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
It looks like Mesa and Beignet are the only callers of this function
(SNA and Anvil don't use libdrm, UXA and vaapi don't use this function.)
This passed our full barrage of Piglit/dEQP/GLCTS/GLESCTS testing.
gnome-shell still works, as does Unigine, and GLBenchmark.
I haven't tested any OpenCL workloads.
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index e260f2dc..f53f1fcc 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1630,9 +1630,7 @@ int
drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
-#ifdef HAVE_VALGRIND
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
-#endif
int ret;
/* If the CPU cache isn't coherent with the GTT, then use a
@@ -1641,8 +1639,12 @@ drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo)
* terms of drm_intel_bo_map vs drm_intel_gem_bo_map_gtt, so
* we would potentially corrupt the buffer even when the user
* does reasonable things.
+ *
+ * The caches are coherent on LLC platforms or snooping is enabled
+ * for the BO. The kernel enables snooping for non-scanout (reusable)
+ * buffers on modern non-LLC systems.
*/
- if (!bufmgr_gem->has_llc)
+ if (bufmgr_gem->gen < 6 || !bo_gem->reusable)
return drm_intel_gem_bo_map_gtt(bo);
pthread_mutex_lock(&bufmgr_gem->lock);
--
2.12.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next reply other threads:[~2017-03-11 1:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-11 1:14 Kenneth Graunke [this message]
2017-03-12 13:21 ` [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping Chris Wilson
2017-03-12 17:19 ` David Weinehall
2017-03-13 13:43 ` [Intel-gfx] " Chris Wilson
2017-03-12 22:07 ` Kenneth Graunke
2017-03-13 8:21 ` Daniel Vetter
2017-03-14 10:48 ` Eero Tamminen
2017-03-14 14:25 ` [Mesa-dev] " Eero Tamminen
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=20170311011432.28962-1-kenneth@whitecape.org \
--to=kenneth@whitecape.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mesa-dev@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