public inbox for intel-gfx@lists.freedesktop.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: "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: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01 22:50 [Intel-gfx] [RFC 00/10] drm/i915/vm_bind: Add VM_BIND functionality Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 01/10] drm/i915/vm_bind: Introduce VM_BIND ioctl Niranjana Vishwanathapura
2022-07-05  9:59   ` Hellstrom, Thomas
2022-07-07  1:18     ` Andi Shyti
2022-07-07  5:06       ` Niranjana Vishwanathapura
2022-07-07  5:01     ` Niranjana Vishwanathapura
2022-07-07  7:32       ` Hellstrom, Thomas
2022-07-08 12:58         ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 02/10] drm/i915/vm_bind: Bind and unbind mappings Niranjana Vishwanathapura
2022-07-06 16:21   ` Thomas Hellström
2022-07-07  1:41     ` Andi Shyti
2022-07-07  5:48       ` Niranjana Vishwanathapura
2022-07-07  5:43     ` Niranjana Vishwanathapura
2022-07-07  8:14       ` Thomas Hellström
2022-07-08 12:57         ` 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 ` [Intel-gfx] [RFC 03/10] drm/i915/vm_bind: Support private and shared BOs Niranjana Vishwanathapura
2022-07-07 10:31   ` Hellstrom, Thomas
2022-07-08 13:14     ` Niranjana Vishwanathapura
2022-07-08 13:43       ` Hellstrom, Thomas
2022-07-08 14:44         ` Hellstrom, Thomas
2022-07-09 20:13           ` Niranjana Vishwanathapura
2022-07-07 13:27   ` Christian König
2022-07-08 13:23     ` Niranjana Vishwanathapura
2022-07-08 17:32       ` Christian König
2022-07-09 20:14         ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 04/10] drm/i915/vm_bind: Add out fence support Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 05/10] drm/i915/vm_bind: Handle persistent vmas Niranjana Vishwanathapura
2022-07-04 17:05   ` Zeng, Oak
2022-07-05  9:20     ` Ramalingam C
2022-07-05 13:50       ` Zeng, Oak
2022-07-07  6:00         ` Niranjana Vishwanathapura
2022-07-07 11:27   ` Hellstrom, Thomas
2022-07-08 15:06     ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 06/10] drm/i915/vm_bind: Add I915_GEM_EXECBUFFER3 ioctl Niranjana Vishwanathapura
2022-07-07 14:41   ` Hellstrom, Thomas
2022-07-07 19:38     ` Andi Shyti
2022-07-08 12:22       ` Hellstrom, Thomas
2022-07-08 13:47     ` Niranjana Vishwanathapura
2022-07-08 14:37       ` Hellstrom, Thomas
2022-07-09 20:23         ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 07/10] drm/i915/vm_bind: Handle persistent vmas in execbuf3 Niranjana Vishwanathapura
2022-07-07 14:54   ` Hellstrom, Thomas
2022-07-08 12:44     ` Niranjana Vishwanathapura
2022-07-08 13:03       ` Hellstrom, Thomas
2022-07-09 20:25         ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes Niranjana Vishwanathapura
2022-07-07 13:11   ` Hellstrom, Thomas [this message]
2022-07-08 14:51     ` Niranjana Vishwanathapura
2022-07-08 15:20       ` Hellstrom, Thomas
2022-07-09 20:56         ` Niranjana Vishwanathapura
2022-07-08 12:17   ` Hellstrom, Thomas
2022-07-08 14:54     ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 09/10] drm/i915/vm_bind: Skip vma_lookup for persistent vmas Niranjana Vishwanathapura
2022-07-05  8:57   ` Thomas Hellström
2022-07-08 12:40     ` Niranjana Vishwanathapura
2022-07-01 22:50 ` [Intel-gfx] [RFC 10/10] drm/i915/vm_bind: Fix vm->vm_bind_mutex and vm->mutex nesting Niranjana Vishwanathapura
2022-07-05  8:40   ` Thomas Hellström
2022-07-06 16:33     ` Ramalingam C
2022-07-07  5:56     ` 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=matthew.auld@intel.com \
    --cc=niranjana.vishwanathapura@intel.com \
    --cc=paulo.r.zanoni@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox