自动关联目录：管线与渲染线程

UE 的渲染不是"一个函数画一帧"，而是三条线程流水作业：游戏线程算逻辑、渲染线程生成命令、RHI 线程提交给 GPU。它们之间允许错开一帧，这是吞吐与延迟之间的核心取舍。

一句话定位：理解帧流水线，才能解释"为什么我改了代码但这一帧没变""为什么 stat unit 里 Game 不高但帧率还是低"。这是整个 Rendering 分支的地基。

1. 定位

本页回答三个问题：

1. 一帧是怎么从逻辑变成 GPU 命令的
2. 三条线程之间在哪里同步，同步的代价是什么
3. 写渲染相关代码时必须遵守哪些线程规则

不回答：具体 Pass 怎么实现（那是 RDG 渲染图 及各特性篇的事），以及 GPU 上发生了什么（那是 Base Knowledge / Computer Graphics）。

2. 结构

三条线程

时间轴 ─────────────────────────────────────────────►

游戏线程    [第 N 帧 Tick]  [第 N+1 帧 Tick]  [第 N+2 帧 Tick]
                │  EndFrame
                ▼
渲染线程              [第 N 帧 可见性+Pass] [第 N+1 帧]
                          │ 提交命令
                          ▼
RHI 线程                     [第 N 帧 提交] [第 N+1 帧]
                                  ▼
GPU                                [第 N 帧 执行]

最关键的一条规则：渲染线程不能碰 UObject。UObject 归游戏线程与 GC 管，跨线程访问既是数据竞争也可能读到正在被销毁的对象。

两侧的数据交换靠 Scene Proxy：

游戏线程                    渲染线程
UPrimitiveComponent   ──►   FPrimitiveSceneProxy
（UObject，可改）            （纯数据快照，只读渲染用）
        │  MarkRenderStateDirty
        └──► 重新 CreateSceneProxy，在渲染线程上替换

// 组件侧：状态变了要通知渲染线程重建代理
void UMyComp::SetColor(FLinearColor NewColor)
{
    Color = NewColor;
    MarkRenderStateDirty();      // 触发 CreateSceneProxy
}

FPrimitiveSceneProxy* UMyComp::CreateSceneProxy()
{
    return new FMySceneProxy(this);   // 在渲染线程上构造，只读拷贝所需数据
}

忘记 MarkRenderStateDirty() 的表现：逻辑值变了，画面不变——非常典型。

一帧里的关键步骤

游戏线程
 ├─ UWorld::Tick（Actor / 组件 / 动画 / 物理）
 ├─ 更新组件变换 → 推给渲染线程
 ├─ SendAllEndOfFrameUpdates
 └─ UGameViewportClient::Draw → BeginRenderingViewFamily
        │
渲染线程
 ├─ FSceneRenderer 构造（延迟渲染走 FDeferredShadingSceneRenderer）
 ├─ InitViews：视锥剔除 + 可见性（可并行）
 ├─ 各 Pass 经 RDG 编排
 ├─ 生成 RHI 命令列表
 └─ 交给 RHI 线程
        │
RHI 线程 → 提交 → GPU 执行 → 呈现

源码位置：

3. 关键 API 与代码

往渲染线程投递命令

ENQUEUE_RENDER_COMMAND(MyCmd)([](FRHICommandListImmediate& RHICmdList)
{
    // 这里跑在渲染线程，不能碰 UObject
    DoSomethingOnRenderThread(RHICmdList);
});

lambda 捕获要小心：捕获裸指针指向的 UObject 是错的（可能已销毁）。要传数据就按值拷贝，要引用对象就用 TWeakObjectPtr 并在内部校验。

栅栏：等待渲染线程追上

FRenderCommandFence Fence;
Fence.BeginFence();          // 投递一个"到了就标记"的命令
Fence.Wait();                // 阻塞游戏线程，直到渲染线程执行到那里

// 典型必需场景：从渲染目标回读像素
FlushRenderingCommands();              // 必须先保证 GPU 命令已提交
RHICmdList.ReadSurfaceData(...);       // 否则读到的是上一帧或未定义内容

FlushRenderingCommands() 是卡顿制造机：它把三条线程的流水硬拉成串行。编辑器工具和截图功能可以用，运行时热路径上出现它基本等于一次掉帧。

渲染资源

class FMyRenderResource : public FRenderResource
{
public:
    virtual void InitRHI(FRHICommandListBase& RHICmdList) override { /* 创建 RHI 资源 */ }
    virtual void ReleaseRHI() override { /* 释放 */ }
};

// 初始化必须走渲染线程
void Init()
{
    Resource = new FMyRenderResource();
    BeginInitResource(Resource);
}
void Shutdown()
{
    BeginReleaseResource(Resource);
}

忘了 BeginReleaseResource 就 delete，会崩在 RHI 层。

4. 参数与控制台变量

版本提示：RHI 线程在 UE 4.22 引入；5.x 上 RHI 线程与 RDG 的并行细节有过调整，具体行为以 stat unit 实测为准。

5. 代价与权衡

最容易踩的权衡：为了让"改了立刻生效"而在 Tick 里 FlushRenderingCommands。正确做法是先想清楚——画面本来就该落后逻辑一帧，这是设计，不是 bug。

6. 踩坑与排查

排查顺序（固定套路）

1. stat unit          → 分清 Game / Draw / GPU / RHIT
2. Game 高？          → 不是渲染问题，去 [Profile](/4eea9393.html)
3. Draw 高？          → stat sceneupdate → 剔除与代理更新
4. GPU 高？           → profilegpu / GPU Visualizer → 定位 Pass
5. 都不高但帧率低？    → 多半是同步点（Flush）或垂直同步/帧率上限

"四项都不高但帧率低"几乎总是同步问题：某处在等栅栏、等加载、或等垂直同步。用 Unreal Insights 看游戏线程的阻塞栈。