Lines Matching +full:container +full:- +full:rules
1 .. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
10 * ``VRAM``: On-device memory. Sometimes referred to as device local memory.
16 an IOCTL. The operations include mapping and unmapping system- or
19 * ``syncobj``: A container that abstracts synchronization objects. The
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
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.
61 * ``UMD``: User-mode driver.
63 * ``KMD``: Kernel-mode driver.
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
89 the in-syncobjs needs to signal before the first operation starts to
90 execute, and the out-syncobjs signal after the last operation
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
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
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
168 will return -ENOENT.
179 .. code-block:: c
260 that is used to facilitate out-of-order VM_BINDs.
262 .. code-block:: c