Shader 变体管理与工程实践原理

1. 工程视角：从上层引擎到底层 API 的映射

在大型 3D 游戏项目中，Shader 的管理是一个核心的工程挑战。理解这一点的关键在于建立上层引擎架构与底层图形 API 之间的认知映射。

API 抽象层思考：
- 在编写 Shader 或设计材质系统时，需要反向思考其在底层（如 DX12、Vulkan、OpenGL）的具体实现。
- 例如：上层的材质参数如何映射到 Constant Buffer 或 Root Signature？
- PSO (Pipeline State Object) 的封装时机：思考 PSO 应该在材质层、Shader 层还是 Pass 层进行构建。
学习方法论：
- 先基于原理推测主流引擎（如 Unity/Unreal）的实现方式。
- 再阅读商业引擎源码（Source Code）进行印证，对比差异。
常见现象： 游戏启动时的 Shader 预热 (Pre-warming) 环节，正是为了解决运行时编译带来的卡顿问题。

2. 静态分支：宏定义与 Shader 变体

静态分支 (Static Branching) 是在编译阶段确定的逻辑路径，它直接决定了最终生成的二进制代码（如 DXBC、SPIR-V）的结构。

2.1 宏 (Macro) 与指令剪裁

机制： 使用 #ifdef / #else 等预处理指令控制代码块。
编译结果： 未被激活的分支代码会被完全剔除，不会出现在最终的 Shader 二进制文件中。
- 案例： 开启级联阴影（Cascade Shadow）的 Shader 编译后指令行数（如 211 行）多于未开启版本（如 190 行）。

2.2 Keyword 的声明与定义

声明组 (Keyword Group)： 通过 #pragma multi_compile 或 shader_feature 声明一组互斥或并存的功能开关。
定义方式：
- 直接定义： 激活变体时直接定义对应的宏（如 _MAIN_LIGHT_SHADOWS）。
- 间接定义 (Indirect Definition)： 针对复杂的逻辑组合，抽象出中间宏以简化代码维护。
  - 场景： 当多个条件（如 A 或 B 或 C）都需要开启某个功能时，定义一个中间宏 NEED_FEATURE_X，避免在逻辑代码中重复书写 if (A || B || C)。

3. 动态分支：Uniform 变量与 GPU 执行流

开发者常试图通过传递 Uniform 变量 并在 Shader 中使用 if/else 来代替宏，以减少变体数量。这种做法在 GPU 的 SIMD（单指令多数据）架构下有特殊的性能考量。

3.1 GPU 并行机制

执行单位： GPU 以 Warp (NV) 或 Wavefront (AMD) 为单位调度线程（通常为 32 或 64 个线程）。
锁步执行 (Lock-step)： 同一个 Warp 内的所有线程必须执行相同的指令。

3.2 `[branch]` vs `[flatten]`

当 Shader 中存在 if-else 时，编译器或开发者可以选择两种策略：

[flatten] (扁平化/推测执行)：
- 行为： 强制执行 if 和 else 两个分支 的所有指令。
- 结果选择： 计算完成后，根据条件掩码（Mask）选择正确的结果赋值。
- 适用场景： 分支内代码量少、计算简单（ALU 操作）。避免了控制流跳转的开销。
[branch] (动态分支)：
- 行为： 产生真正的控制流跳转。
- Warp Divergence (线程歧义)： 如果 Warp 内部分线程走 if，部分走 else，GPU 会串行化执行：先挂起一部分线程执行 if 块，再挂起另一部分执行 else 块。
- 适用场景： 分支内包含高昂的开销（如 Texture Sampling、复杂光照计算）。如果所有线程都走同一分支，性能收益极高。

注意： 现代 Shader 编译器通常能自动优化选择，但开发者可显式添加 [branch] 或 [flatten] 属性进行干预。

4. 变体 (Variant) 的本质与组合爆炸

4.1 错误实践：复制粘贴

现象： 为了添加新效果（如“腮红”），将整个 Shader 文件复制一份并重命名。
后果： 随着功能（阴影、雾效、反射）增加，Shader 文件数量呈指数级失控，维护成本极高。

4.2 变体计数原理

定义： 一个 Shader Variant 是所有生效 Keyword 的特定组合。
指数增长公式： 假设有 $N$ 个 Keyword 组，每组包含 $k_{i}$ 个互斥选项（包含默认的 disable 状态），总变体数 $V$ 为： $V = \prod_{i = 1}^{N} k_{i}$
示例：
- 开关 A (2种状态) $\times$ 开关 B (2种状态) $\times$ 模式 C (3种状态) = $2 \times 2 \times 3 = 12$ 个变体。
- 每增加一个二选一的 Feature，变体总数翻倍。

4.3 管理的必要性

构建与内存压力： 变体数量的指数级增长会导致打包时间过长、安装包体积增大以及运行时内存占用飙升。
核心目标： 在灵活性（功能组合）与性能（包体、加载时间、绘制效率）之间寻找平衡。

Shader 编译管线与变体（Variant）的底层机制

1. 领域特定语言 (DSL) 与图形 API 差异

1.1 ShaderLab 与 DSL

DSL (Domain Specific Language): Unity 的 ShaderLab 本质上是一种封装了 HLSL/CG 的 DSL，专门用于描述渲染状态和着色器代码。
编译目标: DSL 最终会被编译为特定平台的 Source Code（源码）或 Binary（二进制字节码）。

1.2 不同图形 API 的 Shader 处理方式

不同的图形 API 对 Shader 的加载和编译流程处理不同：

OpenGL:
- 通常上传 GLSL 源码字符串。
- 驱动程序 (Driver) 在运行时将源码编译为 GPU 可执行指令。
- 流程：创建 Shader Handle $\to$ 绑定源码 $\to$ 编译 $\to$ 链接。
DirectX 12 / Vulkan:
- 更倾向于使用 离线编译 的二进制格式或中间语言。
- 格式：DX12 使用 DXBC (DirectX Bytecode)，Vulkan 使用 SPIR-V。
- 优势：避免了运行时解析源码的开销。

2. 变体 (Variant) 的底层实现：宏定义

在底层 API（如 D3D）的视角中，变体本质上就是一组 宏定义 (Macros) 的组合。

2.1 D3D_SHADER_MACRO 结构

以 DirectX 为例，编译 Shader 时使用的 D3DCompile 接口，其第二个参数 pDefines 决定了变体的生成。它通常是一个结构体数组：

// 伪代码示例：底层变体定义的本质
struct D3D_SHADER_MACRO {
    LPCSTR Name;       // 宏名称 (Keyword)
    LPCSTR Definition; // 宏的值 (通常为 "1")
};
 
// 一个具体的变体实例 (Variant) = 一个宏数组
D3D_SHADER_MACRO specificVariant[] = {
    { "FOG_LINEAR", "1" },
    { "_MAIN_LIGHT_SHADOWS", "1" },
    { NULL, NULL } // 结束符
};

原理： 每一个变体在编译前，编译器（如 DXC）会先进行 预处理 (Preprocessing)，用上述宏数组替换代码中的 #ifdef 逻辑，剔除无效分支，然后才编译成二进制代码。
结论： 引擎层面的“变体指数级增长”，在底层对应的是生成了成千上万个不同的 GLSL 文件或 DXBC/SPIR-V 二进制块。

3. 跨平台 Shader 编译管线 (Unity 为例)

打包时，引擎会将 ShaderLab + HLSL 转换为目标平台的原生格式。

PC (DirectX 11/12):
- HLSL $D3DCompiler$ DXBC (二进制)。
Mobile (Android/iOS):
- 核心工具: HLSLcc (HLSL Cross Compiler) 或类似的转换库。
- OpenGL ES: HLSL $\to$ HLSLcc $\to$ GLSL。
- Vulkan: HLSL $\to$ HLSLcc $\to$ GLSL $glslang$ SPIR-V。
- Metal: HLSL $\to$ HLSLcc $\to$ MSL (Metal Shading Language)。

4. 变体的代价：内存与预热 (Warmup)

4.1 包体大小 vs. 运行时内存

压缩欺骗性: 在 Asset Bundle 中，Shader 代码（文本或二进制）的压缩率极高（例如几百 MB 压缩后仅几 MB）。
运行时膨胀: 游戏运行时需要将 Shader 解压并加载到内存中。
- 风险点: 实际占用的内存可能高达 数 GB，导致 OOM (Out of Memory)。
分析工具: 使用 Unity 的 Memory Profiler 或 Windows Performance Analyzer (Memory 模块) 可查看 ShaderLab 的真实内存占用。

4.2 预热 (Pre-warming) 与卡顿

动态编译卡顿: 如果不预热，GPU 在首次渲染某物体时才创建 Shader/PSO，会导致显著的掉帧。
预热策略: 在加载阶段（Loading Screen）集中编译 Shader。
- 双刃剑: 变体过多会导致预热时间过长。
- 案例: 某 3A 游戏（如 COD）PC 版预热可能需 15 分钟；手游如果预热超过 1 分钟，会导致用户大量流失。

5. 补充：Q&A 与职业建议 (针对图形程序)

5.1 移动端性能陷阱：Raymarching & SDF

问题: 虽然 SDF (Signed Distance Field) 和 Raymarching 在 Shadertoy 上效果很炫，但在移动端架构上极其昂贵。
原因: 步进计算（Raymarching step）会导致大量的 Cache Miss (纹理/内存缓存未命中)，轻易撑爆移动 GPU 的 On-chip Tile Memory。
工业界解法: 实际项目中通常使用 几何替身、特效面片 (Billboards) 或简化的几何算法来模拟体积光等效果，而非纯数学步进。

5.2 学习与成长建议

作品集方向: 推荐复刻风格化渲染（如《原神》、《崩坏：星穹铁道》）或 PDR 流程。
自我驱动: 工作中要主动寻找跨引擎的对标实现。
- 练习: "我在 Unity 里实现了这个效果，如果我要在 Unreal 里实现，对应管线和 API 差异在哪里？"
- 通过解决这种差异化需求，能最快掌握底层的通用原理。

变体管理策略：从个人规范到引擎宏定义

1. 变体管理的双重维度

在工程实践中，变体管理通常被拆分为两个独立但相关的环节，开发者常将二者混淆：

变体收集 (Variant Collection): 确定项目中实际需要哪些变体。
变体剔除 (Variant Stripping): 在构建阶段主动移除不需要的变体，这是控制数量的关键手段。

2. 个人开发层面的优化策略

开发者（TA/图形程序）在编写 Shader 代码时，应根据计算负载权衡使用 宏分支 (Macro) 还是 动态分支 (Dynamic Branching)。

2.1 动态分支 (`if/else`) 的适用场景

何时使用：
- 逻辑简单，分支差异仅为少量的 ALU (算术逻辑单元) 运算（如加法、乘法）。
- 代码行数少（例如 10 行以内），不包含昂贵的数学运算（如 sin, cos, tan）。
- 控制方式： 通过 Uniform 变量传入常量缓冲区 (Constant Buffer)，GPU 实时判断执行。
优势： 避免变体数量增加，现代 GPU 的 ALU 运算非常廉价且迅速。

2.2 必须使用变体 (Macro) 的场景

性能陷阱： 如果 if/else 分支中包含大量计算或 纹理采样 (Texture Sampling)：
- Warp Divergence： 两个分支可能都会被执行（或分线程执行），导致开销倍增。
- Cache Missing： 随机采样（如噪声图）可能导致缓存未命中，引发带宽暴涨。
- 梯度问题： 在动态流控制中采样纹理可能导致 Mipmap 计算错误（需要手动处理梯度）。
结论： 涉及光照计算（几百行代码）、纹理采样或复杂逻辑时，必须使用宏定义变体。

3. Unity 宏定义指令详解：`multi_compile` vs `shader_feature`

这是 ShaderLab 中最易混淆的概念，二者在 打包 (Build) 时的行为截然不同。

3.1 `multi_compile` (全排列组合)

行为： 无论变体是否被使用，引擎都会编译该指令组下所有 Keyword 的组合。
计算公式： 笛卡尔积（全排列）。 $T o t a l = G ro u p A \times G ro u pB \times G ro u pC ...$
示例：
- 组 A: A, B (2个)
- 组 B: C, D, E (3个)
- 结果： $2 \times 3 = 6$ 个变体会被打入包中。

3.2 `shader_feature` (按需打包)

行为： 仅编译构建过程中被 材质 (Material) 实际引用了的变体组合。
示例：
- 定义了 A/B 和 C/D/E。
- 场景中仅有一个材质使用了组合 (A, C)。
- 结果： 仅打包 1 个变体 (A, C)，其余组合被丢弃。
适用场景： 材质属性开关、非全局性的效果特性。

3.3 混合使用时的组合逻辑

当 Shader 中同时存在 multi_compile 和 shader_feature 时，最终变体数计算如下： $T o t a l = (M u lt i C o m p i l e_P er m u t a t i o n s) \times (A c t i v e_S ha d er F e a t u re_P er m u t a t i o n s)$

案例推演：
1. multi_compile 组：生成 4 个基础变体。
2. shader_feature 组：项目中有两个材质分别引用了 ED 和 FH 两种组合（共 2 种有效）。
3. 最终产物： $4 (Base) \times 2 (Active) = 8$ 个变体。

4. 扩展资源

参考文章： 搜狐畅游引擎部 在知乎发布的文章。
详细记录了工具的使用与工程实践。

变体剔除 (Variant Stripping) 与收集 (Collection) 详解

1. 概念澄清：剔除与收集的区别

在工程实践中，必须严格区分两个概念：

变体收集 (Collection):
- 目的: 确定哪些变体是必须的。
- 作用: 用于变体预热（Warmup）和引用保持，防止被错误剥离。
- 频率: 定期执行（如每周/每月）。
变体剔除 (Stripping):
- 目的: 主动移除不需要的变体。
- 作用: 减少包体大小、缩短构建时间。
- 频率: 每次打包 (Build) 时都会触发。

2. 传统剔除方案的痛点

早期的变体剔除通常基于简单的配置文件（如 JSON），但这存在显著缺陷：

配置僵化: 仅能进行简单的“全有或全无”剔除（例如：移除所有 FOG_ON）。
逻辑表达力弱: 无法处理复杂的组合逻辑。
- 失败案例: “当 A, B, C, D 同时存在但 E 不存在时，才进行剔除”。
- 失败案例: “仅剔除 Forward 管线下的某些 Keyword，但保留 Deferred 管线下的同名 Keyword”。
难以验证: 修改 JSON 配置后，很难快速验证规则是否生效，容易引发 Runtime Error（Shader 丢失变粉色）。

3. 高级剔除工具设计

讲师介绍了一种基于 可序列化对象 (ScriptableObject) 和 反射 (Reflection) 的高级剔除工具。

3.1 核心设计思路

模块化条件: 将每个剔除逻辑（如“检查 Keyword A”、“检查 Pass 名称”）抽象为一个实现了公共接口的类。
反射加载: 工具自动扫描所有实现了该接口的子类，构建 UI 列表，无需手动注册新规则。
组合逻辑: 支持多条件组合（AND/OR 逻辑）。
- 示例: (PassName == "Forward") AND (Keyword == "SOFT_SHADOWS") $\to$ 剔除。

3.2 关键功能特性

精准剔除:
- 条件剔除: “如果 A 存在且 B 不存在 $\to$ 剔除”。
- Pass 过滤: 针对特定渲染路径（Forward/Deferred）进行剔除。
白名单 (Whitelist):
- 即使满足全局剔除规则（如剔除所有 INSTANCING_ON），也能强制保留特定材质（如“草地”）的变体。
验证机制 (Testing):
- 提供“测试剔除”按钮：输入一个模拟变体组合，工具实时反馈是否会被剔除及其原因。

3.3 接口实现：`IPreprocessShaders`

Unity 提供了标准接口 IPreprocessShaders。

回调方法: void OnProcessShader(Shader shader, ShaderSnippetData snippet, IList<ShaderCompilerData> data)
工作流:
1. 遍历 data 列表（包含所有待编译变体）。
2. 根据自定义逻辑检查每个变体。
3. 从列表中 Remove() 不需要的数据。

4. 变体丢失排查指南

当打包后发现物体变成粉色（Shader 丢失），或效果与编辑器内不一致时，排查步骤如下：

检查构建设置: Project Settings → Graphics → Shader Stripping。
- 确保未被设置为过于激进的模式。
搜索预处理脚本: 全局搜索实现了 IPreprocessShaders 接口的类。
- 第三方插件或项目中可能存在隐式的剔除逻辑。
连接真机调试: 使用 Frame Debugger 查看实际生效的 Variant Keyword 组合。

5. 变体收集 (Variant Collection) 的前奏

5.1 为什么要收集？

热更新 (Hotfix) 与分包 (AssetBundles):
- 在现代商业项目中，Shader 通常被打入独立的 AssetBundle 中以便热更。
- 材质 (Material) 引用了 Shader，但如果 Shader 单独打包，必须明确记录它需要哪些变体。
预热 (Warmup): 收集的变体列表是进行 Shader 预热的基础数据来源。

变体收集 (Variant Collection) 实战：痛点与解决方案

1. 变体收集的核心作用

AssetBundle 隔离问题: 默认情况下，AssetBundle 相互独立。若 Shader 在 Bundle A，而引用该 Shader 的材质在 Bundle B，打包 Bundle A 时无法得知 Bundle B 中的变体需求。
解决方案: 提前收集所有需要的变体组合，写入 SVC (Shader Variant Collection) 文件，并将 SVC 与 Shader 打包在同一个 Bundle 中。这样 Shader Bundle 就明确知道需要包含哪些变体。

2. 基础方法：Unity 原生工具

2.1 手动创建 SVC

操作: Create → Shader Variant Collection.
原理: 一个 SVC 文件本质上就是一个变体列表（Shader + Pass + Keywords）。
痛点 (手动维护):
- 不可操作性: 面对上千个变体，手动添加极其低效且容易出错。
- 性能问题: 编辑器面板在渲染大量变体时会严重卡顿。
- 组合困难: 难以手动处理新 Keyword 与现有 Keyword 的全排列组合。

2.2 自动跑测收集 (Unity 提供的半自动化)

操作: Project Settings → Graphics → 底部 Shader Loading。
- 点击 Clear 清除旧数据。
- 运行游戏，覆盖所有流程。
- 点击 Save to asset 保存 SVC。
痛点 (自动化缺陷):
1. 容易遗漏: 必须人工覆盖所有游戏分支（如特定等级特效、隐藏关卡），测试覆盖率难以达到 100%。
2. 更新维护难: 每次美术修改材质后，都需要重新跑一遍漫长的全流程测试。
3. 受 Shader 质量影响: 如果 Shader 包含错误的管线声明（如在 URP 中声明了 Built-in 的 lightmap 宏），跑测会收集到大量无效变体，污染 SVC。

3. 进阶方法论：动态法 vs. 静态法

3.1 动态法 (Runtime Collection)

原理: 通过修改引擎源码或分析日志，在游戏运行时实时捕获实际使用的变体。
Unity 官方建议 (针对源码授权客户): 在底层 PlayShader 处埋点，获取真实变体请求并发送至服务器，由服务器聚合生成 SVC。
优缺点:
- ✅ 数据真实准确。
- ❌ 依然依赖人工或自动化测试跑流程，无法避免覆盖率问题。

3.2 静态法 (Static Analysis - 讲师推荐)

核心理念: 既然 shader_feature 只有被材质引用才会被打包，那么只要静态分析所有打包资源引用的材质，就能反推出所有需要的变体。
算法逻辑:
1. 扫描项目构建清单（Build Settings 场景列表、资源配置表）。
2. 递归查找所有依赖的 Material。
3. 解析每个 Material 的 m_ShaderKeywords 属性。
4. 结合 Shader 的 multi_compile（全排列）规则，生成最终变体列表。
优势:
- ✅ 全覆盖: 只要资源在打包列表中，其变体就能被收集，无需人工跑测。
- ✅ 自动化: 可以集成到 CI/CD 流程中，每次构建自动更新。
- ✅ 速度快: 静态文件扫描远快于运行游戏。

4. 自研工具：材质收集器 (Material Collector)

讲师展示了一款基于静态分析的工具，用于解决材质收集难题。

4.1 收集策略 (Collectors)

工具支持多种收集维度的扩展：

指定材质: 单独添加（调试用）。
全项目材质: 扫描 Assets 目录（包含垃圾资源，不推荐）。
场景依赖 (Scene Dependency):
- 读取 Build Settings 中的场景列表。
- 分析场景依赖树，提取所有引用的材质。
配置表/Bundle 依赖:
- 针对使用 AssetBundle 构建的项目，读取策划配置表（包含 Prefabs、Direct Assets）。
- 提取这些资源引用的材质。

4.2 工作流

配置收集器: 添加“场景依赖”或“配置表依赖”收集规则。
执行收集: 工具扫描并生成一份确定的材质列表。
生成变体: 遍历材质列表，解析 Keyword 组合，自动更新 SVC 文件。

（这种静态分析方法彻底解决了“测试覆盖率不足”和“更新维护难”的问题，是工业界特别是大型项目的首选方案。）

变体收集进阶：多光源预热与工具实践

1. 静态收集的局限与补充

虽然静态分析材质能解决 引用丢失 (AssetBundle Isolation) 问题，确保 shader_feature 不丢失，但对于 multi_compile 的动态切换，静态分析存在盲区。

场景痛点：
- 初始状态： 场景默认只有主光源 (Main Light)，此时 Shader 编译并使用的是单光源变体。
- 突发状况： 角色释放技能，产生额外的点光源 (Additional Light)。
- 后果： 场景中数百个物体的 Shader 瞬间需要从“单光源变体”切换到“多光源变体”。
- 卡顿： 如果“多光源变体”未提前预热，GPU 需要实时编译（Create Program/PSO），可能导致数秒甚至数十秒的严重卡顿。
解决方案： 必须显式地收集并预热 multi_compile 的关键组合（如 _ADDITIONAL_LIGHTS）。

2. 工具演示：一键式变体收集

讲师展示的工具集成了收集 $\to$ 解析 $\to$ 写入的全流程。

2.1 核心工作流

收集器配置 (Collector Setup): 添加“场景依赖收集器”，扫描 Build Settings 中的所有场景，提取所有引用的 150+ 个材质。
变体解析 (Parsing):
- 输入：150 个材质。
- 处理：解析每个材质引用的 Pass 和 Keyword。
- 去重：由于多个材质可能引用同一变体，最终解析出 85 个唯一变体。
写入 SVC: 将解析结果覆盖写入到 ShaderVariantCollection 文件中。
快速浏览 (Quick View):
- 原生痛点： Unity 原生面板在显示上千个变体时会卡顿，且无法搜索。
- 优化： 工具提供了搜索过滤功能（如搜索 "HDRP/Lit"），方便开发者快速检查收集结果。

2.2 批处理执行器 (Batch Executor)

针对 multi_compile 的组合问题，工具提供了增强功能：

手动/自动解析： 能够扫描 Shader 源码中的 #pragma multi_compile 指令。
组合生成： 自动生成特定 Keyword（如 _ADDITIONAL_LIGHTS + _SHADOWS_SOFT）的组合，强制加入 SVC 中，确保这些动态切换的路径被覆盖。

3. 预热 (Warmup) 策略：对抗卡顿

收集完变体后，如何执行预热是影响用户体验的关键。

3.1 一次性预热 (One-time Warmup)

API: ShaderVariantCollection.WarmUp()
问题：
- 阻塞主线程： 这是一个同步操作，会完全卡死游戏画面。
- 耗时惊人：
  - 30MB ShaderLab 数据：
  - 新 Android 机：~5秒。
  - 旧 Android 机：10~20秒。
  - iPhone X (Metal): 可能高达 1分钟（受 Metal 编译器后端影响）。
- 体验： 进度条卡死不动，玩家会误以为游戏崩溃。

3.2 渐进式预热 (Incremental Warmup)

Unity 2022+: 提供了原生异步/分帧预热接口。
低版本方案 (分片策略):
- 切分: 将大的 SVC 文件拆分为 20 个小的 SVC 对象。
- 分帧: 每帧（或每几帧）调用一次 WarmUp()，每次只编译一小部分。
- 优势: 虽然总耗时可能增加，但游戏画面/进度条能保持刷新，用户体验更好。

3.3 定制化策略 (针对 iPhone X 等慢速设备)

痛点: iPhone X 首次预热耗时过长 (1分多钟)。
优化方案 (分阶段预热):
- Phase 1 (首次启动): 仅预热 前30分钟 游戏内容所需的变体（约占总量的 30%~50%）。让玩家快速进入游戏，剩余变体在游戏过程中遇到时实时编译（轻微卡顿作为妥协）。
- Phase 2 (后续启动): 利用缓存或在后台静默预热剩余变体。

4. 行业现象：“正在编译着色器”

为什么现代游戏（《黑神话：悟空》、《使命召唤》、《三角洲行动》）启动时都要编译很久？

4.1 图形 API 的差异

OpenGL:
- 首次：慢（从源码编译）。
- 二次启动：快。驱动支持二进制缓存 (Program Binary)，直接加载上次编译好的结果。
Vulkan / DX12 (PSO 缓存难题):
- 复杂性: 不仅编译 Shader，还要创建 PSO (Pipeline State Object)。
- 耦合: PSO 绑定了渲染状态（混合模式、深度测试）、光栅化状态、甚至 Render Target 格式。
- 现状: PSO 的变体数量远超 Shader 变体，收集和预热 PSO 是目前工业界的顶级难题。UE5 等引擎投入了大量精力在 PSO Caching 上。

5. 总结

变体管理是一个系统工程：

写 Shader: 区分 multi_compile 和 shader_feature，合理使用宏。
打包前: 使用 剔除工具 (Stripping) 移除无效变体。
打包时: 使用 收集工具 (Collection) 确保材质引用的变体不丢失。
运行时: 使用 分帧预热 (Incremental Warmup) 策略，平衡启动速度与流畅度。

NothingToSay0031

Explorer

Graph View

Shader变体管理与工程实践原理