Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

             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