| Message ID | 20221107085210.17221-1-niranjana.vishwanathapura@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/i915/vm_bind: Add VM_BIND functionality | expand |
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: > DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM > buffer objects (BOs) or sections of a BOs at specified GPU virtual > addresses on a specified address space (VM). Multiple mappings can map > to the same physical pages of an object (aliasing). These mappings (also > referred to as persistent mappings) will be persistent across multiple > GPU submissions (execbuf calls) issued by the UMD, without user having > to provide a list of all required mappings during each submission (as > required by older execbuf mode). > > This patch series support VM_BIND version 1, as described by the param > I915_PARAM_VM_BIND_VERSION. > > Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in > vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. > The new execbuf3 ioctl will not have any execlist support and all the > legacy support like relocations etc., are removed. > > NOTEs: > * It is based on below VM_BIND design+uapi rfc. > Documentation/gpu/rfc/i915_vm_bind.rst Hi One difference for execbuf3 that I noticed that is not mentioned in the RFC document is that we now don't have a way to signal EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some pieces that check for this flag: - there's code that deals with frontbuffer rendering - there's code that deals with fences - there's code that prevents self-modifying batches - another that seems related to waiting for objects Are there any new rules regarding frontbuffer rendering when we use execbuf3? Any other behavior changes related to the other places that we should expect when using execbuf3? Thanks, Paulo > > * The IGT RFC series is posted as, > [PATCH i-g-t v5 0/12] vm_bind: Add VM_BIND validation support > > v2: Address various review comments > v3: Address review comments and other fixes > v4: Remove vm_unbind out fence uapi which is not supported yet, > replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() > v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to > non-recoverable faults > v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, > add new patch for async vm_unbind support > > Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> > > Niranjana Vishwanathapura (20): > drm/i915/vm_bind: Expose vm lookup function > drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() > drm/i915/vm_bind: Expose i915_gem_object_max_page_size() > drm/i915/vm_bind: Add support to create persistent vma > drm/i915/vm_bind: Implement bind and unbind of object > drm/i915/vm_bind: Support for VM private BOs > drm/i915/vm_bind: Add support to handle object evictions > drm/i915/vm_bind: Support persistent vma activeness tracking > drm/i915/vm_bind: Add out fence support > drm/i915/vm_bind: Abstract out common execbuf functions > drm/i915/vm_bind: Use common execbuf functions in execbuf path > drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl > drm/i915/vm_bind: Update i915_vma_verify_bind_complete() > drm/i915/vm_bind: Expose i915_request_await_bind() > drm/i915/vm_bind: Handle persistent vmas in execbuf3 > drm/i915/vm_bind: userptr dma-resv changes > drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts > drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode > drm/i915/vm_bind: Render VM_BIND documentation > drm/i915/vm_bind: Async vm_unbind support > > Documentation/gpu/i915.rst | 78 +- > drivers/gpu/drm/i915/Makefile | 3 + > drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- > drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + > drivers/gpu/drm/i915/gem/i915_gem_create.c | 72 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 + > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 516 +---------- > .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++++++++++++++++++ > .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 +++++++++++++ > .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ > drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 2 + > drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 + > drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 + > .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + > drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + > .../drm/i915/gem/i915_gem_vm_bind_object.c | 449 +++++++++ > drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + > drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + > drivers/gpu/drm/i915/i915_driver.c | 4 + > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 + > drivers/gpu/drm/i915/i915_getparam.c | 3 + > drivers/gpu/drm/i915/i915_sw_fence.c | 28 +- > drivers/gpu/drm/i915/i915_sw_fence.h | 23 +- > drivers/gpu/drm/i915/i915_vma.c | 186 +++- > drivers/gpu/drm/i915/i915_vma.h | 68 +- > drivers/gpu/drm/i915/i915_vma_types.h | 39 + > include/uapi/drm/i915_drm.h | 264 +++++- > 30 files changed, 3008 insertions(+), 546 deletions(-) > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h > create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c >
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote: >On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: >> DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM >> buffer objects (BOs) or sections of a BOs at specified GPU virtual >> addresses on a specified address space (VM). Multiple mappings can map >> to the same physical pages of an object (aliasing). These mappings (also >> referred to as persistent mappings) will be persistent across multiple >> GPU submissions (execbuf calls) issued by the UMD, without user having >> to provide a list of all required mappings during each submission (as >> required by older execbuf mode). >> >> This patch series support VM_BIND version 1, as described by the param >> I915_PARAM_VM_BIND_VERSION. >> >> Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in >> vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. >> The new execbuf3 ioctl will not have any execlist support and all the >> legacy support like relocations etc., are removed. >> >> NOTEs: >> * It is based on below VM_BIND design+uapi rfc. >> Documentation/gpu/rfc/i915_vm_bind.rst > >Hi > >One difference for execbuf3 that I noticed that is not mentioned in the >RFC document is that we now don't have a way to signal >EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some >pieces that check for this flag: > >- there's code that deals with frontbuffer rendering >- there's code that deals with fences >- there's code that prevents self-modifying batches >- another that seems related to waiting for objects > >Are there any new rules regarding frontbuffer rendering when we use >execbuf3? Any other behavior changes related to the other places that >we should expect when using execbuf3? > Paulo, Most of the EXEC_OBJECT_WRITE check in execbuf path is related to implicit dependency tracker which execbuf3 does not support. The frontbuffer related updated is the only exception and I don't remember the rationale to not require this on execbuf3. Matt, Tvrtko, Daniel, can you please comment here? Thanks, Niranjana >Thanks, >Paulo > >> >> * The IGT RFC series is posted as, >> [PATCH i-g-t v5 0/12] vm_bind: Add VM_BIND validation support >> >> v2: Address various review comments >> v3: Address review comments and other fixes >> v4: Remove vm_unbind out fence uapi which is not supported yet, >> replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() >> v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to >> non-recoverable faults >> v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, >> add new patch for async vm_unbind support >> >> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> >> >> Niranjana Vishwanathapura (20): >> drm/i915/vm_bind: Expose vm lookup function >> drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() >> drm/i915/vm_bind: Expose i915_gem_object_max_page_size() >> drm/i915/vm_bind: Add support to create persistent vma >> drm/i915/vm_bind: Implement bind and unbind of object >> drm/i915/vm_bind: Support for VM private BOs >> drm/i915/vm_bind: Add support to handle object evictions >> drm/i915/vm_bind: Support persistent vma activeness tracking >> drm/i915/vm_bind: Add out fence support >> drm/i915/vm_bind: Abstract out common execbuf functions >> drm/i915/vm_bind: Use common execbuf functions in execbuf path >> drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl >> drm/i915/vm_bind: Update i915_vma_verify_bind_complete() >> drm/i915/vm_bind: Expose i915_request_await_bind() >> drm/i915/vm_bind: Handle persistent vmas in execbuf3 >> drm/i915/vm_bind: userptr dma-resv changes >> drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts >> drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode >> drm/i915/vm_bind: Render VM_BIND documentation >> drm/i915/vm_bind: Async vm_unbind support >> >> Documentation/gpu/i915.rst | 78 +- >> drivers/gpu/drm/i915/Makefile | 3 + >> drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- >> drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + >> drivers/gpu/drm/i915/gem/i915_gem_create.c | 72 +- >> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 + >> .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 516 +---------- >> .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++++++++++++++++++ >> .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 +++++++++++++ >> .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ >> drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 2 + >> drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 + >> drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 + >> .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + >> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + >> drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + >> .../drm/i915/gem/i915_gem_vm_bind_object.c | 449 +++++++++ >> drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + >> drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + >> drivers/gpu/drm/i915/i915_driver.c | 4 + >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + >> drivers/gpu/drm/i915/i915_gem_gtt.h | 3 + >> drivers/gpu/drm/i915/i915_getparam.c | 3 + >> drivers/gpu/drm/i915/i915_sw_fence.c | 28 +- >> drivers/gpu/drm/i915/i915_sw_fence.h | 23 +- >> drivers/gpu/drm/i915/i915_vma.c | 186 +++- >> drivers/gpu/drm/i915/i915_vma.h | 68 +- >> drivers/gpu/drm/i915/i915_vma_types.h | 39 + >> include/uapi/drm/i915_drm.h | 264 +++++- >> 30 files changed, 3008 insertions(+), 546 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c >> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c >> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h >> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h >> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c >> >
On 10/11/2022 05:49, Niranjana Vishwanathapura wrote: > On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote: >> On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: >>> DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM >>> buffer objects (BOs) or sections of a BOs at specified GPU virtual >>> addresses on a specified address space (VM). Multiple mappings can map >>> to the same physical pages of an object (aliasing). These mappings (also >>> referred to as persistent mappings) will be persistent across multiple >>> GPU submissions (execbuf calls) issued by the UMD, without user having >>> to provide a list of all required mappings during each submission (as >>> required by older execbuf mode). >>> >>> This patch series support VM_BIND version 1, as described by the param >>> I915_PARAM_VM_BIND_VERSION. >>> >>> Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in >>> vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. >>> The new execbuf3 ioctl will not have any execlist support and all the >>> legacy support like relocations etc., are removed. >>> >>> NOTEs: >>> * It is based on below VM_BIND design+uapi rfc. >>> Documentation/gpu/rfc/i915_vm_bind.rst >> >> Hi >> >> One difference for execbuf3 that I noticed that is not mentioned in the >> RFC document is that we now don't have a way to signal >> EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some >> pieces that check for this flag: >> >> - there's code that deals with frontbuffer rendering >> - there's code that deals with fences >> - there's code that prevents self-modifying batches >> - another that seems related to waiting for objects >> >> Are there any new rules regarding frontbuffer rendering when we use >> execbuf3? Any other behavior changes related to the other places that >> we should expect when using execbuf3? >> > > Paulo, > Most of the EXEC_OBJECT_WRITE check in execbuf path is related to > implicit dependency tracker which execbuf3 does not support. The > frontbuffer related updated is the only exception and I don't > remember the rationale to not require this on execbuf3. > > Matt, Tvrtko, Daniel, can you please comment here? Does not ring a bell to me. Looking at the code it certainly looks like it would be silently failing to handle it properly. I'll let people with more experience in this area answer, but from my point of view, if it is decided that it can be left unsupported, then we probably need a way of failing the ioctl is used against a frontbuffer, or something, instead of having display corruption. Regards, Tvrtko
On 10/11/2022 14:47, Tvrtko Ursulin wrote: > > On 10/11/2022 05:49, Niranjana Vishwanathapura wrote: >> On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote: >>> On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: >>>> DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM >>>> buffer objects (BOs) or sections of a BOs at specified GPU virtual >>>> addresses on a specified address space (VM). Multiple mappings can map >>>> to the same physical pages of an object (aliasing). These mappings >>>> (also >>>> referred to as persistent mappings) will be persistent across multiple >>>> GPU submissions (execbuf calls) issued by the UMD, without user having >>>> to provide a list of all required mappings during each submission (as >>>> required by older execbuf mode). >>>> >>>> This patch series support VM_BIND version 1, as described by the param >>>> I915_PARAM_VM_BIND_VERSION. >>>> >>>> Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in >>>> vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. >>>> The new execbuf3 ioctl will not have any execlist support and all the >>>> legacy support like relocations etc., are removed. >>>> >>>> NOTEs: >>>> * It is based on below VM_BIND design+uapi rfc. >>>> Documentation/gpu/rfc/i915_vm_bind.rst >>> >>> Hi >>> >>> One difference for execbuf3 that I noticed that is not mentioned in the >>> RFC document is that we now don't have a way to signal >>> EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some >>> pieces that check for this flag: >>> >>> - there's code that deals with frontbuffer rendering >>> - there's code that deals with fences >>> - there's code that prevents self-modifying batches >>> - another that seems related to waiting for objects >>> >>> Are there any new rules regarding frontbuffer rendering when we use >>> execbuf3? Any other behavior changes related to the other places that >>> we should expect when using execbuf3? >>> >> >> Paulo, >> Most of the EXEC_OBJECT_WRITE check in execbuf path is related to >> implicit dependency tracker which execbuf3 does not support. The >> frontbuffer related updated is the only exception and I don't >> remember the rationale to not require this on execbuf3. >> >> Matt, Tvrtko, Daniel, can you please comment here? > > Does not ring a bell to me. Looking at the code it certainly looks like > it would be silently failing to handle it properly. > > I'll let people with more experience in this area answer, but from my > point of view, if it is decided that it can be left unsupported, then we > probably need a way of failing the ioctl is used against a frontbuffer, > or something, instead of having display corruption. Maybe it's a coincidence but there is: https://patchwork.freedesktop.org/series/110715/ Which looks relevant. Maarten, any hints here? > > Regards, > > Tvrtko
On Thu, 2022-11-10 at 15:05 +0000, Matthew Auld wrote: > On 10/11/2022 14:47, Tvrtko Ursulin wrote: > > > > On 10/11/2022 05:49, Niranjana Vishwanathapura wrote: > > > On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote: > > > > On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: > > > > > DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM > > > > > buffer objects (BOs) or sections of a BOs at specified GPU virtual > > > > > addresses on a specified address space (VM). Multiple mappings can map > > > > > to the same physical pages of an object (aliasing). These mappings > > > > > (also > > > > > referred to as persistent mappings) will be persistent across multiple > > > > > GPU submissions (execbuf calls) issued by the UMD, without user having > > > > > to provide a list of all required mappings during each submission (as > > > > > required by older execbuf mode). > > > > > > > > > > This patch series support VM_BIND version 1, as described by the param > > > > > I915_PARAM_VM_BIND_VERSION. > > > > > > > > > > Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in > > > > > vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. > > > > > The new execbuf3 ioctl will not have any execlist support and all the > > > > > legacy support like relocations etc., are removed. > > > > > > > > > > NOTEs: > > > > > * It is based on below VM_BIND design+uapi rfc. > > > > > Documentation/gpu/rfc/i915_vm_bind.rst > > > > > > > > Hi > > > > > > > > One difference for execbuf3 that I noticed that is not mentioned in the > > > > RFC document is that we now don't have a way to signal > > > > EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some > > > > pieces that check for this flag: > > > > > > > > - there's code that deals with frontbuffer rendering > > > > - there's code that deals with fences > > > > - there's code that prevents self-modifying batches > > > > - another that seems related to waiting for objects > > > > > > > > Are there any new rules regarding frontbuffer rendering when we use > > > > execbuf3? Any other behavior changes related to the other places that > > > > we should expect when using execbuf3? > > > > > > > > > > Paulo, > > > Most of the EXEC_OBJECT_WRITE check in execbuf path is related to > > > implicit dependency tracker which execbuf3 does not support. The > > > frontbuffer related updated is the only exception and I don't > > > remember the rationale to not require this on execbuf3. > > > > > > Matt, Tvrtko, Daniel, can you please comment here? > > > > Does not ring a bell to me. Looking at the code it certainly looks like > > it would be silently failing to handle it properly. > > > > I'll let people with more experience in this area answer, but from my > > point of view, if it is decided that it can be left unsupported, then we > > probably need a way of failing the ioctl is used against a frontbuffer, > > or something, instead of having display corruption. There's no way for the ioctl to even know we're writing to frontbuffers. Unless of course it decides to parse the whole batchbuffer and understand everything that's going on there, which sounds insane. > > Maybe it's a coincidence but there is: > https://patchwork.freedesktop.org/series/110715/ > > Which looks relevant. Maarten, any hints here? Can we pretty please have the rules of frontbuffer tracking written anywhere? I had major trouble trying to understand this back when I was working on FBC, and now I regret not having written it back then because I just forgot how it's supposed to work. My first guess when looking at that patch is that it would completely break FBC, but hey so many years have passed since I worked on this that maybe things changed completely. At least I wrote tests to cover this. > > > > > Regards, > > > > Tvrtko
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer objects (BOs) or sections of a BOs at specified GPU virtual addresses on a specified address space (VM). Multiple mappings can map to the same physical pages of an object (aliasing). These mappings (also referred to as persistent mappings) will be persistent across multiple GPU submissions (execbuf calls) issued by the UMD, without user having to provide a list of all required mappings during each submission (as required by older execbuf mode). This patch series support VM_BIND version 1, as described by the param I915_PARAM_VM_BIND_VERSION. Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any execlist support and all the legacy support like relocations etc., are removed. NOTEs: * It is based on below VM_BIND design+uapi rfc. Documentation/gpu/rfc/i915_vm_bind.rst * The IGT RFC series is posted as, [PATCH i-g-t v5 0/12] vm_bind: Add VM_BIND validation support v2: Address various review comments v3: Address review comments and other fixes v4: Remove vm_unbind out fence uapi which is not supported yet, replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to non-recoverable faults v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, add new patch for async vm_unbind support Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Niranjana Vishwanathapura (20): drm/i915/vm_bind: Expose vm lookup function drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() drm/i915/vm_bind: Expose i915_gem_object_max_page_size() drm/i915/vm_bind: Add support to create persistent vma drm/i915/vm_bind: Implement bind and unbind of object drm/i915/vm_bind: Support for VM private BOs drm/i915/vm_bind: Add support to handle object evictions drm/i915/vm_bind: Support persistent vma activeness tracking drm/i915/vm_bind: Add out fence support drm/i915/vm_bind: Abstract out common execbuf functions drm/i915/vm_bind: Use common execbuf functions in execbuf path drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl drm/i915/vm_bind: Update i915_vma_verify_bind_complete() drm/i915/vm_bind: Expose i915_request_await_bind() drm/i915/vm_bind: Handle persistent vmas in execbuf3 drm/i915/vm_bind: userptr dma-resv changes drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode drm/i915/vm_bind: Render VM_BIND documentation drm/i915/vm_bind: Async vm_unbind support Documentation/gpu/i915.rst | 78 +- drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + drivers/gpu/drm/i915/gem/i915_gem_create.c | 72 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 516 +---------- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++++++++++++++++++ .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 +++++++++++++ .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 2 + drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 + drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + .../drm/i915/gem/i915_gem_vm_bind_object.c | 449 +++++++++ drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + drivers/gpu/drm/i915/i915_driver.c | 4 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + drivers/gpu/drm/i915/i915_gem_gtt.h | 3 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_sw_fence.c | 28 +- drivers/gpu/drm/i915/i915_sw_fence.h | 23 +- drivers/gpu/drm/i915/i915_vma.c | 186 +++- drivers/gpu/drm/i915/i915_vma.h | 68 +- drivers/gpu/drm/i915/i915_vma_types.h | 39 + include/uapi/drm/i915_drm.h | 264 +++++- 30 files changed, 3008 insertions(+), 546 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c