|
45 | 45 | /**
|
46 | 46 | * DOC: GPUVM
|
47 | 47 | *
|
48 |
| - * GPUVM is similar to the legacy gart on older asics, however |
49 |
| - * rather than there being a single global gart table |
50 |
| - * for the entire GPU, there are multiple VM page tables active |
51 |
| - * at any given time. The VM page tables can contain a mix |
52 |
| - * vram pages and system memory pages and system memory pages |
| 48 | + * GPUVM is the MMU functionality provided on the GPU. |
| 49 | + * GPUVM is similar to the legacy GART on older asics, however |
| 50 | + * rather than there being a single global GART table |
| 51 | + * for the entire GPU, there can be multiple GPUVM page tables active |
| 52 | + * at any given time. The GPUVM page tables can contain a mix |
| 53 | + * VRAM pages and system pages (both memory and MMIO) and system pages |
53 | 54 | * can be mapped as snooped (cached system pages) or unsnooped
|
54 | 55 | * (uncached system pages).
|
55 |
| - * Each VM has an ID associated with it and there is a page table |
56 |
| - * associated with each VMID. When executing a command buffer, |
57 |
| - * the kernel tells the ring what VMID to use for that command |
| 56 | + * |
| 57 | + * Each active GPUVM has an ID associated with it and there is a page table |
| 58 | + * linked with each VMID. When executing a command buffer, |
| 59 | + * the kernel tells the engine what VMID to use for that command |
58 | 60 | * buffer. VMIDs are allocated dynamically as commands are submitted.
|
59 | 61 | * The userspace drivers maintain their own address space and the kernel
|
60 | 62 | * sets up their pages tables accordingly when they submit their
|
61 | 63 | * command buffers and a VMID is assigned.
|
62 |
| - * Cayman/Trinity support up to 8 active VMs at any given time; |
63 |
| - * SI supports 16. |
| 64 | + * The hardware supports up to 16 active GPUVMs at any given time. |
| 65 | + * |
| 66 | + * Each GPUVM is represented by a 1-2 or 1-5 level page table, depending |
| 67 | + * on the ASIC family. GPUVM supports RWX attributes on each page as well |
| 68 | + * as other features such as encryption and caching attributes. |
| 69 | + * |
| 70 | + * VMID 0 is special. It is the GPUVM used for the kernel driver. In |
| 71 | + * addition to an aperture managed by a page table, VMID 0 also has |
| 72 | + * several other apertures. There is an aperture for direct access to VRAM |
| 73 | + * and there is a legacy AGP aperture which just forwards accesses directly |
| 74 | + * to the matching system physical addresses (or IOVAs when an IOMMU is |
| 75 | + * present). These apertures provide direct access to these memories without |
| 76 | + * incurring the overhead of a page table. VMID 0 is used by the kernel |
| 77 | + * driver for tasks like memory management. |
| 78 | + * |
| 79 | + * GPU clients (i.e., engines on the GPU) use GPUVM VMIDs to access memory. |
| 80 | + * For user applications, each application can have their own unique GPUVM |
| 81 | + * address space. The application manages the address space and the kernel |
| 82 | + * driver manages the GPUVM page tables for each process. If an GPU client |
| 83 | + * accesses an invalid page, it will generate a GPU page fault, similar to |
| 84 | + * accessing an invalid page on a CPU. |
64 | 85 | */
|
65 | 86 |
|
66 | 87 | #define START(node) ((node)->start)
|
|
0 commit comments