gpu/rfc/i915_vm_bind.rst

11 issued by the UMD, without user having to provide a list of all required
12 mappings during each submission (as required by older execbuf mode).
14 The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
18 User has to opt-in for VM_BIND mode of binding for an address space (VM)
31 * Support for userptr gem objects (no special uapi is required for this).
34 ------------------------
35 The i915 driver flushes the TLB for each submission and when an object's
37 TLB flush. Any VM_BIND mapping added will be in the working set for subsequent
38 submissions on that VM and will not be in the working set for currently running
42 -------------------------------
48 execlist. Hence, no support for implicit sync. It is expected that the below
52 "dma-buf: Add an API for exporting sync files"
56 works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
57 VM_BIND call) at the time of execbuf3 call are deemed required for that
67 VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
68 be using the i915_vma active reference tracking. It will instead use dma-resv
69 object for that (See `VM_BIND dma_resv usage`_).
73 are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling
78 -------------------
79 By default, BOs can be mapped on multiple VMs and can also be dma-buf
82 dma-resv fence list of all shared BOs mapped on the VM.
87 the VM they are private to and can't be dma-buf exported.
88 All private BOs of a VM share the dma-resv object. Hence during each execbuf
89 submission, they need only one dma-resv fence list updated. Thus, the fast
90 path (where required mappings are already bound) submission latency is O(1)
94 -------------------------
104 1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in
113 2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to
115    dma-resv fence list of an object. Note that private BOs of a VM will all
116    share a dma-resv object.
121 3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of
127 fault handler, where we take lock-A in read mode, whichever lock-B we need to
128 find the backing storage (dma_resv lock for gem objects, and hmm/core mm for
129 system allocator) and some additional locks (lock-D) for taking care of page
131 so won't ever need lock-C.
134 ---------------------
136 performance degradation. We will also need support for bulk LRU movement of
145 -----------------------
152 Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for
153 DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch
154 check. Instead, the execbuf3 out fence should be used for end of batch check
157 Also, in VM_BIND mode, use dma-resv apis for determining object activeness
163 --------------
165 hence improving performance of CPU-bound applications. It also allows us to
166 implement Vulkan's Sparse Resources. With increasing GPU hardware performance,
174 ------------------------------
175 Usage of dma-fence expects that they complete in reasonable amount of time.
176 Compute on the other hand can be long running. Hence it is appropriate for
177 compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage
178 must be limited to in-kernel consumption only.
183 done by having a per-context preempt fence which is enabled when someone tries
199 Allows compute UMD to directly submit GPU jobs instead of through execbuf
201 execbuf. VM_BIND allows bind/unbind of mappings required for the directly
202 submitted jobs.
205 ---------
211 ----------------
214 binding will require using dma-fence to ensure residency, the GPU page faults
215 mode when supported, will not use any dma-fence as residency is purely managed
219 --------------------------
221 include placement and atomicity. Sub-BO level placement hint will be even more
222 relevant with upcoming GPU on-demand page fault support.
225 -------------------------------
229 ---------------------------------
237 ------------------------------------
245 .. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h