Base-虚拟纹理与按需分页

一张超大纹理不代表所有区域都需要同时占用显存。虚拟纹理把逻辑地址与实际驻留页面分开，只让当前需要的区域进入物理缓存。

它借用了分页思想，但 GPU 纹理采样、过滤边界、Mip 选择和反馈延迟都带来了自己的问题。理解虚拟纹理，应从地址映射和缺页后的行为开始。

1. 逻辑纹理与物理缓存

逻辑纹理由许多页面组成；物理缓存只容纳其中一部分。页表把“某个 Mip 的某块逻辑区域”映射到物理页，再由页内坐标找到实际采样位置。

因此“CPU 管理整张页表”只是某些实现的一部分，不能概括所有系统。页表查询、反馈产生、上传和映射更新可以在 CPU/GPU 间分工。

2. 一次采样背后的流程

1
2
3

UV 和 LOD → 虚拟页编号 → 页表查询 → 物理页坐标 → 纹理采样
                          ↓ 缺页
                   请求更细页 / 使用可用粗层

缺页不能让画面随意读取未初始化数据。常见方法保留更粗的层级作为回退，先显示模糊但完整的内容，等待请求满足后再提高细节。

页面边界还要支持过滤。可以为物理页准备邻域边框，或采用相应采样策略；否则双线性过滤会读到物理缓存里毫不相关的另一块页面。

3. 反馈与上传存在延迟

屏幕实际使用过哪些页，可以通过 GPU 反馈记录，再触发读取、解压/转码、上传与页表更新。这个链路通常不会瞬间完成，需要预测和预算。

快速转身或瞬移会突然请求大量页面，产生暂时模糊；上传过多可能占用带宽并造成卡顿。缓存容量、优先级和每帧上传限制，应与可接受的画面收敛时间一起调节。

4. Streaming VT 与 Runtime VT

在 UE 的术语中，Streaming Virtual Texturing 通常把提前制作的数据从磁盘按页加载；Runtime Virtual Texturing 则在运行时渲染或生成需要的纹素，再缓存结果。

两者共享分页与缓存思想，但数据生产路径不同。RVT 的页面不必像 SVT 一样从磁盘读取，“生成结果缓存”和“素材文件流送”不应画成完全相同的一条 IO 链。

5. 与 VSM 的关系

Virtual Shadow Maps（虚拟阴影贴图）也采用分页和按需分配思路，但其页面内容、更新条件、可见性反馈与阴影采样有专门设计。

因此“把 ShadowMap 虚拟化就是一个 RVT”只能表达类比，不能当作 UE 系统身份。也要避免与 Variance Shadow Maps 共用缩写 VSM 时混淆含义。

6. 成本并没有消失

系统增加页表、反馈、物理缓存、页边框与管理开销。小纹理、几乎总会完整访问的资源，未必能从分页中受益。

容量按工作集而不是源纹理总尺寸决定，但如果实际需要的页面长期超过缓存，就会频繁换页。评估时应观察缺页、上传、缓存命中和清晰度恢复，而不只看显存总量。

总结

虚拟纹理用映射和回退，把大逻辑资源拆成受预算控制的驻留集合。它与块压缩、Mipmap 和流式调度相互配合；解释一个具体系统时，仍要明确谁产生页面、谁请求、谁上传以及缺页时显示什么。

参考资料

• Epic：UE4.27 Virtual Texturing

• Microsoft：Tiled Resources