| Message ID | 20220626014916.5130-2-niranjana.vishwanathapura@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/doc/rfc: i915 VM_BIND feature design + uapi | expand |
On Sat, Jun 25, 2022 at 06:49:14PM -0700, Niranjana Vishwanathapura wrote: > VM_BIND design document with description of intended use cases. > > v2: Reduce the scope to simple Mesa use case. > v3: Expand documentation on dma-resv usage, TLB flushing and > execbuf3. > v4: Remove vm_bind tlb flush request support. > v5: Update TLB flushing documentation. > v6: Update out of order completion documentation. > > Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Aside on the tlb flush discussion: I think that one doesn't have a big impact if we need to later on fix it with a flag, and what's currently specified here is the solution that fits best into the existing semantics. So feels like a solid path until we have this all up&running and can do real benchmarks with applications. -Daniel > --- > Documentation/gpu/rfc/i915_vm_bind.rst | 246 +++++++++++++++++++++++++ > Documentation/gpu/rfc/index.rst | 4 + > 2 files changed, 250 insertions(+) > create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst > > diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst > new file mode 100644 > index 000000000000..032ee32b885c > --- /dev/null > +++ b/Documentation/gpu/rfc/i915_vm_bind.rst > @@ -0,0 +1,246 @@ > +========================================== > +I915 VM_BIND feature design and use cases > +========================================== > + > +VM_BIND feature > +================ > +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). 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). > + > +The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for > +signaling the completion of bind/unbind operation. > + > +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. > +User has to opt-in for VM_BIND mode of binding for an address space (VM) > +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. > + > +VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are > +not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done > +asynchronously, when valid out fence is specified. > + > +VM_BIND features include: > + > +* Multiple Virtual Address (VA) mappings can map to the same physical pages > + of an object (aliasing). > +* VA mapping can map to a partial section of the BO (partial binding). > +* Support capture of persistent mappings in the dump upon GPU error. > +* Support for userptr gem objects (no special uapi is required for this). > + > +TLB flush consideration > +------------------------ > +The i915 driver flushes the TLB for each submission and when an object's > +pages are released. The VM_BIND/UNBIND operation will not do any additional > +TLB flush. Any VM_BIND mapping added will be in the working set for subsequent > +submissions on that VM and will not be in the working set for currently running > +batches (which would require additional TLB flushes, which is not supported). > + > +Execbuf ioctl in VM_BIND mode > +------------------------------- > +A VM in VM_BIND mode will not support older execbuf mode of binding. > +The execbuf ioctl handling in VM_BIND mode differs significantly from the > +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). > +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See > +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any > +execlist. Hence, no support for implicit sync. It is expected that the below > +work will be able to support requirements of object dependency setting in all > +use cases: > + > +"dma-buf: Add an API for exporting sync files" > +(https://lwn.net/Articles/859290/) > + > +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only > +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through > +VM_BIND call) at the time of execbuf3 call are deemed required for that > +submission. > + > +The execbuf3 ioctl directly specifies the batch addresses instead of as > +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not > +support many of the older features like in/out/submit fences, fence array, > +default gem context and many more (See struct drm_i915_gem_execbuffer3). > + > +In VM_BIND mode, VA allocation is completely managed by the user instead of > +the i915 driver. Hence all VA assignment, eviction are not applicable in > +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not > +be using the i915_vma active reference tracking. It will instead use dma-resv > +object for that (See `VM_BIND dma_resv usage`_). > + > +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA > +evictions, vma lookup table, implicit sync, vma active reference tracking etc., > +are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling > +should be in a separate file and only functionalities common to these ioctls > +can be the shared code where possible. > + > +VM_PRIVATE objects > +------------------- > +By default, BOs can be mapped on multiple VMs and can also be dma-buf > +exported. Hence these BOs are referred to as Shared BOs. > +During each execbuf submission, the request fence must be added to the > +dma-resv fence list of all shared BOs mapped on the VM. > + > +VM_BIND feature introduces an optimization where user can create BO which > +is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during > +BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on > +the VM they are private to and can't be dma-buf exported. > +All private BOs of a VM share the dma-resv object. Hence during each execbuf > +submission, they need only one dma-resv fence list updated. Thus, the fast > +path (where required mappings are already bound) submission latency is O(1) > +w.r.t the number of VM private BOs. > + > +VM_BIND locking hirarchy > +------------------------- > +The locking design here supports the older (execlist based) execbuf mode, the > +newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future > +system allocator support (See `Shared Virtual Memory (SVM) support`_). > +The older execbuf mode and the newer VM_BIND mode without page faults manages > +residency of backing storage using dma_fence. The VM_BIND mode with page faults > +and the system allocator support do not use any dma_fence at all. > + > +VM_BIND locking order is as below. > + > +1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in > + vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the > + mapping. > + > + In future, when GPU page faults are supported, we can potentially use a > + rwsem instead, so that multiple page fault handlers can take the read side > + lock to lookup the mapping and hence can run in parallel. > + The older execbuf mode of binding do not need this lock. > + > +2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to > + be held while binding/unbinding a vma in the async worker and while updating > + dma-resv fence list of an object. Note that private BOs of a VM will all > + share a dma-resv object. > + > + The future system allocator support will use the HMM prescribed locking > + instead. > + > +3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of > + invalidated vmas (due to eviction and userptr invalidation) etc. > + > +When GPU page faults are supported, the execbuf path do not take any of these > +locks. There we will simply smash the new batch buffer address into the ring and > +then tell the scheduler run that. The lock taking only happens from the page > +fault handler, where we take lock-A in read mode, whichever lock-B we need to > +find the backing storage (dma_resv lock for gem objects, and hmm/core mm for > +system allocator) and some additional locks (lock-D) for taking care of page > +table races. Page fault mode should not need to ever manipulate the vm lists, > +so won't ever need lock-C. > + > +VM_BIND LRU handling > +--------------------- > +We need to ensure VM_BIND mapped objects are properly LRU tagged to avoid > +performance degradation. We will also need support for bulk LRU movement of > +VM_BIND objects to avoid additional latencies in execbuf path. > + > +The page table pages are similar to VM_BIND mapped objects (See > +`Evictable page table allocations`_) and are maintained per VM and needs to > +be pinned in memory when VM is made active (ie., upon an execbuf call with > +that VM). So, bulk LRU movement of page table pages is also needed. > + > +VM_BIND dma_resv usage > +----------------------- > +Fences needs to be added to all VM_BIND mapped objects. During each execbuf > +submission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to prevent > +over sync (See enum dma_resv_usage). One can override it with either > +DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit object > +dependency setting. > + > +Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for > +DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch > +check. Instead, the execbuf3 out fence should be used for end of batch check > +(See struct drm_i915_gem_execbuffer3). > + > +Also, in VM_BIND mode, use dma-resv apis for determining object activeness > +(See dma_resv_test_signaled() and dma_resv_wait_timeout()) and do not use the > +older i915_vma active reference tracking which is deprecated. This should be > +easier to get it working with the current TTM backend. > + > +Mesa use case > +-------------- > +VM_BIND can potentially reduce the CPU overhead in Mesa (both Vulkan and Iris), > +hence improving performance of CPU-bound applications. It also allows us to > +implement Vulkan's Sparse Resources. With increasing GPU hardware performance, > +reducing CPU overhead becomes more impactful. > + > + > +Other VM_BIND use cases > +======================== > + > +Long running Compute contexts > +------------------------------ > +Usage of dma-fence expects that they complete in reasonable amount of time. > +Compute on the other hand can be long running. Hence it is appropriate for > +compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage > +must be limited to in-kernel consumption only. > + > +Where GPU page faults are not available, kernel driver upon buffer invalidation > +will initiate a suspend (preemption) of long running context, finish the > +invalidation, revalidate the BO and then resume the compute context. This is > +done by having a per-context preempt fence which is enabled when someone tries > +to wait on it and triggers the context preemption. > + > +User/Memory Fence > +~~~~~~~~~~~~~~~~~~ > +User/Memory fence is a <address, value> pair. To signal the user fence, the > +specified value will be written at the specified virtual address and wakeup the > +waiting process. User fence can be signaled either by the GPU or kernel async > +worker (like upon bind completion). User can wait on a user fence with a new > +user fence wait ioctl. > + > +Here is some prior work on this: > +https://patchwork.freedesktop.org/patch/349417/ > + > +Low Latency Submission > +~~~~~~~~~~~~~~~~~~~~~~~ > +Allows compute UMD to directly submit GPU jobs instead of through execbuf > +ioctl. This is made possible by VM_BIND is not being synchronized against > +execbuf. VM_BIND allows bind/unbind of mappings required for the directly > +submitted jobs. > + > +Debugger > +--------- > +With debug event interface user space process (debugger) is able to keep track > +of and act upon resources created by another process (debugged) and attached > +to GPU via vm_bind interface. > + > +GPU page faults > +---------------- > +GPU page faults when supported (in future), will only be supported in the > +VM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode of > +binding will require using dma-fence to ensure residency, the GPU page faults > +mode when supported, will not use any dma-fence as residency is purely managed > +by installing and removing/invalidating page table entries. > + > +Page level hints settings > +-------------------------- > +VM_BIND allows any hints setting per mapping instead of per BO. > +Possible hints include read-only mapping, placement and atomicity. > +Sub-BO level placement hint will be even more relevant with > +upcoming GPU on-demand page fault support. > + > +Page level Cache/CLOS settings > +------------------------------- > +VM_BIND allows cache/CLOS settings per mapping instead of per BO. > + > +Evictable page table allocations > +--------------------------------- > +Make pagetable allocations evictable and manage them similar to VM_BIND > +mapped objects. Page table pages are similar to persistent mappings of a > +VM (difference here are that the page table pages will not have an i915_vma > +structure and after swapping pages back in, parent page link needs to be > +updated). > + > +Shared Virtual Memory (SVM) support > +------------------------------------ > +VM_BIND interface can be used to map system memory directly (without gem BO > +abstraction) using the HMM interface. SVM is only supported with GPU page > +faults enabled. > + > +VM_BIND UAPI > +============= > + > +.. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h > diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst > index 91e93a705230..7d10c36b268d 100644 > --- a/Documentation/gpu/rfc/index.rst > +++ b/Documentation/gpu/rfc/index.rst > @@ -23,3 +23,7 @@ host such documentation: > .. toctree:: > > i915_scheduler.rst > + > +.. toctree:: > + > + i915_vm_bind.rst > -- > 2.21.0.rc0.32.g243a4c7e27 >
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote: > VM_BIND design document with description of intended use cases. > > v2: Reduce the scope to simple Mesa use case. > v3: Expand documentation on dma-resv usage, TLB flushing and > execbuf3. > v4: Remove vm_bind tlb flush request support. > v5: Update TLB flushing documentation. > v6: Update out of order completion documentation. > > Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> > --- > Documentation/gpu/rfc/i915_vm_bind.rst | 246 +++++++++++++++++++++++++ > Documentation/gpu/rfc/index.rst | 4 + > 2 files changed, 250 insertions(+) > create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst > > diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst > new file mode 100644 > index 000000000000..032ee32b885c > --- /dev/null > +++ b/Documentation/gpu/rfc/i915_vm_bind.rst > @@ -0,0 +1,246 @@ > +========================================== > +I915 VM_BIND feature design and use cases > +========================================== > + > +VM_BIND feature > +================ > +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). 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). > + > +The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for > +signaling the completion of bind/unbind operation. > + > +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. I915_PARAM_VM_BIND_VERSION > +User has to opt-in for VM_BIND mode of binding for an address space (VM) > +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. > + > +VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are > +not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done > +asynchronously, when valid out fence is specified. > + > +VM_BIND features include: > + > +* Multiple Virtual Address (VA) mappings can map to the same physical pages > + of an object (aliasing). > +* VA mapping can map to a partial section of the BO (partial binding). > +* Support capture of persistent mappings in the dump upon GPU error. > +* Support for userptr gem objects (no special uapi is required for this). > + > +TLB flush consideration > +------------------------ > +The i915 driver flushes the TLB for each submission and when an object's > +pages are released. The VM_BIND/UNBIND operation will not do any additional > +TLB flush. Any VM_BIND mapping added will be in the working set for subsequent > +submissions on that VM and will not be in the working set for currently running > +batches (which would require additional TLB flushes, which is not supported). > + > +Execbuf ioctl in VM_BIND mode > +------------------------------- > +A VM in VM_BIND mode will not support older execbuf mode of binding. > +The execbuf ioctl handling in VM_BIND mode differs significantly from the > +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). > +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See > +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any > +execlist. Hence, no support for implicit sync. It is expected that the below > +work will be able to support requirements of object dependency setting in all > +use cases: > + > +"dma-buf: Add an API for exporting sync files" > +(https://lwn.net/Articles/859290/) > + > +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only > +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through > +VM_BIND call) at the time of execbuf3 call are deemed required for that > +submission. > + > +The execbuf3 ioctl directly specifies the batch addresses instead of as > +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not > +support many of the older features like in/out/submit fences, fence array, > +default gem context and many more (See struct drm_i915_gem_execbuffer3). Just as a note: both Iris and Vulkan use some of these features, so some rework will be required. From what I can see, all current behavior we depend on will be supported in some way or another, so hopefully we'll be fine. > + > +In VM_BIND mode, VA allocation is completely managed by the user instead of > +the i915 driver. Hence all VA assignment, eviction are not applicable in > +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not > +be using the i915_vma active reference tracking. It will instead use dma-resv > +object for that (See `VM_BIND dma_resv usage`_). > + > +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA > +evictions, vma lookup table, implicit sync, vma active reference tracking etc., > +are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling > +should be in a separate file and only functionalities common to these ioctls > +can be the shared code where possible. > + > +VM_PRIVATE objects > +------------------- > +By default, BOs can be mapped on multiple VMs and can also be dma-buf > +exported. Hence these BOs are referred to as Shared BOs. > +During each execbuf submission, the request fence must be added to the > +dma-resv fence list of all shared BOs mapped on the VM. > + > +VM_BIND feature introduces an optimization where user can create BO which > +is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during > +BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on > +the VM they are private to and can't be dma-buf exported. > +All private BOs of a VM share the dma-resv object. Hence during each execbuf > +submission, they need only one dma-resv fence list updated. Thus, the fast > +path (where required mappings are already bound) submission latency is O(1) > +w.r.t the number of VM private BOs. > + > +VM_BIND locking hirarchy > +------------------------- > +The locking design here supports the older (execlist based) execbuf mode, the > +newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future > +system allocator support (See `Shared Virtual Memory (SVM) support`_). > +The older execbuf mode and the newer VM_BIND mode without page faults manages > +residency of backing storage using dma_fence. The VM_BIND mode with page faults > +and the system allocator support do not use any dma_fence at all. > + > +VM_BIND locking order is as below. > + > +1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in > + vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the > + mapping. > + > + In future, when GPU page faults are supported, we can potentially use a > + rwsem instead, so that multiple page fault handlers can take the read side > + lock to lookup the mapping and hence can run in parallel. > + The older execbuf mode of binding do not need this lock. > + > +2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to > + be held while binding/unbinding a vma in the async worker and while updating > + dma-resv fence list of an object. Note that private BOs of a VM will all > + share a dma-resv object. > + > + The future system allocator support will use the HMM prescribed locking > + instead. > + > +3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of > + invalidated vmas (due to eviction and userptr invalidation) etc. > + > +When GPU page faults are supported, the execbuf path do not take any of these > +locks. There we will simply smash the new batch buffer address into the ring and > +then tell the scheduler run that. The lock taking only happens from the page > +fault handler, where we take lock-A in read mode, whichever lock-B we need to > +find the backing storage (dma_resv lock for gem objects, and hmm/core mm for > +system allocator) and some additional locks (lock-D) for taking care of page > +table races. Page fault mode should not need to ever manipulate the vm lists, > +so won't ever need lock-C. > + > +VM_BIND LRU handling > +--------------------- > +We need to ensure VM_BIND mapped objects are properly LRU tagged to avoid > +performance degradation. We will also need support for bulk LRU movement of > +VM_BIND objects to avoid additional latencies in execbuf path. > + > +The page table pages are similar to VM_BIND mapped objects (See > +`Evictable page table allocations`_) and are maintained per VM and needs to > +be pinned in memory when VM is made active (ie., upon an execbuf call with > +that VM). So, bulk LRU movement of page table pages is also needed. > + > +VM_BIND dma_resv usage > +----------------------- > +Fences needs to be added to all VM_BIND mapped objects. During each execbuf > +submission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to prevent > +over sync (See enum dma_resv_usage). One can override it with either > +DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit object > +dependency setting. > + > +Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for > +DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch > +check. Instead, the execbuf3 out fence should be used for end of batch check > +(See struct drm_i915_gem_execbuffer3). From what I remember Mesa is calling gem_wait and gem_busy on batches sometimes, so some adjusting will be required. - From what I could understand, the general plan seems fine. We'll need some adjusting in our drivers before we can even try to use this new API, but hopefully the API will be usable with the current plans. If it isn't, then we can always change the plan. So, with that said, the plan is: Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > + > +Also, in VM_BIND mode, use dma-resv apis for determining object activeness > +(See dma_resv_test_signaled() and dma_resv_wait_timeout()) and do not use the > +older i915_vma active reference tracking which is deprecated. This should be > +easier to get it working with the current TTM backend. > + > +Mesa use case > +-------------- > +VM_BIND can potentially reduce the CPU overhead in Mesa (both Vulkan and Iris), > +hence improving performance of CPU-bound applications. It also allows us to > +implement Vulkan's Sparse Resources. With increasing GPU hardware performance, > +reducing CPU overhead becomes more impactful. > + > + > +Other VM_BIND use cases > +======================== > + > +Long running Compute contexts > +------------------------------ > +Usage of dma-fence expects that they complete in reasonable amount of time. > +Compute on the other hand can be long running. Hence it is appropriate for > +compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage > +must be limited to in-kernel consumption only. > + > +Where GPU page faults are not available, kernel driver upon buffer invalidation > +will initiate a suspend (preemption) of long running context, finish the > +invalidation, revalidate the BO and then resume the compute context. This is > +done by having a per-context preempt fence which is enabled when someone tries > +to wait on it and triggers the context preemption. > + > +User/Memory Fence > +~~~~~~~~~~~~~~~~~~ > +User/Memory fence is a <address, value> pair. To signal the user fence, the > +specified value will be written at the specified virtual address and wakeup the > +waiting process. User fence can be signaled either by the GPU or kernel async > +worker (like upon bind completion). User can wait on a user fence with a new > +user fence wait ioctl. > + > +Here is some prior work on this: > +https://patchwork.freedesktop.org/patch/349417/ > + > +Low Latency Submission > +~~~~~~~~~~~~~~~~~~~~~~~ > +Allows compute UMD to directly submit GPU jobs instead of through execbuf > +ioctl. This is made possible by VM_BIND is not being synchronized against > +execbuf. VM_BIND allows bind/unbind of mappings required for the directly > +submitted jobs. > + > +Debugger > +--------- > +With debug event interface user space process (debugger) is able to keep track > +of and act upon resources created by another process (debugged) and attached > +to GPU via vm_bind interface. > + > +GPU page faults > +---------------- > +GPU page faults when supported (in future), will only be supported in the > +VM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode of > +binding will require using dma-fence to ensure residency, the GPU page faults > +mode when supported, will not use any dma-fence as residency is purely managed > +by installing and removing/invalidating page table entries. > + > +Page level hints settings > +-------------------------- > +VM_BIND allows any hints setting per mapping instead of per BO. > +Possible hints include read-only mapping, placement and atomicity. > +Sub-BO level placement hint will be even more relevant with > +upcoming GPU on-demand page fault support. > + > +Page level Cache/CLOS settings > +------------------------------- > +VM_BIND allows cache/CLOS settings per mapping instead of per BO. > + > +Evictable page table allocations > +--------------------------------- > +Make pagetable allocations evictable and manage them similar to VM_BIND > +mapped objects. Page table pages are similar to persistent mappings of a > +VM (difference here are that the page table pages will not have an i915_vma > +structure and after swapping pages back in, parent page link needs to be > +updated). > + > +Shared Virtual Memory (SVM) support > +------------------------------------ > +VM_BIND interface can be used to map system memory directly (without gem BO > +abstraction) using the HMM interface. SVM is only supported with GPU page > +faults enabled. > + > +VM_BIND UAPI > +============= > + > +.. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h > diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst > index 91e93a705230..7d10c36b268d 100644 > --- a/Documentation/gpu/rfc/index.rst > +++ b/Documentation/gpu/rfc/index.rst > @@ -23,3 +23,7 @@ host such documentation: > .. toctree:: > > > > > > > > > > > > > > > > > i915_scheduler.rst > + > +.. toctree:: > + > + i915_vm_bind.rst
On Wed, Jun 29, 2022 at 05:38:59PM -0700, Zanoni, Paulo R wrote: >On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote: >> VM_BIND design document with description of intended use cases. >> >> v2: Reduce the scope to simple Mesa use case. >> v3: Expand documentation on dma-resv usage, TLB flushing and >> execbuf3. >> v4: Remove vm_bind tlb flush request support. >> v5: Update TLB flushing documentation. >> v6: Update out of order completion documentation. >> >> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> >> --- >> Documentation/gpu/rfc/i915_vm_bind.rst | 246 +++++++++++++++++++++++++ >> Documentation/gpu/rfc/index.rst | 4 + >> 2 files changed, 250 insertions(+) >> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst >> >> diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst >> new file mode 100644 >> index 000000000000..032ee32b885c >> --- /dev/null >> +++ b/Documentation/gpu/rfc/i915_vm_bind.rst >> @@ -0,0 +1,246 @@ >> +========================================== >> +I915 VM_BIND feature design and use cases >> +========================================== >> + >> +VM_BIND feature >> +================ >> +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). 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). >> + >> +The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for >> +signaling the completion of bind/unbind operation. >> + >> +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. > >I915_PARAM_VM_BIND_VERSION Thanks, will fix. > > >> +User has to opt-in for VM_BIND mode of binding for an address space (VM) >> +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. >> + >> +VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are >> +not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done >> +asynchronously, when valid out fence is specified. >> + >> +VM_BIND features include: >> + >> +* Multiple Virtual Address (VA) mappings can map to the same physical pages >> + of an object (aliasing). >> +* VA mapping can map to a partial section of the BO (partial binding). >> +* Support capture of persistent mappings in the dump upon GPU error. >> +* Support for userptr gem objects (no special uapi is required for this). >> + >> +TLB flush consideration >> +------------------------ >> +The i915 driver flushes the TLB for each submission and when an object's >> +pages are released. The VM_BIND/UNBIND operation will not do any additional >> +TLB flush. Any VM_BIND mapping added will be in the working set for subsequent >> +submissions on that VM and will not be in the working set for currently running >> +batches (which would require additional TLB flushes, which is not supported). >> + >> +Execbuf ioctl in VM_BIND mode >> +------------------------------- >> +A VM in VM_BIND mode will not support older execbuf mode of binding. >> +The execbuf ioctl handling in VM_BIND mode differs significantly from the >> +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). >> +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See >> +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any >> +execlist. Hence, no support for implicit sync. It is expected that the below >> +work will be able to support requirements of object dependency setting in all >> +use cases: >> + >> +"dma-buf: Add an API for exporting sync files" >> +(https://lwn.net/Articles/859290/) >> + >> +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only >> +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through >> +VM_BIND call) at the time of execbuf3 call are deemed required for that >> +submission. >> + >> +The execbuf3 ioctl directly specifies the batch addresses instead of as >> +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not >> +support many of the older features like in/out/submit fences, fence array, >> +default gem context and many more (See struct drm_i915_gem_execbuffer3). > >Just as a note: both Iris and Vulkan use some of these features, so >some rework will be required. From what I can see, all current behavior >we depend on will be supported in some way or another, so hopefully >we'll be fine. > > >> + >> +In VM_BIND mode, VA allocation is completely managed by the user instead of >> +the i915 driver. Hence all VA assignment, eviction are not applicable in >> +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not >> +be using the i915_vma active reference tracking. It will instead use dma-resv >> +object for that (See `VM_BIND dma_resv usage`_). >> + >> +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA >> +evictions, vma lookup table, implicit sync, vma active reference tracking etc., >> +are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling >> +should be in a separate file and only functionalities common to these ioctls >> +can be the shared code where possible. >> + >> +VM_PRIVATE objects >> +------------------- >> +By default, BOs can be mapped on multiple VMs and can also be dma-buf >> +exported. Hence these BOs are referred to as Shared BOs. >> +During each execbuf submission, the request fence must be added to the >> +dma-resv fence list of all shared BOs mapped on the VM. >> + >> +VM_BIND feature introduces an optimization where user can create BO which >> +is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during >> +BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on >> +the VM they are private to and can't be dma-buf exported. >> +All private BOs of a VM share the dma-resv object. Hence during each execbuf >> +submission, they need only one dma-resv fence list updated. Thus, the fast >> +path (where required mappings are already bound) submission latency is O(1) >> +w.r.t the number of VM private BOs. >> + >> +VM_BIND locking hirarchy >> +------------------------- >> +The locking design here supports the older (execlist based) execbuf mode, the >> +newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future >> +system allocator support (See `Shared Virtual Memory (SVM) support`_). >> +The older execbuf mode and the newer VM_BIND mode without page faults manages >> +residency of backing storage using dma_fence. The VM_BIND mode with page faults >> +and the system allocator support do not use any dma_fence at all. >> + >> +VM_BIND locking order is as below. >> + >> +1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in >> + vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the >> + mapping. >> + >> + In future, when GPU page faults are supported, we can potentially use a >> + rwsem instead, so that multiple page fault handlers can take the read side >> + lock to lookup the mapping and hence can run in parallel. >> + The older execbuf mode of binding do not need this lock. >> + >> +2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to >> + be held while binding/unbinding a vma in the async worker and while updating >> + dma-resv fence list of an object. Note that private BOs of a VM will all >> + share a dma-resv object. >> + >> + The future system allocator support will use the HMM prescribed locking >> + instead. >> + >> +3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of >> + invalidated vmas (due to eviction and userptr invalidation) etc. >> + >> +When GPU page faults are supported, the execbuf path do not take any of these >> +locks. There we will simply smash the new batch buffer address into the ring and >> +then tell the scheduler run that. The lock taking only happens from the page >> +fault handler, where we take lock-A in read mode, whichever lock-B we need to >> +find the backing storage (dma_resv lock for gem objects, and hmm/core mm for >> +system allocator) and some additional locks (lock-D) for taking care of page >> +table races. Page fault mode should not need to ever manipulate the vm lists, >> +so won't ever need lock-C. >> + >> +VM_BIND LRU handling >> +--------------------- >> +We need to ensure VM_BIND mapped objects are properly LRU tagged to avoid >> +performance degradation. We will also need support for bulk LRU movement of >> +VM_BIND objects to avoid additional latencies in execbuf path. >> + >> +The page table pages are similar to VM_BIND mapped objects (See >> +`Evictable page table allocations`_) and are maintained per VM and needs to >> +be pinned in memory when VM is made active (ie., upon an execbuf call with >> +that VM). So, bulk LRU movement of page table pages is also needed. >> + >> +VM_BIND dma_resv usage >> +----------------------- >> +Fences needs to be added to all VM_BIND mapped objects. During each execbuf >> +submission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to prevent >> +over sync (See enum dma_resv_usage). One can override it with either >> +DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit object >> +dependency setting. >> + >> +Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for >> +DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch >> +check. Instead, the execbuf3 out fence should be used for end of batch check >> +(See struct drm_i915_gem_execbuffer3). > >From what I remember Mesa is calling gem_wait and gem_busy on batches >sometimes, so some adjusting will be required. > > >- > >From what I could understand, the general plan seems fine. We'll need >some adjusting in our drivers before we can even try to use this new >API, but hopefully the API will be usable with the current plans. If it >isn't, then we can always change the plan. So, with that said, the plan >is: > >Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > Thanks, Niranjana > >> + >> +Also, in VM_BIND mode, use dma-resv apis for determining object activeness >> +(See dma_resv_test_signaled() and dma_resv_wait_timeout()) and do not use the >> +older i915_vma active reference tracking which is deprecated. This should be >> +easier to get it working with the current TTM backend. >> + >> +Mesa use case >> +-------------- >> +VM_BIND can potentially reduce the CPU overhead in Mesa (both Vulkan and Iris), >> +hence improving performance of CPU-bound applications. It also allows us to >> +implement Vulkan's Sparse Resources. With increasing GPU hardware performance, >> +reducing CPU overhead becomes more impactful. >> + >> + >> +Other VM_BIND use cases >> +======================== >> + >> +Long running Compute contexts >> +------------------------------ >> +Usage of dma-fence expects that they complete in reasonable amount of time. >> +Compute on the other hand can be long running. Hence it is appropriate for >> +compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage >> +must be limited to in-kernel consumption only. >> + >> +Where GPU page faults are not available, kernel driver upon buffer invalidation >> +will initiate a suspend (preemption) of long running context, finish the >> +invalidation, revalidate the BO and then resume the compute context. This is >> +done by having a per-context preempt fence which is enabled when someone tries >> +to wait on it and triggers the context preemption. >> + >> +User/Memory Fence >> +~~~~~~~~~~~~~~~~~~ >> +User/Memory fence is a <address, value> pair. To signal the user fence, the >> +specified value will be written at the specified virtual address and wakeup the >> +waiting process. User fence can be signaled either by the GPU or kernel async >> +worker (like upon bind completion). User can wait on a user fence with a new >> +user fence wait ioctl. >> + >> +Here is some prior work on this: >> +https://patchwork.freedesktop.org/patch/349417/ >> + >> +Low Latency Submission >> +~~~~~~~~~~~~~~~~~~~~~~~ >> +Allows compute UMD to directly submit GPU jobs instead of through execbuf >> +ioctl. This is made possible by VM_BIND is not being synchronized against >> +execbuf. VM_BIND allows bind/unbind of mappings required for the directly >> +submitted jobs. >> + >> +Debugger >> +--------- >> +With debug event interface user space process (debugger) is able to keep track >> +of and act upon resources created by another process (debugged) and attached >> +to GPU via vm_bind interface. >> + >> +GPU page faults >> +---------------- >> +GPU page faults when supported (in future), will only be supported in the >> +VM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode of >> +binding will require using dma-fence to ensure residency, the GPU page faults >> +mode when supported, will not use any dma-fence as residency is purely managed >> +by installing and removing/invalidating page table entries. >> + >> +Page level hints settings >> +-------------------------- >> +VM_BIND allows any hints setting per mapping instead of per BO. >> +Possible hints include read-only mapping, placement and atomicity. >> +Sub-BO level placement hint will be even more relevant with >> +upcoming GPU on-demand page fault support. >> + >> +Page level Cache/CLOS settings >> +------------------------------- >> +VM_BIND allows cache/CLOS settings per mapping instead of per BO. >> + >> +Evictable page table allocations >> +--------------------------------- >> +Make pagetable allocations evictable and manage them similar to VM_BIND >> +mapped objects. Page table pages are similar to persistent mappings of a >> +VM (difference here are that the page table pages will not have an i915_vma >> +structure and after swapping pages back in, parent page link needs to be >> +updated). >> + >> +Shared Virtual Memory (SVM) support >> +------------------------------------ >> +VM_BIND interface can be used to map system memory directly (without gem BO >> +abstraction) using the HMM interface. SVM is only supported with GPU page >> +faults enabled. >> + >> +VM_BIND UAPI >> +============= >> + >> +.. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h >> diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst >> index 91e93a705230..7d10c36b268d 100644 >> --- a/Documentation/gpu/rfc/index.rst >> +++ b/Documentation/gpu/rfc/index.rst >> @@ -23,3 +23,7 @@ host such documentation: >> .. toctree:: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> i915_scheduler.rst >> + >> +.. toctree:: >> + >> + i915_vm_bind.rst >
diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index 000000000000..032ee32b885c --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,246 @@ +========================================== +I915 VM_BIND feature design and use cases +========================================== + +VM_BIND feature +================ +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). 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). + +The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for +signaling the completion of bind/unbind operation. + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are +not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done +asynchronously, when valid out fence is specified. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* Support for userptr gem objects (no special uapi is required for this). + +TLB flush consideration +------------------------ +The i915 driver flushes the TLB for each submission and when an object's +pages are released. The VM_BIND/UNBIND operation will not do any additional +TLB flush. Any VM_BIND mapping added will be in the working set for subsequent +submissions on that VM and will not be in the working set for currently running +batches (which would require additional TLB flushes, which is not supported). + +Execbuf ioctl in VM_BIND mode +------------------------------- +A VM in VM_BIND mode will not support older execbuf mode of binding. +The execbuf ioctl handling in VM_BIND mode differs significantly from the +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any +execlist. Hence, no support for implicit sync. It is expected that the below +work will be able to support requirements of object dependency setting in all +use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) + +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through +VM_BIND call) at the time of execbuf3 call are deemed required for that +submission. + +The execbuf3 ioctl directly specifies the batch addresses instead of as +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not +support many of the older features like in/out/submit fences, fence array, +default gem context and many more (See struct drm_i915_gem_execbuffer3). + +In VM_BIND mode, VA allocation is completely managed by the user instead of +the i915 driver. Hence all VA assignment, eviction are not applicable in +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not +be using the i915_vma active reference tracking. It will instead use dma-resv +object for that (See `VM_BIND dma_resv usage`_). + +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA +evictions, vma lookup table, implicit sync, vma active reference tracking etc., +are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling +should be in a separate file and only functionalities common to these ioctls +can be the shared code where possible. + +VM_PRIVATE objects +------------------- +By default, BOs can be mapped on multiple VMs and can also be dma-buf +exported. Hence these BOs are referred to as Shared BOs. +During each execbuf submission, the request fence must be added to the +dma-resv fence list of all shared BOs mapped on the VM. + +VM_BIND feature introduces an optimization where user can create BO which +is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during +BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on +the VM they are private to and can't be dma-buf exported. +All private BOs of a VM share the dma-resv object. Hence during each execbuf +submission, they need only one dma-resv fence list updated. Thus, the fast +path (where required mappings are already bound) submission latency is O(1) +w.r.t the number of VM private BOs. + +VM_BIND locking hirarchy +------------------------- +The locking design here supports the older (execlist based) execbuf mode, the +newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future +system allocator support (See `Shared Virtual Memory (SVM) support`_). +The older execbuf mode and the newer VM_BIND mode without page faults manages +residency of backing storage using dma_fence. The VM_BIND mode with page faults +and the system allocator support do not use any dma_fence at all. + +VM_BIND locking order is as below. + +1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in + vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the + mapping. + + In future, when GPU page faults are supported, we can potentially use a + rwsem instead, so that multiple page fault handlers can take the read side + lock to lookup the mapping and hence can run in parallel. + The older execbuf mode of binding do not need this lock. + +2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to + be held while binding/unbinding a vma in the async worker and while updating + dma-resv fence list of an object. Note that private BOs of a VM will all + share a dma-resv object. + + The future system allocator support will use the HMM prescribed locking + instead. + +3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of + invalidated vmas (due to eviction and userptr invalidation) etc. + +When GPU page faults are supported, the execbuf path do not take any of these +locks. There we will simply smash the new batch buffer address into the ring and +then tell the scheduler run that. The lock taking only happens from the page +fault handler, where we take lock-A in read mode, whichever lock-B we need to +find the backing storage (dma_resv lock for gem objects, and hmm/core mm for +system allocator) and some additional locks (lock-D) for taking care of page +table races. Page fault mode should not need to ever manipulate the vm lists, +so won't ever need lock-C. + +VM_BIND LRU handling +--------------------- +We need to ensure VM_BIND mapped objects are properly LRU tagged to avoid +performance degradation. We will also need support for bulk LRU movement of +VM_BIND objects to avoid additional latencies in execbuf path. + +The page table pages are similar to VM_BIND mapped objects (See +`Evictable page table allocations`_) and are maintained per VM and needs to +be pinned in memory when VM is made active (ie., upon an execbuf call with +that VM). So, bulk LRU movement of page table pages is also needed. + +VM_BIND dma_resv usage +----------------------- +Fences needs to be added to all VM_BIND mapped objects. During each execbuf +submission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to prevent +over sync (See enum dma_resv_usage). One can override it with either +DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit object +dependency setting. + +Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for +DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch +check. Instead, the execbuf3 out fence should be used for end of batch check +(See struct drm_i915_gem_execbuffer3). + +Also, in VM_BIND mode, use dma-resv apis for determining object activeness +(See dma_resv_test_signaled() and dma_resv_wait_timeout()) and do not use the +older i915_vma active reference tracking which is deprecated. This should be +easier to get it working with the current TTM backend. + +Mesa use case +-------------- +VM_BIND can potentially reduce the CPU overhead in Mesa (both Vulkan and Iris), +hence improving performance of CPU-bound applications. It also allows us to +implement Vulkan's Sparse Resources. With increasing GPU hardware performance, +reducing CPU overhead becomes more impactful. + + +Other VM_BIND use cases +======================== + +Long running Compute contexts +------------------------------ +Usage of dma-fence expects that they complete in reasonable amount of time. +Compute on the other hand can be long running. Hence it is appropriate for +compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage +must be limited to in-kernel consumption only. + +Where GPU page faults are not available, kernel driver upon buffer invalidation +will initiate a suspend (preemption) of long running context, finish the +invalidation, revalidate the BO and then resume the compute context. This is +done by having a per-context preempt fence which is enabled when someone tries +to wait on it and triggers the context preemption. + +User/Memory Fence +~~~~~~~~~~~~~~~~~~ +User/Memory fence is a <address, value> pair. To signal the user fence, the +specified value will be written at the specified virtual address and wakeup the +waiting process. User fence can be signaled either by the GPU or kernel async +worker (like upon bind completion). User can wait on a user fence with a new +user fence wait ioctl. + +Here is some prior work on this: +https://patchwork.freedesktop.org/patch/349417/ + +Low Latency Submission +~~~~~~~~~~~~~~~~~~~~~~~ +Allows compute UMD to directly submit GPU jobs instead of through execbuf +ioctl. This is made possible by VM_BIND is not being synchronized against +execbuf. VM_BIND allows bind/unbind of mappings required for the directly +submitted jobs. + +Debugger +--------- +With debug event interface user space process (debugger) is able to keep track +of and act upon resources created by another process (debugged) and attached +to GPU via vm_bind interface. + +GPU page faults +---------------- +GPU page faults when supported (in future), will only be supported in the +VM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode of +binding will require using dma-fence to ensure residency, the GPU page faults +mode when supported, will not use any dma-fence as residency is purely managed +by installing and removing/invalidating page table entries. + +Page level hints settings +-------------------------- +VM_BIND allows any hints setting per mapping instead of per BO. +Possible hints include read-only mapping, placement and atomicity. +Sub-BO level placement hint will be even more relevant with +upcoming GPU on-demand page fault support. + +Page level Cache/CLOS settings +------------------------------- +VM_BIND allows cache/CLOS settings per mapping instead of per BO. + +Evictable page table allocations +--------------------------------- +Make pagetable allocations evictable and manage them similar to VM_BIND +mapped objects. Page table pages are similar to persistent mappings of a +VM (difference here are that the page table pages will not have an i915_vma +structure and after swapping pages back in, parent page link needs to be +updated). + +Shared Virtual Memory (SVM) support +------------------------------------ +VM_BIND interface can be used to map system memory directly (without gem BO +abstraction) using the HMM interface. SVM is only supported with GPU page +faults enabled. + +VM_BIND UAPI +============= + +.. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 91e93a705230..7d10c36b268d 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -23,3 +23,7 @@ host such documentation: .. toctree:: i915_scheduler.rst + +.. toctree:: + + i915_vm_bind.rst
VM_BIND design document with description of intended use cases. v2: Reduce the scope to simple Mesa use case. v3: Expand documentation on dma-resv usage, TLB flushing and execbuf3. v4: Remove vm_bind tlb flush request support. v5: Update TLB flushing documentation. v6: Update out of order completion documentation. Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> --- Documentation/gpu/rfc/i915_vm_bind.rst | 246 +++++++++++++++++++++++++ Documentation/gpu/rfc/index.rst | 4 + 2 files changed, 250 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst