On Tue, Nov 15, 2022 at 04:58:42PM +0100, Andi Shyti wrote:
Hi Niranjana,
On Sat, Nov 12, 2022 at 11:57:32PM -0800, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathap...@intel.com>
---
.../drm/i915/gem/i915_gem_vm_bind_object.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +++++++++++++++++--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct i915_address_space
*vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
I still like the defines on this, they look cleaner, but it's a
matter of taste.
Ok, will change.
Niranjana
Reviewed-by: Andi Shyti <andi.sh...@linux.intel.com>
Andi