第九篇【维度：深度·下】GPU-Driven、虚拟化与 Compute 潜力
读完此篇你将理解：GPU-Driven 渲染的完整管线、虚拟纹理/虚拟阴影的原理、Temporal 技术族的统一视角、Compute Shader 如何重塑渲染架构、Work Graph 的前沿方向、字体渲染的归属、光线追踪的引擎级集成架构。
引子
上一篇深潜了"经典"的渲染技术——管线、材质、光照。本篇进入"现代"领域——GPU-Driven、虚拟化、Temporal 技术、Compute 管线，以及光线追踪的集成。
这些技术代表着渲染引擎的演进方向：从"CPU 编排、GPU 执行"向"GPU 自治自主"转变。
9.1 场景管理与 GPU-Driven 渲染
空间数据结构对比
| 结构 | 构建方式 | 查询效率 | 动态更新 | 典型用途 |
|---|---|---|---|---|
| BVH | 自顶向下/自底向上 | O(log n) | 重构或增量更新 | 光追加速、通用碰撞 |
| K-D Tree | 按轴交替分割 | O(log n) | 困难 | 点云查询、光子映射 |
| Octree | 空间八等分 | O(log n) | 方便 | 大世界管理、稀疏体素 |
| BSP | 按平面分割 | O(log n) | 极难（预编译） | 室内场景（经典方案） |
| Spatial Hash | 哈希映射 | O(1) 平均 | 极快 | 均匀分布的粒子/物体 |
现代渲染引擎最常用BVH和Octree。BVH 在光线追踪场景中几乎是唯一选择（GPU RT 硬件加速也基于 BVH）。
GPU-Driven 剔除管线
传统管线：
CPU: 遍历场景 → 判断可见性 → 生成 Draw Call 列表 → 提交给 GPU GPU: 被动执行 Draw CallGPU-Driven 管线：
CPU: 上传完整物体列表（一次性） → 提交 Indirect Draw GPU: 1. Compute Shader 做视锥裁剪 2. Compute Shader 做 Hi-Z 遮挡剔除 3. 生成 Indirect Draw 参数 4. 执行 Indirect Draw —— GPU 自己决定画什么核心优势：CPU 不再逐物体工作。百万级物体的场景中，CPU 端的开销从 O(n) 降为 O(1)（只需提交一次 Dispatch + Indirect Draw）。
Hi-Z 剔除的工作原理
Hi-Z（Hierarchical-Z）利用上一帧的深度缓冲做快速遮挡剔除：
- 上一帧的深度缓冲 → 生成 Mip Chain（每个 Mip Level 取 max depth）
- 对每个物体的包围盒，取对应 Mip Level 的 max depth
- 如果包围盒的最近深度 > max depth → 物体被完全遮挡 → 跳过
Hi-Z 是纯 GPU 操作——完美配合 GPU-Driven 管线。
Mesh Shader 管线
Mesh Shader 是 GPU 几何处理的重新设计：
传统管线： Input Assembly → Vertex Shader → Hull → Tessellation → Domain → Geometry → Rasterizer Mesh Shader 管线： Task Shader（可选） → Mesh Shader → Rasterizer- Task Shader（Amplification Shader）：决定需要多少个 Mesh Shader 工作组——可以做 LOD 选择、Cluster 级别的裁剪
- Mesh Shader：替代 VS/HS/DS/GS 所有阶段，输出一组三角形（Meshlet）
Mesh Shader 的意义：给了 GPU 端完全自主的几何处理能力——裁剪、LOD 选择、动态生成三角形，全部在 GPU 上完成。
Nanite：虚拟化几何的极致
UE5 Nanite 是 GPU-Driven + Visibility Buffer + 软/硬件混合光栅化的集大成者。
关键技术点：
- Cluster 化：网格被预处理为小的 Cluster（约 128 个三角形）
- DAG LOD 选择：GPU 端用两级 BVH 选择合适的 LOD Cluster
- 软件光栅：小三角形用 Compute Shader 做软件光栅（避免硬件光栅器效率低的小三角形问题）
- 硬件光栅：大三角形仍然走传统硬件光栅器
- Visibility Buffer 输出：每像素输出 Cluster ID + Triangle ID
结果：数十亿三角形的场景可以实时渲染——美术不再需要手动做 LOD。
9.2 虚拟纹理与虚拟阴影
Virtual Texture（VT）
问题：一个大世界场景可能有 TB 级的纹理数据——不可能全部载入显存。
Virtual Texture 的思路——类似操作系统的虚拟内存：
┌─────────────────────────────────────┐ │ Virtual Texture Space │ ← 逻辑上的超大纹理（如 128K × 128K） │ ┌───┬───┬───┬───┬───┬───┬───┬───┐ │ │ │ │ P │ │ │ P │ │ │ │ │ ← 只有被"看到"的 Page 真正加载 │ └───┴───┴───┴───┴───┴───┴───┴───┘ │ └─────────────────────────────────────┘ ↕ Page Table ┌─────────────────────────────────────┐ │ Physical Texture Cache │ ← 实际 GPU 显存中的纹理缓存 │ ┌───┬───┬───┬───┐ │ │ │ P │ P │ │ │ │ ← 缓存最近使用的 Page │ └───┴───┴───┴───┘ │ └─────────────────────────────────────┘工作流程：
- Feedback Pass：渲染时记录每个像素需要哪个虚拟纹理的哪个 Page（哪个 Mip Level）
- CPU 分析 Feedback：确定需要新加载的 Page
- 流式加载：从磁盘异步加载需要的 Page 到 Physical Cache
- 更新 Page Table：告诉 GPU “虚拟地址 X → 物理地址 Y”
Virtual Shadow Map（VSM）
UE5 将相同的虚拟化思想应用到阴影——Virtual Shadow Map。
问题：大量光源 × 大规模场景 = Shadow Map 数量和分辨率爆炸。
VSM 的做法：
- 每个光源的 Shadow Map 是一个虚拟的超大贴图（如 16K × 16K）
- 只有摄像机可见区域对应的 Shadow Map 区域（Page）被实际渲染
- 与 Nanite 配合：只有 Nanite 判断可见的几何体才被渲染到 Shadow Map
VT 与 VSM 的共同模式
两者的核心思想完全一致——虚拟资源模式：
逻辑资源（超大、超多） ↕ 间接层（Page Table / 映射表） 物理资源（有限的缓存空间） ↕ 按需加载 磁盘 / 动态生成这个模式还可以推广到：
- 虚拟几何体：Nanite 的 Cluster Streaming
- 虚拟光照探针：按需更新的 GI Probe
9.3 Temporal 技术族：时域复用与帧生成
统一视角：用时间换空间
所有 Temporal 技术的核心思想是一样的：当前帧不需要从零计算，可以复用历史帧的信息。
Frame N-1 的结果 ──Motion Vector 校正──→ 重投影到 Frame N Frame N 的新信息 ─────────────────────→ 与重投影结果融合关键前提：Motion Vector（运动向量）—— 告诉每个像素从 Frame N-1 到 Frame N 移动了多少。
TAA（Temporal Anti-Aliasing）
- 每帧用略微偏移的采样位置（Jitter）渲染
- 积累多帧的采样结果，等效于超采样
- 副作用：Ghosting（运动物体拖影）、Flickering
TSR / TAAU（Temporal Super Resolution）
- TAA 的升级版——不仅抗锯齿，还做上采样
- 用低分辨率渲染 → 通过 Temporal 积累重建高分辨率
- UE5 的 TSR：用 1080p 渲染 → 重建 4K 输出
DLSS / FSR / XeSS
| 技术 | 厂商 | 方法 | 硬件要求 |
|---|---|---|---|
| DLSS | NVIDIA | AI（深度学习网络） | RTX GPU（Tensor Core） |
| FSR | AMD | FSR 1 = 空间滤波（EASU + RCAS）；FSR 2+ = Temporal 时域重建 | 任意 GPU |
| XeSS | Intel | AI + 传统混合 | Intel Arc（最佳），任意 GPU（降级） |
引擎集成的共同点：
- 低分辨率渲染 → 提供颜色 + 深度 + Motion Vector + 曝光信息
- 超分模块做上采样
- 输出高分辨率结果
Frame Generation（帧生成）
DLSS 3 / FSR 3 的帧生成更进一步：在两个真实帧之间插入一个合成帧。
真实帧 N → [光流分析] → 合成帧 N+0.5 → 真实帧 N+1对渲染引擎的影响：
- 真实帧率不变，但显示帧率翻倍
- 增加一帧的输入延迟——合成帧不能包含最新的输入
- 引擎需要提供额外的光流数据（UI 层需要特殊处理）
9.4 Compute Shader 在渲染引擎中的多重角色
Compute Shader 已经渗透到渲染引擎的每一个角落。
Compute 的使用场景
| 场景 | 替代了什么 | 为什么用 Compute |
|---|---|---|
| GPU 剔除 | CPU 侧遍历 | GPU 并行剔除百万物体 |
| 光源分配 | CPU 光源裁剪 | Cluster/Tile 光源分配在 GPU 上做更快 |
| 后处理 | 全屏 Fragment Shader | Compute 可以利用 Shared Memory、灵活的工作组大小 |
| 粒子模拟 | CPU 粒子更新 | 避免 CPU↔GPU 数据往返 |
| 软光栅 | 硬件光栅器 | 小三角形时效率更高（Nanite） |
| 降噪 | — | RT 降噪（NRD）纯 Compute 实现 |
| 生成 Mip | 硬件 Blit | SPD（Single-Pass Downsampler）一次 Dispatch 生成全 Mip Chain |
Compute 如何重塑架构
传统架构：
CPU 逻辑 → 渲染命令（VS/PS）→ GPU 执行现代架构：
CPU 逻辑 → Compute + Indirect Draw → GPU 自主决策 → GPU 执行区别在于："GPU 做什么"不再由 CPU 精确指定——CPU 只提供初始数据和 Dispatch 命令，GPU 通过 Compute Shader 自行决定剔除结果、Draw 参数、资源分配。
极端方向：全 Compute 管线
有人探索过完全抛弃传统光栅化管线——所有的渲染（包括光栅化本身）都用 Compute Shader 实现。Nanite 的软光栅就是朝这个方向的实践。
当然，完全脱离硬件光栅器在大多数场景下仍不划算——硬件光栅器对大三角形的效率仍远超软件方案。
9.5 前沿：Work Graph
什么是 Work Graph？
Work Graph 是 D3D12 引入的新概念：让 GPU 上的一个 Shader 可以动态发起另一个 Shader 的执行。
传统模式： CPU → Dispatch Compute A → Dispatch Compute B → Dispatch Compute C （CPU 预先编排好所有步骤） Work Graph 模式： CPU → 启动 Work Graph GPU: Node A 执行 → 发现需要处理的数据 → 动态启动 Node B → 动态启动 Node C （GPU 运行时自行决定执行什么、多少次）与 Indirect Dispatch 的区别
Indirect Dispatch 允许 GPU 决定"执行多少次"，但执行的 Shader 和顺序仍由 CPU 预先编排。
Work Graph 更进一步：GPU 可以决定"执行哪个 Shader、多少次、以什么输入"——完全的 GPU 自治。
对渲染引擎的潜在影响
Frame Graph 目前在 CPU 端编排 Pass 依赖关系。如果 GPU 可以自己动态编排……Frame Graph 的部分职责是否可以下放到 GPU？
这是一个开放的研究问题。目前 Work Graph 还处于早期阶段，硬件支持有限，但它代表了一个方向：GPU 的自治程度持续提高。
9.6 文字/字体渲染在渲染引擎中的位置
技术方案对比
| 方案 | 原理 | 质量 | 性能 | 缩放表现 |
|---|---|---|---|---|
| 位图字体 | 预渲染字符为纹理 | 固定分辨率 | 极快 | ❌ 放大模糊 |
| SDF 字体 | 存储每个像素到字符边缘的签名距离 | 高 | 快 | ✅ 任意缩放清晰 |
| MSDF | 多通道 SDF，保留尖角 | 更高 | 快 | ✅ 尖角也清晰 |
| 矢量字体 | GPU 实时解析贝塞尔曲线 | 最高 | 中 | ✅ 完美 |
归属问题
字体渲染是典型的灰色地带：
- 布局计算（文字断行、对齐、Unicode 处理）→ UI 框架的职责
- 字形光栅化（生成位图/SDF）→ 字形库的职责（FreeType、HarfBuzz）
- GPU 绘制（纹理采样 + Alpha Test/Blend）→ 渲染引擎的职责
实际上，大多数引擎把字体渲染放在 UI 框架中实现，但底层的 GPU 绘制依赖渲染引擎的能力。
3D 场景中的文字
当文字出现在 3D 场景中（如游戏中的广告牌、伤害数字、物体名称标签），渲染引擎必须直接支持——因为这些文字需要参与 3D 变换和深度测试。
9.7 光线追踪的引擎级集成
加速结构管理
光线追踪的性能取决于**加速结构（Acceleration Structure，AS）**的质量。
| 结构 | 内容 | 更新策略 |
|---|---|---|
| BLAS（Bottom-Level AS） | 单个 Mesh 的三角形数据 | 静态 Mesh 构建一次；蒙皮 Mesh 每帧 Refit |
| TLAS（Top-Level AS） | 所有 BLAS 实例的变换和引用 | 每帧重建（变换频繁变化） |
BLAS 构建代价高但不频繁；TLAS 重建代价低但每帧都需要。合理的 BLAS 分组策略（哪些三角形放在同一个 BLAS 中）对性能影响显著。
RT Pipeline vs Ray Query
| 方式 | 描述 | 适用场景 |
|---|---|---|
| RT Pipeline | 完整的 RT 管线（Ray Generation、Any Hit、Closest Hit、Miss Shader） | 复杂光追效果、路径追踪 |
| Ray Query（inline RT） | 在光栅化 Shader 中调用TraceRay | 简单光追效果（RT Shadow、RT AO） |
Ray Query 的集成更简单——不需要专门的 RT Pipeline，只需在现有 Fragment Shader 中加一个RayQuery调用。大多数引擎的 RT Shadow 和 RT AO 使用 Ray Query 实现。
Shader Binding Table（SBT）管理
SBT 是 RT Pipeline 模式下的核心复杂度。它定义了：
- 光线打到某个物体时，执行哪个 Hit Shader
- 光线未命中时，执行哪个 Miss Shader
- 不同材质的物体对应不同的 Shader 和参数
SBT 的管理涉及：
- 材质与 Hit Shader 的映射：每种材质需要在 SBT 中有对应的条目
- 动态更新：场景变化（物体增删）时，SBT 需要同步更新
- 内存布局：SBT 的 Record 需要按特定对齐和顺序组织
这是 RT 在引擎中集成的工程复杂度核心。
混合管线架构
实际中，RT 不会取代光栅化——而是互补：
不透明物体 → 光栅化（Deferred / Visibility Buffer） 阴影 → RT Shadow（精确、无走样）或 Shadow Map（更快） 反射 → RT Reflection（精确）或 SSR（更快） GI → RT Probe（DDGI）或 Lumen 混合方案 AO → RTAO 或 SSAO引擎需要提供质量/性能档位切换——让用户根据硬件能力选择 RT 或传统方案。
各引擎的 RT 集成对比
| 引擎 | RT 策略 | 特点 |
|---|---|---|
| UE5 Lumen | 软件光追（SDF-based）+ 可选硬件 RT | 不强制要求 RT 硬件 |
| Frostbite | 硬件 RT Reflection + RT Shadow | EA 的旗舰效果 |
| Unity HDRP | RT Shadow / Reflection / GI（需要 DXR 硬件） | 可选开启 |
| Filament | 无 RT 集成 | 移动端优先，RT 不在设计目标内 |
小结
本篇涵盖了渲染引擎"现代化"的核心主题：
| 主题 | 核心趋势 |
|---|---|
| GPU-Driven | CPU 退出逐物体工作，GPU 自主决策 |
| 虚拟化 | 逻辑资源无限大，物理资源按需加载 |
| Temporal 技术 | 用历史帧信息降低当前帧计算量 |
| Compute 管线 | Compute Shader 渗透渲染引擎每个角落 |
| Work Graph | GPU 自治程度持续提高 |
| 光线追踪集成 | 混合管线为主流，全 RT 仍遥远 |
下一篇，我们从技术维度转向时间维度——回顾渲染引擎的历史演进。
💭 思考题：
- 为什么延迟渲染在移动端不受待见，而 Forward+ 却很流行？
- Virtual Texture 和 Virtual Shadow Map 的"虚拟化"思想有什么共同点？能否抽象出一个统一的"虚拟资源"模式？
- Work Graph 会不会让 Frame Graph 过时？
