2.2 渲染管线基础

2.2 渲染管线基础

本节摘要：游戏逻辑算完的世界只是数据，把它变成屏幕上的像素要经过一条多工位流水线，而且游戏线程、渲染线程与 GPU 三方并行、各记各的账。本节讲清一帧画面经过哪些工位、前向与延迟渲染如何取舍，让你看到画面时能反推出预算流向。

卡顿为什么总是"慢半拍"

用性能面板看过帧时间的人常发现一个反直觉现象：帧率掉了，但游戏逻辑明明很轻。原因在于渲染不是一个线程的单人舞，而是三个参与者的接力——游戏线程决定世界状态，渲染线程把状态翻译成绘制指令，GPU 执行指令产出像素。三方排队前进：渲染线程要等游戏线程交出场景，GPU 要等渲染线程喂饱指令。任何一环排队，瓶颈就在那一环，其他环节再闲也救不了帧率。

本节在知识体系中的位置：承接 2.1 的四层架构（渲染属于引擎的功能模块，但它的并行结构独立成篇），向下为第五章的材质、Nanite、Lumen 提供工位坐标——到时候学的每个特性，都能对应到管线上的具体工位和具体开销。看懂本节，第五章的"预算听证"才有账本可查。

一帧画面的流水工位

以延迟渲染（引擎默认路径）为例，一帧画面的加工顺序大致是：可见性剔除决定哪些物体进入本帧；几何处理生成 GPU 缓冲并写入深度；基础通道把场景里每个可见像素的材质属性（颜色、法线、粗糙度）写进一组缓冲区；光照通道拿着这些缓冲对每个光源做着色计算；半透明物体按深度从后往前叠加；后处理做曝光、色调映射、抗锯齿等收尾。每帧如此，周而复始。

三个工位概念需要提前认识。绘制调用（Draw Call）是 CPU 向 GPU 下达的一次绘制命令，一帧的绘制调用数量直接影响渲染线程负载——两万个独立小物件即使面数很少，两万次调用也能压垮渲染线程，这正是第五章 Nanite 要解决的问题之一。过度绘制（Overdraw）指同一像素被反复着色，半透明区域与粒子密集处尤其严重，这是第六章特效章节的预算重点。动态分辨率则是一根安全阀：预算超支时引擎主动降低渲染分辨率保帧率，画质换流畅的自动交易。

前向与延迟的取舍值得一笔账。前向渲染在基础通道就直接算光照，每个像素对每个光源算一遍，光源一多开销爆炸，但半透明与抗锯齿天然友好；延迟渲染先把材质属性存进缓冲、最后统一算光照，光源数量几乎不影响成本，代价是那组全屏缓冲的显存与带宽、以及半透明物体的特殊处理。引擎对不透明物体走延迟、半透明物体走前向，等于每个物体按自身性质选了最划算的柜台。移动端则常整体退回移动前向管线，用画质上限换取带宽——不同平台，预算结构不同。

渲染管线工位图

多线程时序：为什么改动会"慢一帧"

游戏线程与渲染线程各持有场景的一份视角，渲染线程用的是上一次游戏线程交出的快照。于是有一个可观察的现象：在 C++ 里改了某个物体的可见性，同一帧的画面未必变化，要等渲染线程消化完队列。两线程之间的同步点叫帧栅栏，渲染线程落后游戏线程过多时，栅栏会让游戏线程停下来等——这就是性能面板上"游戏线程被渲染拖住"的形态。

一条实用的诊断经验：逻辑改动生效慢，查线程间排队；画面内容错了，查快照与依赖；帧率整体下滑，先分清三方谁在超时。第九章的性能分析会把这套判断自动化，本节先建立直觉。

案例：用控制台给一帧称重

背景：场景里摆了上万个小物件后帧率从一百二掉到四十多，需要定位瓶颈在哪一方。这是全书第一个完整的性能听证操作，流程在第九章还会升级复用。

操作：在运行中的视口按波浪键呼出控制台，依次输入三条统计命令。第一条统计每帧的总耗时、游戏线程耗时、渲染线程耗时与 GPU 耗时四行数字；第二条细分渲染线程内部的耗时构成；第三条直接测量 GPU 各通道耗时。观察十几秒，记录四行数字的相对大小。

stat unit          // 四行考勤：帧 · 游戏 · 渲染 · GPU，看谁最大
stat scenerendering // 渲染线程内部：绘制调用数、三角面数、可见物体数
stat gpu            // GPU 各通道耗时：基础通道、光照、半透明、后处理
​

结果：帧时间约二十五毫秒，其中游戏线程九毫秒、渲染线程二十二毫秒、GPU 十八毫秒。渲染线程最大且接近帧时间，细分面板显示绘制调用一万四千多次。

解读：瓶颈锁定在渲染线程的指令提交环节——物件多而散，每个都是一次独立绘制调用，GPU 本身并不满载（十八毫秒说明它还能接活），纯粹是点菜的人把厨房单子堆爆了。这正是绘制调用瓶颈的标准形态：与面数无关，与物件数量有关。变式与对策在后续章节各有一个：短期用合批与实例化减少调用次数（第九章详述），长期把静态小物件交给 Nanite（第五章），让引擎用集群化绘制吃掉这批单子。同一套听证流程换个场景：若 GPU 行最大而渲染线程很小，问题就从"单子太多"变成"菜太硬"，该查的是材质复杂度与过度绘制——第六章的粒子案例会演示这个分支。

本节要点回顾

• 三方接力：游戏线程、渲染线程、GPU 排队前进，帧时间是三者最大值而非总和。
• 延迟渲染的取舍：光源数量与像素成本解耦，代价是缓冲区带宽；半透明仍走前向。
• 绘制调用数与物件数量挂钩而与面数无关，是渲染线程最常见的超支项。
• 改动慢一帧源于渲染线程消费快照，属于正常的并行时序而非故障。
• 听证入口是统计命令三件套：先分清三方，再钻进超时方内部看明细。

高频问答

问：动态分辨率降低了渲染分辨率，画质损失玩家能看出来吗？
快速运动的场景里几乎无感，静止低负载时引擎会主动升回满分辨率——它只在预算超支的瞬间介入。真正要警惕的是频繁抖动：场景负载在阈值附近来回跳，分辨率忽高忽低，画面会发糊。对策是给项目设置里加上下限约束，或从源头削减负载让分辨率稳定在高位。

问：为什么半透明物体排序错了会穿帮，不透明就没事？
不透明物体靠深度缓冲说话，谁离相机近谁赢，与绘制顺序无关；半透明不写深度，只能按"从后往前"的顺序叠加，顺序错一对，叠加结果就错一次。这也是半透明贵的原因之一——它需要排序，且排序依据只在粗粒度上可靠，重叠复杂处免不了露馅。

问：帧率掉到三十，加到六十需要把三方都提速吗？
不需要，只需要修最大那个。帧时间由三方最大值决定，让第二名提速对总分没有帮助。先考勤、后动手，是本节最重要的一句结论——第九章的完整取证流程就是把这句话展开成工具与参数。

一个观察能力的练习

打开任何一个运行中的项目，先猜后测：猜瓶颈在三方中的哪一方，再用考勤命令验证。猜错的次数就是直觉校准的进度——有经验的工程师猜中率高，不是天赋，是被验证过的直觉反复训练出来的。这个练习成本几乎为零，值得在每个项目里做。