到这里我们已经走完 GEM 的用户态抽象第三章。一个很自然的问题浮现出来drm_gem_object只是一个「壳」它下面真正的物理页到底从哪来、由谁管第三章 3.1 已经埋下伏笔——GEM 把「对象身份」与「后备存储」分离后者是一个可插拔的选择同一个drm_gem_object换一种后备存储即可适配不同设备形态。落到实现上后备存储分成两大类、共三种方案本章讲其中的「轻量」一类第五章讲「重型」的 TTM轻量后备本章面向无专用显存VRAM的设备页直接来自系统内存。按「是否要求物理连续」又分两种——drm_gem_dma_object基于 CMA 的物理连续内存最简与drm_gem_shmem_object基于 shmem 的可换出匿名页更通用重型后备第五章面向有 VRAM 的独显由TTM管理 system RAM ↔ VRAM 的放置、迁移与驱逐。本节作为全章概述回答三个问题为什么轻量后备不走 TTM两类轻量后备各自解决什么本章按什么顺序展开具体实现留给后续各节。1、问题的根源不是所有 GPU 都有 VRAMDRM 的显存管理长期是围绕「独显 VRAM」建模的。但现实里一大类设备根本没有板载显存它们的缓冲区只能落在普通 system RAM 上集成显卡iGPU与 CPU 共享同一份内存各类 SoC GPUMali、Adreno、树莓派 VC4/V3D 等统一内存架构UMA虚拟 GPU比如virtio-gpu——guest 侧压根不存在物理显存BO 就是一批 guest 系统内存页。这类设备的共同特征叫UMAUnified Memory Architecture统一内存架构CPU 与 GPU 共用系统内存没有「显存 ↔ 系统内存」这道搬迁墙。对 UMA 设备来说「BO 的页从哪来」这个问题的答案极其朴素就是从系统内存里分配一批页pin 住给设备用用完释放。没有 VRAM、没有放置策略、没有驱逐迁移。2、为什么不直接用 TTM既然 DRM 已经有了 TTM为什么不让 UMA 设备也走 TTM因为TTM 的核心价值恰恰是 UMA 设备用不上的那部分。TTM 存在的理由是解决三件事Placement放置一个 BO 可以放在 VRAM、GTT 或 system 多个「内存域」需要选择与描述Migration迁移在这些域之间搬数据比如把 BO 从 system 搬进 VRAM 再搬回来Eviction驱逐显存不够时按 LRU 把别的 BO 踢出 VRAM 腾地方。这三件事都围绕「有一块稀缺的 VRAM 要精打细算」而设计。可 UMA 设备只有一种内存域——system RAMBO 永远待在那儿不需要 placement只有一个候选不需要 migration没有第二个域可搬不需要 VRAM eviction没有 VRAM。于是如果强行套 TTMUMA 驱动要为一整套用不上的机制买单复杂的ttm_resource/ttm_resource_manager/ placement 数组 / move 回调……成本全付收益为零。一句话TTM 是为「稀缺 VRAM 的精细调度」而生的重型框架UMA 场景没有 VRAM这套调度纯属负担。3、它在专栏主线中的位置回到本专栏「BO 生命周期」的主线drm_gem_shmem_helper与 TTM 是同一问题的两条并列路径drm_gem_dma_object4.2drm_gem_shmem_object4.3~TTM第五章面向场景无 VRAM、需物理连续UMA / 无专用显存有 VRAM 的独显内存域只有 system RAM只有 system RAMVRAM GTT system 多域页来源CMA 物理连续内存dma_allocshmem 可换出匿名页page pool / VRAM可否换出否钉死是可换出/回收由放置策略决定有无放置/迁移/驱逐无无有placement / move / eviction复杂度最轻轻量 helper重型 framework典型用户display controller、无 IOMMU 的 SoC、v4l2virtio-gpu、iGPU、SoC GPUamdgpu、nouveau、radeon读者读到这里应建立的核心认知是「GEM 抽象之下并非必然是 TTM」。有 VRAM 走 TTM 的重型调度无 VRAM 则走轻量后备——需要物理连续用 DMA-CMA否则用 shmem——它们与 TTM 平级各司其职。4、两类轻量后备各解决什么两类轻量后备都从系统内存取页区别在于设备能不能处理分散的页设备只能访问一段连续地址不少 display controller、没有 IOMMU 的 SoC 外设BO 必须物理连续用drm_gem_dma_object。创建时从 CMA 一次分配、钉死到底。实现最简单但连续内存稀缺也不能换出设备能处理分散的页有 IOMMU 或支持 scatter-gatherBO 不需要连续用drm_gem_shmem_object。按需取页闲置时可以换出。更通用代价是要管理页的借还、pin 与回收。选择规则只有一句需要物理连续选 DMA-CMA否则选 shmem。至于为什么偏偏是 shmem 文件而不是别的内存来源4.3 专门讨论。5、本章路线4.2 DMA-CMA最简后备用它走通「对象 后备页 用户态/内核态访问」的最小闭环4.3 为什么是 shmem从 BO 的使用需求到 GEM 框架层对后备的要求再逐层检验 shmem 文件4.3.14.3.8 shmem helper结构、建立、资源模型、核心流程、CPU 访问、回收、共享与 driver 集成4.4 应用实战用 virtio-gpu GUEST blob 把整章串起来。shmem helper 与 TTMttm_tt的对比辨析放在第五章 5.6.6那时两边都已讲过。6、本节小结GEM 把「对象身份」与「后备存储」分离后备存储是可插拔的选择存在一大类无专用显存的设备iGPU / SoC GPU / virtio-gpu / display controller它们的 BO 页只能来自系统内存用轻量后备即可轻量后备分两种drm_gem_dma_objectCMA 物理连续、钉死、最简与drm_gem_shmem_objectshmem 可换出、更通用、天然支持 dma-buf 共享TTM 的价值placement / migration / eviction都围绕「稀缺 VRAM」展开对无 VRAM 设备是用不上的负担——所以轻量后备与 TTM 是「BO 的页从哪来」的并列路径而非上下级。下一节我们先从更简单的drm_gem_dma_object入手——看 CMA 如何一次性分配物理连续内存、如何 mmap/vmap、回调表长什么样用它把「对象 后备页 用户态访问」这条最小闭环走通随后从 4.3 起再进入更复杂、更通用的drm_gem_shmem_object。
到这里我们已经走完 GEM 的用户态抽象第三章。一个很自然的问题浮现出来drm_gem_object只是一个「壳」它下面真正的物理页到底从哪来、由谁管第三章 3.1 已经埋下伏笔——GEM 把「对象身份」与「后备存储」分离后者是一个可插拔的选择同一个drm_gem_object换一种后备存储即可适配不同设备形态。落到实现上后备存储分成两大类、共三种方案本章讲其中的「轻量」一类第五章讲「重型」的 TTM轻量后备本章面向无专用显存VRAM的设备页直接来自系统内存。按「是否要求物理连续」又分两种——drm_gem_dma_object基于 CMA 的物理连续内存最简与drm_gem_shmem_object基于 shmem 的可换出匿名页更通用重型后备第五章面向有 VRAM 的独显由TTM管理 system RAM ↔ VRAM 的放置、迁移与驱逐。本节作为全章概述回答三个问题为什么轻量后备不走 TTM两类轻量后备各自解决什么本章按什么顺序展开具体实现留给后续各节。1、问题的根源不是所有 GPU 都有 VRAMDRM 的显存管理长期是围绕「独显 VRAM」建模的。但现实里一大类设备根本没有板载显存它们的缓冲区只能落在普通 system RAM 上集成显卡iGPU与 CPU 共享同一份内存各类 SoC GPUMali、Adreno、树莓派 VC4/V3D 等统一内存架构UMA虚拟 GPU比如virtio-gpu——guest 侧压根不存在物理显存BO 就是一批 guest 系统内存页。这类设备的共同特征叫UMAUnified Memory Architecture统一内存架构CPU 与 GPU 共用系统内存没有「显存 ↔ 系统内存」这道搬迁墙。对 UMA 设备来说「BO 的页从哪来」这个问题的答案极其朴素就是从系统内存里分配一批页pin 住给设备用用完释放。没有 VRAM、没有放置策略、没有驱逐迁移。2、为什么不直接用 TTM既然 DRM 已经有了 TTM为什么不让 UMA 设备也走 TTM因为TTM 的核心价值恰恰是 UMA 设备用不上的那部分。TTM 存在的理由是解决三件事Placement放置一个 BO 可以放在 VRAM、GTT 或 system 多个「内存域」需要选择与描述Migration迁移在这些域之间搬数据比如把 BO 从 system 搬进 VRAM 再搬回来Eviction驱逐显存不够时按 LRU 把别的 BO 踢出 VRAM 腾地方。这三件事都围绕「有一块稀缺的 VRAM 要精打细算」而设计。可 UMA 设备只有一种内存域——system RAMBO 永远待在那儿不需要 placement只有一个候选不需要 migration没有第二个域可搬不需要 VRAM eviction没有 VRAM。于是如果强行套 TTMUMA 驱动要为一整套用不上的机制买单复杂的ttm_resource/ttm_resource_manager/ placement 数组 / move 回调……成本全付收益为零。一句话TTM 是为「稀缺 VRAM 的精细调度」而生的重型框架UMA 场景没有 VRAM这套调度纯属负担。3、它在专栏主线中的位置回到本专栏「BO 生命周期」的主线drm_gem_shmem_helper与 TTM 是同一问题的两条并列路径drm_gem_dma_object4.2drm_gem_shmem_object4.3~TTM第五章面向场景无 VRAM、需物理连续UMA / 无专用显存有 VRAM 的独显内存域只有 system RAM只有 system RAMVRAM GTT system 多域页来源CMA 物理连续内存dma_allocshmem 可换出匿名页page pool / VRAM可否换出否钉死是可换出/回收由放置策略决定有无放置/迁移/驱逐无无有placement / move / eviction复杂度最轻轻量 helper重型 framework典型用户display controller、无 IOMMU 的 SoC、v4l2virtio-gpu、iGPU、SoC GPUamdgpu、nouveau、radeon读者读到这里应建立的核心认知是「GEM 抽象之下并非必然是 TTM」。有 VRAM 走 TTM 的重型调度无 VRAM 则走轻量后备——需要物理连续用 DMA-CMA否则用 shmem——它们与 TTM 平级各司其职。4、两类轻量后备各解决什么两类轻量后备都从系统内存取页区别在于设备能不能处理分散的页设备只能访问一段连续地址不少 display controller、没有 IOMMU 的 SoC 外设BO 必须物理连续用drm_gem_dma_object。创建时从 CMA 一次分配、钉死到底。实现最简单但连续内存稀缺也不能换出设备能处理分散的页有 IOMMU 或支持 scatter-gatherBO 不需要连续用drm_gem_shmem_object。按需取页闲置时可以换出。更通用代价是要管理页的借还、pin 与回收。选择规则只有一句需要物理连续选 DMA-CMA否则选 shmem。至于为什么偏偏是 shmem 文件而不是别的内存来源4.3 专门讨论。5、本章路线4.2 DMA-CMA最简后备用它走通「对象 后备页 用户态/内核态访问」的最小闭环4.3 为什么是 shmem从 BO 的使用需求到 GEM 框架层对后备的要求再逐层检验 shmem 文件4.3.14.3.8 shmem helper结构、建立、资源模型、核心流程、CPU 访问、回收、共享与 driver 集成4.4 应用实战用 virtio-gpu GUEST blob 把整章串起来。shmem helper 与 TTMttm_tt的对比辨析放在第五章 5.6.6那时两边都已讲过。6、本节小结GEM 把「对象身份」与「后备存储」分离后备存储是可插拔的选择存在一大类无专用显存的设备iGPU / SoC GPU / virtio-gpu / display controller它们的 BO 页只能来自系统内存用轻量后备即可轻量后备分两种drm_gem_dma_objectCMA 物理连续、钉死、最简与drm_gem_shmem_objectshmem 可换出、更通用、天然支持 dma-buf 共享TTM 的价值placement / migration / eviction都围绕「稀缺 VRAM」展开对无 VRAM 设备是用不上的负担——所以轻量后备与 TTM 是「BO 的页从哪来」的并列路径而非上下级。下一节我们先从更简单的drm_gem_dma_object入手——看 CMA 如何一次性分配物理连续内存、如何 mmap/vmap、回调表长什么样用它把「对象 后备页 用户态访问」这条最小闭环走通随后从 4.3 起再进入更复杂、更通用的drm_gem_shmem_object。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
