1. 从Humus的仓库说起：HyperFrames在图形技术版图里的位置
如果你在GitHub上搜索"HyperFrames"这个词，大概率会看到一位ID叫Humus的开发者留下的仓库。Humus本名Emil Persson，是EA DICE时期Frostbite引擎渲染架构的核心人物之一，也是图形圈子里公认的"喜欢把复杂的渲染技术做成小巧demo"的高手。HyperFrames就是他在离开DICE之后，以一个独立研究者的身份持续维护的实验性渲染框架——它不是要跟商业引擎比功能完整度，而是要回答一个更本质的问题：现代GPU驱动渲染（GPU-driven rendering）到底应该长什么样。
我这个月在组里做渲染架构调研，顺手把这个项目翻了个底朝天，从clone到跑demo再到逐段读shader，前后花了大概一个多星期。说实话，看它的价值不在"拿过来就能用"，而在"看懂以后你的引擎很多设计都能少走弯路"。这篇文章就围绕HyperFrames展开，聚焦几个最值得吃透的技术点：GPU驱动的绘制提交、可见性缓冲、虚拟纹理，以及它作为"实验台"所展现出来的现代API设计思路。不管你是正在做自研引擎，还是给公司项目做渲染优化，这篇文章都适合你。
开头先声明一点：HyperFrames不是一个产品级引擎，也没有完整的材质系统、动画系统、场景管理。它是一个带有一组演示场景的渲染试验框架，代码量不算大，但信息密度很高。理解它的正确姿势，是先把它拆散，再按自己的需求组装。
1.1 Frostbite渲染架构师的开源试验场
Humus在DICE期间做的事情，很多关注Frostbite的人应该略有耳闻——那时候他就经常在个人网站上放出各种炫技demo，从Shadow Volume的改进到HDR色调映射的细节，每篇都配了可直接下载的源码。他的风格很统一：把某个难点剥离出来，做一个最精简的可运行项目，然后附上几句直击要害的说明。HyperFrames延续了这个风格。
这个项目把近些年在各家引擎里才逐步落地的技术，以"开放式教科书"的形式呈现出来。你可以看到Indirect Drawing（间接绘制）是如何与Compute Shader配合的，可以看到Visibility Buffer（可见性缓冲）和传统G-Buffer在实际Demo中的取舍，也可以看到虚拟纹理是如何通过反馈机制去管理几十GB级别的贴图集的。它是个将"最新的图形学论文思想"直接转化为HLSL代码的试验场。
值得多说一句的是，Humus后来参与过SIGGRAPH 2021的GPU-Driven Rendering课程分享，日期是2021年8月，主题材料在社区里流传度很高。HyperFrames里很多代码其实就是那段时间迭代出来的。因此，如果你之前看过那套课程又觉得太抽象，那么以HyperFrames为参考底稿去对照着读，理解速度会快很多。
1.2 给"名字"排雷：同名技术分散在很多领域
我为什么特意要提一句"排雷"？因为"hyperframes"这个名字并不只有GPU渲染这一个指向。如果你是做网络协议或者嵌入式开发的，搜索这个词时会看到大量不同的内容：某些链路层协议把多个帧打包成一个聚合物，称为超帧（hyperframe），它服务于提高链路的传输效率；如果你关注一级方程式赛事，也会遇到一个发音接近的"Hyperfast"概念，指的是一种偏向极端性能的轮胎或调教策略。这些和图形渲染都没有关系。
所以，搜技术资料时一定要带上下文。我接下来聊的全部内容，都限定在一句话以内：HyperFrames是一个用于研究和演示GPU驱动渲染的Vulkan/Direct3D 12实验项目。读代码时也是同样的道理，先分清它内部哪些目录属于Core抽象层，哪些属于Demo场景，否则很容易在框架代码里迷路。
2. 上手实践：把HyperFrames跑起来的完整过程
我不想把文章直接写成纯理论课，所以先讲实操。HyperFrames在Windows上编译最顺，它的核心后端同时支持Direct3D 12和Vulkan，但我个人建议主要用Vulkan后端来跑，原因很简单：RenderDoc对Vulkan的抓帧调试支持更完善，而且Vulkan的验证层（Validation Layers）能帮你抓到很多隐藏的资源使用错误。
2.1 环境准备清单
我的测试环境是Windows 10 22H2，CPU是Ryzen 7 5800X，显卡是RTX 3070，显存8GB。这套配置跑它的所有示例都没有压力。具体需要准备的东西如下：
- Visual Studio 2022，选择"使用C++的桌面开发"工作负载，装Windows SDK组件。
- Vulkan SDK，建议装最新的稳定版，这样才能匹配到较新的HLSL编译器dxc。
- CMake 3.20以上版本，官方直装包或者Visual Studio自带的都可以。
- Git，用来clone仓库。
有一个特别常见的坑：Vulkan SDK安装时默认会设置VULKAN_SDK环境变量，但如果你同时安装了多个版本的SDK，CMake配置时可能缓存了旧路径，导致链接阶段报出vulkan-1.lib找不到。解决方式是删除CMake缓存目录重新配置，或者在系统环境变量里手动检查VULKAN_SDK是否指向当前安装的版本。
2.2 构建、编译、运行三个示例
仓库clone下来之后，目录结构很清爽。构建流程基本就是标准的CMake流程：
git clone --recursive https://github.com/humus/HyperFrames.git cd HyperFrames cmake -S . -B build -G "Visual Studio 17 2022" -A x64 cmake --build build --config Release --parallel 8在这里我额外提醒一句--recursive不是可选项。项目里有几个子模块依赖，其中包含了部分第三方头文件库，不拉子模块的话，编译到一半会报找不到头文件的错误。我第一次就没拉，硬是浪费了半小时去手动下载，属于赔了时间又折了心情。
构建完成后，build\Release目录下会生成若干可执行文件。我建议按下面三个顺序依次跑：
- 第一个示例是最基础的绘制三角形/立方体的程序，验证渲染管线整体是否正常。跑它的时候留意控制台输出，如果Vulkan验证层报错，通常驱动或者SDK版本有问题。
- 第二个示例是加载glTF模型并做常规的PBR光照。它内部其实已经用到了间接绘制和GPU材质绑定，可以先感受一下和传统实现在观感上的差异。
- 第三个示例是GPU粒子系统，也是我第一次跑完就忍不住截图的场景。数万个粒子完全由Compute Shader模拟并直接生成绘制参数，CPU这边只是每帧丢一个时间戳下去，剩下的什么都不管。
2.3 用RenderDoc抓一帧：看GPU开销的分布
跑通之后，我立刻用RenderDoc抓了几帧，这一步最好别跳过。抓帧之后重点看两个地方：
第一是事件浏览器（Event Browser）里的GPU时间。你会发现HyperFrames里几个Demo的draw call数量并不小，动辄上千，但CPU端的API调用耗时被压缩得很低。原因在于大量绘制指令是通过DrawIndexedInstancedIndirect这类间接绘制一口气提交给GPU的，CPU逐个生成绘制命令的开销被彻底移除了。
第二是几何阶段之后缓冲区的尺寸。以可见性缓冲Demo为例，G-Buffer不再存一整堆颜色、法线、粗糙度、金属度浮点纹理，而只存了三角形ID、实例ID这样的整数信息。这意味着带宽占用明显下降，这在高分辨率和高刷新率场景下收益非常大。后面我会专门展开讲这个机制。
这里要说一下很多人容易产生的误解：并不是每个场景都适合无脑上GPU Driven。如果你的场景最多只有几百个物体，三角形总数几十万，那传统管线配合实例化的开销完全可以忽略。GPU Driven这套方法论适合的场景是：物体数量成千上万，遮挡关系复杂，可见集每帧都在剧烈变化，这时候用CPU做可见性计算就会相当吃力。
3. 拆解GPU驱动的渲染主循环
HyperFrames最核心的贡献，是把一整套GPU驱动渲染的主循环讲清楚了。所谓GPU驱动，通俗点说就是：传统流程里CPU像一位"勤劳的场记"，它要去数场景里有哪些物体、哪些被视锥剔除、哪些被遮挡剔除，然后逐条写下"先画这个，再画那个"的指令清单交给GPU。而GPU驱动的思路是让CPU退位成"制片人"，只负责定大方向和分配大块资源，具体的"谁该出现在镜头里、用什么LOD、画几份"这些细活，全部由GPU自己算。
3.1 传统管线的CPU瓶颈
传统Forward或Deferred渲染里，一个场景有几千个物体时，CPU就要为这一帧循环做几千次粗粒度剔除操作，每次剔除还要处理矩阵变换、包围体判断、状态切换。当调用DrawCall数量达到上千时，即便对Direct3D 12或Vulkan这样较新的API来说，CPU的开销依然会成为帧率瓶颈，尤其在一些物理、动画逻辑本身就要吃不少帧时间的项目中，渲染线程的时间预算会更紧张。
一个值得注意的细节是：DrawCall的瓶颈往往不是在调用本身，而是在驱动层的命令缓冲区构建和状态校验。GPU驱动渲染的动机之一就是"绕开"这条链路，通过批量提交的Indirect参数，让GPU在自己的硬件调度器里完成可见性判断和绘制参数生成。它强调的是"少汇报、多干活"。
3.2 间接绘制：把"画什么"的决定权交给GPU
在Direct3D 12和Vulkan中，间接绘制的基本数据结构是统一的，大概长这样：
struct DrawIndexedIndirectArgs { uint indexCountPerInstance; uint instanceCount; uint startIndexLocation; int baseVertexLocation; uint startInstanceLocation; };HyperFrames里的大量绘制，都是CPU提前分配好一个较大的命令参数缓冲（Argument Buffer），然后在GPU上用一个Compute Shader去填充这个结构体。这个Compute Shader的工作包括：遍历实例列表、做视锥剔除、检查LOD距离、把需要绘制的实例写入参数缓冲区，同时通过原子操作累计实际instance数量。整个过程CPU完全不参与。
StructuredBuffer instanceIdBuffer;
RWStructuredBuffer indirectArgsBuffer;
[numthreads(64, 1)] void CSMain(uint3 id : SV_DispatchThreadID) { uint instanceId = instanceIdBuffer[id.x]; float3 center = GetInstanceWorldPos(instanceId); // 简单视锥剔除，通过则翻转可见位 if (IsVisible(center)) { uint slot; InterlockedAdd(indirectArgsBuffer[0].instanceCount, 1, slot); visList[slot] = instanceId; } }
这段代码是示意性质，但思路完全一致：GPU需要维护一个每帧清空的可见列表，再通过InterlockedAdd来紧凑化存储。紧凑化之所以重要，是因为如果Graphics Pipeline直接从一个稀疏的instance列表里拿数据，你很难判断哪些实例的连续内存被跳过了，而紧凑列表让后续的光栅化阶段可以保持连贯的内存访问。 间接绘制另外一个容易忽略的好处是状态切换减少。因为大量的物体使用同一套渲染状态（同一个Pipeline State Object，同一组绑定资源），GPU就可以在硬件层面做更高效的批处理，省掉很多状态切换时间。 ### 3.3 可见性缓冲：少一点G-Buffer写入 G-Buffer这个老朋友，在传统Deferred渲染里承担着非常大的带宽压力。常见的做法是存3到4张全屏纹理：漫反射颜色、法线/粗糙度、金属度/环境光遮蔽，再加上深度。每张纹理都是RGBA甚至R16G16B16A16F格式，四张加起来，一张1080p的GBuffer就要写接近100MB的数据。要是跑到4K，这个数字会膨胀到以GB计算。 可见性缓冲的思路很简单：渲染G-Buffer阶段时只写少量信息——三角形ID、实例ID、深度，中间结果都留在寄存器里。真正需要做像素着色的阶段放到后面，通过ID反查出材质数据，再按需读取。这样G-Buffer的写入量可以压缩到原来的几分之一，带宽压力小得多。 HyperFrames对这条思路的实现很直接：在它的Visibility Buffer Demo中，第一遍光栅化只输出一个整数型的Instance/Triangle ID加上Depth，后面的光照阶段再用全屏Pass做材质数据读取和BRDF计算。因为材质信息不再存储在全屏纹理里，光照阶段也要换成"按需采样"的间接寻址读取模式。 实践中有个需要特别考虑的点：三角形ID到材质数据的映射需要一张全局的物体-材质表，很多数据要提前填充到一个大Buffer里。这类"一整个场景数据全在GPU大缓冲里"的存储方式，是GPU Driven路线的基础习惯，你得习惯这种"不按单个物体绑定资源，而是把所有物体数据摊开在几个巨型Buffer里"的思维模式。 ### 3.4 HZB遮挡剔除：用上一帧的深度经验剔除 前面说的视锥剔除只是开胃菜，真正复杂的是遮挡剔除。一个场景里，视锥外部的物体可以快速被干掉，但大量在视锥内、却被墙或建筑挡住的物体，传统CPU方案要逐帧用上一帧的深度做查询，效率不高。GPU Driven方案自然的做法是：把上一帧渲染好的深度图降采样，构建一棵层次Z缓冲（HZB，Hierarchical Z-Buffer），再用Compute Shader快速判断当前物体的包围盒在哪个Mip层级上就完全不可见。 HyperFrames沿用了这些年行业验证过的HZB思路。核心步骤是：上一帧深度写入一张纹理，然后做若干次降采样，每级Mip存储对应区域的最小深度。剔除时，先算出包围体的屏幕投影范围和它对应的Mip级别，再对HZB采样；如果包围体深度全部大于HZB中记录的深度，说明它完全被遮挡，可以跳过绘制。 再用一句话说明白点：HZB就是让GPU做遮挡剔除时不需要"精确地逐像素查询"，而是用一个更粗粒度的深度表，快速排除一大批肯定被挡住的东西。这个技术很有魔力，我第一次在项目里用HZB做剔除时，场景里上万棵树实际每帧需要绘制的不到三成，画面看上去却没有任何区别。 ## 4. 虚拟纹理这门"字典功夫" HyperFrames里的虚拟纹理（Virtual Texture）实现，是我认为最值得单独写一节的内容。它在图形学里算是个老技术了，但在今天的大世界场景、开放世界项目里依然有相当高的实战价值。 ### 4.1 一张大贴图怎么塞进小显存 传统纹理处理方式中，艺术家会给每个物体做一套2K或4K的贴图，一个场景的贴图总量动辄几十个GB。显卡显存普遍在8GB到16GB之间，不可能全部装下。过去做法要么是压缩格式硬扛，要么用Mipmap加上运行时流送，把低Mip的贴图常驻显存、高Mip的按需加载。 但这么做有个问题：你只能在一个方向（Mip级别）上做取舍，没办法灵活地按"空间区域"精确加载。换句话说，假设整个场景是一张几十GB的"超级大贴图"，你希望在离玩家近的地方保留细节、远的地方丢弃细节，且希望某个距离范围内能按需只加载那一小片区域的高Mip内容。这就要靠虚拟纹理来当"翻译官"了。 ### 4.2 页表、页面、反馈：VR机制三步走 虚拟纹理的基本思想，是把一张巨大的逻辑纹理分成很多小块，每个小块称为一个页（Page），通常尺寸是128x128或256x256像素。显卡里同时驻留一个固定大小的页缓存（Page Cache），它就像一个"物理托盘"，只放得下少数页。还需要一张页表（Page Table），它记录了逻辑页号到物理缓存位置的映射关系，GPU通过它完成"本来想访问逻辑坐标，但真正去缓存里找物理数据"的跳转。 想让这套机制工作，光有映射还不够，还必须知道"当前画面里缺了哪些页"，这里需要GPU反馈（Feedback）。做法是在一个Pass里把画面需要的页号写出来：每个像素根据自己的UV坐标算出需要的Page ID，写入一个Feedback Buffer，然后CPU或GPU端再把这个Buffer收集起来，决定哪些页需要从磁盘加载到显存缓存里。 这个过程有点像查字典：GPU拿到的UV坐标是"单词"，页表是"目录"，根页表是"章节号"，物理缓存页才是"具体的释义页"。虚拟纹理系统要做的是维持这本字典：哪个词（页）最近经常被翻到，就把它留在手边；哪个词很少被翻到，就把它换出去。 ### 4.3 HyperFrames实现里的三个细节 我在读HyperFrames虚拟纹理相关代码时注意到三个值得学习的细节： 第一是页表层级的选择。它没有用单个巨大的页表，而是用了多级页表结构，这在处理超大虚拟纹理时很关键。单级页表在逻辑纹理达到64Kx64K时需要极其臃肿的连续显存，多级页表则可以让常见访问命中在较高层级上，提高命中率。 第二是反馈Pass的设计。它并不每帧都对全屏做页面请求采集，而是会结合上帧的需要做增量更新——只有变化的那部分屏幕区域才需要重新采样。这种"按帧差更新"的思路在避免CPU-GPU同步方面起到很大帮助。 第三是Mipmap与页的绑定关系。它把Mip级别也视为页的维度之一，一个物理缓存页既能存放一个高Mip的局部区域，也能存放一个较低Mip的更大范围。这种设计让"远处用低分辨率、近处用高分辨率"这一规则能非常自然地融入页表结构，而不用在纹理API层面做额外调节。 我实际写过一个简化版虚拟纹理系统，最深的体会是：反馈环节的CPU-GPU同步是最容易做坏的。一个无脑的做法是每帧把Feedback Buffer映射回CPU，用for循环扫描几万个页号去拼请求列表，这样做通常在1000个以内时没事，但场景一大就会产生可感知的帧时间尖刺。正确做法是先把Feedback Buffer在GPU上做一次紧凑化压缩（Compaction），把有效页号压缩到一小块Staging Buffer里，等真正只有几百条的请求列表生成后，再同步回CPU。HyperFrames处理这一步时也用了类似的思路。 ## 5. 值得"偷师"的几个设计决策 这一节不讲宏大的架构，就讲我从HyperFrames里提炼出来的、可以直接用到自己项目里的几个工程决策。它们看起来都不起眼，但组合到一起，能让渲染代码的条理性提升一大截。 ### 5.1 让CPU当"制片人"而不是"场记" 通常引擎的RenderThread会管理一个命令列表，逐个物体设置常量、绑定资源、提交绘制。这种模式在引擎开发早期很自然，但随着渲染特性的增多，CPU侧代码会逐渐变得臃肿：每个新特性都需要在CPU侧增加一段"设置这个、绑定那个"的逻辑，最终导致渲染线程成为性能瓶颈。 HyperFrames给我的启示是：**把"逐物体决策"尽量下沉到GPU侧的数据结构里**。CPU要做的，是提前把物体列表、变换矩阵、材质索引这些数据写成紧凑的Buffer，然后告诉GPU"这是本帧所有候选对象的家底"；具体怎么剔除、怎么排序、怎么合并实例，是GPU里Compute Shader的职责。这样CPU侧代码量会明显减少，新加一个渲染特性时，你通常只在GPU端增加一个计算Pass，而不是在CPU端增加一堆状态设置。 ### 5.2 粒子系统的一次性参数提交 HyperFrames里的GPU粒子Demo，可以看作5.1思想的一个小而精的实践。粒子的位置、速度、生命周期全部保存在GPU Buffer里，模拟逻辑在Compute Shader中完成。CPU每帧只更新一个包含全局时间、风力方向、粒子数量上限的常量缓冲，剩下的全都在GPU里流转。 用RenderDoc抓帧时你会看到：粒子Pass里只有一个Compute Shader模拟调度，加一个DrawIndexedInstancedIndirect绘制。所有粒子的基本信息是从一个巨大的顶点缓冲中读的，而"当前实际活跃粒子数"则是上一个Compute Pass写进IndirectArgs的。CPU对这个数量完全不需要知道，你甚至可以在UI里实时调节粒子生成速率，CPU侧一个字节都不用改。 ### 5.3 光栅化与光追混合：算力花在刀口上 HyperFrames的实验范围也触及了混合渲染——一部分物体用传统光栅化，另一部分（比如反射/折射要求高的）用光线追踪。这不是简单的二选一，而是把光追作为光栅化的一份"补充协议"，只对屏幕上真正需要精确光线的像素做追踪。 实际工程里我比较倾向的一种做法：先正常光栅化不透明几何体，得到主视图的深度和材质数据，然后在需要镜面反射或者大面积焦散的像素位置，做稀疏的光线追踪。这样既保留了光栅化在纯表面着色上的高效，又得到了光追在间接光照/TAA/反射方面的准确度。代价是需要仔细处理两种管线产生数据的一致性。 ### 5.4 现代API下的资源状态管理 如果你从Direct3D 11或者OpenGL迁到Direct3D 12或Vulkan，最先爆棚的一定是资源状态管理的复杂程度。HyperFrames在这方面做了一个非常实用的处理：把资源状态转换集中到Pass边界上。也就是说，每个RenderPass开始时统一处理所有资源的初始状态，结束时统一转回可读状态，尽量避免在Pass中间随意做Barrier。这样虽然会有一些不必要的过度转换，但换来的是极低的调度复杂度和极容易排查的状态错误。对中型渲染框架来说，这个取舍很划算。 ## 6. 我踩过的坑和给你的忠告 最后这部分，全是实际操作中容易踩到的问题，也是网上资料轻易不会提到的。如果你正准备拿这个项目练手，建议把这一节先读完。 ### 6.1 硬件与驱动版本的坑 HyperFrames对硬件的要求其实不高，GTX 1660级别就能跑大多数Demo，但如果你用的是非常老的驱动或者非常新的Beta驱动，体验可能会不太稳定。我遇到过一次画面随机闪烁，排查了整整两天，最后把NVIDIA驱动从某个Beta版回退到Studio版就消失了。渲染技术栈越"新潮"，对驱动的敏感度就越高，HyperFrames里大量用到了可变速率着色（VRS）、Mesh Shader这类需要驱动配合的特性，驱动版本不对很容易出奇怪Bug。 另外，如果你用AMD显卡跑Vulkan后端，建议开启Shader Cache选项，并保持最新的Adrenalin驱动。个别示例在旧版本驱动上有明显的短板效应。 ### 6.2 编译链路上的坑：Vulkan SDK与CMake 再强调一次编译链路的问题。Vulkan SDK安装完成后，你最好手动检查一下环境变量： ```bash echo %VULKAN_SDK%如果输出为空或者路径不对，CMake虽然也能生成工程，但最终的链接阶段会报一堆"无法解析的外部符号"，全是vulkan-1.lib里的函数。这时候不在代码里找Bug，回环境变量里找原因就行。
还有一个常见坑：如果系统里装了多个版本的Visual Studio，CMake配置时要显式指定Generator，否则它会默认选择最新的，而你最新的VS可能没装C++工具链，配置成功但编译失败，报错还非常隐晦，容易让人怀疑人生。
6.3 别把Demo当产品：它是什么和学习建议
最后给出我的定性结论：HyperFrames是教科书，不是产品。它的代码刻意简化了很多在真实引擎里不可回避的复杂度，比如完整的内存分配器、跨平台抽象、资产管线。你不能指望直接拿它去做一个可发布的产品。
但我依然建议你花时间认真读它，有几个理由。第一，它展现了渲染架构演进的方向，让你看到"未来三到五年主流引擎会往哪里走"。第二，它的目录组织方式就是一套极佳的"渲染特性索引"：想做间接绘制就看对应示例，想做虚拟纹理就看对应目录，想做GPU粒子就直接抄那一段核心Shader，省去到处搜资料的时间。第三，它是当前少有的、同时覆盖光栅化和光线追踪两条路线的开源结构，对研究对象非常有价值。
如果你读完这篇还想深挖，我的建议是接下来再去看Frostbite在GDC上公开的那套GPU Driven渲染分享，以及3D渲染系列里关于Visibility Buffer的经典文章，它们和HyperFrames形成了很好的互补关系。动手方面，就别只满足于跑通示例了——试着给HyperFrames加一个自己的渲染Pass，比如一个简单的SSAO或者轮廓线渲染，把你改完的代码和原版的差异当作你的个人学习笔记。这种方法，比单纯抄代码要扎实得多。
