mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: intel-gfx <intel-gfx@lists.freedesktop.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: [PATCH 07/13] drm/i915: move clflushing into shmem_pread
Date: Sun,  6 Nov 2011 20:13:54 +0100	[thread overview]
Message-ID: <1320606840-21132-8-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1320606840-21132-1-git-send-email-daniel.vetter@ffwll.ch>

This is obviously gonna slow down pread. But for a half-way realistic
micro-benchmark, it doesn't matter: Non-broken userspace reads back
data from the gpu once before the gpu again dirties it.

So all this ranged clflush tracking is just a waste of time.

No pread performance change (neglecting the dumb benchmark of
constantly reading the same data) measured.

As an added bonus, this avoids clflush on read on coherent objects.
Which means that partial preads on snb are now roughly 4x as fast.
This will be usefull for e.g. the libva encoder - when I finally get
around to fix that up.

v2: Properly sync with the gpu on LLC machines.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem.c |   26 ++++++++++++++++++++------
 1 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5eec933..0e9cc81 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -342,12 +342,25 @@ i915_gem_shmem_pread(struct drm_device *dev,
 	int shmem_page_offset, page_length, ret;
 	int obj_do_bit17_swizzling, page_do_bit17_swizzling;
 	int hit_slowpath = 0;
+	int needs_clflush = 0;
 
 	user_data = (char __user *) (uintptr_t) args->data_ptr;
 	remain = args->size;
 
 	obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
 
+	if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
+		/* If we're not in the cpu read domain, set ourself into the gtt
+		 * read domain and manually flush cachelines (if required). This
+		 * optimizes for the case when the gpu will dirty the data
+		 * anyway again before the next pread happens. */
+		if (obj->cache_level == I915_CACHE_NONE)
+			needs_clflush = 1;
+		ret = i915_gem_object_set_to_gtt_domain(obj, false);
+		if (ret)
+			return ret;
+	}
+
 	offset = args->offset;
 
 	while (remain > 0) {
@@ -374,6 +387,9 @@ i915_gem_shmem_pread(struct drm_device *dev,
 
 		if (!obj_do_bit17_swizzling || !page_do_bit17_swizzling) {
 			vaddr = kmap_atomic(page);
+			if (needs_clflush)
+				drm_clflush_virt_range(vaddr + shmem_page_offset,
+						       page_length);
 			ret = __copy_to_user_inatomic(user_data,
 						      vaddr + shmem_page_offset,
 						      page_length);
@@ -387,6 +403,10 @@ i915_gem_shmem_pread(struct drm_device *dev,
 		mutex_unlock(&dev->struct_mutex);
 
 		vaddr = kmap(page);
+		if (needs_clflush)
+			drm_clflush_virt_range(vaddr + shmem_page_offset,
+					       page_length);
+
 		if (obj_do_bit17_swizzling && page_do_bit17_swizzling)
 			ret = __copy_to_user_swizzled(user_data,
 						      vaddr, shmem_page_offset,
@@ -467,12 +487,6 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
 
 	trace_i915_gem_object_pread(obj, args->offset, args->size);
 
-	ret = i915_gem_object_set_cpu_read_domain_range(obj,
-							args->offset,
-							args->size);
-	if (ret)
-		goto out;
-
 	ret = i915_gem_shmem_pread(dev, obj, args, file);
 
 out:
-- 
1.7.6.4


  parent reply	other threads:[~2011-11-06 19:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-06 19:13 [PATCH 00/13] pwrite/pread rework Daniel Vetter
2011-11-06 19:13 ` [PATCH 01/13] drm/i915: fall through pwrite_gtt_slow to the shmem slow path Daniel Vetter
2011-11-21  3:09   ` [Intel-gfx] " Ben Widawsky
2011-11-21 10:20     ` Chris Wilson
2011-11-06 19:13 ` [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user Daniel Vetter
2011-11-21  5:56   ` [Intel-gfx] " Ben Widawsky
2011-11-21 16:02     ` Daniel Vetter
2011-11-21 17:55       ` Ben Widawsky
2011-11-21 18:43         ` Ben Widawsky
2011-11-06 19:13 ` [PATCH 03/13] drm/i915: rewrite shmem_pread_slow to use copy_to_user Daniel Vetter
2011-11-06 19:13 ` [PATCH 04/13] drm/i915: merge shmem_pwrite slow&fast-path Daniel Vetter
2011-11-06 19:13 ` [PATCH 05/13] drm/i915: merge shmem_pread slow&fast-path Daniel Vetter
2011-11-06 19:13 ` [PATCH 06/13] drm: add helper to clflush a virtual address range Daniel Vetter
2011-11-21 19:46   ` [Intel-gfx] " Ben Widawsky
2011-11-06 19:13 ` Daniel Vetter [this message]
2011-11-06 19:13 ` [PATCH 08/13] drm/i915: kill ranged cpu read domain support Daniel Vetter
2011-11-06 19:13 ` [PATCH 09/13] drm/i915: don't use gtt_pwrite on LLC cached objects Daniel Vetter
2011-11-06 21:16   ` Chris Wilson
2011-11-06 22:19     ` Daniel Vetter
2011-11-06 19:13 ` [PATCH 10/13] drm/i915: don't call shmem_read_mapping unnecessarily Daniel Vetter
2011-11-06 19:13 ` [PATCH 11/13] mm: extend prefault helpers to fault in more than PAGE_SIZE Daniel Vetter
2011-11-06 22:24   ` Chris Wilson
2011-11-06 19:13 ` [PATCH 12/13] drm/i915: drop gtt slowpath Daniel Vetter
2011-11-06 19:14 ` [PATCH 13/13] drm/i915: don't clobber userspace memory before commiting to the pread 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=1320606840-21132-8-git-send-email-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®