All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hellstrom, Thomas" <thomas.hellstrom@intel.com>
To: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Vishwanathapura,
	Niranjana" <niranjana.vishwanathapura@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Brost, Matthew" <matthew.brost@intel.com>,
	"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>,
	"Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>,
	"Landwerlin, Lionel G" <lionel.g.landwerlin@intel.com>,
	"Auld, Matthew" <matthew.auld@intel.com>,
	"jason@jlekstrand.net" <jason@jlekstrand.net>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>
Subject: Re: [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes
Date: Thu, 7 Jul 2022 13:11:13 +0000	[thread overview]
Message-ID: <d1c8cd2c44c07ebc7053f192100bf0ee5aa67140.camel@intel.com> (raw)
In-Reply-To: <20220701225055.8204-9-niranjana.vishwanathapura@intel.com>

On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> For persistent (vm_bind) vmas of userptr BOs, handle the user
> page pinning by using the i915_gem_object_userptr_submit_init()
> /done() functions
> 
> Signed-off-by: Niranjana Vishwanathapura
> <niranjana.vishwanathapura@intel.com>
> ---
>  .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 67
> +++++++++++++++++++
>  .../drm/i915/gem/i915_gem_vm_bind_object.c    | 16 +++++
>  drivers/gpu/drm/i915/gt/intel_gtt.c           |  1 +
>  drivers/gpu/drm/i915/gt/intel_gtt.h           |  1 +
>  4 files changed, 85 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> index 2079f5ca9010..bf13dd6d642e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> @@ -22,6 +22,7 @@
>  #include "i915_gem_vm_bind.h"
>  #include "i915_trace.h"
>  
> +#define __EXEC3_USERPTR_USED           BIT_ULL(34)
>  #define __EXEC3_HAS_PIN                        BIT_ULL(33)
>  #define __EXEC3_ENGINE_PINNED          BIT_ULL(32)
>  #define __EXEC3_INTERNAL_FLAGS         (~0ull << 32)
> @@ -147,10 +148,36 @@ static void eb_scoop_unbound_vmas(struct
> i915_address_space *vm)
>         spin_unlock(&vm->vm_rebind_lock);
>  }
>  
> +static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer
> *eb)
> +{
> +       struct i915_address_space *vm = eb->context->vm;
> +       struct i915_vma *last_vma = NULL;
> +       struct i915_vma *vma;
> +       int err;
> +
> +       assert_vm_bind_held(vm);
> +
> +       list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link) {
> +               if (i915_gem_object_is_userptr(vma->obj)) {
> +                       err =
> i915_gem_object_userptr_submit_init(vma->obj);
> +                       if (err)
> +                               return err;
> +
> +                       last_vma = vma;
> +               }
> +       }
> +

Don't we need to loop also over non-private userptr objects?


> +       if (last_vma)
> +               eb->args->flags |= __EXEC3_USERPTR_USED;
> +
> +       return 0;
> +}
> +
>  static int eb_lookup_vmas(struct i915_execbuffer *eb)
>  {
>         unsigned int i, current_batch = 0;
>         struct i915_vma *vma;
> +       int err = 0;
>  
>         for (i = 0; i < eb->num_batches; i++) {
>                 vma = eb_find_vma(eb->context->vm, eb-
> >batch_addresses[i]);
> @@ -163,6 +190,10 @@ static int eb_lookup_vmas(struct i915_execbuffer
> *eb)
>  
>         eb_scoop_unbound_vmas(eb->context->vm);
>  
> +       err = eb_lookup_persistent_userptr_vmas(eb);
> +       if (err)
> +               return err;
> +
>         return 0;
>  }
>  
> @@ -358,15 +389,51 @@ static void
> eb_persistent_vmas_move_to_active(struct i915_execbuffer *eb)
>  
>  static int eb_move_to_gpu(struct i915_execbuffer *eb)
>  {
> +       int err = 0, j;
> +
>         assert_vm_bind_held(eb->context->vm);
>         assert_vm_priv_held(eb->context->vm);
>  
>         eb_persistent_vmas_move_to_active(eb);
>  
> +#ifdef CONFIG_MMU_NOTIFIER
> +       if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
> +               struct i915_vma *vma;
> +
> +               assert_vm_bind_held(eb->context->vm);
> +               assert_vm_priv_held(eb->context->vm);
> +
> +               read_lock(&eb->i915->mm.notifier_lock);
> +               list_for_each_entry(vma, &eb->context->vm-
> >vm_bind_list,
> +                                   vm_bind_link) {
> +                       if (!i915_gem_object_is_userptr(vma->obj))
> +                               continue;
> +
> +                       err =
> i915_gem_object_userptr_submit_done(vma->obj);
> +                       if (err)
> +                               break;
> +               }
> +
> +               read_unlock(&eb->i915->mm.notifier_lock);
> +       }

Since we don't loop over the vm_bound_list, there is a need to check
whether the rebind_list is empty here under the notifier_lock in read
mode, and in that case, restart from eb_lookup_vmas(). That might also
eliminate the need for the __EXEC3_USERPTR_USED flag?

That will also catch any objects that were evicted between
eb_lookup_vmas() where the rebind_list was last checked, and
i915_gem_vm_priv_lock(), which prohibits further eviction, but if we
want to catch these earlier (which I think is a good idea), we could
check that the rebind_list is indeed empty just after taking the
vm_priv_lock(), and if not, restart from eb_lookup_vmas().


> +#endif
> +
> +       if (unlikely(err))
> +               goto err_skip;
> +
>         /* Unconditionally flush any chipset caches (for streaming
> writes). */
>         intel_gt_chipset_flush(eb->gt);
>  
>         return 0;
> +
> +err_skip:
> +       for_each_batch_create_order(eb, j) {
> +               if (!eb->requests[j])
> +                       break;
> +
> +               i915_request_set_error_once(eb->requests[j], err);
> +       }
> +       return err;
>  }
>  
>  static int eb_request_submit(struct i915_execbuffer *eb,
> 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 1a8efa83547f..cae282b91618 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
> @@ -263,6 +263,12 @@ int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
>                 goto put_obj;
>         }
>  
> +       if (i915_gem_object_is_userptr(obj)) {
> +               ret = i915_gem_object_userptr_submit_init(obj);
> +               if (ret)
> +                       goto put_obj;
> +       }
> +
>         ret = i915_gem_vm_bind_lock_interruptible(vm);
>         if (ret)
>                 goto put_obj;
> @@ -295,6 +301,16 @@ int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
>         /* Make it evictable */
>         __i915_vma_unpin(vma);
>  
> +#ifdef CONFIG_MMU_NOTIFIER
> +       if (i915_gem_object_is_userptr(obj)) {
> +               write_lock(&vm->i915->mm.notifier_lock);

Why do we need the lock in write mode here? 

> +               ret = i915_gem_object_userptr_submit_done(obj);
> +               write_unlock(&vm->i915->mm.notifier_lock);
> +               if (ret)
> +                       goto out_ww;
> +       }
> +#endif
> +
>         list_add_tail(&vma->vm_bind_link, &vm->vm_bound_list);
>         i915_vm_bind_it_insert(vma, &vm->va);
>         if (!obj->priv_root)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index 55d5389b2c6c..4ab3bda644ff 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -295,6 +295,7 @@ void i915_address_space_init(struct
> i915_address_space *vm, int subclass)
>         GEM_BUG_ON(IS_ERR(vm->root_obj));
>         INIT_LIST_HEAD(&vm->vm_rebind_list);
>         spin_lock_init(&vm->vm_rebind_lock);
> +       INIT_LIST_HEAD(&vm->invalidate_link);
>  }
>  
>  void *__px_vaddr(struct drm_i915_gem_object *p)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index fe5485c4a1cd..f9edf11c144f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -267,6 +267,7 @@ struct i915_address_space {
>         struct list_head vm_bound_list;
>         struct list_head vm_rebind_list;
>         spinlock_t vm_rebind_lock;   /* Protects vm_rebind_list */
> +       struct list_head invalidate_link;
>         /* va tree of persistent vmas */
>         struct rb_root_cached va;
>         struct list_head non_priv_vm_bind_list;


WARNING: multiple messages have this Message-ID (diff)
From: "Hellstrom, Thomas" <thomas.hellstrom@intel.com>
To: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Vishwanathapura,
	Niranjana" <niranjana.vishwanathapura@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>,
	"Auld, Matthew" <matthew.auld@intel.com>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes
Date: Thu, 7 Jul 2022 13:11:13 +0000	[thread overview]
Message-ID: <d1c8cd2c44c07ebc7053f192100bf0ee5aa67140.camel@intel.com> (raw)
In-Reply-To: <20220701225055.8204-9-niranjana.vishwanathapura@intel.com>

On Fri, 2022-07-01 at 15:50 -0700, Niranjana Vishwanathapura wrote:
> For persistent (vm_bind) vmas of userptr BOs, handle the user
> page pinning by using the i915_gem_object_userptr_submit_init()
> /done() functions
> 
> Signed-off-by: Niranjana Vishwanathapura
> <niranjana.vishwanathapura@intel.com>
> ---
>  .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 67
> +++++++++++++++++++
>  .../drm/i915/gem/i915_gem_vm_bind_object.c    | 16 +++++
>  drivers/gpu/drm/i915/gt/intel_gtt.c           |  1 +
>  drivers/gpu/drm/i915/gt/intel_gtt.h           |  1 +
>  4 files changed, 85 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> index 2079f5ca9010..bf13dd6d642e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
> @@ -22,6 +22,7 @@
>  #include "i915_gem_vm_bind.h"
>  #include "i915_trace.h"
>  
> +#define __EXEC3_USERPTR_USED           BIT_ULL(34)
>  #define __EXEC3_HAS_PIN                        BIT_ULL(33)
>  #define __EXEC3_ENGINE_PINNED          BIT_ULL(32)
>  #define __EXEC3_INTERNAL_FLAGS         (~0ull << 32)
> @@ -147,10 +148,36 @@ static void eb_scoop_unbound_vmas(struct
> i915_address_space *vm)
>         spin_unlock(&vm->vm_rebind_lock);
>  }
>  
> +static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer
> *eb)
> +{
> +       struct i915_address_space *vm = eb->context->vm;
> +       struct i915_vma *last_vma = NULL;
> +       struct i915_vma *vma;
> +       int err;
> +
> +       assert_vm_bind_held(vm);
> +
> +       list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link) {
> +               if (i915_gem_object_is_userptr(vma->obj)) {
> +                       err =
> i915_gem_object_userptr_submit_init(vma->obj);
> +                       if (err)
> +                               return err;
> +
> +                       last_vma = vma;
> +               }
> +       }
> +

Don't we need to loop also over non-private userptr objects?


> +       if (last_vma)
> +               eb->args->flags |= __EXEC3_USERPTR_USED;
> +
> +       return 0;
> +}
> +
>  static int eb_lookup_vmas(struct i915_execbuffer *eb)
>  {
>         unsigned int i, current_batch = 0;
>         struct i915_vma *vma;
> +       int err = 0;
>  
>         for (i = 0; i < eb->num_batches; i++) {
>                 vma = eb_find_vma(eb->context->vm, eb-
> >batch_addresses[i]);
> @@ -163,6 +190,10 @@ static int eb_lookup_vmas(struct i915_execbuffer
> *eb)
>  
>         eb_scoop_unbound_vmas(eb->context->vm);
>  
> +       err = eb_lookup_persistent_userptr_vmas(eb);
> +       if (err)
> +               return err;
> +
>         return 0;
>  }
>  
> @@ -358,15 +389,51 @@ static void
> eb_persistent_vmas_move_to_active(struct i915_execbuffer *eb)
>  
>  static int eb_move_to_gpu(struct i915_execbuffer *eb)
>  {
> +       int err = 0, j;
> +
>         assert_vm_bind_held(eb->context->vm);
>         assert_vm_priv_held(eb->context->vm);
>  
>         eb_persistent_vmas_move_to_active(eb);
>  
> +#ifdef CONFIG_MMU_NOTIFIER
> +       if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
> +               struct i915_vma *vma;
> +
> +               assert_vm_bind_held(eb->context->vm);
> +               assert_vm_priv_held(eb->context->vm);
> +
> +               read_lock(&eb->i915->mm.notifier_lock);
> +               list_for_each_entry(vma, &eb->context->vm-
> >vm_bind_list,
> +                                   vm_bind_link) {
> +                       if (!i915_gem_object_is_userptr(vma->obj))
> +                               continue;
> +
> +                       err =
> i915_gem_object_userptr_submit_done(vma->obj);
> +                       if (err)
> +                               break;
> +               }
> +
> +               read_unlock(&eb->i915->mm.notifier_lock);
> +       }

Since we don't loop over the vm_bound_list, there is a need to check
whether the rebind_list is empty here under the notifier_lock in read
mode, and in that case, restart from eb_lookup_vmas(). That might also
eliminate the need for the __EXEC3_USERPTR_USED flag?

That will also catch any objects that were evicted between
eb_lookup_vmas() where the rebind_list was last checked, and
i915_gem_vm_priv_lock(), which prohibits further eviction, but if we
want to catch these earlier (which I think is a good idea), we could
check that the rebind_list is indeed empty just after taking the
vm_priv_lock(), and if not, restart from eb_lookup_vmas().


> +#endif
> +
> +       if (unlikely(err))
> +               goto err_skip;
> +
>         /* Unconditionally flush any chipset caches (for streaming
> writes). */
>         intel_gt_chipset_flush(eb->gt);
>  
>         return 0;
> +
> +err_skip:
> +       for_each_batch_create_order(eb, j) {
> +               if (!eb->requests[j])
> +                       break;
> +
> +               i915_request_set_error_once(eb->requests[j], err);
> +       }
> +       return err;
>  }
>  
>  static int eb_request_submit(struct i915_execbuffer *eb,
> 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 1a8efa83547f..cae282b91618 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
> @@ -263,6 +263,12 @@ int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
>                 goto put_obj;
>         }
>  
> +       if (i915_gem_object_is_userptr(obj)) {
> +               ret = i915_gem_object_userptr_submit_init(obj);
> +               if (ret)
> +                       goto put_obj;
> +       }
> +
>         ret = i915_gem_vm_bind_lock_interruptible(vm);
>         if (ret)
>                 goto put_obj;
> @@ -295,6 +301,16 @@ int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
>         /* Make it evictable */
>         __i915_vma_unpin(vma);
>  
> +#ifdef CONFIG_MMU_NOTIFIER
> +       if (i915_gem_object_is_userptr(obj)) {
> +               write_lock(&vm->i915->mm.notifier_lock);

Why do we need the lock in write mode here? 

> +               ret = i915_gem_object_userptr_submit_done(obj);
> +               write_unlock(&vm->i915->mm.notifier_lock);
> +               if (ret)
> +                       goto out_ww;
> +       }
> +#endif
> +
>         list_add_tail(&vma->vm_bind_link, &vm->vm_bound_list);
>         i915_vm_bind_it_insert(vma, &vm->va);
>         if (!obj->priv_root)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index 55d5389b2c6c..4ab3bda644ff 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -295,6 +295,7 @@ void i915_address_space_init(struct
> i915_address_space *vm, int subclass)
>         GEM_BUG_ON(IS_ERR(vm->root_obj));
>         INIT_LIST_HEAD(&vm->vm_rebind_list);
>         spin_lock_init(&vm->vm_rebind_lock);
> +       INIT_LIST_HEAD(&vm->invalidate_link);
>  }
>  
>  void *__px_vaddr(struct drm_i915_gem_object *p)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index fe5485c4a1cd..f9edf11c144f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -267,6 +267,7 @@ struct i915_address_space {
>         struct list_head vm_bound_list;
>         struct list_head vm_rebind_list;
>         spinlock_t vm_rebind_lock;   /* Protects vm_rebind_list */
> +       struct list_head invalidate_link;
>         /* va tree of persistent vmas */
>         struct rb_root_cached va;
>         struct list_head non_priv_vm_bind_list;


  reply	other threads:[~2022-07-07 13:11 UTC|newest]

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01 22:50 [RFC 00/10] drm/i915/vm_bind: Add VM_BIND functionality Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 01/10] drm/i915/vm_bind: Introduce VM_BIND ioctl Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-05  9:59   ` Hellstrom, Thomas
2022-07-05  9:59     ` Hellstrom, Thomas
2022-07-07  1:18     ` [Intel-gfx] " Andi Shyti
2022-07-07  1:18       ` Andi Shyti
2022-07-07  5:06       ` Niranjana Vishwanathapura
2022-07-07  5:01     ` Niranjana Vishwanathapura
2022-07-07  5:01       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-07  7:32       ` Hellstrom, Thomas
2022-07-07  7:32         ` [Intel-gfx] " Hellstrom, Thomas
2022-07-08 12:58         ` Niranjana Vishwanathapura
2022-07-08 12:58           ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 02/10] drm/i915/vm_bind: Bind and unbind mappings Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-06 16:21   ` Thomas Hellström
2022-07-06 16:21     ` [Intel-gfx] " Thomas Hellström
2022-07-07  1:41     ` Andi Shyti
2022-07-07  1:41       ` Andi Shyti
2022-07-07  5:48       ` Niranjana Vishwanathapura
2022-07-07  5:43     ` Niranjana Vishwanathapura
2022-07-07  5:43       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-07  8:14       ` Thomas Hellström
2022-07-07  8:14         ` [Intel-gfx] " Thomas Hellström
2022-07-08 12:57         ` Niranjana Vishwanathapura
2022-07-08 12:57           ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-18 10:55   ` Tvrtko Ursulin
2022-07-26  5:07     ` Niranjana Vishwanathapura
2022-07-26  8:40       ` Tvrtko Ursulin
2022-07-01 22:50 ` [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-07 10:31   ` Hellstrom, Thomas
2022-07-07 10:31     ` [Intel-gfx] " Hellstrom, Thomas
2022-07-08 13:14     ` Niranjana Vishwanathapura
2022-07-08 13:14       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-08 13:43       ` Hellstrom, Thomas
2022-07-08 13:43         ` [Intel-gfx] " Hellstrom, Thomas
2022-07-08 14:44         ` Hellstrom, Thomas
2022-07-08 14:44           ` [Intel-gfx] " Hellstrom, Thomas
2022-07-09 20:13           ` Niranjana Vishwanathapura
2022-07-09 20:13             ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-07 13:27   ` Christian König
2022-07-07 13:27     ` [Intel-gfx] " Christian König
2022-07-08 13:23     ` Niranjana Vishwanathapura
2022-07-08 13:23       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-08 17:32       ` Christian König
2022-07-08 17:32         ` [Intel-gfx] " Christian König
2022-07-09 20:14         ` Niranjana Vishwanathapura
2022-07-09 20:14           ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 04/10] drm/i915/vm_bind: Add out fence support Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 05/10] drm/i915/vm_bind: Handle persistent vmas Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-04 17:05   ` Zeng, Oak
2022-07-04 17:05     ` Zeng, Oak
2022-07-05  9:20     ` Ramalingam C
2022-07-05  9:20       ` Ramalingam C
2022-07-05 13:50       ` Zeng, Oak
2022-07-05 13:50         ` Zeng, Oak
2022-07-07  6:00         ` Niranjana Vishwanathapura
2022-07-07 11:27   ` Hellstrom, Thomas
2022-07-07 11:27     ` [Intel-gfx] " Hellstrom, Thomas
2022-07-08 15:06     ` Niranjana Vishwanathapura
2022-07-08 15:06       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 06/10] drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-07 14:41   ` Hellstrom, Thomas
2022-07-07 14:41     ` [Intel-gfx] " Hellstrom, Thomas
2022-07-07 19:38     ` Andi Shyti
2022-07-07 19:38       ` Andi Shyti
2022-07-08 12:22       ` Hellstrom, Thomas
2022-07-08 12:22         ` Hellstrom, Thomas
2022-07-08 13:47     ` Niranjana Vishwanathapura
2022-07-08 13:47       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-08 14:37       ` Hellstrom, Thomas
2022-07-08 14:37         ` [Intel-gfx] " Hellstrom, Thomas
2022-07-09 20:23         ` Niranjana Vishwanathapura
2022-07-09 20:23           ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 07/10] drm/i915/vm_bind: Handle persistent vmas in execbuf3 Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-07 14:54   ` Hellstrom, Thomas
2022-07-07 14:54     ` [Intel-gfx] " Hellstrom, Thomas
2022-07-08 12:44     ` Niranjana Vishwanathapura
2022-07-08 12:44       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-08 13:03       ` Hellstrom, Thomas
2022-07-08 13:03         ` [Intel-gfx] " Hellstrom, Thomas
2022-07-09 20:25         ` Niranjana Vishwanathapura
2022-07-09 20:25           ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-07 13:11   ` Hellstrom, Thomas [this message]
2022-07-07 13:11     ` Hellstrom, Thomas
2022-07-08 14:51     ` Niranjana Vishwanathapura
2022-07-08 14:51       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-08 15:20       ` Hellstrom, Thomas
2022-07-08 15:20         ` [Intel-gfx] " Hellstrom, Thomas
2022-07-09 20:56         ` Niranjana Vishwanathapura
2022-07-09 20:56           ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-08 12:17   ` Hellstrom, Thomas
2022-07-08 12:17     ` [Intel-gfx] " Hellstrom, Thomas
2022-07-08 14:54     ` Niranjana Vishwanathapura
2022-07-08 14:54       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 09/10] drm/i915/vm_bind: Skip vma_lookup for persistent vmas Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-05  8:57   ` Thomas Hellström
2022-07-05  8:57     ` Thomas Hellström
2022-07-08 12:40     ` Niranjana Vishwanathapura
2022-07-08 12:40       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 22:50 ` [RFC 10/10] drm/i915/vm_bind: Fix vm->vm_bind_mutex and vm->mutex nesting Niranjana Vishwanathapura
2022-07-01 22:50   ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-05  8:40   ` Thomas Hellström
2022-07-05  8:40     ` [Intel-gfx] " Thomas Hellström
2022-07-06 16:33     ` Ramalingam C
2022-07-06 16:33       ` [Intel-gfx] " Ramalingam C
2022-07-07  5:56     ` Niranjana Vishwanathapura
2022-07-07  5:56       ` [Intel-gfx] " Niranjana Vishwanathapura
2022-07-01 23:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vm_bind: Add VM_BIND functionality Patchwork
2022-07-01 23:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-07-01 23:40 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1c8cd2c44c07ebc7053f192100bf0ee5aa67140.camel@intel.com \
    --to=thomas.hellstrom@intel.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=lionel.g.landwerlin@intel.com \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=niranjana.vishwanathapura@intel.com \
    --cc=paulo.r.zanoni@intel.com \
    --cc=tvrtko.ursulin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.