Lines Matching full:gpu

4 GPU SVM Section
25 	* Eviction is defined as migrating data from the GPU back to the
26 	  CPU without a virtual address to free up GPU memory.
32 	* GPU page table invalidation, which requires a GPU virtual address, is
33 	  handled via the notifier that has access to the GPU virtual address.
34 * GPU fault side
36 	  and should strive to take mmap_read lock only in GPU SVM layer.
37 	* Big retry loop to handle all races with the mmu notifier under the gpu
47 	  migration policy requiring GPU access to occur in GPU memory.
49 	  While no current user (Xe) of GPU SVM has such a policy, it is likely
60 * GPU pagetable locking
70 .. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
73 .. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
76 .. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
79 .. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
85 .. kernel-doc:: drivers/gpu/drm/drm_pagemap.c
88 .. kernel-doc:: drivers/gpu/drm/drm_pagemap.c
94 * Concurrent GPU faults
95 	* CPU faults are concurrent so makes sense to have concurrent GPU
97 	* Should be possible with fined grained locking in the driver GPU
99 	* No expected GPU SVM changes required.
102 * Multi-GPU support
103 	* Work in progress and patches expected after initially landing on GPU
105 	* Ideally can be done with little to no changes to GPU SVM.
116 * Build common userptr implementation on top of GPU SVM