[RFC libdrm] intel: Softpin support

[RFC libdrm] intel: Softpin support

[Michał Winiarski]

The goal of this series is to start a discussion whether the interface and
implementation of softpin support proposed for libdrm is acceptable by all
interested parties.
The i915 patches are added so that it's easy to apply the series on latest
drm-intel-nightly and libdrm master and start using softpin.

Michał Winiarski (1):
  drm/i915/gtt: Allow adventurous users to select enable_ppgtt=3
is not strictly necessary for softpin itself, but it is needed for SVM usecase.

Chris Wilson (1):
  drm/i915: Add soft-pinning API for execbuffer
is just v5 from Thomas Daniel rebased on top of current nightly.

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

[PATCH 1/2] drm/i915/gtt: Allow adventurous users to select enable_ppgtt=3

[Michał Winiarski]

While support for 48b ppgtt is here, parameter enabling it is not known
to the sanitize function. Let's update it to allow selecting
full_48bit_ppgtt using module parameter.

Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8786281..f598d63 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,9 +104,11 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
 {
 	bool has_aliasing_ppgtt;
 	bool has_full_ppgtt;
+	bool has_full_48bit_ppgtt;
 
 	has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
 	has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
+	has_full_48bit_ppgtt = INTEL_INFO(dev)->gen >= 9 || IS_BROADWELL(dev);
 
 	if (intel_vgpu_active(dev))
 		has_full_ppgtt = false; /* emulation is too hard */
@@ -125,6 +127,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
 	if (enable_ppgtt == 2 && has_full_ppgtt)
 		return 2;
 
+	if (enable_ppgtt == 3 && has_full_48bit_ppgtt)
+		return 3;
+
 #ifdef CONFIG_INTEL_IOMMU
 	/* Disable ppgtt on SNB if VT-d is on. */
 	if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) {
-- 
2.4.3

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

[PATCH v6 2/2] drm/i915: Add soft-pinning API for execbuffer

[Michał Winiarski]

From: Chris Wilson <chris@chris-wilson.co.uk>

Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.

v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
Wilson.  Fixed incorrect error paths causing crash found by Michal Winiarski.
(Not published externally)

v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed eviction
to allow eviction of soft-pinned objects when another soft-pinned object used
by a subsequent execbuffer overlaps reported by Michal Winiarski.
(Not published externally)

v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
pinned first after an address conflict happens to avoid repeated conflicts in
rare cases (Suggested by Chris Wilson).  Expanded comment on
drm_i915_gem_exec_object2.offset to cover this new API.

v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
(Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
buffers are not considered misplaced without the user specifying
EXEC_OBJECT_SUPPORTS_48BBADDRESS.  User must assume responsibility for any
addressing workarounds.  Updated object2.offset field comment again to clarify
NO_RELOC case (Chris).  checkpatch cleanup.

v6: Rebase on top of current nightly. Dropped any references to
EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in upstream
yet, and are not a dependency.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Zou Nanhai <nanhai.zou@intel.com>
Cc: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c            |  3 ++
 drivers/gpu/drm/i915/i915_drv.h            |  3 ++
 drivers/gpu/drm/i915/i915_gem.c            | 52 ++++++++++++++++++++++--------
 drivers/gpu/drm/i915/i915_gem_evict.c      | 39 ++++++++++++++++++++++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 16 +++++++--
 include/uapi/drm/i915_drm.h                | 10 +++++-
 6 files changed, 106 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 066a0ef..bd619af 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -170,6 +170,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 	case I915_PARAM_HAS_RESOURCE_STREAMER:
 		value = HAS_RESOURCE_STREAMER(dev);
 		break;
+	case I915_PARAM_HAS_EXEC_SOFTPIN:
+		value = 1;
+		break;
 	default:
 		DRM_DEBUG("Unknown parameter %d\n", param->param);
 		return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ef83c5..8eb01e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2815,6 +2815,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
 #define PIN_OFFSET_BIAS	(1<<3)
 #define PIN_USER	(1<<4)
 #define PIN_UPDATE	(1<<5)
+#define PIN_OFFSET_FIXED	(1<<6)
 #define PIN_OFFSET_MASK (~4095)
 int __must_check
 i915_gem_object_pin(struct drm_i915_gem_object *obj,
@@ -3157,6 +3158,8 @@ int __must_check i915_gem_evict_something(struct drm_device *dev,
 					  unsigned long start,
 					  unsigned long end,
 					  unsigned flags);
+int __must_check
+i915_gem_evict_for_vma(struct i915_vma *target);
 int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
 int i915_gem_evict_everything(struct drm_device *dev);
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 41263cd..bb2ff81 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3437,22 +3437,42 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
 	if (IS_ERR(vma))
 		goto err_unpin;
 
+	if (flags & PIN_OFFSET_FIXED) {
+		uint64_t offset = flags & PIN_OFFSET_MASK;
+
+		if (offset & (alignment - 1)) {
+			ret = -EINVAL;
+			goto err_free_vma;
+		}
+		vma->node.start = offset;
+		vma->node.size = size;
+		vma->node.color = obj->cache_level;
+		ret = drm_mm_reserve_node(&vm->mm, &vma->node);
+		if (ret) {
+			ret = i915_gem_evict_for_vma(vma);
+			if (ret == 0)
+				ret = drm_mm_reserve_node(&vm->mm, &vma->node);
+		}
+		if (ret)
+			goto err_free_vma;
+	} else {
 search_free:
-	ret = drm_mm_insert_node_in_range_generic(&vm->mm, &vma->node,
-						  size, alignment,
-						  obj->cache_level,
-						  start, end,
-						  DRM_MM_SEARCH_DEFAULT,
-						  DRM_MM_CREATE_DEFAULT);
-	if (ret) {
-		ret = i915_gem_evict_something(dev, vm, size, alignment,
-					       obj->cache_level,
-					       start, end,
-					       flags);
-		if (ret == 0)
-			goto search_free;
+		ret = drm_mm_insert_node_in_range_generic(&vm->mm, &vma->node,
+							  size, alignment,
+							  obj->cache_level,
+							  start, end,
+							  DRM_MM_SEARCH_DEFAULT,
+							  DRM_MM_CREATE_DEFAULT);
+		if (ret) {
+			ret = i915_gem_evict_something(dev, vm, size, alignment,
+						       obj->cache_level,
+						       start, end,
+						       flags);
+			if (ret == 0)
+				goto search_free;
 
-		goto err_free_vma;
+			goto err_free_vma;
+		}
 	}
 	if (WARN_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level))) {
 		ret = -EINVAL;
@@ -3986,6 +4006,10 @@ i915_vma_misplaced(struct i915_vma *vma, uint32_t alignment, uint64_t flags)
 	    vma->node.start < (flags & PIN_OFFSET_MASK))
 		return true;
 
+	if (flags & PIN_OFFSET_FIXED &&
+	    vma->node.start != (flags & PIN_OFFSET_MASK))
+		return true;
+
 	return false;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
index d09e35e..bc5b91c 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -199,6 +199,45 @@ found:
 	return ret;
 }
 
+int
+i915_gem_evict_for_vma(struct i915_vma *target)
+{
+	struct drm_mm_node *node, *next;
+
+	list_for_each_entry_safe(node, next,
+			&target->vm->mm.head_node.node_list,
+			node_list) {
+		struct i915_vma *vma;
+		int ret;
+
+		if (node->start + node->size <= target->node.start)
+			continue;
+		if (node->start >= target->node.start + target->node.size)
+			break;
+
+		vma = container_of(node, typeof(*vma), node);
+
+		if (vma->pin_count) {
+			if (!vma->exec_entry || (vma->pin_count > 1))
+				/* Object is pinned for some other use */
+				return -EBUSY;
+
+			/* We need to evict a buffer in the same batch */
+			if (vma->exec_entry->flags & EXEC_OBJECT_PINNED)
+				/* Overlapping fixed objects in the same batch */
+				return -EINVAL;
+
+			return -ENOSPC;
+		}
+
+		ret = i915_vma_unbind(vma);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 /**
  * i915_gem_evict_vm - Evict all idle vmas from a vm
  * @vm: Address space to cleanse
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a953d49..49ef155 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -594,6 +594,8 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
 			flags |= PIN_GLOBAL | PIN_MAPPABLE;
 		if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
 			flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
+		if (entry->flags & EXEC_OBJECT_PINNED)
+			flags |= entry->offset | PIN_OFFSET_FIXED;
 	}
 
 	ret = i915_gem_object_pin(obj, vma->vm, entry->alignment, flags);
@@ -663,6 +665,10 @@ eb_vma_misplaced(struct i915_vma *vma)
 	    vma->node.start & (entry->alignment - 1))
 		return true;
 
+	if (entry->flags & EXEC_OBJECT_PINNED &&
+	    vma->node.start != entry->offset)
+		return true;
+
 	if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS &&
 	    vma->node.start < BATCH_OFFSET_BIAS)
 		return true;
@@ -684,6 +690,7 @@ i915_gem_execbuffer_reserve(struct intel_engine_cs *ring,
 	struct i915_vma *vma;
 	struct i915_address_space *vm;
 	struct list_head ordered_vmas;
+	struct list_head pinned_vmas;
 	bool has_fenced_gpu_access = INTEL_INFO(ring->dev)->gen < 4;
 	int retry;
 
@@ -692,6 +699,7 @@ i915_gem_execbuffer_reserve(struct intel_engine_cs *ring,
 	vm = list_first_entry(vmas, struct i915_vma, exec_list)->vm;
 
 	INIT_LIST_HEAD(&ordered_vmas);
+	INIT_LIST_HEAD(&pinned_vmas);
 	while (!list_empty(vmas)) {
 		struct drm_i915_gem_exec_object2 *entry;
 		bool need_fence, need_mappable;
@@ -710,7 +718,9 @@ i915_gem_execbuffer_reserve(struct intel_engine_cs *ring,
 			obj->tiling_mode != I915_TILING_NONE;
 		need_mappable = need_fence || need_reloc_mappable(vma);
 
-		if (need_mappable) {
+		if (entry->flags & EXEC_OBJECT_PINNED)
+			list_move_tail(&vma->exec_list, &pinned_vmas);
+		else if (need_mappable) {
 			entry->flags |= __EXEC_OBJECT_NEEDS_MAP;
 			list_move(&vma->exec_list, &ordered_vmas);
 		} else
@@ -720,6 +730,7 @@ i915_gem_execbuffer_reserve(struct intel_engine_cs *ring,
 		obj->base.pending_write_domain = 0;
 	}
 	list_splice(&ordered_vmas, vmas);
+	list_splice(&pinned_vmas, vmas);
 
 	/* Attempt to pin all of the buffers into the GTT.
 	 * This is done in 3 phases:
@@ -1398,7 +1409,8 @@ eb_get_batch(struct eb_vmas *eb)
 	 * Note that actual hangs have only been observed on gen7, but for
 	 * paranoia do it everywhere.
 	 */
-	vma->exec_entry->flags |= __EXEC_OBJECT_NEEDS_BIAS;
+	if ((vma->exec_entry->flags & EXEC_OBJECT_PINNED) == 0)
+		vma->exec_entry->flags |= __EXEC_OBJECT_NEEDS_BIAS;
 
 	return vma->obj;
 }
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index fd5aa47..0a0e781 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -356,6 +356,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_EU_TOTAL		 34
 #define I915_PARAM_HAS_GPU_RESET	 35
 #define I915_PARAM_HAS_RESOURCE_STREAMER 36
+#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
 
 typedef struct drm_i915_getparam {
 	__s32 param;
@@ -684,13 +685,20 @@ struct drm_i915_gem_exec_object2 {
 	/**
 	 * Returned value of the updated offset of the object, for future
 	 * presumed_offset writes.
+	 * When the EXEC_OBJECT_PINNED flag is specified this is populated by
+	 * the user with the GTT offset at which this object will be pinned.
+	 * When the I915_EXEC_NO_RELOC flag is specified this must contain the
+	 * presumed_offset of the object.
+	 * During execbuffer2 the kernel populates it with the value of the
+	 * current GTT offset of the object, for future presumed_offset writes.
 	 */
 	__u64 offset;
 
 #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
 #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
 #define EXEC_OBJECT_WRITE	(1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_PINNED	(1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
 	__u64 flags;
 
 	__u64 rsvd1;
-- 
2.4.3

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

[RFC libdrm] intel: Add support for softpin

[Michał Winiarski]

Softpin allows userspace to take greater control of GPU virtual address
space and eliminates the need of relocations. It can also be used to
mirror addresses between GPU and CPU (shared virtual memory).
Calls to drm_intel_bo_emit_reloc are still required to build the list of
drm_i915_gem_exec_objects at exec time, but no entries in relocs are
created. Self-relocs don't make any sense for softpinned objects and can
indicate a programming errors, thus are forbidden. Softpinned objects
are marked by asterisk in debug dumps.

Cc: Thomas Daniel <thomas.daniel@intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Zou Nanhai <nanhai.zou@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
---
 include/drm/i915_drm.h    |   4 +-
 intel/intel_bufmgr.c      |   9 +++
 intel/intel_bufmgr.h      |   1 +
 intel/intel_bufmgr_gem.c  | 176 ++++++++++++++++++++++++++++++++++++++++------
 intel/intel_bufmgr_priv.h |   7 ++
 5 files changed, 173 insertions(+), 24 deletions(-)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..2b99fc6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_REVISION              32
 #define I915_PARAM_SUBSLICE_TOTAL	 33
 #define I915_PARAM_EU_TOTAL		 34
+#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
 
 typedef struct drm_i915_getparam {
 	int param;
@@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
 #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
 #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
 #define EXEC_OBJECT_WRITE	(1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_PINNED	(1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
 	__u64 flags;
 
 	__u64 rsvd1;
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 14ea9f9..bd92335 100644
--- a/intel/intel_bufmgr.c
+++ b/intel/intel_bufmgr.c
@@ -261,6 +261,15 @@ drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t * tiling_mode,
 }
 
 int
+drm_intel_bo_set_softpin_offset(drm_intel_bo *bo, uint64_t offset)
+{
+	if (bo->bufmgr->bo_set_softpin_offset)
+		return bo->bufmgr->bo_set_softpin_offset(bo, offset);
+
+	return -ENODEV;
+}
+
+int
 drm_intel_bo_disable_reuse(drm_intel_bo *bo)
 {
 	if (bo->bufmgr->bo_disable_reuse)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 95eecb8..62ea4a0 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -164,6 +164,7 @@ int drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t * tiling_mode,
 int drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name);
 int drm_intel_bo_busy(drm_intel_bo *bo);
 int drm_intel_bo_madvise(drm_intel_bo *bo, int madv);
+int drm_intel_bo_set_softpin_offset(drm_intel_bo *bo, uint64_t offset);
 
 int drm_intel_bo_disable_reuse(drm_intel_bo *bo);
 int drm_intel_bo_is_reusable(drm_intel_bo *bo);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2723e21..615741c 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -184,6 +184,13 @@ struct _drm_intel_bo_gem {
 	drm_intel_reloc_target *reloc_target_info;
 	/** Number of entries in relocs */
 	int reloc_count;
+	/** Array of BOs that are referenced by this buffer and will be softpinned */
+	drm_intel_bo **softpin_target;
+	/** Number softpinned BOs that are referenced by this buffer */
+	int softpin_target_count;
+	/** Maximum amount of softpinned BOs that are referenced by this buffer */
+	int softpin_target_size;
+
 	/** Mapped address for the buffer, saved across map/unmap cycles */
 	void *mem_virtual;
 	/** GTT virtual address for the buffer, saved across map/unmap cycles */
@@ -237,6 +244,11 @@ struct _drm_intel_bo_gem {
 	bool is_userptr;
 
 	/**
+	 * Whether this buffer is softpinned at offset specified by the user
+	 */
+	bool is_softpin;
+
+	/**
 	 * Size in bytes of this buffer and its relocation descendents.
 	 *
 	 * Used to avoid costly tree walking in
@@ -384,8 +396,9 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem *bufmgr_gem)
 		drm_intel_bo *bo = bufmgr_gem->exec_bos[i];
 		drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
 
-		if (bo_gem->relocs == NULL) {
-			DBG("%2d: %d (%s)\n", i, bo_gem->gem_handle,
+		if (bo_gem->relocs == NULL && bo_gem->softpin_target == NULL) {
+			DBG("%2d: %d %s(%s)\n", i, bo_gem->gem_handle,
+			    bo_gem->is_softpin ? "*" : "",
 			    bo_gem->name);
 			continue;
 		}
@@ -395,16 +408,33 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem *bufmgr_gem)
 			drm_intel_bo_gem *target_gem =
 			    (drm_intel_bo_gem *) target_bo;
 
-			DBG("%2d: %d (%s)@0x%08llx -> "
+			DBG("%2d: %d %s(%s)@0x%016llx -> "
 			    "%d (%s)@0x%08lx + 0x%08x\n",
 			    i,
-			    bo_gem->gem_handle, bo_gem->name,
+			    bo_gem->gem_handle,
+			    bo_gem->is_softpin ? "*" : "",
+			    bo_gem->name,
 			    (unsigned long long)bo_gem->relocs[j].offset,
 			    target_gem->gem_handle,
 			    target_gem->name,
 			    target_bo->offset64,
 			    bo_gem->relocs[j].delta);
 		}
+
+		for (j = 0; j < bo_gem->softpin_target_count; j++) {
+			drm_intel_bo *target_bo = bo_gem->softpin_target[j];
+			drm_intel_bo_gem *target_gem =
+			    (drm_intel_bo_gem *) target_bo;
+			DBG("%2d: %d %s(%s) -> "
+			    "%d *(%s)@0x%016lx\n",
+			    i,
+			    bo_gem->gem_handle,
+			    bo_gem->is_softpin ? "*" : "",
+			    bo_gem->name,
+			    target_gem->gem_handle,
+			    target_gem->name,
+			    target_bo->offset64);
+		}
 	}
 }
 
@@ -468,11 +498,18 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int need_fence)
 	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo->bufmgr;
 	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *)bo;
 	int index;
+	int flags = 0;
+
+	if (need_fence)
+		flags |= EXEC_OBJECT_NEEDS_FENCE;
+	if (bo_gem->is_softpin)
+		flags |= EXEC_OBJECT_PINNED;
 
 	if (bo_gem->validate_index != -1) {
 		if (need_fence)
 			bufmgr_gem->exec2_objects[bo_gem->validate_index].flags |=
 				EXEC_OBJECT_NEEDS_FENCE;
+		bufmgr_gem->exec2_objects[bo_gem->validate_index].flags |= flags;
 		return;
 	}
 
@@ -499,15 +536,12 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int need_fence)
 	bufmgr_gem->exec2_objects[index].relocation_count = bo_gem->reloc_count;
 	bufmgr_gem->exec2_objects[index].relocs_ptr = (uintptr_t)bo_gem->relocs;
 	bufmgr_gem->exec2_objects[index].alignment = bo->align;
-	bufmgr_gem->exec2_objects[index].offset = 0;
+	bufmgr_gem->exec2_objects[index].offset = bo_gem->is_softpin ?
+		bo->offset64 : 0;
 	bufmgr_gem->exec_bos[index] = bo;
-	bufmgr_gem->exec2_objects[index].flags = 0;
+	bufmgr_gem->exec2_objects[index].flags = flags;
 	bufmgr_gem->exec2_objects[index].rsvd1 = 0;
 	bufmgr_gem->exec2_objects[index].rsvd2 = 0;
-	if (need_fence) {
-		bufmgr_gem->exec2_objects[index].flags |=
-			EXEC_OBJECT_NEEDS_FENCE;
-	}
 	bufmgr_gem->exec_count++;
 }
 
@@ -1256,8 +1290,12 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, time_t time)
 								  time);
 		}
 	}
+	for (i = 0; i < bo_gem->softpin_target_count; i++)
+		drm_intel_gem_bo_unreference_locked_timed(bo_gem->softpin_target[i],
+								  time);
 	bo_gem->reloc_count = 0;
 	bo_gem->used_as_reloc_target = false;
+	bo_gem->softpin_target_count = 0;
 
 	DBG("bo_unreference final: %d (%s)\n",
 	    bo_gem->gem_handle, bo_gem->name);
@@ -1271,6 +1309,11 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, time_t time)
 		free(bo_gem->relocs);
 		bo_gem->relocs = NULL;
 	}
+	if (bo_gem->softpin_target) {
+		free(bo_gem->softpin_target);
+		bo_gem->softpin_target = NULL;
+		bo_gem->softpin_target_size = 0;
+	}
 
 	/* Clear any left-over mappings */
 	if (bo_gem->map_count) {
@@ -1908,14 +1951,6 @@ do_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
 		bo_gem->reloc_tree_fences += target_bo_gem->reloc_tree_fences;
 	}
 
-	bo_gem->relocs[bo_gem->reloc_count].offset = offset;
-	bo_gem->relocs[bo_gem->reloc_count].delta = target_offset;
-	bo_gem->relocs[bo_gem->reloc_count].target_handle =
-	    target_bo_gem->gem_handle;
-	bo_gem->relocs[bo_gem->reloc_count].read_domains = read_domains;
-	bo_gem->relocs[bo_gem->reloc_count].write_domain = write_domain;
-	bo_gem->relocs[bo_gem->reloc_count].presumed_offset = target_bo->offset64;
-
 	bo_gem->reloc_target_info[bo_gem->reloc_count].bo = target_bo;
 	if (target_bo != bo)
 		drm_intel_gem_bo_reference(target_bo);
@@ -1925,21 +1960,70 @@ do_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
 	else
 		bo_gem->reloc_target_info[bo_gem->reloc_count].flags = 0;
 
+	bo_gem->relocs[bo_gem->reloc_count].offset = offset;
+	bo_gem->relocs[bo_gem->reloc_count].delta = target_offset;
+	bo_gem->relocs[bo_gem->reloc_count].target_handle =
+	    target_bo_gem->gem_handle;
+	bo_gem->relocs[bo_gem->reloc_count].read_domains = read_domains;
+	bo_gem->relocs[bo_gem->reloc_count].write_domain = write_domain;
+	bo_gem->relocs[bo_gem->reloc_count].presumed_offset = target_bo->offset64;
 	bo_gem->reloc_count++;
 
 	return 0;
 }
 
 static int
+drm_intel_gem_bo_add_softpin_target(drm_intel_bo *bo, drm_intel_bo *target_bo)
+{
+	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+	drm_intel_bo_gem *target_bo_gem = (drm_intel_bo_gem *) target_bo;
+	if (bo_gem->has_error)
+		return -ENOMEM;
+
+	if (target_bo_gem->has_error) {
+		bo_gem->has_error = true;
+		return -ENOMEM;
+	}
+
+	if (!target_bo_gem->is_softpin)
+		return -EINVAL;
+	if (target_bo_gem == bo_gem)
+		return -EINVAL;
+
+	if (bo_gem->softpin_target_count == bo_gem->softpin_target_size) {
+		int new_size = bo_gem->softpin_target_size * 2;
+		if (new_size == 0)
+			new_size = bufmgr_gem->max_relocs;
+
+		bo_gem->softpin_target = realloc(bo_gem->softpin_target, new_size *
+				sizeof(drm_intel_bo *));
+		if (!bo_gem->softpin_target)
+			return -ENOMEM;
+
+		bo_gem->softpin_target_size = new_size;
+	}
+	bo_gem->softpin_target[bo_gem->softpin_target_count] = target_bo;
+	drm_intel_gem_bo_reference(target_bo);
+	bo_gem->softpin_target_count++;
+
+	return 0;
+}
+
+static int
 drm_intel_gem_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
 			    drm_intel_bo *target_bo, uint32_t target_offset,
 			    uint32_t read_domains, uint32_t write_domain)
 {
 	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo->bufmgr;
+	drm_intel_bo_gem *target_bo_gem = (drm_intel_bo_gem *)target_bo;
 
-	return do_bo_emit_reloc(bo, offset, target_bo, target_offset,
-				read_domains, write_domain,
-				!bufmgr_gem->fenced_relocs);
+	if (target_bo_gem->is_softpin)
+		return drm_intel_gem_bo_add_softpin_target(bo, target_bo);
+	else
+		return do_bo_emit_reloc(bo, offset, target_bo, target_offset,
+					read_domains, write_domain,
+					!bufmgr_gem->fenced_relocs);
 }
 
 static int
@@ -1972,6 +2056,8 @@ drm_intel_gem_bo_get_reloc_count(drm_intel_bo *bo)
  *
  * Any further drm_intel_bufmgr_check_aperture_space() queries
  * involving this buffer in the tree are undefined after this call.
+ *
+ * This also removes all softpinned targets being referenced by the BO.
  */
 void
 drm_intel_gem_bo_clear_relocs(drm_intel_bo *bo, int start)
@@ -1998,6 +2084,12 @@ drm_intel_gem_bo_clear_relocs(drm_intel_bo *bo, int start)
 	}
 	bo_gem->reloc_count = start;
 
+	for (i = 0; i < bo_gem->softpin_target_count; i++) {
+		drm_intel_bo_gem *target_bo_gem = (drm_intel_bo_gem *) bo_gem->softpin_target[i];
+		drm_intel_gem_bo_unreference_locked_timed(&target_bo_gem->bo, time.tv_sec);
+	}
+	bo_gem->softpin_target_count = 0;
+
 	pthread_mutex_unlock(&bufmgr_gem->lock);
 
 }
@@ -2038,7 +2130,7 @@ drm_intel_gem_bo_process_reloc2(drm_intel_bo *bo)
 	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *)bo;
 	int i;
 
-	if (bo_gem->relocs == NULL)
+	if (bo_gem->relocs == NULL && bo_gem->softpin_target == NULL)
 		return;
 
 	for (i = 0; i < bo_gem->reloc_count; i++) {
@@ -2059,6 +2151,17 @@ drm_intel_gem_bo_process_reloc2(drm_intel_bo *bo)
 		/* Add the target to the validate list */
 		drm_intel_add_validate_buffer2(target_bo, need_fence);
 	}
+
+	for (i = 0; i < bo_gem->softpin_target_count; i++) {
+		drm_intel_bo *target_bo = bo_gem->softpin_target[i];
+
+		if (target_bo == bo)
+			continue;
+
+		drm_intel_gem_bo_mark_mmaps_incoherent(bo);
+		drm_intel_gem_bo_process_reloc2(target_bo);
+		drm_intel_add_validate_buffer2(target_bo, false);
+	}
 }
 
 
@@ -2094,7 +2197,11 @@ drm_intel_update_buffer_offsets2 (drm_intel_bufmgr_gem *bufmgr_gem)
 
 		/* Update the buffer offset */
 		if (bufmgr_gem->exec2_objects[i].offset != bo->offset64) {
-			DBG("BO %d (%s) migrated: 0x%08lx -> 0x%08llx\n",
+			/* If we're seeing softpinned object here it means that the kernel
+			 * has relocated our object... Indicating a programming error
+			 */
+			assert(!bo_gem->is_softpin);
+			DBG("BO %d (%s) migrated: 0x%016lx -> 0x%016llx\n",
 			    bo_gem->gem_handle, bo_gem->name, bo->offset64,
 			    (unsigned long long)bufmgr_gem->exec2_objects[i].offset);
 			bo->offset64 = bufmgr_gem->exec2_objects[i].offset;
@@ -2418,6 +2525,17 @@ drm_intel_gem_bo_get_tiling(drm_intel_bo *bo, uint32_t * tiling_mode,
 	return 0;
 }
 
+static int
+drm_intel_gem_bo_set_softpin_offset(drm_intel_bo *bo, uint64_t offset)
+{
+	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+
+	bo_gem->is_softpin = true;
+	bo->offset64 = offset;
+	bo->offset = offset;
+	return 0;
+}
+
 drm_intel_bo *
 drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr *bufmgr, int prime_fd, int size)
 {
@@ -2796,6 +2914,13 @@ _drm_intel_gem_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
 			return 1;
 	}
 
+	for (i = 0; i< bo_gem->softpin_target_count; i++) {
+		if (bo_gem->softpin_target[i] == target_bo)
+			return 1;
+		if (_drm_intel_gem_bo_references(bo_gem->softpin_target[i], target_bo))
+			return 1;
+	}
+
 	return 0;
 }
 
@@ -3252,6 +3377,11 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
 	ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
 	bufmgr_gem->has_vebox = (ret == 0) & (*gp.value > 0);
 
+	gp.param = I915_PARAM_HAS_EXEC_SOFTPIN;
+	ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
+	if (ret == 0 && *gp.value > 0)
+		bufmgr_gem->bufmgr.bo_set_softpin_offset = drm_intel_gem_bo_set_softpin_offset;
+
 	if (bufmgr_gem->gen < 4) {
 		gp.param = I915_PARAM_NUM_FENCES_AVAIL;
 		gp.value = &bufmgr_gem->available_fences;
diff --git a/intel/intel_bufmgr_priv.h b/intel/intel_bufmgr_priv.h
index 59ebd18..86991c9 100644
--- a/intel/intel_bufmgr_priv.h
+++ b/intel/intel_bufmgr_priv.h
@@ -227,6 +227,13 @@ struct _drm_intel_bufmgr {
 			      uint32_t * swizzle_mode);
 
 	/**
+	 * Set the offset at which this buffer will be softpinned
+	 * \param bo Buffer to set the softpin offset for
+	 * \param offset Softpin offset
+	 */
+	int (*bo_set_softpin_offset) (drm_intel_bo *bo, uint64_t offset);
+
+	/**
 	 * Create a visible name for a buffer which can be used by other apps
 	 *
 	 * \param buf Buffer to create a name for
-- 
2.4.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/2] drm/i915: Add soft-pinning API for execbuffer

[Chris Wilson]

On Wed, Sep 09, 2015 at 04:07:09PM +0200, Michał Winiarski wrote:
> From: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Userspace can pass in an offset that it presumes the object is located
> at. The kernel will then do its utmost to fit the object into that
> location. The assumption is that userspace is handling its own object
> locations (for example along with full-ppgtt) and that the kernel will
> rarely have to make space for the user's requests.
> 
> v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
> Wilson.  Fixed incorrect error paths causing crash found by Michal Winiarski.
> (Not published externally)
> 
> v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed eviction
> to allow eviction of soft-pinned objects when another soft-pinned object used
> by a subsequent execbuffer overlaps reported by Michal Winiarski.
> (Not published externally)
> 
> v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
> pinned first after an address conflict happens to avoid repeated conflicts in
> rare cases (Suggested by Chris Wilson).  Expanded comment on
> drm_i915_gem_exec_object2.offset to cover this new API.
> 
> v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
> (Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
> buffers are not considered misplaced without the user specifying
> EXEC_OBJECT_SUPPORTS_48BBADDRESS.  User must assume responsibility for any
> addressing workarounds.  Updated object2.offset field comment again to clarify
> NO_RELOC case (Chris).  checkpatch cleanup.
> 
> v6: Rebase on top of current nightly. Dropped any references to
> EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in upstream
> yet, and are not a dependency.
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Akash Goel <akash.goel@intel.com>
> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
> Cc: Michal Winiarski <michal.winiarski@intel.com>
> Cc: Zou Nanhai <nanhai.zou@intel.com>
> Cc: Kristian Høgsberg <hoegsberg@gmail.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>

Again, the precursors are not included in this series or upstream, so
NAK.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [PATCH v6 2/2] drm/i915: Add soft-pinning API for execbuffer

[Yang, Rong R]

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Wednesday, September 9, 2015 22:25
> To: Winiarski, Michal
> Cc: intel-gfx@lists.freedesktop.org; Kristian Høgsberg; dri-
> devel@lists.freedesktop.org; Goel, Akash; Belgaumkar, Vinay; mesa-
> dev@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Add soft-pinning API for
> execbuffer
> 
> On Wed, Sep 09, 2015 at 04:07:09PM +0200, Michał Winiarski wrote:
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> >
> > Userspace can pass in an offset that it presumes the object is located
> > at. The kernel will then do its utmost to fit the object into that
> > location. The assumption is that userspace is handling its own object
> > locations (for example along with full-ppgtt) and that the kernel will
> > rarely have to make space for the user's requests.
> >
> > v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested
> > by Chris Wilson.  Fixed incorrect error paths causing crash found by Michal
> Winiarski.
> > (Not published externally)
> >
> > v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed
> > eviction to allow eviction of soft-pinned objects when another
> > soft-pinned object used by a subsequent execbuffer overlaps reported by
> Michal Winiarski.
> > (Not published externally)
> >
> > v4: Moved soft-pinned objects to the front of ordered_vmas so that
> > they are pinned first after an address conflict happens to avoid
> > repeated conflicts in rare cases (Suggested by Chris Wilson).
> > Expanded comment on drm_i915_gem_exec_object2.offset to cover this
> new API.
> >
> > v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this
> > capability (Kristian). Added check for multiple pinnings on eviction
> > (Akash). Made sure buffers are not considered misplaced without the
> > user specifying EXEC_OBJECT_SUPPORTS_48BBADDRESS.  User must
> assume
> > responsibility for any addressing workarounds.  Updated object2.offset
> > field comment again to clarify NO_RELOC case (Chris).  checkpatch cleanup.
> >
> > v6: Rebase on top of current nightly. Dropped any references to
> > EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in
> upstream
> > yet, and are not a dependency.
> >
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Akash Goel <akash.goel@intel.com>
> > Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
> > Cc: Michal Winiarski <michal.winiarski@intel.com>
> > Cc: Zou Nanhai <nanhai.zou@intel.com>
> > Cc: Kristian Høgsberg <hoegsberg@gmail.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
> > Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> 
> Again, the precursors are not included in this series or upstream, so NAK.
> -Chris
I have post a beignet's OpenCL2.0 SVM patch based on this patch set. It works well on i386 system.
Can you  review this patchset again? thanks.

> 
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v6 2/2] drm/i915: Add soft-pinning API for execbuffer

[Daniel, Thomas]

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of
> Yang, Rong R
> Sent: Wednesday, November 4, 2015 10:32 AM
> To: Chris Wilson; Winiarski, Michal
> Cc: intel-gfx@lists.freedesktop.org; Kristian H?gsberg; dri-
> devel@lists.freedesktop.org; Goel, Akash; mesa-dev@lists.freedesktop.org;
> Belgaumkar, Vinay
> Subject: Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Add soft-pinning API for
> execbuffer
> 
> 
> 
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf
> > Of Chris Wilson
> > Sent: Wednesday, September 9, 2015 22:25
> > To: Winiarski, Michal
> > Cc: intel-gfx@lists.freedesktop.org; Kristian Høgsberg; dri-
> > devel@lists.freedesktop.org; Goel, Akash; Belgaumkar, Vinay; mesa-
> > dev@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Add soft-pinning API for
> > execbuffer
> >
> > On Wed, Sep 09, 2015 at 04:07:09PM +0200, Michał Winiarski wrote:
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > >
> > > Userspace can pass in an offset that it presumes the object is located
> > > at. The kernel will then do its utmost to fit the object into that
> > > location. The assumption is that userspace is handling its own object
> > > locations (for example along with full-ppgtt) and that the kernel will
> > > rarely have to make space for the user's requests.
> > >
> > > v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested
> > > by Chris Wilson.  Fixed incorrect error paths causing crash found by Michal
> > Winiarski.
> > > (Not published externally)
> > >
> > > v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed
> > > eviction to allow eviction of soft-pinned objects when another
> > > soft-pinned object used by a subsequent execbuffer overlaps reported by
> > Michal Winiarski.
> > > (Not published externally)
> > >
> > > v4: Moved soft-pinned objects to the front of ordered_vmas so that
> > > they are pinned first after an address conflict happens to avoid
> > > repeated conflicts in rare cases (Suggested by Chris Wilson).
> > > Expanded comment on drm_i915_gem_exec_object2.offset to cover this
> > new API.
> > >
> > > v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this
> > > capability (Kristian). Added check for multiple pinnings on eviction
> > > (Akash). Made sure buffers are not considered misplaced without the
> > > user specifying EXEC_OBJECT_SUPPORTS_48BBADDRESS.  User must
> > assume
> > > responsibility for any addressing workarounds.  Updated object2.offset
> > > field comment again to clarify NO_RELOC case (Chris).  checkpatch cleanup.
> > >
> > > v6: Rebase on top of current nightly. Dropped any references to
> > > EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in
> > upstream
> > > yet, and are not a dependency.
> > >
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Akash Goel <akash.goel@intel.com>
> > > Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
> > > Cc: Michal Winiarski <michal.winiarski@intel.com>
> > > Cc: Zou Nanhai <nanhai.zou@intel.com>
> > > Cc: Kristian Høgsberg <hoegsberg@gmail.com>
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
> > > Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> >
> > Again, the precursors are not included in this series or upstream, so NAK.
> > -Chris
> I have post a beignet's OpenCL2.0 SVM patch based on this patch set. It works
> well on i386 system.
> Can you  review this patchset again? thanks.
Chris posted a new version which we want to use instead.  Akash has posted a comment on it already.
http://patchwork.freedesktop.org/patch/61122/

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

Re: [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Micha? Winiarski
> Sent: Wednesday, September 9, 2015 10:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org;
> mesa-dev@lists.freedesktop.org
> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> Softpin allows userspace to take greater control of GPU virtual address
> space and eliminates the need of relocations. It can also be used to
> mirror addresses between GPU and CPU (shared virtual memory).
> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> created. Self-relocs don't make any sense for softpinned objects and can
> indicate a programming errors, thus are forbidden. Softpinned objects
> are marked by asterisk in debug dumps.
> 
> Cc: Thomas Daniel <thomas.daniel@intel.com>
> Cc: Kristian Høgsberg <krh@bitplanet.net>
> Cc: Zou Nanhai <nanhai.zou@intel.com>
> Cc: Michel Thierry <michel.thierry@intel.com>
> Cc: Ben Widawsky <ben@bwidawsk.net>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> ---
>  include/drm/i915_drm.h    |   4 +-
>  intel/intel_bufmgr.c      |   9 +++
>  intel/intel_bufmgr.h      |   1 +
>  intel/intel_bufmgr_gem.c  | 176
> ++++++++++++++++++++++++++++++++++++++++------
>  intel/intel_bufmgr_priv.h |   7 ++
>  5 files changed, 173 insertions(+), 24 deletions(-)

Will anybody help to push the patch to libdrm? Beignet highly depend on this to implement ocl2.0 svm.

Thanks!
Ruiling

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

Re: [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com> wrote:
>> -----Original Message-----
>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf
>> Of Micha? Winiarski
>> Sent: Wednesday, September 9, 2015 10:07 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org;
>> mesa-dev@lists.freedesktop.org
>> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>
>> Softpin allows userspace to take greater control of GPU virtual address
>> space and eliminates the need of relocations. It can also be used to
>> mirror addresses between GPU and CPU (shared virtual memory).
>> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> created. Self-relocs don't make any sense for softpinned objects and can
>> indicate a programming errors, thus are forbidden. Softpinned objects
>> are marked by asterisk in debug dumps.
>>
>> Cc: Thomas Daniel <thomas.daniel@intel.com>
>> Cc: Kristian Høgsberg <krh@bitplanet.net>
>> Cc: Zou Nanhai <nanhai.zou@intel.com>
>> Cc: Michel Thierry <michel.thierry@intel.com>
>> Cc: Ben Widawsky <ben@bwidawsk.net>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>> ---
>>  include/drm/i915_drm.h    |   4 +-
>>  intel/intel_bufmgr.c      |   9 +++
>>  intel/intel_bufmgr.h      |   1 +
>>  intel/intel_bufmgr_gem.c  | 176
>> ++++++++++++++++++++++++++++++++++++++++------
>>  intel/intel_bufmgr_priv.h |   7 ++
>>  5 files changed, 173 insertions(+), 24 deletions(-)
>
> Will anybody help to push the patch to libdrm? Beignet highly depend on this to implement ocl2.0 svm.

Is the kernel patch upstream?

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

Re: [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -----Original Message-----
> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of
> Kristian H?gsberg
> Sent: Monday, December 14, 2015 1:34 PM
> To: Song, Ruiling <ruiling.song@intel.com>
> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
> wrote:
> >> -----Original Message-----
> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> Behalf
> >> Of Micha? Winiarski
> >> Sent: Wednesday, September 9, 2015 10:07 PM
> >> To: intel-gfx@lists.freedesktop.org
> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
> devel@lists.freedesktop.org;
> >> mesa-dev@lists.freedesktop.org
> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >>
> >> Softpin allows userspace to take greater control of GPU virtual address
> >> space and eliminates the need of relocations. It can also be used to
> >> mirror addresses between GPU and CPU (shared virtual memory).
> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> >> created. Self-relocs don't make any sense for softpinned objects and can
> >> indicate a programming errors, thus are forbidden. Softpinned objects
> >> are marked by asterisk in debug dumps.
> >>
> >> Cc: Thomas Daniel <thomas.daniel@intel.com>
> >> Cc: Kristian Høgsberg <krh@bitplanet.net>
> >> Cc: Zou Nanhai <nanhai.zou@intel.com>
> >> Cc: Michel Thierry <michel.thierry@intel.com>
> >> Cc: Ben Widawsky <ben@bwidawsk.net>
> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> >> ---
> >>  include/drm/i915_drm.h    |   4 +-
> >>  intel/intel_bufmgr.c      |   9 +++
> >>  intel/intel_bufmgr.h      |   1 +
> >>  intel/intel_bufmgr_gem.c  | 176
> >> ++++++++++++++++++++++++++++++++++++++++------
> >>  intel/intel_bufmgr_priv.h |   7 ++
> >>  5 files changed, 173 insertions(+), 24 deletions(-)
> >
> > Will anybody help to push the patch to libdrm? Beignet highly depend on
> this to implement ocl2.0 svm.
> 
> Is the kernel patch upstream?

Yes, the kernel patch already merged, see:
http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750

I find below line of code in libdrm does not match the kernel version. The kernel patch defined as:
"#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).

Hello Michal,

Could you help to rebase the patch against:
[Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in	i915
I think we need both 48bit & softpin in libdrm.

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..2b99fc6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_REVISION              32
 #define I915_PARAM_SUBSLICE_TOTAL	 33
 #define I915_PARAM_EU_TOTAL		 34
+#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
 
 typedef struct drm_i915_getparam {
 	int param;
@@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
 #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
 #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
 #define EXEC_OBJECT_WRITE	(1<<2)
-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
+#define EXEC_OBJECT_PINNED	(1<<3)
+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
 	__u64 flags;
 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC libdrm] intel: Add support for softpin

[Daniel Vetter]

On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
> 
> 
> > -----Original Message-----
> > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of
> > Kristian H?gsberg
> > Sent: Monday, December 14, 2015 1:34 PM
> > To: Song, Ruiling <ruiling.song@intel.com>
> > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
> > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
> > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > 
> > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
> > wrote:
> > >> -----Original Message-----
> > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> > Behalf
> > >> Of Micha? Winiarski
> > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > >> To: intel-gfx@lists.freedesktop.org
> > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
> > devel@lists.freedesktop.org;
> > >> mesa-dev@lists.freedesktop.org
> > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > >>
> > >> Softpin allows userspace to take greater control of GPU virtual address
> > >> space and eliminates the need of relocations. It can also be used to
> > >> mirror addresses between GPU and CPU (shared virtual memory).
> > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > >> created. Self-relocs don't make any sense for softpinned objects and can
> > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > >> are marked by asterisk in debug dumps.
> > >>
> > >> Cc: Thomas Daniel <thomas.daniel@intel.com>
> > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
> > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
> > >> Cc: Michel Thierry <michel.thierry@intel.com>
> > >> Cc: Ben Widawsky <ben@bwidawsk.net>
> > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > >> ---
> > >>  include/drm/i915_drm.h    |   4 +-
> > >>  intel/intel_bufmgr.c      |   9 +++
> > >>  intel/intel_bufmgr.h      |   1 +
> > >>  intel/intel_bufmgr_gem.c  | 176
> > >> ++++++++++++++++++++++++++++++++++++++++------
> > >>  intel/intel_bufmgr_priv.h |   7 ++
> > >>  5 files changed, 173 insertions(+), 24 deletions(-)
> > >
> > > Will anybody help to push the patch to libdrm? Beignet highly depend on
> > this to implement ocl2.0 svm.
> > 
> > Is the kernel patch upstream?
> 
> Yes, the kernel patch already merged, see:
> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> 
> I find below line of code in libdrm does not match the kernel version. The kernel patch defined as:
> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).

Please always regenerate the entire headers from the kernel sources using

$ make headers_install

Then copy the headers from the kernel's usr/include/drm to libdrm. Never
patch i915_drm.h manually.

Thanks, Daniel

> 
> Hello Michal,
> 
> Could you help to rebase the patch against:
> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in	i915
> I think we need both 48bit & softpin in libdrm.
> 
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index ded43b1..2b99fc6 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_REVISION              32
>  #define I915_PARAM_SUBSLICE_TOTAL	 33
>  #define I915_PARAM_EU_TOTAL		 34
> +#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
>  
>  typedef struct drm_i915_getparam {
>  	int param;
> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>  #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
>  #define EXEC_OBJECT_WRITE	(1<<2)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> +#define EXEC_OBJECT_PINNED	(1<<3)
> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>  	__u64 flags;
>  
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, December 14, 2015 4:28 PM
> To: Song, Ruiling <ruiling.song@intel.com>
> Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;
> mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
> Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
> >
> >
> > > -----Original Message-----
> > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
> Of
> > > Kristian H?gsberg
> > > Sent: Monday, December 14, 2015 1:34 PM
> > > To: Song, Ruiling <ruiling.song@intel.com>
> > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
> > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
> Widawsky
> > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > >
> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
> > > wrote:
> > > >> -----Original Message-----
> > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> > > Behalf
> > > >> Of Micha? Winiarski
> > > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > > >> To: intel-gfx@lists.freedesktop.org
> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
> > > devel@lists.freedesktop.org;
> > > >> mesa-dev@lists.freedesktop.org
> > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > >>
> > > >> Softpin allows userspace to take greater control of GPU virtual address
> > > >> space and eliminates the need of relocations. It can also be used to
> > > >> mirror addresses between GPU and CPU (shared virtual memory).
> > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > > >> created. Self-relocs don't make any sense for softpinned objects and
> can
> > > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > > >> are marked by asterisk in debug dumps.
> > > >>
> > > >> Cc: Thomas Daniel <thomas.daniel@intel.com>
> > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
> > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
> > > >> Cc: Michel Thierry <michel.thierry@intel.com>
> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>
> > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > > >> ---
> > > >>  include/drm/i915_drm.h    |   4 +-
> > > >>  intel/intel_bufmgr.c      |   9 +++
> > > >>  intel/intel_bufmgr.h      |   1 +
> > > >>  intel/intel_bufmgr_gem.c  | 176
> > > >> ++++++++++++++++++++++++++++++++++++++++------
> > > >>  intel/intel_bufmgr_priv.h |   7 ++
> > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
> > > >
> > > > Will anybody help to push the patch to libdrm? Beignet highly depend
> on
> > > this to implement ocl2.0 svm.
> > >
> > > Is the kernel patch upstream?
> >
> > Yes, the kernel patch already merged, see:
> > http://cgit.freedesktop.org/drm-
> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> >
> > I find below line of code in libdrm does not match the kernel version. The
> kernel patch defined as:
> > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
> 
> Please always regenerate the entire headers from the kernel sources using
> 
> $ make headers_install
> 
> Then copy the headers from the kernel's usr/include/drm to libdrm. Never
> patch i915_drm.h manually.

Thanks for the info. But the problem is libdrm still tracks such kind of header files.
Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?

Thanks!
Ruiling
 
> Thanks, Daniel
> 
> >
> > Hello Michal,
> >
> > Could you help to rebase the patch against:
> > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in	i915
> > I think we need both 48bit & softpin in libdrm.
> >
> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > index ded43b1..2b99fc6 100644
> > --- a/include/drm/i915_drm.h
> > +++ b/include/drm/i915_drm.h
> > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
> >  #define I915_PARAM_REVISION              32
> >  #define I915_PARAM_SUBSLICE_TOTAL	 33
> >  #define I915_PARAM_EU_TOTAL		 34
> > +#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
> >
> >  typedef struct drm_i915_getparam {
> >  	int param;
> > @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
> >  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
> >  #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
> >  #define EXEC_OBJECT_WRITE	(1<<2)
> > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> > +#define EXEC_OBJECT_PINNED	(1<<3)
> > +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
> >  	__u64 flags;
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Daniel Vetter]

On Mon, Dec 14, 2015 at 08:41:05AM +0000, Song, Ruiling wrote:
> 
> 
> > -----Original Message-----
> > From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, December 14, 2015 4:28 PM
> > To: Song, Ruiling <ruiling.song@intel.com>
> > Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;
> > mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
> > Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > 
> > On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
> > Of
> > > > Kristian H?gsberg
> > > > Sent: Monday, December 14, 2015 1:34 PM
> > > > To: Song, Ruiling <ruiling.song@intel.com>
> > > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
> > > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
> > Widawsky
> > > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > >
> > > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
> > > > wrote:
> > > > >> -----Original Message-----
> > > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> > > > Behalf
> > > > >> Of Micha? Winiarski
> > > > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > > > >> To: intel-gfx@lists.freedesktop.org
> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
> > > > devel@lists.freedesktop.org;
> > > > >> mesa-dev@lists.freedesktop.org
> > > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > > >>
> > > > >> Softpin allows userspace to take greater control of GPU virtual address
> > > > >> space and eliminates the need of relocations. It can also be used to
> > > > >> mirror addresses between GPU and CPU (shared virtual memory).
> > > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> > > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> > > > >> created. Self-relocs don't make any sense for softpinned objects and
> > can
> > > > >> indicate a programming errors, thus are forbidden. Softpinned objects
> > > > >> are marked by asterisk in debug dumps.
> > > > >>
> > > > >> Cc: Thomas Daniel <thomas.daniel@intel.com>
> > > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
> > > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
> > > > >> Cc: Michel Thierry <michel.thierry@intel.com>
> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>
> > > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > > > >> ---
> > > > >>  include/drm/i915_drm.h    |   4 +-
> > > > >>  intel/intel_bufmgr.c      |   9 +++
> > > > >>  intel/intel_bufmgr.h      |   1 +
> > > > >>  intel/intel_bufmgr_gem.c  | 176
> > > > >> ++++++++++++++++++++++++++++++++++++++++------
> > > > >>  intel/intel_bufmgr_priv.h |   7 ++
> > > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
> > > > >
> > > > > Will anybody help to push the patch to libdrm? Beignet highly depend
> > on
> > > > this to implement ocl2.0 svm.
> > > >
> > > > Is the kernel patch upstream?
> > >
> > > Yes, the kernel patch already merged, see:
> > > http://cgit.freedesktop.org/drm-
> > intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> > >
> > > I find below line of code in libdrm does not match the kernel version. The
> > kernel patch defined as:
> > > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
> > 
> > Please always regenerate the entire headers from the kernel sources using
> > 
> > $ make headers_install
> > 
> > Then copy the headers from the kernel's usr/include/drm to libdrm. Never
> > patch i915_drm.h manually.
> 
> Thanks for the info. But the problem is libdrm still tracks such kind of header files.
> Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?

All other kernel headers are extracted from the kernel directly, but
generally those packages only get update when a new kernel comes out.
Usually it's called linux-headers or similar. And only updating headers
when the release is out is _way_ too slow for drm/gfx. That's why we have
drm headers in libdrm.

But yeah we should document this, maybe even script it. Perhaps even just
upgrade headers automatically as soon as the upstream drm-next branch
changes.
-Daniel

> 
> Thanks!
> Ruiling
>  
> > Thanks, Daniel
> > 
> > >
> > > Hello Michal,
> > >
> > > Could you help to rebase the patch against:
> > > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in	i915
> > > I think we need both 48bit & softpin in libdrm.
> > >
> > > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > > index ded43b1..2b99fc6 100644
> > > --- a/include/drm/i915_drm.h
> > > +++ b/include/drm/i915_drm.h
> > > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
> > >  #define I915_PARAM_REVISION              32
> > >  #define I915_PARAM_SUBSLICE_TOTAL	 33
> > >  #define I915_PARAM_EU_TOTAL		 34
> > > +#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
> > >
> > >  typedef struct drm_i915_getparam {
> > >  	int param;
> > > @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
> > >  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
> > >  #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
> > >  #define EXEC_OBJECT_WRITE	(1<<2)
> > > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> > > +#define EXEC_OBJECT_PINNED	(1<<3)
> > > +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
> > >  	__u64 flags;
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm] intel: Add support for softpin

[Emil Velikov]

On 14 December 2015 at 09:04, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Dec 14, 2015 at 08:41:05AM +0000, Song, Ruiling wrote:
>>
>>
>> > -----Original Message-----
>> > From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
>> > Vetter
>> > Sent: Monday, December 14, 2015 4:28 PM
>> > To: Song, Ruiling <ruiling.song@intel.com>
>> > Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;
>> > mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
>> > Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> >
>> > On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
>> > Of
>> > > > Kristian H?gsberg
>> > > > Sent: Monday, December 14, 2015 1:34 PM
>> > > > To: Song, Ruiling <ruiling.song@intel.com>
>> > > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>> > > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
>> > Widawsky
>> > > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> > > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > >
>> > > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>> > > > wrote:
>> > > > >> -----Original Message-----
>> > > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>> > > > Behalf
>> > > > >> Of Micha? Winiarski
>> > > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > > >> To: intel-gfx@lists.freedesktop.org
>> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>> > > > devel@lists.freedesktop.org;
>> > > > >> mesa-dev@lists.freedesktop.org
>> > > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > > >>
>> > > > >> Softpin allows userspace to take greater control of GPU virtual address
>> > > > >> space and eliminates the need of relocations. It can also be used to
>> > > > >> mirror addresses between GPU and CPU (shared virtual memory).
>> > > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>> > > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> > > > >> created. Self-relocs don't make any sense for softpinned objects and
>> > can
>> > > > >> indicate a programming errors, thus are forbidden. Softpinned objects
>> > > > >> are marked by asterisk in debug dumps.
>> > > > >>
>> > > > >> Cc: Thomas Daniel <thomas.daniel@intel.com>
>> > > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>> > > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>> > > > >> Cc: Michel Thierry <michel.thierry@intel.com>
>> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>
>> > > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>> > > > >> ---
>> > > > >>  include/drm/i915_drm.h    |   4 +-
>> > > > >>  intel/intel_bufmgr.c      |   9 +++
>> > > > >>  intel/intel_bufmgr.h      |   1 +
>> > > > >>  intel/intel_bufmgr_gem.c  | 176
>> > > > >> ++++++++++++++++++++++++++++++++++++++++------
>> > > > >>  intel/intel_bufmgr_priv.h |   7 ++
>> > > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> > > > >
>> > > > > Will anybody help to push the patch to libdrm? Beignet highly depend
>> > on
>> > > > this to implement ocl2.0 svm.
>> > > >
>> > > > Is the kernel patch upstream?
>> > >
>> > > Yes, the kernel patch already merged, see:
>> > > http://cgit.freedesktop.org/drm-
>> > intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>> > >
>> > > I find below line of code in libdrm does not match the kernel version. The
>> > kernel patch defined as:
>> > > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>> >
>> > Please always regenerate the entire headers from the kernel sources using
>> >
>> > $ make headers_install
>> >
>> > Then copy the headers from the kernel's usr/include/drm to libdrm. Never
>> > patch i915_drm.h manually.
>>
>> Thanks for the info. But the problem is libdrm still tracks such kind of header files.
>> Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?
>
> All other kernel headers are extracted from the kernel directly, but
> generally those packages only get update when a new kernel comes out.
> Usually it's called linux-headers or similar. And only updating headers
> when the release is out is _way_ too slow for drm/gfx. That's why we have
> drm headers in libdrm.
>
That plus hysterical raisins, from when drm was part of userspace ;-)

> But yeah we should document this, maybe even script it. Perhaps even just
> upgrade headers automatically as soon as the upstream drm-next branch
> changes.
I'm all for tweaking the make target, although automating to the point
of zero developer interaction might not be ideal. Plus we do have the
occasional revert in -next and even -rcX :-\

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

RE: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

"Song, Ruiling" <ruiling.song@intel.com> writes:

>> -----Original Message-----
>> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Monday, December 14, 2015 4:28 PM
>> To: Song, Ruiling <ruiling.song@intel.com>
>> Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;
>> mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
>> Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
>> >
>> >
>> > > -----Original Message-----
>> > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
>> Of
>> > > Kristian H?gsberg
>> > > Sent: Monday, December 14, 2015 1:34 PM
>> > > To: Song, Ruiling <ruiling.song@intel.com>
>> > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>> > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
>> Widawsky
>> > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > >
>> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>> > > wrote:
>> > > >> -----Original Message-----
>> > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>> > > Behalf
>> > > >> Of Micha? Winiarski
>> > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > >> To: intel-gfx@lists.freedesktop.org
>> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>> > > devel@lists.freedesktop.org;
>> > > >> mesa-dev@lists.freedesktop.org
>> > > >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > >>
>> > > >> Softpin allows userspace to take greater control of GPU virtual address
>> > > >> space and eliminates the need of relocations. It can also be used to
>> > > >> mirror addresses between GPU and CPU (shared virtual memory).
>> > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>> > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> > > >> created. Self-relocs don't make any sense for softpinned objects and
>> can
>> > > >> indicate a programming errors, thus are forbidden. Softpinned objects
>> > > >> are marked by asterisk in debug dumps.
>> > > >>
>> > > >> Cc: Thomas Daniel <thomas.daniel@intel.com>
>> > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>> > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>> > > >> Cc: Michel Thierry <michel.thierry@intel.com>
>> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>
>> > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>> > > >> ---
>> > > >>  include/drm/i915_drm.h    |   4 +-
>> > > >>  intel/intel_bufmgr.c      |   9 +++
>> > > >>  intel/intel_bufmgr.h      |   1 +
>> > > >>  intel/intel_bufmgr_gem.c  | 176
>> > > >> ++++++++++++++++++++++++++++++++++++++++------
>> > > >>  intel/intel_bufmgr_priv.h |   7 ++
>> > > >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> > > >
>> > > > Will anybody help to push the patch to libdrm? Beignet highly depend
>> on
>> > > this to implement ocl2.0 svm.
>> > >
>> > > Is the kernel patch upstream?
>> >
>> > Yes, the kernel patch already merged, see:
>> > http://cgit.freedesktop.org/drm-
>> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>> >
>> > I find below line of code in libdrm does not match the kernel version. The
>> kernel patch defined as:
>> > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>> 
>> Please always regenerate the entire headers from the kernel sources using
>> 
>> $ make headers_install
>> 
>> Then copy the headers from the kernel's usr/include/drm to libdrm. Never
>> patch i915_drm.h manually.
>
> Thanks for the info. But the problem is libdrm still tracks such kind of header files.
> Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?

The motivation is that compiling libdrm should be independent of
kernel headers on the system. You could probably get away with requiring
some recent enough linux-headers pkg or something, but in the end this
seemed more pragmatic.

Kristian

> Thanks!
> Ruiling
>  
>> Thanks, Daniel
>> 
>> >
>> > Hello Michal,
>> >
>> > Could you help to rebase the patch against:
>> > [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in	i915
>> > I think we need both 48bit & softpin in libdrm.
>> >
>> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> > index ded43b1..2b99fc6 100644
>> > --- a/include/drm/i915_drm.h
>> > +++ b/include/drm/i915_drm.h
>> > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>> >  #define I915_PARAM_REVISION              32
>> >  #define I915_PARAM_SUBSLICE_TOTAL	 33
>> >  #define I915_PARAM_EU_TOTAL		 34
>> > +#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
>> >
>> >  typedef struct drm_i915_getparam {
>> >  	int param;
>> > @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>> >  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>> >  #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
>> >  #define EXEC_OBJECT_WRITE	(1<<2)
>> > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>> > +#define EXEC_OBJECT_PINNED	(1<<3)
>> > +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>> >  	__u64 flags;
>> >
>> > _______________________________________________
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

"Song, Ruiling" <ruiling.song@intel.com> writes:

>> -----Original Message-----
>> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of
>> Kristian H?gsberg
>> Sent: Monday, December 14, 2015 1:34 PM
>> To: Song, Ruiling <ruiling.song@intel.com>
>> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
>> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>> wrote:
>> >> -----Original Message-----
>> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>> Behalf
>> >> Of Micha? Winiarski
>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>> >> To: intel-gfx@lists.freedesktop.org
>> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>> devel@lists.freedesktop.org;
>> >> mesa-dev@lists.freedesktop.org
>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> >>
>> >> Softpin allows userspace to take greater control of GPU virtual address
>> >> space and eliminates the need of relocations. It can also be used to
>> >> mirror addresses between GPU and CPU (shared virtual memory).
>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>> >> created. Self-relocs don't make any sense for softpinned objects and can
>> >> indicate a programming errors, thus are forbidden. Softpinned objects
>> >> are marked by asterisk in debug dumps.
>> >>
>> >> Cc: Thomas Daniel <thomas.daniel@intel.com>
>> >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>> >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>> >> Cc: Michel Thierry <michel.thierry@intel.com>
>> >> Cc: Ben Widawsky <ben@bwidawsk.net>
>> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>> >> ---
>> >>  include/drm/i915_drm.h    |   4 +-
>> >>  intel/intel_bufmgr.c      |   9 +++
>> >>  intel/intel_bufmgr.h      |   1 +
>> >>  intel/intel_bufmgr_gem.c  | 176
>> >> ++++++++++++++++++++++++++++++++++++++++------
>> >>  intel/intel_bufmgr_priv.h |   7 ++
>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
>> >
>> > Will anybody help to push the patch to libdrm? Beignet highly depend on
>> this to implement ocl2.0 svm.
>> 
>> Is the kernel patch upstream?
>
> Yes, the kernel patch already merged, see:
> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>
> I find below line of code in libdrm does not match the kernel version. The kernel patch defined as:
> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).

I have the two 48 bit patches merge here. I'll pull in Michał's patch,
update the kernel header and  then push it all.

Kristian

> Hello Michal,
>
> Could you help to rebase the patch against:
> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in	i915
> I think we need both 48bit & softpin in libdrm.
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index ded43b1..2b99fc6 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_REVISION              32
>  #define I915_PARAM_SUBSLICE_TOTAL	 33
>  #define I915_PARAM_EU_TOTAL		 34
> +#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
>  
>  typedef struct drm_i915_getparam {
>  	int param;
> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>  #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
>  #define EXEC_OBJECT_WRITE	(1<<2)
> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
> +#define EXEC_OBJECT_PINNED	(1<<3)
> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>  	__u64 flags;
>  
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [RFC libdrm] intel: Add support for softpin

[Kristian Høgsberg]

Kristian Høgsberg <hoegsberg@gmail.com> writes:

> "Song, Ruiling" <ruiling.song@intel.com> writes:
>
>>> -----Original Message-----
>>> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of
>>> Kristian H?gsberg
>>> Sent: Monday, December 14, 2015 1:34 PM
>>> To: Song, Ruiling <ruiling.song@intel.com>
>>> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>>> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
>>> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>> 
>>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>>> wrote:
>>> >> -----Original Message-----
>>> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>>> Behalf
>>> >> Of Micha? Winiarski
>>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>>> >> To: intel-gfx@lists.freedesktop.org
>>> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>>> devel@lists.freedesktop.org;
>>> >> mesa-dev@lists.freedesktop.org
>>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>> >>
>>> >> Softpin allows userspace to take greater control of GPU virtual address
>>> >> space and eliminates the need of relocations. It can also be used to
>>> >> mirror addresses between GPU and CPU (shared virtual memory).
>>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
>>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
>>> >> created. Self-relocs don't make any sense for softpinned objects and can
>>> >> indicate a programming errors, thus are forbidden. Softpinned objects
>>> >> are marked by asterisk in debug dumps.
>>> >>
>>> >> Cc: Thomas Daniel <thomas.daniel@intel.com>
>>> >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>>> >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>>> >> Cc: Michel Thierry <michel.thierry@intel.com>
>>> >> Cc: Ben Widawsky <ben@bwidawsk.net>
>>> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>>> >> ---
>>> >>  include/drm/i915_drm.h    |   4 +-
>>> >>  intel/intel_bufmgr.c      |   9 +++
>>> >>  intel/intel_bufmgr.h      |   1 +
>>> >>  intel/intel_bufmgr_gem.c  | 176
>>> >> ++++++++++++++++++++++++++++++++++++++++------
>>> >>  intel/intel_bufmgr_priv.h |   7 ++
>>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
>>> >
>>> > Will anybody help to push the patch to libdrm? Beignet highly depend on
>>> this to implement ocl2.0 svm.
>>> 
>>> Is the kernel patch upstream?
>>
>> Yes, the kernel patch already merged, see:
>> http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
>>
>> I find below line of code in libdrm does not match the kernel version. The kernel patch defined as:
>> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3).
>
> I have the two 48 bit patches merge here. I'll pull in Michał's patch,
> update the kernel header and  then push it all.

All pushed now.

Kristian

>> Hello Michal,
>>
>> Could you help to rebase the patch against:
>> [Intel-gfx] [PATCH libdrm v4 0/2] 48-bit virtual address support in	i915
>> I think we need both 48bit & softpin in libdrm.
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index ded43b1..2b99fc6 100644
>> --- a/include/drm/i915_drm.h
>> +++ b/include/drm/i915_drm.h
>> @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
>>  #define I915_PARAM_REVISION              32
>>  #define I915_PARAM_SUBSLICE_TOTAL	 33
>>  #define I915_PARAM_EU_TOTAL		 34
>> +#define I915_PARAM_HAS_EXEC_SOFTPIN	 37
>>  
>>  typedef struct drm_i915_getparam {
>>  	int param;
>> @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 {
>>  #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>>  #define EXEC_OBJECT_NEEDS_GTT	(1<<1)
>>  #define EXEC_OBJECT_WRITE	(1<<2)
>> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>> +#define EXEC_OBJECT_PINNED	(1<<3)
>> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1)
>>  	__u64 flags;
>>  
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

RE: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -----Original Message-----
> From: Kristian Høgsberg [mailto:hoegsberg@gmail.com]
> Sent: Tuesday, December 15, 2015 4:09 AM
> To: Song, Ruiling <ruiling.song@intel.com>; krh@bitplanet.net; Winiarski,
> Michal <michal.winiarski@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
> Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org; Yang,
> Rong R <rong.r.yang@intel.com>
> Subject: RE: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> Kristian Høgsberg <hoegsberg@gmail.com> writes:
> 
> > "Song, Ruiling" <ruiling.song@intel.com> writes:
> >
> >>> -----Original Message-----
> >>> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
> Of
> >>> Kristian H?gsberg
> >>> Sent: Monday, December 14, 2015 1:34 PM
> >>> To: Song, Ruiling <ruiling.song@intel.com>
> >>> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
> >>> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
> Widawsky
> >>> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >>>
> >>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
> >>> wrote:
> >>> >> -----Original Message-----
> >>> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> >>> Behalf
> >>> >> Of Micha? Winiarski
> >>> >> Sent: Wednesday, September 9, 2015 10:07 PM
> >>> >> To: intel-gfx@lists.freedesktop.org
> >>> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
> >>> devel@lists.freedesktop.org;
> >>> >> mesa-dev@lists.freedesktop.org
> >>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >>> >>
> >>> >> Softpin allows userspace to take greater control of GPU virtual
> address
> >>> >> space and eliminates the need of relocations. It can also be used to
> >>> >> mirror addresses between GPU and CPU (shared virtual memory).
> >>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> >>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs
> are
> >>> >> created. Self-relocs don't make any sense for softpinned objects and
> can
> >>> >> indicate a programming errors, thus are forbidden. Softpinned
> objects
> >>> >> are marked by asterisk in debug dumps.
> >>> >>
> >>> >> Cc: Thomas Daniel <thomas.daniel@intel.com>
> >>> >> Cc: Kristian Høgsberg <krh@bitplanet.net>
> >>> >> Cc: Zou Nanhai <nanhai.zou@intel.com>
> >>> >> Cc: Michel Thierry <michel.thierry@intel.com>
> >>> >> Cc: Ben Widawsky <ben@bwidawsk.net>
> >>> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >>> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> >>> >> ---
> >>> >>  include/drm/i915_drm.h    |   4 +-
> >>> >>  intel/intel_bufmgr.c      |   9 +++
> >>> >>  intel/intel_bufmgr.h      |   1 +
> >>> >>  intel/intel_bufmgr_gem.c  | 176
> >>> >> ++++++++++++++++++++++++++++++++++++++++------
> >>> >>  intel/intel_bufmgr_priv.h |   7 ++
> >>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
> >>> >
> >>> > Will anybody help to push the patch to libdrm? Beignet highly depend
> on
> >>> this to implement ocl2.0 svm.
> >>>
> >>> Is the kernel patch upstream?
> >>
> >> Yes, the kernel patch already merged, see:
> >> http://cgit.freedesktop.org/drm-
> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> >>
> >> I find below line of code in libdrm does not match the kernel version. The
> kernel patch defined as:
> >> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as
> (1<<3).
> >
> > I have the two 48 bit patches merge here. I'll pull in Michał's patch,
> > update the kernel header and  then push it all.
> 
> All pushed now.

Thanks. We have tried some basic OpenCL tests. Both patches work!
I have another question, does KMD allow soft-pin a bo at zero address?
I have tried to pin a bo with the size of 64KB at zero address in Beignet. It can succeed.
But I met some random failure with bo_exec() returning -EINVAL.
I am trying to figure out why. So I want to confirm is it allowed by KMD?

Thanks!
Ruiling

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm] intel: Add support for softpin

[Chris Wilson]

On Wed, Sep 09, 2015 at 04:07:10PM +0200, Michał Winiarski wrote:
> Softpin allows userspace to take greater control of GPU virtual address
> space and eliminates the need of relocations. It can also be used to
> mirror addresses between GPU and CPU (shared virtual memory).
> Calls to drm_intel_bo_emit_reloc are still required to build the list of
> drm_i915_gem_exec_objects at exec time, but no entries in relocs are
> created. Self-relocs don't make any sense for softpinned objects and can
> indicate a programming errors, thus are forbidden. Softpinned objects
> are marked by asterisk in debug dumps.

This patch gets the kernel interface wrong.

>  static int
> +drm_intel_gem_bo_add_softpin_target(drm_intel_bo *bo, drm_intel_bo *target_bo)
> +{
> +	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
> +	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> +	drm_intel_bo_gem *target_bo_gem = (drm_intel_bo_gem *) target_bo;
> +	if (bo_gem->has_error)
> +		return -ENOMEM;
> +
> +	if (target_bo_gem->has_error) {
> +		bo_gem->has_error = true;
> +		return -ENOMEM;
> +	}
> +
> +	if (!target_bo_gem->is_softpin)
> +		return -EINVAL;
> +	if (target_bo_gem == bo_gem)
> +		return -EINVAL;
> +
> +	if (bo_gem->softpin_target_count == bo_gem->softpin_target_size) {
> +		int new_size = bo_gem->softpin_target_size * 2;
> +		if (new_size == 0)
> +			new_size = bufmgr_gem->max_relocs;
> +
> +		bo_gem->softpin_target = realloc(bo_gem->softpin_target, new_size *
> +				sizeof(drm_intel_bo *));
> +		if (!bo_gem->softpin_target)
> +			return -ENOMEM;
> +
> +		bo_gem->softpin_target_size = new_size;
> +	}
> +	bo_gem->softpin_target[bo_gem->softpin_target_count] = target_bo;
> +	drm_intel_gem_bo_reference(target_bo);
> +	bo_gem->softpin_target_count++;
> +
> +	return 0;
> +}

Short-circuiting the reloc handling like this is broken without
instructing the kernel via the alternative mechanisms about the special
handling the buffer requires EXEC_OBJECT_WRITE, EXEC_OBJECT_NEEDS_GTT).

>  void
>  drm_intel_gem_bo_clear_relocs(drm_intel_bo *bo, int start)
> @@ -1998,6 +2084,12 @@ drm_intel_gem_bo_clear_relocs(drm_intel_bo *bo, int start)
>  	}
>  	bo_gem->reloc_count = start;
>  
> +	for (i = 0; i < bo_gem->softpin_target_count; i++) {
> +		drm_intel_bo_gem *target_bo_gem = (drm_intel_bo_gem *) bo_gem->softpin_target[i];
> +		drm_intel_gem_bo_unreference_locked_timed(&target_bo_gem->bo, time.tv_sec);
> +	}
> +	bo_gem->softpin_target_count = 0;

This would have better pursued using a batch manager.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx