Lines Matching full:object

10 external / shared object mappings that is needed in the simplest
34   a GEM object or anonymous or page-cache pages mapped also into the CPU
36 * ``gpu_vm_bo``: Abstracts the association of a GEM object and
37   a VM. The GEM object maintains a list of gpu_vm_bos, where each gpu_vm_bo
48 * ``dma_resv``: A struct dma_resv (a.k.a reservation object) that is used
50   gpu_vm or a GEM object. The dma_resv contains an array / list
63 * ``local object``: A GEM object which is only mapped within a
65 * ``external object``: a.k.a shared object: A GEM object which may be shared
73 dma_resv object and hence the dma_resv lock. So, even with a huge
104 * The ``gem_object->gpuva_lock`` This lock protects the GEM object's
106   object's dma_resv, but some drivers protects this list differently,
109   to be able to update the gpu_vm evicted- and external object
120 The GEM object's list of gpu_vm_bos, and the gpu_vm_bo's list of gpu_vmas
122 same as the GEM object's dma_resv, but if the driver
135 object, and each gpu_vma holds a reference counted pointer to the
136 gpu_vm_bo. When iterating over the GEM object's list of gpu_vm_bos and
172            // The following list iteration needs the Gem object's
193 might be userptr gpu_vmas that are not mapping a buffer object that
217 Note that since the object is local to the gpu_vm, it will share the gpu_vm's
230 code holding the object's dma_resv while revalidating will ensure a
242 can't share their reservation object with a single gpu_vm. Instead
243 they need to have a reservation object of their own. The external
247 the gpu_vm's reservation object is locked, it is safe to traverse the
248 external object list and lock the dma_resvs of all external
253 object is bound to need to be put on their gpu_vm's evict list.
254 However, when evicting an external object, the dma_resvs of the
255 gpu_vms the object is bound to are typically not held. Only
256 the object's private dma_resv can be guaranteed to be held. If there
259 option is to just mark the gpu_vm_bos of the evicted gem object with
263 both the gpu_vm's dma_resv and the object's dma_resv is held, and the
266 object's dma_resv.
274    // External object list is protected by the gpu_vm->resv lock.
301 And the corresponding shared-object aware eviction would look like:
387 A userptr gpu_vma is a gpu_vma that, instead of mapping a buffer object to a
532 At bind time, assuming a GEM object backed gpu_vma, each
534 gpu_vm_bo in turn needs to be added to the GEM object's
535 gpu_vm_bo list, and possibly to the gpu_vm's external object
540 the ``gpu_vm->resv`` or the GEM object's dma_resv, that the gpu_vmas
567 zapping. For GEM object backed gpu_vmas, zapping will take place under
568 the GEM object's dma_resv and ensuring that the dma_resv is held also
570 object, will similarly ensure we are race-free.