类型系统与语义分析：Shader中的数据类型

好，咱们今天聊聊Shader编译器的类型系统和语义分析。说实话，这部分看起来基础，但坑特别多。我见过不少项目，渲染效果不对，最后查来查去，就是类型转换出了问题。

Shader里的类型系统，说白了就是告诉编译器：你手里拿的是什么数据，该怎么处理它。GPU是个高度并行的家伙，它可没CPU那么聪明，不会帮你兜底。所以类型检查必须严格，否则轻则性能下降，重则画面直接崩掉。

Shader中的核心数据类型

先过一遍Shader里最常见的几种类型。嗯，这里我按使用频率排个序：

• float：单精度浮点数，Shader里的绝对主力。几乎所有颜色、位置、法线计算都靠它。
• int：整数类型。循环计数器、数组索引、某些标志位会用。但注意，GPU对整数的支持其实不如float那么高效。
• bool：布尔类型。条件判断用。但底层其实还是用整数或浮点数实现的。
• sampler：采样器类型。这是Shader特有的，用来绑定纹理。你不能对它做算术运算，只能用它来采样。
• vec2/vec3/vec4：向量类型。float的集合体，分别有2、3、4个分量。做图形学的人天天跟它打交道。
• mat2/mat3/mat4：矩阵类型。变换矩阵、投影矩阵都靠它。

我个人习惯，在写Shader时尽量统一用float，少用int。为什么？因为GPU的ALU（算术逻辑单元）天生为浮点运算优化。你写个int加法，它可能先转成float算完再转回来，反而更慢。

类型检查与隐式类型转换

类型检查，就是编译器在编译阶段检查你的操作是否合法。比如你不能把一个sampler赋值给一个float变量，这毫无意义。

但Shader语言里有个让人又爱又恨的东西——隐式类型转换。说白了，就是编译器偷偷帮你把一种类型转成另一种类型。

举个例子：

float a = 1.0;
int b = 2;
float c = a + b;  // 这里b被隐式转换为float

这段代码能编译通过。编译器会把b从int转成float，然后做加法。看起来很方便对吧？

但我在项目中遇到过一个问题：

int a = 3;
float b = 1.5;
float c = a * b;  // 结果是4.5，没问题

// 但下面这个就有问题了
int d = a * 2.5;  // 隐式转换后，d = 7（截断）

你看，隐式转换有时候会丢失精度。编译器不会警告你，因为它觉得这是合法的。但结果可能不是你想要的。

我建议的实践是：显式转换。别指望编译器帮你做决定。

// 显式转换，意图明确
float a = 1.5;
int b = int(a);  // 明确告诉编译器：我要截断

float c = float(b);  // 明确告诉编译器：我要转成浮点

这样做的好处是，代码的可读性和可维护性都提高了。你想想看，半年后你回来看这段代码，看到显式转换，一眼就知道当时在想什么。如果是隐式转换，你可能得琢磨半天。

语义分析常见错误处理

语义分析阶段，编译器会检查你的代码逻辑是否合理。这里我总结几个最常见的错误：

错误类型	示例	原因	解决方法
类型不匹配	sampler2D tex = 1.0;	采样器不能接受数值赋值	检查变量声明，确保类型一致
维度不匹配	vec4 color = vec3(1.0);	vec4需要4个分量，只给了3个	使用正确的构造函数
精度不匹配	highp float a; mediump float b = a;	高精度赋值给中精度可能丢失数据	显式指定精度转换
未初始化变量	float a; float b = a + 1.0;	a没有初始值，结果是未定义的	所有变量都初始化

我曾经遇到过一个特别隐蔽的bug。一个同事写了一段代码：

vec3 normal = normalize(inputNormal);
float diffuse = max(dot(normal, lightDir), 0.0);
// 这里normal和lightDir都是vec3，没问题

// 但后来他改了lightDir的类型
vec4 lightDir = vec4(0.0, 1.0, 0.0, 0.0);
float diffuse = max(dot(normal, lightDir), 0.0);  // 编译错误！

dot函数要求两个参数维度相同。vec3和vec4不能做点积。编译器报错了，但错误信息可能不太直观。新手看到这个错误，可能会一脸懵。

还有一种错误，编译器不会报错，但结果完全不对——精度问题。

// 在移动设备上，这个计算可能不精确
mediump float a = 0.1;
mediump float b = 0.2;
mediump float c = a + b;  // 结果可能不是0.3

为什么？因为mediump在移动GPU上可能只有10位有效数字。0.1和0.2在二进制里是无限循环小数，精度不够就会截断。累积误差就出来了。

我建议的做法是：关键计算用highp，显示结果用mediump。比如深度计算、位置变换这些，必须用highp。最终的颜色输出，用mediump就够了，人眼分辨不出来。

避坑指南

嗯，这里我总结几个实战中容易踩的坑：

• 不要依赖隐式转换：尤其是int和float混用的时候。显式转换虽然多打几个字，但能避免很多莫名其妙的bug。
• 注意精度声明：不同GPU对精度的处理不一样。在PC上跑得好好的，到手机上就出问题，八成是精度问题。
• 检查纹理采样器的绑定：sampler类型不能做算术运算，只能采样。如果你试图对sampler做加减法，编译器会直接报错。
• 向量和矩阵的维度：做矩阵乘法时，维度必须匹配。mat4 * vec4是合法的，mat4 * vec3就不行。

我曾经在项目里犯过一个低级错误：把一个vec4的颜色值直接赋值给一个vec3的变量。编译器没报错，因为GLSL允许swizzle操作。但结果颜色完全不对，因为vec4的w分量被丢弃了。查了半天才发现是这个问题。

所以，我的建议是：写Shader时，把类型检查当成第一道防线。编译器能帮你发现的问题，就别等到运行时去调试。GPU的调试工具远不如CPU那么成熟，运行时bug查起来特别痛苦。

好了，类型系统和语义分析就聊到这儿。下一章咱们会深入讲讲控制流分析和循环优化，那才是真正考验编译器功底的地方。