云边笔记

先给结论#

UE5 的“渲染管线”不能只理解成一条从 Vertex Shader 到 Pixel Shader 的 GPU 流水线。站在引擎源码层面，它至少包含四层：

1. 场景同步：Game Thread 上的 UPrimitiveComponent 等对象，把渲染所需数据同步为 Render Thread 拥有的 FPrimitiveSceneProxy / FScene 数据。
2. 可见性与绘制准备：为每个 View 做剔除、LOD、遮挡判断，把 FMeshBatch 转成适合提交和排序的 FMeshDrawCommand。
3. 帧图调度：Renderer 用 RDG 声明 Pass、资源与依赖，RDG 管理资源生命周期、屏障、Pass 裁剪和部分异步计算调度。
4. GPU 执行：RHI 把引擎命令映射到 D3D12、Vulkan、Metal 等后端，GPU 最终执行光栅、计算、光追与拷贝工作。

Nanite、Lumen、Virtual Shadow Maps（VSM）和 Temporal Super Resolution（TSR）都嵌在这套框架中，但职责不同：

• Nanite 主要解决几何可见性、LOD/Cluster 选择和高密度几何光栅化，不等于完整渲染器。
• Lumen 主要提供动态全局光照与反射，不接管基础几何、材质和全部直接光照。
• VSM 生成和缓存阴影可见性，仍要被光照阶段消费。
• TSR 用低于输出分辨率的当前帧，加上运动矢量和历史数据重建高分辨率图像。
• RDG 是帧内工作与资源依赖的组织层，不是新的底层图形 API。

一张总图#

这张图表达的是所有权与依赖，不是说各线程必须串行等待。正常情况下，Game Thread、Render Thread、RHI 提交和 GPU 会跨帧重叠；是否存在独立 RHI Thread、允许多少帧排队，也取决于平台和配置。

研究边界：先盯住哪条渲染路径#

UE5 同时维护多条渲染路径，不能把其中一条的结论无条件套到全部平台。

一帧是怎样进入 Renderer 的#

下面是适合源码跟读的概念调用链。具体函数名和拆分会随 UE 分支变化，不应把它当成固定 ABI：

1
FEngineLoop::Tick
2
  └─ Game / Viewport Tick 与 Draw
3
      └─ UGameViewportClient::Draw
4
          └─ 构造 FSceneViewFamily 与 FSceneView
5
              └─ RendererModule.BeginRenderingViewFamily / ViewFamilies
6
                  └─ 向 Render Thread 排队
7
                      └─ FSceneRenderer::CreateSceneRenderer
8
                          └─ FDeferredShadingSceneRenderer::Render
9
                              ├─ InitViews / Visibility
10
                              ├─ 创建 FRDGBuilder
11
                              ├─ 添加各类 Render Pass
12
                              └─ GraphBuilder.Execute

阅读这条链时要分清两类数据：

• UObject / Component 属于 Gameplay 世界，通常由 Game Thread 管理。
• FPrimitiveSceneProxy 和 Renderer 内的场景数据服务于渲染，通常由 Render Thread 拥有；跨线程更新必须通过明确的同步或排队机制，不能在两个线程间随意读写同一份可变数据。

一个常见误解是“Renderer 每帧直接遍历所有 Actor”。实际中，Renderer 面向的是已经注册到 FScene 的渲染代理和紧凑数据结构；这正是 Scene Proxy 层存在的原因。

默认延迟渲染帧：按依赖理解，不背固定顺序#

一帧在 GPU Capture 里看起来会有很多 Pass。更可靠的记法是理解它们生产和消费什么资源：

IMPORTANT

这是一张依赖图，不是所有项目都严格执行的线性清单。Early Z 模式、是否启用 Nanite/Lumen/VSM、半透明位置、硬件光追、异步计算、Scene Capture、反射捕获和插件都会改变实际帧图。以 RenderDoc、PIX 或 ProfileGPU 捕获到的项目帧为准。

Scene Proxy：Gameplay 世界与渲染世界的边界#

大多数可渲染 Component 会创建某种 FPrimitiveSceneProxy。Proxy 的价值不是简单复制 Component，而是：

• 把 Renderer 真正需要的数据从庞大的 Gameplay 对象中剥离出来；
• 明确 Game Thread 与 Render Thread 的所有权；
• 提供静态或动态 Mesh Element、包围盒、材质相关性等渲染信息；
• 让场景更新以命令形式跨线程传播。

需要跟读的核心类型：

Mesh Drawing Pipeline：从“一个网格”到 GPU 命令#

传统网格绘制路径中，FMeshBatch 更像“这批几何应该怎样画”的高层描述；它不会原样直接变成一次 API Draw Call。Mesh Pass Processor 会结合目标 Pass、材质 Shader、Vertex Factory、Render State 等信息，生成或选择 FMeshDrawCommand。

1
Primitive Scene Proxy
2
  └─ FMeshBatch / Static Mesh Batch
3
      └─ FMeshPassProcessor
4
          ├─ 选择 Shader Permutation
5
          ├─ 组合 PSO / Render State
6
          ├─ 绑定资源与参数
7
          └─ 生成 FMeshDrawCommand
8
              └─ 排序、缓存、合并或并行提交

研究时重点区分：

• Static / Cached 路径：场景状态稳定时尽量复用已经构建的绘制命令。
• Dynamic 路径：每帧或每 View 重新收集和生成，灵活但 CPU 成本更高。
• Pass 类型：Depth、Base Pass、Shadow Depth、Velocity 等会用不同的 Mesh Pass Processor。
• Nanite 路径：Nanite Mesh 的 Cluster 可见性与光栅化绕开了大量传统逐 Mesh Draw Call 工作，但最终仍要向深度、材质属性和光照阶段提供数据。

RDG：为什么现代 UE 渲染代码都在 AddPass#

Render Dependency Graph 的核心不是“把代码写成 Lambda”，而是先声明一帧中：

• Pass 读取和写入哪些 Texture / Buffer；
• 哪些资源只在图内临时存在；
• 哪些工作之间存在真实依赖；
• 最终哪些结果会被外部使用或提取。

典型骨架：

1
FRDGTextureDesc Desc = FRDGTextureDesc::Create2D(
2
    Extent,
3
    PF_FloatRGBA,
4
    FClearValueBinding::Black,
5
    TexCreate_ShaderResource | TexCreate_UAV);
6

7
FRDGTextureRef Output = GraphBuilder.CreateTexture(Desc, TEXT("Research.Output"));
8

9
FMyPassParameters* Parameters = GraphBuilder.AllocParameters<FMyPassParameters>();
10
Parameters->Output = GraphBuilder.CreateUAV(Output);
11

12
FComputeShaderUtils::AddPass(
13
    GraphBuilder,
14
    RDG_EVENT_NAME("ResearchPass"),
15
    ComputeShader,
16
    Parameters,
17
    GroupCount);

RDG 能据此做的事情包括：

• 自动推导大部分资源状态转换与屏障；
• 裁掉既无副作用、结果又没有被消费的 Pass；
• 复用生命周期不重叠的瞬态资源内存；
• 按依赖安排 Graphics / Async Compute 工作；
• 生成事件、统计信息和图调试数据。

两个容易踩的坑：

1. FRDGTextureRef / FRDGBufferRef 是图内句柄。若资源要跨出当前 Graph，必须按 RDG 规则注册 External Resource 或 Queue Extraction，不能保存句柄下帧直接用。
2. Lambda 捕获的普通 CPU 数据必须在 Pass 真正执行时仍然有效。优先把 GPU 参数放进 RDG Pass Parameters，不要随意引用临时栈对象。

四项 UE5 核心技术怎样接进主线#

源码阅读地图#

若本地有从 Epic GitHub 获取的 UE 5.8 源码，可从以下位置开始。文件名会随分支调整，优先搜索符号而不是死记路径。

推荐按这条顺序读：

1
调用入口
2
  → FSceneRenderer / FDeferredShadingSceneRenderer
3
  → 只选一个 Pass（例如 Base Pass）
4
  → 对应 MeshPassProcessor 或 Compute Shader
5
  → RDG 资源声明
6
  → Shader 参数结构
7
  → .usf / .ush Shader
8
  → GPU Capture 中的同名事件

不要第一次就从 DeferredShadingRenderer.cpp 顶部顺序读到底；把一个 CPU 事件、一个 RDG Pass 和一个 GPU 事件对齐，信息闭环更快。

实验计划：用捕获验证，而不是只读文档#

建立一个最小测试工程，固定相机和内容，使用 Development Editor 构建。每次只改变一个变量并保存同一机位的数据：

每次采集至少保存：

• CPU：Game、Render、RHI Thread 时间；
• GPU：总帧时间和最重的 5 个 Pass；
• 场景：分辨率、Screen Percentage、视角、灯光数、Nanite 三角形 / Instance 规模；
• 配置：RHI、是否硬件光追、关键 Project Settings；
• 证据：GPU Capture、Unreal Insights Trace、对应源码提交号。

性能排查顺序#

1. 先用 stat unit 判断瓶颈主要在 Game、Draw/Render 还是 GPU。
2. CPU 瓶颈进入 Unreal Insights，看线程时间线、TaskGraph 和等待关系。
3. GPU 瓶颈先用 ProfileGPU 定位大类，再用 RenderDoc 或 PIX 看资源、事件和具体 Draw / Dispatch。
4. 用 View Mode / Visualization 验证“为什么贵”，例如 Overdraw、Shader Complexity、Nanite Cluster、Lumen Scene、VSM Page，而不是只看 Pass 名称猜。
5. 改一个变量后重新捕获同一场景；不要同时改分辨率、光照、几何和 AA，再比较两个不可归因的数字。

后续专题路线图#

• 00：总览——统一线程、帧图和四项核心技术的关系
• 01：Game Thread → Render Thread——Scene Proxy 与一帧延迟
• 02：InitViews、Instance Culling 与 Mesh Drawing Pipeline
• 03：RDG 实战——资源生命周期、Pass Culling、Barrier 与 Async Compute
• 04：Deferred Renderer 逐 Pass 捕获——从 Depth 到 Tonemap
• 05：Nanite——Cluster、Visibility Buffer、Raster 与 Streaming
• 06：Lumen——Scene 表示、Screen Probe、Surface Cache 与 Reflections
• 07：VSM——Page、Clipmap、缓存失效与 Nanite 阴影
• 08：TSR——Velocity、History、Disocclusion 与 Screen Percentage
• 09：性能实验室——Unreal Insights + ProfileGPU + RenderDoc / PIX 对齐

当前待验证问题#

1. UE 5.8 默认 Desktop Deferred 中，Nanite 材质阶段在不同平台/RHI 下的具体 Pass 拆分有什么差异？
2. 开启 Hardware Ray Tracing 后，Lumen 的哪些阶段被替换，哪些缓存和 Screen Trace 仍然保留？
3. VSM 缓存失效在 WPO、骨骼动画和移动局部光下的实际成本曲线如何？
4. TSR 在 50%、67%、77% 内部分辨率下，对细线条、粒子和高速遮挡显露的失败模式分别是什么？
5. RDG Async Compute 在目标平台上是否真正形成 GPU 重叠，还是被依赖、Barrier 或硬件队列限制抵消？

官方资料#

以下链接于 2026-07-16 核对可访问；阅读时选择与项目一致的 UE 版本：

• Rendering Overview
• Graphics Programming
• Mesh Drawing Pipeline
• Render Dependency Graph
• Nanite Virtualized Geometry
• Lumen Global Illumination and Reflections
• Virtual Shadow Maps
• Temporal Super Resolution
• UE 5.8 Release Notes
• EpicGames/UnrealEngine 源码仓库（需要 Epic 与 GitHub 账号授权）

这项研究的判定标准不是“记住所有 Pass”，而是看到一个 GPU 事件时，能回答四个问题：谁在 CPU 端创建它、它读写哪些 RDG 资源、它依赖哪项场景表示、它的结果被谁消费。