GLSL的规范文档里《Variables and Types》这章读起来很枯燥——没有纹理采样那种画面感也没有光照模型那样能让脑子里立刻浮现出漂亮的渲染结果。但凡是真正在GPU上写过几个shader、调过几个深夜bug的人最后都会回到这一章里找答案。比如切线空间算错排查半天发现是mat3的构造参数顺序记反了比如移动端画面远处出现色阶断层查了一圈发现是法线变量被精度限定符偷偷降成了半精度再比如uniform buffer里的数据对不上仔细一对才发现std140的对齐规则和CPU端的结构体完全不是一回事。诸如此类根子都出在变量声明和类型规则上。这篇就从GLSL的变量与类型系统入手把规范里那套规则掰开揉碎讲一遍。重点不光是“有什么类型”更会讲“为什么是这个规则”“实际项目中踩过哪些坑”以及哪些细节是规范里写了但日常文档很少强调的。适合刚接触GLSL的图形学初学者也适合写了好几年shader但没系统读过规范的人用来查漏补缺。1. 为什么说变量和类型是shader与GPU之间的契约1.1 GLSL是严格强类型语言这点和C/C差别很大GLSL在设计上继承了C语言的语法骨架但类型系统远比C严格。C语言里int和float互相转换非常随意写错类型通常只是警告甚至编译器会默默帮你做隐式转换。GLSL不同它在类型检查上几乎是“零容忍”的类型不匹配就是编译错误没有讨论余地。为什么这么设计因为shader是跑在GPU上的GPU的每个执行单元都对应特定的数据通路。顶点属性进来是vec4纹理坐标是vec2变换矩阵是mat4——这些类型直接决定了硬件要准备多少个寄存器、怎么解析二进制流、怎么组织并行运算。如果类型可以随随便便转换硬件层的资源调度就没法做了。所以GLSL用强类型来保证每一个变量在编译期就有明确的大小和语义编译器才能把它映射到对应的物理资源上。比如一个最简单的顶点着色器#version 330 core in vec3 position; in vec3 normal; uniform mat4 modelViewProjection; out vec3 vNormal; void main() { vNormal normal; gl_Position modelViewProjection * vec4(position, 1.0); }这里in vec3 position声明了顶点属性是一个三通道向量GPU就知道要从顶点缓冲里按3个float为一组去读数据uniform mat4 modelViewProjection声明了一个4x4矩阵驱动层就知道要用glUniformMatrix4fv上传16个float。整个渲染管线的数据流就是靠这些变量声明串起来的。1.2 类型系统决定了shader能做什么、不能做什么GLSL没有指针没有动态内存分配没有字符串没有类。这些都被刻意砍掉了因为GPU的编程模型就是数据并行成千上万个线程同时运行同一段代码处理不同的数据。指针和动态分配在这种模型下是灾难——每个线程各自管理内存分布式内存分配的开销无法承受。所以GLSL的类型列表非常精简基本围绕“数值计算”这个核心场景展开标量bool、int、uint、float、double向量由标量组成的2/3/4维向量矩阵2x2到4x4的方阵和非方阵数组固定大小的同类元素集合结构体把不同类型打包成一个自定义类型不透明类型采样器sampler*、图像image*、原子计数器atomic_uint这套类型系统没有“字符串”“链表”这类高级抽象但足以覆盖实时渲染里绝大多数的数学运算。理解了这个前提再看规范里的每一项规则逻辑就顺了。2. 标量、向量与矩阵从维度数学到硬件寄存器2.1 标量类型各自的定位五个标量类型里最常用的是floatGPU的ALU天生就是为浮点运算设计的。int和uint主要在索引、循环控制、位运算、整数纹理采样这些场景使用。bool用于分支判断注意在大多数GPU上bool实际占用一个32位寄存器不像CPU那样压缩到1位。double在桌面端GL 4.0以后才引入移动端几乎不可用而且双精度运算在GPU上非常慢消费级显卡的双精度单元数量远少于单精度除非做科学计算否则实时渲染项目里基本不用。用一个表格来对比会更直观类型大小典型用途注意事项bool实现相关通常32位分支条件、逻辑标志不要在GPU上依赖位宽int32位有符号循环、索引、整数运算与uint之间无隐式转换uint32位无符号位操作、原子计数器、索引负数赋值会回卷float32位IEEE754几乎所有渲染计算精度和范围要看具体GPUdouble64位IEEE754高精度计算桌面高端卡才靠谱速度慢2.2 向量类型分量访问与swizzle操作向量是GLSL里使用频率最高的类型vec2、vec3、vec4分别对应二维、三维、齐次坐标。除了vec同一套维度还配套了布尔向量bvec*、整数向量ivec*、无符号整数向量uvec*、双精度向量dvec*。这套“同构家族”设计的意义在于数学向量运算是冗余的只要给一个浮点向量实现了加法其他类型的向量也能复用同一套语法。向量的分量有三种命名空间位置坐标x、y、z、w颜色分量r、g、b、a纹理坐标s、t、p、q三套名字可以互相访问同一个分量v.r和v.x是同一个东西。但规则有一条硬性限制一个swizzle表达式里不能混用不同命名空间的字母比如v.xy合法v.xr就是编译错误。swizzle操作最大的价值是可以一次性重排分量这在处理法线、切线、UV坐标时非常实用vec2 uv01 texCoord.xy; vec3 normalFromTangent vec3(bitangent * tangent.xyw); // 重排并升维 vec4 packedColor albedo.rgba;有一点必须强调当swizzle出现在赋值号左边时不能有重复分量v.xx vec2(1.0)是非法的但作为右值重复分量完全没问题vec2 duplicated v.xx可以正常编译。这是因为GPU并行写同一个寄存器会出现竞争规范从设计层面禁止了这种不确定性。2.3 矩阵类型构造方式与列主序存储矩阵类型包括mat2、mat3、mat4以及非方阵mat2x3、mat3x2、mat2x4等。第一个数字是列数第二个是行数例如mat3x2表示3列2行。GLSL的矩阵存储是列主序的这个细节影响深远。构造矩阵时参数是按“列”来填充的// 三列分别对应 // col0 (1.0, 0.0, 0.0) // col1 (0.0, 1.0, 0.0) // col2 (0.0, 0.0, 1.0) mat3 m mat3(1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0);用单个标量构造mat3 m mat3(1.0);会生成对角矩阵对角线上的分量都是1.0其他位置都是0.0。这是最常用的初始化方式相当于创建单位矩阵。从低维矩阵升维比如mat3 m mat3(mat2);会保留左上角的2x2部分其余位置按单位矩阵补全。从高维矩阵降维mat2 m mat2(mat4);则取左上角2x2。这套构造规则在处理法线矩阵、切空间旋转时经常用到写的时候要心里有数。矩阵乘法和向量的顺序不能记错。mat4 * vec4把矩阵作用到向量上是常规的变换操作vec4 * mat4相当于对矩阵做转置后再作用结果完全不同。实际项目里模型变换矩阵、视图矩阵、透视矩阵的链式乘法M * V * P这种顺序要始终一致否则会出现模型扭曲、方向翻转这类很难定位的问题。3. 复合类型结构体、数组与接口块3.1 结构体把零散的变量打包成有意义的数据单元结构体在GLSL里的作用和C语言类似把相关的变量聚合成一个逻辑单元struct Light { vec3 direction; vec3 color; float intensity; }; uniform Light u_light; void main() { vec3 diffuse u_light.color * u_light.intensity * max(dot(normal, -u_light.direction), 0.0); }结构体可以嵌套成员类型可以是标量、向量、矩阵、数组甚至另一个结构体。两个结构体变量可以直接赋值前提是类型完全一致结构体之间支持和!比较会逐一比较所有成员但前提是成员类型也要完全相同。需要注意不透明类型采样器、图像、原子计数器不能作为结构体成员也不能作为数组元素。这点和很多图形API的处理方式不同本质原因是这些类型无法被拷贝而结构体和数组的赋值语义要求成员可以被整体拷贝。3.2 数组大小、索引与length()数组的声明有两种等价写法float arr[5]; float[5] arr2; // 4.0以后支持的类型名在前写法主要用于函数返回值和参数数组大小必须是编译期常量或者通过初始化列表推断float values[] { 1.0, 2.0, 3.0 }; // 大小推断为3数组访问用[]运算符越界访问在GLSL里是未定义行为——有的驱动会报错有的驱动会静默返回垃圾值这是极其隐蔽的bug来源。数组的成员数量可以通过.length()获取距离值类型是int在循环里做边界判断非常方便for (int i 0; i values.length(); i) { total values[i]; }数组之间不允许整体赋值、比较、拼接。数组作为函数参数时按引用传递省去拷贝开销但形参必须声明数组类型可以用空大小float[]表示“任意长度的数组”也可以指定固定大小。我见过不少人在for循环里用float i做索引然后总是不功——因为GLSL里数组索引必须用整数类型浮点索引直接编译报错。这个问题在移动端低精度优化时特别容易犯后面精度部分会再展开。3.3 接口块跨阶段数据传递的正规渠道接口块interface block是GLSL中非常重要但容易被初学者忽略的复合类型。它本质上是一个带存储限定符的结构体用uniform或buffer限定用于批量管理uniform数据和着色器存储缓冲区SSBO。// uniform块声明在shader里 layout(std140) uniform TransformBlock { mat4 viewProjection; mat4 model; vec3 cameraPosition; float ambientFactor; };接口块和普通结构体最大的区别在于块内的成员实际存储在GPU缓冲区中CPU端通过glUniformBlockBinding关联一个缓冲区对象然后往里填充数据。这就牵出著名的std140布局规则它规定了GPU缓冲区里每个成员的字节偏移CPU端结构体必须按同样规则排列才能对上号。std140的规则归纳起来大致是类型对齐规则典型偏移float/int/bool4字节从4字节边界开始vec2/ivec28字节从8字节边界开始vec3/vec4及更大16字节从16字节边界开始数组元素按自身对齐要求排列整体对齐取其最大成员对齐的倍数vec3 arr[2]每元素占16字节嵌套结构体按内部最大成员对齐且整体对齐到其最大成员对齐的倍数内部成员各自对齐后再对外对齐这里最反直觉的一点vec3变量。表面上是12字节但std140下它的对齐是16字节也就是说三个vec3成员连续声明内存里会是48字节而不是36字节。如果CPU端的C结构体直接用float pos[3]、float normal[3]这样子排缓冲区就会错位渲染出来的模型会奇形怪状或者干脆什么都不显示。排查这类问题有个好方法用glGetActiveUniformsiv查询每个uniform的偏移量和CPU端结构体做对比。偏移量对不上十有八九是std140对齐没处理好。4. 存储限定符数据从哪来、到哪去4.1 in/out/const/inout函数参数与阶段间通信GLSL的存储限定符定义了变量的生命周期和可见范围。先看最基础的几类const编译期常量值不可修改shader内联优化的重要依据。in函数参数时表示输入参数在着色器入口main之外用于声明从上一个阶段接收的数据比如顶点着色器里的顶点属性。out函数参数时表示输出参数实际上是通过指针/引用语义写回在着色器入口用于声明传递给下一个阶段的数据。inout函数参数里既读又写效果相当于引用传递。函数参数默认是in可以省略不写。inout在GLSL里不像C有引用语法那么直观但它就是“修改实参本身”的意思void applyTransform(inout vec3 pos, mat4 m) { pos (m * vec4(pos, 1.0)).xyz; }调用后外面的pos变量会被更新。这在封装光照、雾效、坐标变换这类逻辑时能少写很多返回值拼接。在旧版GLSL1.20之前里跨阶段变量用attribute和varying这两个关键字attribute在顶点着色器里声明顶点属性varying在顶点和片段着色器之间传数据。从GLSL 1.30开始统一替换为in/out。现在写新代码一律用in/out但看老项目代码时遇到attribute可别懵。4.2 uniform、buffer与shared三种不同粒度的共享数据uniform着色器全局只读数据在一次绘制调用中不变。所有可编程阶段都能访问。它适合放模型矩阵、材质参数、光照参数这些高频变更但每个绘制批次只设置一次的数据。现代GL更推荐把多个uniform打包进uniform块减少状态切换的开销。buffer声明着色器存储缓冲区SSBO支持读写。计算着色器里做通用计算、粒子系统更新、可见性查询都会用。buffer块可以用std430布局比std140更紧凑没有vec3那种16字节对齐的额外膨胀。shared只在计算着色器里使用用于同一个工作组内线程之间的数据共享。共享内存的大小有硬件上限通常几十KB访问要比全局内快很多适合做分块归约、局部缓存这类优化。4.3 插值限定符flat、smooth与noperspective当变量从顶点着色器输出到片段着色器时GPU会在片元之间做插值。默认是smooth就是透视正确插值flat则不做插值所有片元都取触发这个图元的顶点值noperspective表示线性插值不用透视校正。这三个限定符里flat的实用价值最大。典型场景是顶点色ID、图元索引这类数据——如果这些值被插值边缘会糊成一片像素级拾取就会出错flat可以完美避开flat out int primitiveID;插值限定符错误导致的问题很典型模型表面出现奇怪的颜色渐变或者边缘出现细线。有人会把问题归到光栅化设置上其实查一下out变量的插值限定符很快就能定位。5. 精度限定符移动端性能的隐形开关5.1 highp、mediump与lowp到底改了什么GLSL的精度限定符是一个容易被桌面开发者忽视、但移动端必须重视的特性。三种精度精度浮点范围典型典型尾数位适用场景highp32位IEEE75423位位置坐标、矩阵、深度mediump范围约±6550410位颜色、UV、法线方向lowp范围约±26位环境光系数、高光强度注意上面给的是相对常见的实现实际精度由GPU决定着色器里声明的精度只是“最低要求”。桌面GPU通常把所有精度都实现为32位浮点所以桌面环境下mediump和highp性能可能没有差别移动端就不同了——很多移动GPU把mediump实现为半精度浮点fp16运算更快、带宽更低但范围和精度都有限。highp、mediump、lowp可以修饰float和int不能修饰bool和矩阵矩阵的精度由其元素类型决定。用法有两种// 变量级别 mediump vec2 texCoord; // 全局默认精度声明 precision mediump float; precision highp int;5.2 默认精度片段着色器里的float没有默认值规范对默认精度做了很严格的规定顶点着色器中float和int默认是highp所以不写精度也能正常工作。片段着色器中int默认是highp但float没有默认精度——如果不显式声明会直接编译报错除非所有浮点变量都显式写了精度。所以几乎每个片段着色器文件顶部都会有一行precision highp float;这句已经成为移动端GLSL的“惯例咒语”了但很多人不知道它真正解决的是“没有默认精度”这个硬性规则。5.3 移动端实战mediump优化要谨慎踩过的坑很真实我自己印象最深的一个教训是帮人排查一个移动端项目。现象是法线贴图在角色近景时边缘出现明显色带远看以为是贴图压缩问题。后来把片元着色器里的法线变量从mediump vec3改成highp vec3画面立刻正常。原因很简单法线贴图采样之后要跟TBN矩阵做乘法矩阵可能是highp的两边精度不一致时中间结果被截断到半精度误差被放大成可见的色阶。另一个容易翻车的点在循环里用mediump int做索引。mediump int在部分移动GPU上只有16位值超过32767就会溢出循环会变成死循环或者提前退出。这类问题很难肉眼发现定位时可以把循环变量单独提到highp int验证。所以我的建议很直接移动端做精度优化时优先把UV、颜色、光照系数这类“数值范围小、对误差不敏感”的量降成mediump凡是要做矩阵乘法、要参与深度计算、要做循环索引的变量一律保持highp。性能收益虽然存在但为了一点性能换来画面撕裂和数值错乱的调试成本性价比太低了。5.4 invariant与precise解决同一个表达式在不同shader里计算结果不一致的问题这部分在《Variables and Types》里不算显眼但遇到特定问题时极其关键。invariant保证同一个表达式在不同着色器里的计算结果严格一致——GPU编译器可以重新关联浮点表达式类似CPU的-ffast-math导致两个shader里写法完全相同的表达式生成了不同的指令顺序最终数值有微小差异。典型的场景是深度预渲染主渲染pass用一套texture矩阵算深度后处理pass里再用同一套矩阵算深度做测试两边结果差了一点点就会出现像素抖动。解决办法是在深度输出变量前加invariantinvariant out vec3 vDepthPosition;precise是更新的限定符要求某个变量的计算不能做会改变其值的优化但允许具体的指令顺序有差异。它和invariant的区别在于precise影响的是该变量相关的运算invariant保证的是同一个表达式在不同编译单元里的位精确一致性。平时用不上但如果做大型渲染管线且涉及到多pass复用相同数值最好记住有这两个保命关键字。6. 类型转换与构造规则严谨处处是坑6.1 隐式转换只做安全的加宽GLSL并非完全禁止隐式类型转换但规则非常保守。规范允许的隐式转换大致是“从窄到宽”的方向int可以隐式转换为float和doubleuint可以隐式转换为float和doublefloat可以隐式转换为double注意有两类经常被误以为可以但实际不行的int和uint之间没有隐式转换。写uint a intValue;如果intValue是int类型编译直接报错。bool不参与任何数值隐式转换。不能把int当bool用也不能把bool当float用。隐式转换会发生在表达式内部比如int float会自动把int转成float再运算结果是float。矩阵和向量的混合运算也有类似的隐式升级规则但维度不匹配依然直接报错。一个很容易让人困惑的实际例子uint参与运算时如果混入int在某些编译器上会报错在另一些编译器上会得到更宽的转换。最稳妥的做法是显式构造不依赖编译器的“仁慈”。6.2 构造函数与显式转换一切都可以手动做GLSL的构造函数同时承担了类型转换的职责任何标量、向量、矩阵都可以通过显式的构造函数互相转换float f float(intVal); int i int(floatVal); // 截断不是四舍五入 uint u uint(intVal); // 负数会按模运算回卷 vec3 v vec3(1.0, 2.0, 3.0); ivec3 iv ivec3(v); // 每个分量独立截断 vec4 v4 vec4(v3, 1.0); // 追加一个分量 vec3 v3 vec3(v4); // 丢弃多余分量浮点转整数是截断行为和C语言一致不是四舍五入也不会报溢出错误。对负数来说转成uint会按2^32取模回卷uint u uint(-1); // 结果是42949672956.3 运算符重载与矩阵乘法陷阱GLSL为向量和矩阵重载了几乎所有的算术运算符。向量之间按分量逐一运算向量和标量混合运算会把标量广播到每个分量。这些都是很方便的语法糖但有两个陷阱常踩。第一个是标量乘矩阵和矩阵乘向量时维数对齐问题。vec3 * mat3和mat3 * vec3都允许但前者相当于对矩阵做转置后再作用。第二个是运算结果类型随操作数升级。int * vec3会先把int隐式转成float再乘结果是vec3但uint * vec3呢uint转float也是允许的所以也能编译。这种“能编译”不代表“语义正确”尤其在做精确整数计算时转成浮点再回来会丢精度。需要固定整数语义时务必把两个操作数都声明成同样的整数类型。6.4 数组和结构体不能隐式转换类型转换规则对复合类型不适用。两个结构体即使成员类型完全一样只要声明类型不同哪怕仅仅是名字不同在GLSL里结构体相同定义就是相同类型实际上结构体类型是按成员类型和顺序区分的相同定义的结构体是同一个类型。规范不允许结构体之间隐式转换也不允许数组和相同元素类型的数组相互转换。所有复合类型的赋值必须是严格类型匹配的。写代码时如果感觉“这个vec3数组和那个vec3数组好像可以互相赋一下”——别想编译不过。7. 实操排查常见编译错误与运行期异常速查7.1 编译错误汇总表错误信息关键词原因处理办法cannot convert from float to vec3类型不匹配的赋值或函数实参用构造函数显式转换检查维度no matching function for call to vec4(float, int)构造函数的实参类型不匹配把int实参显式转为floatimplicit conversion from int to uint is not allowed有符号整型与无符号整型混用显式做uint()或int()转换swizzle ... cant ...swizzle表达式混用命名空间或左值重复分量统一用xyzw或rgba左值不重复array index must be an integer用浮点或非整数类型做数组索引索引变量改用int或uintprecision must be ...片段着色器的float没有默认精度文件顶部加precision highp float;undeclared identifier变量名拼写或作用域问题或者#version不匹配导致关键字不存在检查关键字与GLSL版本是否匹配7.2 一个典型的“类型不匹配”实战案例有位开发者在计算着色器里写了一个通用卷积函数声明如下shared float cache[256]; void convolve(float[] data, int width, int idx) { ... }调用时传入了shared内存数组。结果编译报错数组参数无法与shared数组匹配因为共享变量和普通全局变量在存储空间上不兼容。最后把convolve改成直接操作shared数组的专用版本或者用buffer块把数据搬出去处理问题才解决。这类问题在GLSL里很常见语法的“看起来能传”和规范层面的“存储空间不匹配”是两码事。7.3 std140对齐错位的排查流程uniform buffer数据错位的典型特征同一份代码在桌面端正常移动端或者某个特定驱动上表现异常或者改了CPU端结构体之后立刻花屏。排查步骤建议如下CPU端用glGetUniformBlockIndex拿到块索引。调用glGetActiveUniformsiv查询每个uniform的GL_UNIFORM_OFFSET。在shader里分别打印/调试每个成员的实际生效值和CPU写入值做对比。如果偏移不一致重点检查vec3、数组、嵌套结构体的对齐规则。实际项目中我见过有人为了对齐在C结构体里手动插入float padding[1]来对齐16字节结果shader端一改字段顺序C端忘了同步又花了一晚上排查。这件事的教训是不要依赖手动padding统一的办法是C端定义一个宏封装std140对齐规则或者直接把所有vec3字段手动补成vec4。提示凡是跨CPU/GPU边界传递的结构体数据不要在两边各写一份“看起来一样”的定义一定要让CPU端和shader端共享同一个布局规则文档或头文件布局变更时同步才不容易漏。7.4 矩阵构造顺序错误导致的模型扭曲某次做骨骼动画顶点着色器里要先用蒙皮矩阵变换位置再用模型矩阵变换到世界空间。代码写成了mat4 skinTransform mat4(0.0); mat4 finalTransform model * skinTransform; // 顺序写反成 skinTransform * model表现是模型每隔一段时间就“跳一下”不是完全扭曲但动画明显不对。后来发现不是动画数据问题而是构造矩阵时第一个参数按行传了mat4的列主序构造导致变换顺序全乱。GLSL里写矩阵构造时记住三列是连续的不能按行的习惯写否则“旋转”“平移”效果会串位。排查路径也分享一下先在CPU端把同一个矩阵用数学库算好再上传到uniform里做对比如果CPU算出来的结果和shader计算的不一致基本可以确定是构造顺序或者列主序/行主序搞反了。8. 一些项目里的使用建议和最终经验从实际项目角度补充几条关于变量与类型使用的长期经验这可能比单纯背规则更有用。第一写shader时先声明所有的in、out、uniform再写函数和逻辑。这样编译器能更早发现类型问题GPU编译器的优化也更有依据。很多人习惯把逻辑和变量声明混在一起写最后变量多了自己都忘了哪个是哪个。第二尽量使用新版布局限定符。现在的GLSL版本都支持location尽量不用旧式的layout缺省绑定方式显式指定location可以避免跨阶段接口匹配错位。第三计算着色器里索引变量统一用uint避免和gl_GlobalInvocationID的类型做不必要的转换。顶点属性索引、纹理数组索引等也优先用int不要随手写成float。第四类型转换要显示做即使编译器允许隐式转换代码里也应该优先写构造函数。这样在团队协作时别人看代码能一眼理解你的意图不用猜这个转换是“有意的”还是“手滑的”。最后再提一个经常被忽略的点GLSL的规范文档本身读起来虽然枯燥但很多驱动编译器的行为是以规范为基准实现的。遇到“这个shader在A卡上正常、在B卡上花屏”这类问题翻一翻规范里对应的章节往往比在网上搜半天案例更有效。变量与类型这一章更是在底子上决定了shader能不能编译、编译后跑得对不对。把这里的规则吃透后面学高级光照、几何着色器、计算着色器都会顺畅很多。
