[RFC] non-blocking map

[RFC] non-blocking map

[Ben Widawsky]

These are dirty hacks just to enable testing write only non-blocking maps. I haven't yet created a good test, but maybe someone can shoot this down before I waste more time :).

Ben

[PATCH 1/2] drm/i915: add assumed cpu-dirtied flush

[Ben Widawsky]

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_drv.h            |    2 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index feb4f16..2a61e63 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,8 @@ struct drm_i915_gem_object {
 	 * reaches 0, dev_priv->pending_flip_queue will be woken up.
 	 */
 	atomic_t pending_flip;
+
+	atomic_t always_cpu_dirty;
 };
 
 #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 4934cf8..f60cfcc 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -201,6 +201,10 @@ i915_gem_object_set_to_gpu_domain(struct drm_i915_gem_object *obj,
 
 	cd->invalidate_domains |= invalidate_domains;
 	cd->flush_domains |= flush_domains;
+
+	if (atomic_read(&obj->always_cpu_dirty))
+		cd->flush_domains |= I915_GEM_DOMAIN_CPU;
+
 	if (flush_domains & I915_GEM_GPU_DOMAINS)
 		cd->flush_rings |= obj->ring->id;
 	if (invalidate_domains & I915_GEM_GPU_DOMAINS)
-- 
1.7.6

[PATCH 2/2] drm/i915: Assume size & 1 means WO map (hack)

[Ben Widawsky]

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_gem.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a546a71..8e14fbe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1156,6 +1156,11 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 		return -E2BIG;
 	}
 
+	if (args->offset & 1) {
+		atomic_set(&(to_intel_bo(obj)->always_cpu_dirty), 1);
+		args->offset -= 1;
+	}
+
 	down_write(&current->mm->mmap_sem);
 	addr = do_mmap(obj->filp, 0, args->size,
 		       PROT_READ | PROT_WRITE, MAP_SHARED,
-- 
1.7.6

[PATCH] intel: hack to allow WO mappings

[Ben Widawsky]

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 intel/intel_bufmgr_gem.c |   49 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 4f4de92..7431ed9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -195,6 +195,11 @@ struct _drm_intel_bo_gem {
 	 * relocations.
 	 */
 	int reloc_tree_fences;
+
+	/**
+	 * CPU write only buffer.
+	 */
+	char cpu_mapping;
 };
 
 static unsigned int
@@ -998,15 +1003,12 @@ static void drm_intel_gem_bo_unreference(drm_intel_bo *bo)
 	}
 }
 
-static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
+static int do_gem_bo_map(drm_intel_bo *bo, int write_enable)
 {
 	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
 	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
-	struct drm_i915_gem_set_domain set_domain;
 	int ret;
 
-	pthread_mutex_lock(&bufmgr_gem->lock);
-
 	/* Allow recursive mapping. Mesa may recursively map buffers with
 	 * nested display loops.
 	 */
@@ -1018,6 +1020,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
 		memset(&mmap_arg, 0, sizeof(mmap_arg));
 		mmap_arg.handle = bo_gem->gem_handle;
 		mmap_arg.offset = 0;
+		if (write_enable == 27)
+			mmap_arg.offset |= 1 ;
 		mmap_arg.size = bo->size;
 		ret = drmIoctl(bufmgr_gem->fd,
 			       DRM_IOCTL_I915_GEM_MMAP,
@@ -1027,7 +1031,6 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
 			DBG("%s:%d: Error mapping buffer %d (%s): %s .\n",
 			    __FILE__, __LINE__, bo_gem->gem_handle,
 			    bo_gem->name, strerror(errno));
-			pthread_mutex_unlock(&bufmgr_gem->lock);
 			return ret;
 		}
 		bo_gem->mem_virtual = (void *)(uintptr_t) mmap_arg.addr_ptr;
@@ -1036,6 +1039,39 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
 	    bo_gem->mem_virtual);
 	bo->virtual = bo_gem->mem_virtual;
 
+	return 0;
+}
+
+static int drm_intel_gem_bo_map_wo(drm_intel_bo *bo)
+{
+	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+	int wo_mapping_change;
+	int ret;
+
+	wo_mapping_change = ((bo_gem->cpu_mapping) != 0);
+	assert(!bo_gem->mem_virtual || !wo_mapping_change);
+
+	pthread_mutex_lock(&bufmgr_gem->lock);
+	ret = do_gem_bo_map(bo, 27);
+	if (ret == 0)
+		bo_gem->cpu_mapping = 1;
+	pthread_mutex_unlock(&bufmgr_gem->lock);
+	return ret;
+}
+
+static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
+{
+	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+	struct drm_i915_gem_set_domain set_domain;
+	int ret;
+
+	if (write_enable == 27)
+		return drm_intel_gem_bo_map_wo(bo);
+
+	pthread_mutex_lock(&bufmgr_gem->lock);
+	ret = do_gem_bo_map(bo, write_enable);
 	set_domain.handle = bo_gem->gem_handle;
 	set_domain.read_domains = I915_GEM_DOMAIN_CPU;
 	if (write_enable)
@@ -1052,8 +1088,7 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
 	}
 
 	pthread_mutex_unlock(&bufmgr_gem->lock);
-
-	return 0;
+	return ret;
 }
 
 int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
-- 
1.7.6

Re: [RFC] non-blocking map

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 325 bytes --]

On Thu, 11 Aug 2011 17:47:24 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:

> These are dirty hacks just to enable testing write only non-blocking
> maps. I haven't yet created a good test, but maybe someone can shoot
> this down before I waste more time :).

What's the planned usage?

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/2] drm/i915: add assumed cpu-dirtied flush

[Ben Widawsky]

Oops. The previous patch was the wrong one.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/i915_drv.h            |    2 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    7 +++++++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index feb4f16..2a61e63 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,8 @@ struct drm_i915_gem_object {
 	 * reaches 0, dev_priv->pending_flip_queue will be woken up.
 	 */
 	atomic_t pending_flip;
+
+	atomic_t always_cpu_dirty;
 };
 
 #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 4934cf8..b88febf 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -179,6 +179,12 @@ i915_gem_object_set_to_gpu_domain(struct drm_i915_gem_object *obj,
 		invalidate_domains |=
 			obj->base.pending_read_domains & ~obj->base.write_domain;
 	}
+
+	if (atomic_read(&obj->always_cpu_dirty)) {
+		flush_domains |= I915_GEM_DOMAIN_CPU;
+		cd->flush_domains |= I915_GEM_DOMAIN_CPU;
+	}
+
 	/*
 	 * Invalidate any read caches which may have
 	 * stale data. That is, any new read domains.
@@ -201,6 +207,7 @@ i915_gem_object_set_to_gpu_domain(struct drm_i915_gem_object *obj,
 
 	cd->invalidate_domains |= invalidate_domains;
 	cd->flush_domains |= flush_domains;
+
 	if (flush_domains & I915_GEM_GPU_DOMAINS)
 		cd->flush_rings |= obj->ring->id;
 	if (invalidate_domains & I915_GEM_GPU_DOMAINS)
-- 
1.7.6

Re: [RFC] non-blocking map

[Ben Widawsky]

[-- Attachment #1.1: Type: text/plain, Size: 573 bytes --]

On Thu, Aug 11, 2011 at 05:56:21PM -0700, Keith Packard wrote:
> On Thu, 11 Aug 2011 17:47:24 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> 
> > These are dirty hacks just to enable testing write only non-blocking
> > maps. I haven't yet created a good test, but maybe someone can shoot
> > this down before I waste more time :).
> 
> What's the planned usage?

It's supposed to speed up things like map_range_buffer which tend to do
write only operations and shouldn't have to do a blocking set domain for
write only actions (read only from GPU).

Ben



[-- Attachment #1.2: Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] non-blocking map

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 814 bytes --]

On Thu, 11 Aug 2011 18:19:40 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On Thu, Aug 11, 2011 at 05:56:21PM -0700, Keith Packard wrote:
> > On Thu, 11 Aug 2011 17:47:24 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> > 
> > > These are dirty hacks just to enable testing write only non-blocking
> > > maps. I haven't yet created a good test, but maybe someone can shoot
> > > this down before I waste more time :).
> > 
> > What's the planned usage?
> 
> It's supposed to speed up things like map_range_buffer which tend to do
> write only operations and shouldn't have to do a blocking set domain for
> write only actions (read only from GPU).

I think for write-only ARB_mbr we want to be using GTT mappings, not CPU
mappings.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] non-blocking map

[Ben Widawsky]

[-- Attachment #1.1: Type: text/plain, Size: 1033 bytes --]

On Fri, Aug 12, 2011 at 04:28:17PM -0700, Eric Anholt wrote:
> On Thu, 11 Aug 2011 18:19:40 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> Non-text part: multipart/mixed
> Non-text part: multipart/signed
> > On Thu, Aug 11, 2011 at 05:56:21PM -0700, Keith Packard wrote:
> > > On Thu, 11 Aug 2011 17:47:24 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> > > 
> > > > These are dirty hacks just to enable testing write only non-blocking
> > > > maps. I haven't yet created a good test, but maybe someone can shoot
> > > > this down before I waste more time :).
> > > 
> > > What's the planned usage?
> > 
> > It's supposed to speed up things like map_range_buffer which tend to do
> > write only operations and shouldn't have to do a blocking set domain for
> > write only actions (read only from GPU).
> 
> I think for write-only ARB_mbr we want to be using GTT mappings, not CPU
> mappings.

I'm also planning to do this for GTT mappings, but that was harder and I
thought this might also be of some benefit.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx