4.1 着色器模块与 SPIR-V

4.1 着色器模块与 SPIR-V

本节摘要：Vulkan 不收着色器源码，只收 SPIR-V 字节码——这个决定把着色器编译从驱动热路径里整体搬走，交给你选择的编译器。本节讲清 SPIR-V 的来龙去脉、离线与运行时两条编译路线、着色器接口匹配规则，以及反射工具的自动化价值。

SPIR-V 并非 Vulkan 凭空发明——它的前身 SPIR 最初是为 OpenCL 设计的中间语言，Khronos 把它升级成带统一能力的二进制格式，让 Vulkan 从出生起就带着一套与驱动厂商解耦的着色器体系。理解这个出身，就理解了本节全部内容的动机：编译一次做足，驱动只做消费。

一、为什么是字节码

老 API 把 GLSL 源码直接交给驱动，驱动各自解析、各自优化，结果是「同一份着色器，A 卡正常 B 卡报错」成为常态，编译耗时还潜藏在首次绘制的卡顿里。SPIR-V 把契约改成：源码到字节码由你的工具链负责（可测试、可固定版本），字节码到硬件指令由驱动负责（单一职责）。三方各让一步——应用得到可控的编译流程与缓存能力，驱动卸掉源码解析负担，Khronos 则握住了中间层的规范权。

对应用侧的直接好处有两个。编译结果可以缓存：SPIR-V 文件随资产打包，首次绘制不再卡顿。工具链可以离线验证：编译错误在构建机上报出，而不是在玩家的驱动里。

图 4-1：着色器从源码到管线的工具链

二、编译会话与运行时入场

编译用 Khronos 官方的 glslc（SDK 自带）。一条典型会话，从源码到可打包的字节码：

$ glslc shader.vert -o shader.vert.spv
$ glslc shader.frag -o shader.frag.spv
$ glslc -fshader-stage=compute -O comp.glsl -o comp.spv
# 报错示例：源码里把 vec3 与 vec4 的插值限定符写岔
shader.vert:12: error: 'location' : redefinition
​

注意编译期就能抓住的错误（语法、接口不匹配的静态部分）在构建机上复现，与驱动无关——这是离线路线的核心红利。运行时入场则简单得多，字节码进模块：

std::vector<char> code = readFile("shader.vert.spv");

VkShaderModuleCreateInfo mi = {VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO};
mi.codeSize = code.size();
mi.pCode    = reinterpret_cast<const uint32_t*>(code.data());

VkShaderModule module;
vkCreateShaderModule(device, &mi, NULL, &module);

// 模块不直接绑定，而是作为管线装配的原料之一
VkPipelineShaderStageCreateInfo stage = {VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO};
stage.stage  = VK_SHADER_STAGE_VERTEX_BIT;
stage.module = module;
stage.pName  = "main";    // 入口函数名；一个模块可含多个入口
​

模块生命周期有个反直觉的宽松点：管线创建完成后，模块即可销毁——管线装配时字节码已被消化，模块只是包装。内存紧张的应用常在启动装配完所有管线后统一释放模块。

三、接口匹配：两边对上的规则

顶点与片段着色器之间的传递量（varying）按「location 加类型」匹配，规则严格：位置号一致、分量与类型兼容、插值限定符一致。片段着色器输出与渲染通道附件格式之间也有兼容表。这些匹配大多在管线创建时核验，验证层的报错会明确指出哪个 location 对不上——比起老 API 的「黑屏不解释」，已经是文明时代。

真正费人工的是另一头的匹配：着色器里的 uniform 与采样器声明，要和 3.4 节的描述符布局逐条对上。手写既累又容易漂移，工程标准解法是反射：用 spirv-cross 之类工具从字节码读出全部绑定量（set、binding、类型、数组长度），自动生成描述符布局。布局不再手抄，着色器改动时布局自动跟随。

四、案例：编译路线的工程决策

背景：一个支持玩家自写着色器的沙盒游戏，初期用运行时编译 GLSL（把 glslang 编译器嵌入进程），加载自定义材质时主线程卡顿明显，且编译失败的报错在不同驱动上不一致。

操作：改造分三档。内置材质全部转离线编译，SPIR-V 随包发布，启动期装配、模块即用即毁；玩家材质保留运行时编译但挪到工作线程，失败时回退到哨兵材质（粉黑棋盘格）并给出编译日志；两档共享同一套反射流程生成描述符布局，保证玩家着色器与内置着色器的资源声明规范一致。

结果：内置路径零编译卡顿；玩家材质的编译等待被并行掩盖，出错体验从「白屏」变成「棋盘格加日志」。跨驱动一致性问题的报障量归零。

解读：这个案例的分工逻辑是「确定性走离线、灵活性走运行时、两条路共用一套接口规范」。运行时编译不是禁区，但它必须被隔离在工作线程与回退机制之后——把编译失败当成正常业务而不是异常，是这个场景的成熟标志。

变式：纯运行时生成的着色器（程序化材质、用户图 composing）还可以缓存在磁盘：SPIR-V 的生成是确定性的，同一输入的缓存命中能跳过重复编译。缓存键要包含编译器版本，避免跨版本污染。

五、要点回顾

• 字节码契约：SPIR-V 把编译责任从驱动搬到工具链，换来可控、可缓存、跨驱动一致的着色器供应。
• 离线优先：glslc 在构建期抓错，字节码随资产打包；运行时编译要隔离到线程并备回退。
• 模块是包装：ShaderModule 创建轻量、管线装配后即可销毁，一个模块可服务多个入口。
• 接口两头对：varying 按 location 与限定符匹配，绑定量靠反射自动化对齐，别手抄。
• 编译可缓存：SPIR-V 生成确定性的场景可做磁盘缓存，缓存键带编译器版本。

给后续章节留个钩子：本节的阶段结构体（stageCount 与 pStages）在 4.2 的管线装配里只是其中两栏，但它决定了其余所有状态栏是否必须存在——比如细分着色器在场时细分状态才有意义。读下一节时带着这个联动视角，装配结构的十几个子状态就不难记了。