自动关联目录：材质与着色器编译

官方依据：Shader Development（UE 5.8 Documentation）。本页覆盖该页全部 17 个条目。PSO 相关的另一半（首帧卡顿的直接成因）见 PSO 预缓存。

1. 定位

本页回答"一个材质是怎么变成 GPU 上的着色器的"，以及"为什么编译这么慢"。

一句话定位：UE 的编译是异步流式的——材质加载时把编译请求入队，编译结果一可用就套上去，不阻塞引擎。这解释了几乎所有相关的现象：为什么编辑器里物体一开始是默认材质、为什么打包后第一次启动会卡。

2. 结构：三层着色器

Vertex Factory

Vertex Factory 是"材质能应用到不同网格类型"的机制：FVertexFactoryType 代表一种网格类型，FVertexFactory 实例持有该类型所需的每实例数据（如 FGPUSkinVertexFactory 持有骨骼矩阵与顶点缓冲引用）。

它的着色器代码是被各 pass 着色器用来抽象网格类型差异的隐式接口。关键函数：

FMaterialShaderMap：变体是从哪来的

FMaterialShaderMap
   ├── FLightFunctionPixelShader          (FMaterialShaderType)
   ├── FLocalVertexFactory                (FVertexFactoryType)
   │      ├── TDepthOnlyPS                (FMeshMaterialShaderType)
   │      ├── TDepthOnlyVS
   │      ├── TBasePassPS
   │      └── TBasePassVS
   └── FGPUSkinVertexFactory
          └── （同样一套）

这是一个稀疏矩阵：Vertex Factory 依据自身的 ShouldCache（取决于材质用途，如 bUsedWithSkeletalMesh 为真就纳入 GPU skin VF）加入；FMeshMaterialShaderType 依据自己的 ShouldCache（取决于材质与 VF 属性）加入。

官方的说明很坦白：

这种稀疏矩阵方式很快就会累积出大量的着色器，占用内存并增加编译时间。相比"存一份真正需要用到的着色器列表"的做法，它的主要优势是不需要生成那份列表——因此在主机上，运行时需要的着色器总是已经提前编译好了。

UE 用两个办法缓解：

• 内存问题 → 着色器压缩
• 编译时间问题 → 多核着色器编译

3. 编译机制

异步流式编译

材质加载（没有已缓存的 shader map）
   → 编译请求入队
   → Shader Compile Worker 进程编译
   → 结果可用时套用（不阻塞引擎）

为什么用独立的 Worker 进程：平台的着色器编译函数（如 D3DCompile）内部常含临界区，在单个进程里无法多核扩展。所以真正的编译工作放在 Shader Compile Workers 辅助进程里做。

缓存与 Cook

改 FShader 的 Serialize 函数不需要处理向后兼容——只要在被引用的着色器文件里加个空格即可（key 变了就重编）。

4. 参数与控制台变量

想直接单步进编译器 DLL（如 CompileD3D11Shader），把上面两个都设为 false，并确保其它着色器都已缓存（编译会非常慢）。

特殊引擎材质

UMaterial::bUsedAsSpecialEngineMaterial：允许材质用于任何 vertex factory 类型 → 所有 VF 都会与该材质一起编译，集合非常大。适用于：

5. 迭代与调试

输出中间值的方式对构建复杂数据结构的着色器扩展性不好——那种要靠 r.DumpShaderDebugInfo 拿预处理产物。

编译出错重试

开了 r.ShaderDevelopmentMode 后：

• Debug + 调试器附加 → 命中断点，错误输出在 VS 输出窗口，双击错误日志直接跳到出错行
• 否则弹 Yes/No 对话框

对 global shader 尤其重要——它们编译失败是 fatal error。

HLSL 交叉编译器

HLSL Cross Compiler 在离线着色器编译阶段把 HLSL 自动转成 GLSL（OpenGL 平台），让着色器只写一次；同时做一些 OpenGL 驱动常缺失的优化。

AsyncCompute

部分 API / GPU 支持的硬件特性，让任务交错执行以更好利用 GPU 硬件单元。

注意：异步计算开着时 GPU 计时不可靠——分析时要 r.RDG.AsyncCompute 0（仅用于分析，发布版绝不能关，见 虚拟阴影贴图）。

6. 代价与权衡

7. 踩坑与排查

8. 排查顺序

1. 卡在哪？编译慢 → 共享 DDC；运行时卡 → PSO 预缓存
2. 编译错误 → r.ShaderDevelopmentMode = 1，看重试与日志
3. 着色器结果不对 → 输出中间量 + VisualizeTexture
4. 内存大 → 查变体数量与特殊引擎材质
5. 首次启动体验 → -clearPSODriverCache 复现（见 PSO 篇）

参考

• Shader Development
• Graphics Programming
• PSO 预缓存 · 管线与渲染线程