[PATCH v6 00/20] drm/i915/vm_bind: Add VM_BIND functionality
Niranjana Vishwanathapura
niranjana.vishwanathapura at intel.com
Thu Nov 10 05:49:13 UTC 2022
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 at 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
>>
>
More information about the dri-devel
mailing list