TLB flush consideration¶

The i915 driver flushes the TLB for each submission and when an object’spages are released. The VM_BIND/UNBIND operation will not do any additionalTLB flush. Any VM_BIND mapping added will be in the working set for subsequentsubmissions on that VM and will not be in the working set for currently runningbatches (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 theolder execbuf2 ioctl (Seestructdrm_i915_gem_execbuffer2).Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (Seestructdrm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept anyexeclist. Hence, no support for implicit sync. It is expected that the belowwork will be able to support requirements of object dependency setting in alluse 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 onlyworks with execbuf3 ioctl for submission. All BOs mapped on that VM (throughVM_BIND call) at the time of execbuf3 call are deemed required for thatsubmission.

The execbuf3 ioctl directly specifies the batch addresses instead of asobject handles as in execbuf2 ioctl. The execbuf3 ioctl will also notsupport many of the older features like in/out/submit fences, fence array,default gem context and many more (Seestructdrm_i915_gem_execbuffer3).

In VM_BIND mode, VA allocation is completely managed by the user instead ofthe i915 driver. Hence all VA assignment, eviction are not applicable inVM_BIND mode. Also, for determining object activeness, VM_BIND mode will notbe using the i915_vma active reference tracking. It will instead use dma-resvobject for that (SeeVM_BIND dma_resv usage).

So, a lot of existing code supporting execbuf2 ioctl, like relocations, VAevictions, vma lookup table, implicit sync, vma active reference tracking etc.,are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handlingshould be in a separate file and only functionalities common to these ioctlscan be the shared code where possible.

VM_PRIVATE objects¶

By default, BOs can be mapped on multiple VMs and can also be dma-bufexported. Hence these BOs are referred to as Shared BOs.During each execbuf submission, the request fence must be added to thedma-resv fence list of all shared BOs mapped on the VM.

VM_BIND feature introduces an optimization where user can create BO whichis private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag duringBO creation. Unlike Shared BOs, these VM private BOs can only be mapped onthe 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 execbufsubmission, they need only one dma-resv fence list updated. Thus, the fastpath (where required mappings are already bound) submission latency is O(1)w.r.t the number of VM private BOs.

VM_BIND locking hierarchy¶

The locking design here supports the older (execlist based) execbuf mode, thenewer VM_BIND mode, the VM_BIND mode with GPU page faults and possible futuresystem allocator support (SeeShared Virtual Memory (SVM) support).The older execbuf mode and the newer VM_BIND mode without page faults managesresidency of backing storage using dma_fence. The VM_BIND mode with page faultsand 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 invm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing themapping.

   In future, when GPU page faults are supported, we can potentially use arwsem instead, so that multiple page fault handlers can take the read sidelock 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 tobe held while binding/unbinding a vma in the async worker and while updatingdma-resv fence list of an object. Note that private BOs of a VM will allshare a dma-resv object.

   The future system allocator support will use the HMM prescribed lockinginstead.

3. Lock-C: Spinlock/s to protect some of the VM’s lists like the list ofinvalidated vmas (due to eviction and userptr invalidation) etc.

When GPU page faults are supported, the execbuf path do not take any of theselocks. There we will simply smash the new batch buffer address into the ring andthen tell the scheduler run that. The lock taking only happens from the pagefault handler, where we take lock-A in read mode, whichever lock-B we need tofind the backing storage (dma_resv lock for gem objects, and hmm/core mm forsystem allocator) and some additional locks (lock-D) for taking care of pagetable 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 avoidperformance degradation. We will also need support for bulk LRU movement ofVM_BIND objects to avoid additional latencies in execbuf path.

The page table pages are similar to VM_BIND mapped objects (SeeEvictable page table allocations) and are maintained per VM and needs tobe pinned in memory when VM is made active (ie., upon an execbuf call withthat 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 execbufsubmission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to preventover sync (Seeenumdma_resv_usage). One can override it with eitherDMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit objectdependency setting.

Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check forDMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batchcheck. Instead, the execbuf3 out fence should be used for end of batch check(Seestructdrm_i915_gem_execbuffer3).

Also, in VM_BIND mode, use dma-resv apis for determining object activeness(Seedma_resv_test_signaled() anddma_resv_wait_timeout()) and do not use theolder i915_vma active reference tracking which is deprecated. This should beeasier 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 toimplement Vulkan’s Sparse Resources. With increasing GPU hardware performance,reducing CPU overhead becomes more impactful.

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 forcompute to use user/memory fence (SeeUser/Memory Fence) and dma-fence usagemust be limited to in-kernel consumption only.

Where GPU page faults are not available, kernel driver upon buffer invalidationwill initiate a suspend (preemption) of long running context, finish theinvalidation, revalidate the BO and then resume the compute context. This isdone by having a per-context preempt fence which is enabled when someone triesto wait on it and triggers the context preemption.

Debugger¶

With debug event interface user space process (debugger) is able to keep trackof and act upon resources created by another process (debugged) and attachedto GPU via vm_bind interface.

GPU page faults¶

GPU page faults when supported (in future), will only be supported in theVM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode ofbinding will require using dma-fence to ensure residency, the GPU page faultsmode when supported, will not use any dma-fence as residency is purely managedby installing and removing/invalidating page table entries.

Page level hints settings¶

VM_BIND allows any hints setting per mapping instead of per BO. Possible hintsinclude placement and atomicity. Sub-BO level placement hint will be even morerelevant 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_BINDmapped objects. Page table pages are similar to persistent mappings of aVM (difference here are that the page table pages will not have an i915_vmastructure and after swapping pages back in, parent page link needs to beupdated).

Shared Virtual Memory (SVM) support¶

VM_BIND interface can be used to map system memory directly (without gem BOabstraction) using the HMM interface. SVM is only supported with GPU pagefaults enabled.