GPU 地址空间的管理方式由两项因素决定：硬件提供怎样的地址转换，以及地址的分配、映射与驻留在内核与用户态之间如何分工。随着硬件从全局地址翻译表发展到每上下文独立的页表，DRM 的寻址模型先后经历了提交时定址、每进程 VM 下的预先绑定和 VM_BIND 三种形态。每一次演进都把一部分工作从提交路径中移出，同时要求内核在提交之外长期维护更多的状态。本篇按演进顺序梳理三种形态各自解决的问题与遗留的问题，归纳 GPU 虚拟地址管理需要承担的职责，并据此说明 drm_gpuvm 与驱动之间的职责划分。
1. 提交时定址
1.1 全局地址空间与重定位
早期 GPU 只有一张全局地址翻译表，即 GART，Intel 称为 GTT。它把分散的物理页映射为 GPU 地址空间中的连续区间，所有进程共享这一个地址空间。地址只能由内核统一分配，通常由 drm_mm 管理；BO 在其中的位置以及是否被迁移，用户态都无从得知。
用户态构造命令时又必须引用 BO 的地址，由此形成重定位（relocation）机制。用户态在命令中为地址预留占位，并随提交附带一张重定位表，逐条说明“本 BO 的某个偏移处引用了哪个 BO 的哪个位置”。内核在提交时放置每个 BO、确定其地址，再把地址回填到命令缓冲区中，过程如图 10.2.1 所示。i915 的 execbuffer 与 radeon 的 CS 都采用这一模型。
