云边笔记

先给结论#

UE5 把 Gameplay 世界和渲染世界分开维护：

• Game Thread 拥有 Actor、Component 和绝大多数 UObject 状态；
• Render Thread 面向 FScene、FPrimitiveSceneProxy、FPrimitiveSceneInfo 和每个 View 的渲染数据；
• RHI Thread 或并行 RHI 路径把高层渲染命令翻译、整理并提交给图形 API；
• GPU 执行的通常已经是更早一时刻准备好的工作。

这种分离让 Game Thread 和 Render Thread 能并行推进，但也带来三条硬约束：

1. Render Thread 不应直接追着读取会被 Game Thread 修改或回收的 UObject。
2. 跨线程更新必须显式排队，并把执行时需要的数据复制到安全的所有者中。
3. “本帧 Gameplay 已经改变”不等于“显示器上的当前图像已经包含该改变”。

四条执行通道，不是四步串行流程#

图中的 Frame 编号用于表达数据世代，不保证各阶段永远恰好只差一帧。Editor、平台 RHI、VSync、Present 队列、GPU 饱和、r.OneFrameThreadLag 和低延迟模式都会改变排队深度。

Primitive 注册：Component 怎样进入 FScene#

以一个普通可渲染 UPrimitiveComponent 为例，稳定的概念链路如下：

在不同版本中，Scene Info 的具体创建时机、批量 Add/Remove、GPU Scene 更新和缓存更新函数会调整。因此源码阅读时按符号追踪：

1
UPrimitiveComponent::CreateRenderState_Concurrent
2
  → UPrimitiveComponent::CreateSceneProxy（虚函数）
3
  → FSceneInterface::AddPrimitive
4
  → FScene::AddPrimitive / AddPrimitives
5
  → Render Thread 侧 AddPrimitiveSceneInfo...

1
Proxy 描述“这个 Primitive 怎样参与渲染”
2
SceneInfo 描述“这个 Primitive 在当前 FScene 里怎样被管理”

三种标脏，不要一律重建 Render State#

Component 改变后，UE 提供不同粒度的同步意图。具体实现会按组件类型优化，但语义可以这样区分：

典型更新链可抽象为：

1
Game Thread 修改 Component
2
  ├─ Transform Dirty
3
  │   └─ SendRenderTransform_Concurrent → Scene UpdatePrimitiveTransform
4
  ├─ Dynamic Data Dirty
5
  │   └─ SendRenderDynamicData_Concurrent → 自定义 Proxy 更新命令
6
  └─ Render State Dirty
7
      └─ DestroyRenderState + CreateRenderState → Proxy 移除与重建

WARNING

函数名带 _Concurrent 不表示可以从任意线程随意调用，也不表示内部没有排队。它通常表示组件注册/更新框架允许该阶段并行处理，并且实现必须遵守对应线程契约。调用点仍应以 API 注释和源码检查为准。

跨线程命令：安全来自复制和有序生命周期#

典型模式是 Game Thread 读取 UObject 状态，把 Render Thread 真正需要的值复制出来，然后排队一个渲染命令：

1
// 仅示意所有权，不是可直接粘贴的完整组件实现。
2
const FVector3f SafeValue = FVector3f(ComponentOwnedValue);
3
FMySceneProxy* Proxy = static_cast<FMySceneProxy*>(SceneProxy);
4

5
ENQUEUE_RENDER_COMMAND(UpdateMyProxy)(
6
    [Proxy, SafeValue](FRHICommandListImmediate& RHICmdList)
7
    {
8
        Proxy->SetValue_RenderThread(SafeValue);
9
    });

这个模式成立需要额外前提：

• SafeValue 是值拷贝，不再依赖 Component 内存；
• Proxy 的删除命令与更新命令进入可证明的有序命令流；
• 命令不是从多个生产线程无约束竞争；
• SetValue_RenderThread 只修改 Render Thread 拥有的数据；
• 如果生命周期无法用命令顺序证明，就使用明确的引用所有权、Release 流程或 Fence。

下面这种写法风险很高：

1
ENQUEUE_RENDER_COMMAND(UnsafeUpdate)(
2
    [this](FRHICommandListImmediate& RHICmdList)
3
    {
4
        // 执行时 UObject 可能已改变、Pending Kill，甚至被回收。
5
        SceneProxy->SetValue_RenderThread(ComponentOwnedValue);
6
    });

TWeakObjectPtr 也不会自动让 UObject 变成跨线程可安全读取的数据；对象有效性检查与对象字段的并发读写安全是两件事。

删除、Fence 与 Flush#

Component 注销或销毁时，Game Thread 发起从 Scene 移除；Render Thread 按命令顺序清理 Scene Info、缓存和 Proxy。因为两个线程不同步，Game Thread 对象的析构不应假设 Render Thread 已经立即完成删除。

常见同步工具：

“加一个 Flush 就不崩了”只能说明存在竞态或生命周期错误，不代表 Flush 是正确最终方案。它会抹掉 Game / Render 并行性，并可能把偶发卡顿带进运行时。

一帧延迟到底来自哪里#

“UE 有一帧延迟”不是单一机制，而是多段队列与时域处理的合成：

可能增加延迟的因素包括：

• Render Thread 被允许落后于 Game Thread；
• CPU 提交速度高于 GPU 消费速度，Driver / GPU Queue 变深；
• VSync 或显示交换链排队；
• TSR、TAA、Lumen 等使用历史帧，但“使用历史”本身不等于固定增加完整一帧输入延迟；
• Frame Generation 会改变显示帧节奏，需要单独分析输入到显示的延迟。

r.OneFrameThreadLag 控制是否允许 Render Thread 相对 Game Thread 保持一帧线程滞后。把它设为 0 可用于实验低延迟与 CPU 等待的取舍，但不能由此假定整条输入到显示链路只剩零帧延迟。

View Family：场景同步之后，谁描述“这次看什么”#

Primitive 注册描述“世界里有什么”；View Family 描述“这次怎样看这个世界”。主视口的一次 Draw 大致经过：

1
UGameViewportClient::Draw
2
  → 建立 FSceneViewFamilyContext
3
  → LocalPlayer::CalcSceneView 等建立 FSceneView
4
  → View Extension 设置 / 更新
5
  → RendererModule.BeginRenderingViewFamily / ViewFamilies
6
  → Render Thread 创建具体 FSceneRenderer
7
  → FDeferredShadingSceneRenderer::Render

同一个 FScene 可以被主视口、分屏、Stereo View、Scene Capture、Reflection Capture 等不同 View Family 渲染。因而“世界 Tick 一次”与“Renderer 只渲染一个 View”没有必然关系。

FSceneViewState 一类对象保存跨帧 View 状态，例如遮挡查询和时域历史所需的信息。排查 TSR、Lumen 或 Occlusion 的历史问题时，要同时问：

• View State 是否持久？
• 相机 Cut 是否使历史失效？
• 分辨率或 View Rect 是否变化？
• 这是不是 Scene Capture 或没有持久 View State 的 View？

源码断点路线#

有 UE 源码时，第一次跟读只设下面这些断点，不要先追进所有模板和 Task：

每次命中记录：当前线程名、Game Frame / Render Frame 编号、Component / Proxy 地址、调用栈。没有这四项，截图很难支持线程时序结论。

四个可证伪实验#

Unreal Insights 采集表#

建议从 Editor 的 Trace 菜单启动 CPU、Frame、GPU、Bookmark 等相关 Channel；命令行 Channel 名会随版本调整，应从当前版本 Trace UI 或官方文档确认。

结果记录模板：

1
UE 分支 / Commit:
2
平台 / RHI:
3
构建配置:
4
VSync / 帧率上限:
5
r.OneFrameThreadLag:
6

7
Game Frame:
8
Render Frame:
9
Proxy Create 次数:
10
Transform Update 次数:
11
Render State Recreate 次数:
12
Game 等待点:
13
Render 等待点:
14
GPU / Present 排队观察:
15
结论与反例:

常见误区#

本篇建立的心智模型#

1
Gameplay 状态
2
  └─ Component 判断更新粒度
3
      ├─ Transform Update
4
      ├─ Dynamic Data Update
5
      └─ Render State Recreate
6
          ↓ 有序跨线程同步
7
Renderer Scene
8
  └─ Proxy + SceneInfo + GPU Scene / Draw Caches
9
      ↓ 每个 View Family 读取
10
SceneRenderer 构建本次帧图
11
      ↓
12
RHI Submit → GPU → Present

下一篇将沿着 FScene 和 View 继续进入 InitViews：Primitive、Instance 和 Nanite Cluster 分别在哪里做可见性判断，FMeshBatch 又怎样变成 FMeshDrawCommand。

官方资料#

• Threaded Rendering
• FPrimitiveSceneProxy API
• UPrimitiveComponent API
• FRenderCommandFence API
• Unreal Insights
• EpicGames/UnrealEngine（需要 Epic 与 GitHub 账号授权）