Lines Matching +full:per +full:- +full:operation
1 .. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
10 * ``VRAM``: On-device memory. Sometimes referred to as device local memory.
12 * ``gpu_vm``: A virtual GPU address space. Typically per process, but
15 * ``VM_BIND``: An operation or a list of operations to modify a gpu_vm using
16 an IOCTL. The operations include mapping and unmapping system- or
20 synchronization objects can be either generic, like dma-fences or
24 * ``in-syncobj``: Argument to a VM_BIND IOCTL, the VM_BIND operation waits
27 * ``out-syncobj``: Argument to a VM_BIND_IOCTL, the VM_BIND operation
28 signals these when the bind operation is complete.
30 * ``dma-fence``: A cross-driver synchronization object. A basic
31 understanding of dma-fences is required to digest this
33 :doc:`dma-buf doc </driver-api/dma-buf>`.
35 * ``memory fence``: A synchronization object, different from a dma-fence.
39 user-fences, userspace-fences or gpu futexes and do not necessarily obey
40 the dma-fence rule of signaling within a "reasonable amount of time".
43 * ``long-running workload``: A workload that may take more than the
44 current stipulated dma-fence maximum signal delay to complete and
46 a certain mode that disallows completion dma-fences.
54 long-running mode.
57 operation. VM_BIND operations that use the same bind context can be
61 * ``UMD``: User-mode driver.
63 * ``KMD``: Kernel-mode driver.
66 Synchronous / Asynchronous VM_BIND operation
72 IOCTL returns. A synchronous VM_BIND takes neither in-fences nor
73 out-fences. Synchronous VM_BIND may block and wait for GPU operations;
74 for example swap-in or clearing, or even previous binds.
78 Asynchronous VM_BIND accepts both in-syncobjs and out-syncobjs. While the
79 IOCTL may return immediately, the VM_BIND operations wait for the in-syncobjs
80 before modifying the GPU page-tables, and signal the out-syncobjs when
82 awaits for the out-syncobjs will see the change. Errors are reported
84 In low-memory situations the implementation may block, performing the
86 immediately available for preparing the asynchronous operation.
89 the in-syncobjs needs to signal before the first operation starts to
90 execute, and the out-syncobjs signal after the last operation
91 completes. Operations in the operation list can be assumed, where it
94 Since asynchronous VM_BIND operations may use dma-fences embedded in
95 out-syncobjs and internally in KMD to signal bind completion, any
96 memory fences given as VM_BIND in-fences need to be awaited
97 synchronously before the VM_BIND ioctl returns, since dma-fences,
101 The purpose of an Asynchronous VM_BIND operation is for user-mode
103 exec functions. For long-running workloads, such pipelining of a bind
104 operation is not allowed and any in-fences need to be awaited
106 fences gated by a long-running workload and used as in-syncobjs for the
107 VM_BIND operation will need to be awaited synchronously anyway (see
108 above). Second, any dma-fences used as in-syncobjs for VM_BIND
109 operations for long-running workloads will not allow for pipelining
110 anyway since long-running workloads don't allow for dma-fences as
111 out-syncobjs, so while theoretically possible the use of them is
112 questionable and should be rejected until there is a valuable use-case.
113 Note that this is not a limitation imposed by dma-fence rules, but
115 not affect using dma-fences as dependencies for the long-running
116 workload itself, which is allowed by dma-fence rules, but rather for
117 the VM_BIND operation only.
119 An asynchronous VM_BIND operation may take substantial time to
120 complete and signal the out_fence. In particular if the operation is
123 subsequent VM_BIND operation to be queued behind the first one if
124 there are no explicit dependencies. In order to circumvent such a queue-up, a
132 about, for example page-table structure changes. A way to attempt
136 Also for VM_BINDS for long-running gpu_vms the user-mode driver should typically
137 select memory fences as out-fences since that gives greater flexibility for
141 the bind completion using the memory out-fence as the signal condition
145 multi-operation support between asynchronous VM_BIND and synchronous VM_BIND.
147 Multi-operation VM_BIND IOCTL error handling and interrupts
155 If UMD has over-committed a memory resource, an -ENOSPC error will be
157 moment and rerun the IOCTL. On -EINTR, UMD should simply rerun the
158 IOCTL and on -ENOMEM user-space may either attempt to free known
160 bind operation, due to an error return, no additional action is needed
161 to clean up the failed operation, and the VM is left in the same state
168 will return -ENOENT.
173 Starting with the VM_BIND operation struct, the IOCTL call can take
179 .. code-block:: c
234 * Valid on a faulting VM only, do the MAP operation immediately rather
246 /** @op: Operation to perform (lower 16 bits) and flags (upper 16 bits) */
260 that is used to facilitate out-of-order VM_BINDs.
262 .. code-block:: c