4.2 编译、链接与SPIR-V：着色器的诞生

4.2 编译、链接与SPIR-V：着色器的诞生

本节摘要：着色器程序在运行期经历「创建—编译—链接—使用」四步，编译检查语法、链接检查接口对接，而真正的机器码在程序首次使用时才由驱动生成。本节给出完整的加载与诊断代码，解剖两类高发错误（编译期语法错、链接期接口错）的日志解读方法，讲清 uniform 位置查询的时机，并介绍 SPIR-V 中间格式如何把「运行期编译」前移成「离线预编译」。这是把写着色器从碰运气变成工程化的关键一节。

着色器的出生证明

普通程序在构建时编译链接，着色器程序却在你程序运行起来之后才编译——驱动拿到 GLSL 源码，针对当前 GPU 生成机器码。这个设计换来了「同一份代码跑在所有 GPU 上」的可移植性，代价是三样：运行期编译耗时（材质多时首次加载卡顿）、驱动实现差异（不同厂商的编译器优化水平不齐，A 卡视觉正常 N 卡精度告警的来源）、错误发现滞后（语法错误运行时才爆）。理解这套流程是本节的主线，SPIR-V 是这条线末端的补丁。

完整的加载流水线代码

把四步流水线写成可直接复用的工具函数，错误处理一步不省：

GLuint compileShader(GLenum type, const char* src) {
    GLuint sh = glCreateShader(type);            // 造着色器对象
    glShaderSource(sh, 1, &src, nullptr);
    glCompileShader(sh);
    GLint ok; glGetShaderiv(sh, GL_COMPILE_STATUS, &ok); // 查编译状态
    if (!ok) {
        char log[512]; glGetShaderInfoLog(sh, 512, nullptr, log);
        printf("编译失败：%s\n", log);            // 日志带行号，直接定位
    }
    return sh;
}

GLuint linkProgram(GLuint vs, GLuint fs) {
    GLuint prog = glCreateProgram();             // 造程序对象
    glAttachShader(prog, vs);
    glAttachShader(prog, fs);
    glLinkProgram(prog);
    GLint ok; glGetProgramiv(prog, GL_LINK_STATUS, &ok);
    if (!ok) {
        char log[512]; glGetProgramInfoLog(prog, 512, nullptr, log);
        printf("链接失败：%s\n", log);            // 接口错都在这里现形
    }
    glDeleteShader(vs); glDeleteShader(fs);      // 链接完着色器对象即可回收
    return prog;
}
​

使用时 glUseProgram(prog) 切换当前程序，之后所有绘制都用它——注意这又是状态机逻辑：程序也是绑定的对象，不切就一直是上一个。

两类错误的病理与读片

编译期错误的日志格式是「行号 + 描述」，直接按行号修。高频病因排行：分号漏写（GLSL 分号比 C 更较真）、版本声明不在第一行（#version 前有空行或注释直接报错）、给 const 变量赋值、整型浮点混算。读片要点：第一个错误最可信，后面的可能是雪崩——一个分号错误能引发十行报错，修第一个重编译，别追着日志列表挨个修。

链接期错误是接口对接失败：顶点着色器 out 的变量在片元着色器里没有同名 in（或类型不一致）、两个着色器声明了同名却不同精度的 uniform。日志措辞类似「未消费的输出变量」。这类错误的阴险之处在于可能只是警告而非错误——程序照常运行，数据断流，画面黑。所以纪律是：链接日志有警告必读必处理，黑屏排查第一步永远是读日志，第二步是核对 in/out 名单（4.1 节的接口病）。

第三类隐蔽错误发生在 uniform 环节：glGetUniformLocation 返回负一（找不到这个名字）却不报错，后续 glUniform 调用静默失败。病因通常是：uniform 在着色器里声明了但没被使用（优化器直接删掉，名字查不到）、名字拼写错。对策：位置查询结果打印一次，负一即报警；理解「被删的 uniform 不是错误是优化」，别浪费时间去修一个被正确优化掉的东西。

⚠️ 常见坑：每帧重复查询 uniform 位置、重复编译着色器。位置在链接后固定，缓存成变量；程序对象创建一次用到底。把 glGetUniformLocation 写进渲染循环是新手代码里最常见的隐形性能税。

uniform 上传的时机账

glUniform 系列设置的值属于当前程序对象，且只在绑定期间有效——换程序再换回来，值还在（属于程序状态），但「当前」变成别人了。正确的节奏是：每帧每材质，UseProgram → 上传该材质的 uniform → 绘制。摄像机矩阵这种全帧恒定的值，用 uniform 块（UBO）一次上传全局共享（4.1 节三车道图），把重复上传消掉——这是通往第 6 章 AZDO「减少驱动调用」思想的第一级台阶。

SPIR-V：把编译前移到开发期

运行期编译的三大痛点（耗时、差异、滞后）在 OpenGL 4.6 有了官方解法：SPIR-V 中间格式。流程变成开发期离线编译——GLSL 先被编译成标准化的 SPIR-V 二进制，运行期只做「SPIR-V → 本机机器码」的最后一步。收益对应三个痛点：语法与大部分优化前移（错误在构建期暴露，机器无关）、中间格式标准化（削掉厂商编译器的语法分歧）、运行期工作量骤减（首次使用卡顿减轻）。

不必立刻改造现有工程：GLSL 源码路径在 4.6 上依然是一等公民。但两个场景值得尽早接触 SPIR-V：材质体系庞大的项目（离线工具链可以做变体管理与缓存），以及需要跨图形 API 复用着色器的项目（Vulkan 原生就吃 SPIR-V，一套中间格式两头用）。把它记成「着色器工程化的方向」即可，语法层面本章其他内容不受影响。

案例：一个「画面全黑」的完整排错

背景：工程师移植了一段网上抄的着色器，编译链接全部通过，运行黑屏。操作：按本章流程走——先查链接日志，发现一行「输出变量 vColor 未被片元着色器消费」；核对名字，片元端写的是 in vec3 fragColor，顶点端 out 的是 vColor。改名对齐后仍偏暗；再查 uniform，发现光源强度位置查询返回负一——着色器里声明了但实际没参与计算（旧代码删了用法忘了删声明）。结果：名字对齐加清理声明，画面正常。解读：黑屏的两次病因分别卡在链接接口与 uniform 优化，都在本章的病理清单里。变式：若日志完全干净，下一步该查顶点数据与管线状态（VAO 绑定、深度测试配置），那是第 2、3 章的地盘——排错按管线顺序走，日志永远第一站。

本节要点回顾

• 四步流水线：创建—编译—链接—使用，机器码在首次使用时才生成
• 日志纪律：编译错看第一个、链接警告必处理、黑屏先读日志再对接口名单
• uniform 位置负一不是错误是优化：被删的 uniform 查不到位置，缓存查询结果别放循环里
• 上传节奏：切程序→传 uniform→绘制；全帧常量进 UBO
• SPIR-V 是工程化方向：离线预编译消解运行期编译的三大痛点，大材质体系优先受益

语言和工具链都齐了。下一节还第 2 章欠下的数学账：MVP 链每一步在几何上到底做了什么、法线矩阵的逆转置从哪来——不背公式，用几何直觉重建它们。