GPU Gems 1 · Chapter 36. Integrating Shaders into Applications

GPU Gems 1 第 36 章关注的不是某个 shader language 的语法，而是“应用需要提供什么，shader 才能成为可维护的渲染资源”。如果应用只会加载一对 vertex/pixel 程序，却没有材质参数、场景矩阵、顶点格式、pass 顺序和硬件降级的通信层，那么 shader 数量一多，维护工作就会重新回到应用代码里。

1. 把渲染状态设计成 effect file

effect file 是本章推荐的资源边界。单独的 vertex/pixel 文件适合最小示例，但一个多 pass 效果通常还需要 cull mode、blend mode 等设备状态；如果这些状态散落在应用中，每增加一种渲染风格就要增加一组隐式分支。

effect file 的最小心智模型是：

• 变量有名字、类型和值，可以让应用枚举、读取和写入。
• pass 是一次渲染的原子单元，包含 vertex/pixel pipeline setup 与设备状态。
• technique 是多个 pass 的命名容器，也是验证设备支持情况的原子单元。
• annotation 和 semantic 是附加的元数据，让应用知道一个变量、pass 或 technique 应该怎样使用。

一个简化的 effect 资源可以表达下面的关系：

float4x4 CameraTransform : WorldViewProjection;
float4 FillColor : MaterialParam < string Desc = "object color"; >;
 
technique Selected {
  pass p0 {
    CullMode = CCW;
    BlendEnable = false;
    VertexShader = compile vs_1_1 SelectedVS();
    PixelShader = compile ps_1_1 SelectedPS();
  }
}

应用不需要知道每个 shader 函数内部如何计算颜色，但必须能通过 effect API 找到 technique、pass、变量和元数据。这样“渲染状态是资源”才真正成立：换一个 effect 可以换一种渲染风格，而不必先改 renderer 的控制流。

2. 变量、semantic 与 annotation

semantic 是变量名之外的通信标识。例如 WorldViewProjection 可以告诉应用，这个矩阵需要当前对象到 clip space 的变换；LightRadius 可以告诉应用，一个数值应来自光源半径。

annotation 更像给工具和应用读取的描述。它可以为材质参数声明默认值、最小/最大值和帮助文本，也可以说明某个 technique 的使用场景。变量名称适合小型且严格约定的库，semantic/annotation 更适合由不同作者维护的大型 shader 库，因为 shader 作者可以自由命名，只要契约标签保持一致。

应用加载 effect 时可以按类型安全地枚举全局变量：变量不仅有名字，还有 float、matrix、texture、structure 或 array 等类型。绑定层应在写入前验证类型，不要把一个颜色数组静默写入矩阵变量。

推荐的数据契约分四组：

1. scene information：对象到 clip space 的变换、骨骼矩阵、相机位置、当前对象颜色等由应用维护的状态。
2. material parameters：纹理、specular power、滚动速度等由材质资源和艺术家控制的值。
3. renderer context：selected、unselected、shadow 等当前应用情境，用于选择不同的 technique。
4. vertex data：shader 真正需要的位置、法线、切线、UV、骨骼权重等输入。

scene 通常是应用到 shader 的单向数据流，每次场景状态变化就更新；material 则先由工具从 shader 元数据发现参数，再由材质资源在渲染时回写值。这种发现—赋值流程让材质可以拥有不同于其他 shader 的参数，而不必把所有可能的字段硬编码进同一个材质类。

3. 绑定场景与材质数据

scene information 描述渲染器已经知道的事实，material parameters 描述内容作者希望调整的事实。两者都要通过 effect 的全局变量进入 shader，但查找策略可以不同：场景变量可以采用约定语义，材质变量则更适合由 MaterialParam semantic 与 annotation 自动发现。

一个材质工具可以按下面的流程工作：

load effect
  → enumerate typed globals
  → find MaterialParam semantic
  → read annotation: description/default/min/max
  → build material editor
  → at render time, write material values to the active effect

默认值和范围并不只是 UI 装饰。它们是资源缺省、验证和版本迁移的输入：当材质缺少新字段时可以使用默认值；当用户输入超出范围时，工具可以在渲染前报告问题，而不是让 shader 得到未定义结果。

3.1 用 handle table 把解析成本移出热路径

最直接的变量绑定是每帧扫描变量名，遇到 CameraTransform 就写入相机矩阵。这对小示例直观，但大型 effect 会重复字符串操作。正确的优化是加载 shader 时解析一次，再为每个 shader 实例创建独立的 handle table。

ShaderHandles handles = resolveHandles(effect, contract);
 
void updateScene(const SceneState& scene, const ShaderHandles& h) {
  effect.setMatrix(h.worldViewProjection, scene.worldViewProjection);
  effect.setVector(h.cameraPosition, scene.cameraPosition);
}

handle 不能跨 shader 复用。两个 effect 可能有同名变量，但 API handle 只对创建它的 effect 有效；切换 active shader 时，要使用新 shader 的 handle table 把当前 scene information 全量写入。缓存表的价值是把查找和验证集中在创建阶段，不是把契约检查完全删除。

4. 顶点格式也应由 shader 声明

不同 shader 需要不同的顶点输入。bump mapping 可能需要完整的 tangent space 和一组 UV，简单颜色 shader 可能只需要 position、normal 和两组 texture coordinates。如果应用永远发送所有可能的顶点字段，几何带宽和内存都会被不使用的数据拖大。

一种方法是约定 Vertex_Normal、Vertex_Position 等变量名；更清晰的方法是让 effect 定义一个包含语义的 vertex structure 实例，绑定层据此生成或打包需要的 vertex components：

struct SVertex {
  float3 Position : Position;
  float3 Normal : Normal;
  float2 UV0 : TexCoord0;
};
 
SVertex VertexDecl;

结构定义本身不能直接被应用枚举时，可以像示例一样声明一个实例。若 shader 在预处理阶段已经确定，工具可以只生成它所需的顶点属性；若 shader 运行时才决定，就要在“全字段顶点格式”和“运行时生成属性”的成本之间取舍。

顶点格式也是契约的一部分。缺少 semantic、类型不匹配或 shader 需要 skinning 数据而网格没有权重，都应在资源创建或 technique 验证阶段报告，而不是等到 draw call 后出现无声的黑屏。

5. 用 technique 表达 context 与 pass 顺序

renderer context 解决“同一个 shader 在不同应用情境下要怎么画”。比如用户选中对象时可以使用高亮 technique，未选中时使用普通 technique，shadow context 则选择只输出深度的路径。

每个 context 对应一个 technique，technique 内部再按顺序包含 pass。technique 是设备验证单元：如果其中任一 pass 不支持，整个 technique 都应被视为不可用。pass 是执行单元，真正描述当前阶段的 vertex/pixel program 和 device state。把 context 直接当作 pass 会丢失整体验证的边界；把所有 pass 直接散在应用代码中，又会失去资源驱动的可维护性。

当需要覆盖不同硬件时，可以用带 context 和序号的 pass 命名约定，或者为 technique 指定 fallback。加载时先解析当前设备能支持的 technique 和 pass 顺序，再把不可用的效果降级到更便宜但仍可见的 shader。fallback 的参数和 vertex declaration 应取所有可能继承 shader 的并集，否则降级发生时才发现缺字段，仍然会在运行时失败。

6. 用预处理器复用 shader variation

成熟的 shader 系统应支持 include，并让应用控制相对当前 shader 文件的路径。这样可以建立共享的数学函数、skinning 工具和标准语义定义，减少每个 shader 的复制代码。

预处理器还可以把 rigid 与 skeletal variation 收敛到一个源文件：

#ifdef SKELETAL
  #define DECLARE_WEIGHTS float4 Weights : BlendWeight
  #define SKIN_POINT(P, V) SkinPoint(P, V.Weights)
#else
  #define DECLARE_WEIGHTS
  #define SKIN_POINT(P, V) (P)
#endif

同样的方式可以切换光源数量、vertex format 或目标 hardware profile。源文件减少不代表变化空间消失：构建系统仍应记录宏组合、include 版本和最终 technique，避免“同一个 shader”在不同编译配置下实际变成无法追踪的多个资源。

7. 交互实验：从 shader 资源到设备

实验中的语义映射与变量名映射对应两种真实设计。变量名规则简单，但要求所有作者严格遵守；semantic/annotation 允许自由命名，却要求工具和 renderer 共同维护契约。vertex data 组数越多，几何带宽与内存压力越大；preprocessor 可以减少重复源码；fallback 则把“不可支持”变成可验证的降级路径。

8. 发布前的集成检查表

一套可维护的 shader integration layer 至少应该能回答以下问题：

• 加载 effect 后，是否能列出所有 typed variables、techniques、passes 和 annotations？
• scene、material、context 与 vertex data 是否各自有稳定 semantic 或 annotation？
• shader 切换时是否使用了新实例自己的 handle table，并重新写入当前 scene state？
• technique 是否在当前设备上整体验证，且 fallback 的参数与顶点需求完整？
• vertex data 是否按 shader 需求生成，而不是无条件上传所有可能属性？
• include 的文件系统、当前工作目录、宏组合和继承关系是否能进入构建缓存与错误报告？

这份清单把 shader 从“能编译的文件”提升为“可被应用发现、绑定、验证、降级和维护的资源”。Chapter 36 的重点也正在这里：应用工程工作量不能被 shader authoring 文档掩盖，通信层本身是 renderer 架构的一部分。

小结

• effect file 把 vertex/pixel program、technique、pass 和 device state 组织成数据驱动资源。
• semantic 与 annotation 让应用发现变量用途、材质参数和上下文，而不是依赖所有作者共享同一套变量名。
• scene information 通常由应用单向提供，material parameters 由工具发现并由材质回写，renderer context 选择 technique。
• shader 加载时应解析并缓存每个实例独立的 handles；运行时只按变化写值，不能跨 effect 复用 handle。
• shader 可以声明自己的 vertex data 需求，应用据此生成更紧凑的顶点格式，减少带宽和内存。
• technique 是整体验证单元，pass 是渲染原子单元；context 到 technique 的映射与 fallback 是硬件覆盖的关键。
• preprocessor、shader variation 与 inheritance 让一套资源适配 rigid/skinned、不同光源数量和不同硬件能力，但构建配置必须可追踪。