WebGPU 的 WGSL 着色器语言：与 GLSL 的对比与现代图形编程

WebGPU 已经不再是一个只出现在规格书里的名词。当它在桌面端浏览器里逐渐默认开放，很多原本长期依赖 WebGL 的图形项目开始认真规划迁移。迁移的第一步，通常不是 API 调用，而是着色器。你很快会发现，GLSL 里写起来很自然的几行代码，到了 WGSL 里不是报类型错误，就是找不到绑定位置。这不是 WGSL 故意制造麻烦，而是它在设计上没有打算成为 GLSL 的兼容层。

这篇文章想从一个实际写渲染代码的角度，聊一聊 WGSL 着色器语言与 GLSL 的核心差异，为什么 WebGPU 需要一种新的着色器语言，以及当我们真的从 GLSL 迁移过来时，哪些地方最容易出问题。

为什么 WebGPU 要重新设计着色器语言

GLSL 是与 OpenGL 一起成长起来的。它写起来舒服，变量声明可以省略类型，整数可以隐式转浮点，各种内建变量直接使用。但这些特性带来了一个代价：编译器要在不同驱动里做很多纠错和猜测，同样的着色器在不同 GPU 上可能表现不同。

WGSL 是 WebGPU 的官方着色器语言。WebGPU 本身位于浏览器与底层图像 API 之间，需要同时映射到 Vulkan、Metal 和 D3D12。如果着色器语言仍然依赖驱动层面的模糊解释，跨平台稳定性和调试体验就没有办法保证。WGSL 的强类型、显式绑定和明确的内存布局，都是为这个前提服务的。

一个典型的 WebGL 团队第一次在 WGSL 里写带 uniform 的 vertex shader 时，往往会卡在声明上。GLSL 里 uniform vec2 uScale; 就够了，位置交给 program 对象。WGSL 里不仅要写 var<uniform> params: Params;，还要在结构体里定义字段，并在 JS 侧用 GPUBindGroup 把数据绑到对应的 @group 和 @binding。这种额外工作不是白费的，它让渲染管线的资源关联变得可预测。

WGSL 与 GLSL 的核心差异

先看一个最简单的顶点着色器，同样完成一件事，GLSL 和 WGSL 的写法差别有多大。

GLSL 的写法

#version 300 es
layout(location = 0) in vec2 aPos;
layout(location = 0) out vec2 vUv;

uniform vec2 uScale;

void main() {
  vUv = aPos;
  gl_Position = vec4(aPos * uScale, 0.0, 1.0);
}

WGSL 的写法

struct Params {
  scale: vec2<f32>,
};

@group(0) @binding(0) var<uniform> params: Params;

struct VSOut {
  @builtin(position) clip_position: vec4<f32>,
  @location(0) uv: vec2<f32>,
};

@vertex
fn vs_main(@location(0) pos: vec2<f32>) -> VSOut {
  var out: VSOut;
  out.uv = pos;
  out.clip_position = vec4<f32>(pos * params.scale, 0.0, 1.0);
  return out;
}

两者放在一起看，最明显的区别不是语法，而是信息密度。GLSL 靠关键字和隐式规则表达语义，WGSL 则把入口点参数、返回结构、资源和绑定位置全部显式化。它变长了不少，但每一行都是在告诉你一个确定的事实：这个变量从哪来，到哪去，存放在哪个地址空间，绑在哪个槽位。

下面这张表梳理了 GLSL（以 GLES 3.0 / WebGL2 为参照）与 WGSL 的主要差异，方便快速定位关键节点。

这些差异背后的工程取舍

如果只把 WGSL 看成 GLSL 的另一种写法，就很难理解为什么 WebGPU 社区会坚持用这么“啰嗦”的语言。WGSL 真正解决的，是几个 GLSL 时代长期没理顺的问题。

GLSL 的着色器编译发生在 GPU 驱动里，浏览器的 console 往往只能收到一串驱动返回的错误码。WGSL 会在浏览器侧先做解析和验证，很多类型错误、绑定错误在调用 createShaderModule 时就能暴露出来，错误信息直接指向 WGSL 源码位置。对整天和渲染 bug 搏斗的开发者来说，这几乎是换了一个工作方式。

跨后端一致性同样关键。WebGPU 在浏览器底层的后端可能是 Vulkan、Metal 或 D3D12，同样的 WGSL 要能稳定翻译到这些后端。GLSL 时代依赖驱动决定太多细节，导致同一个着色器在桌面端正常、在移动端就会发黑的情况并不少见。WGSL 把内存布局和对齐规则明确化，很大程度缓解了这类问题。

还有一个被低估的原因是 compute shader。WebGPU 不是只做渲染，还要承担 GPU 计算。WGSL 中的 storage buffer、atomic 操作、workgroup memory 等设计，从一开始就是为了通用计算准备的。GLSL 的 compute shader 虽然存在，但绑定和跨后端体验都不够统一。

从 GLSL 迁移到 WGSL，最容易踩的坑

很多团队在迁移时，会先把 GLSL 直接翻译成 WGSL，然后开始处理各种奇怪的现象。最大的麻烦往往不是语法，而是下面这些隐藏规则。

• 依赖隐式类型转换：WGSL 不允许 int 和 float 混算。比如表达式 pixelIndex * 4 如果一个是 i32 一个是 u32，会直接报错。你需要先想清楚索引变量应该是什么类型。
• 忽略了地址空间：WGSL 中普通 var 是 private 变量，不是 uniform。想要 uniform，必须写成 var<uniform>。忘记这个前缀，着色器会把数据当成函数内的普通变量。
• 存储缓冲对齐：结构体字段如果包含 vec3，或者数组 stride 没对齐，在不同 GPU 后端上可能得到不同结果。WGSL 提供了 @align 和 @size 属性，但需要你有意识地去使用。
• 矩阵运算顺序：WGSL 的矩阵默认列主序，mat * vec 和 vec * mat 语义不同，迁移时很容易沿用 GLSL 的直觉而忘记检查布局。
• 把 @location 和 @builtin 混用：内置变量如顶点索引、实例索引、位置输出必须使用 @builtin，而用户自定义的顶点属性和 varying 使用 @location。两类标识符映射到不同的管线槽位，写错了通常会得到难以理解的报错。

一个很常见的案例是：uniform 没有生效，画面颜色一直不对。排查半天，最后发现是结构体里一个 vec3 字段后面没有手动 padding，导致内存布局和 CPU 端 buffer 对不上。GLSL 时代驱动会帮你在底层处理这类细节，WGSL 把控制权交给你，同时也把责任交给你。

什么项目适合现在就上 WGSL

并不是所有 WebGL 项目都应该立刻迁移。如果现有系统稳定，团队对 GLSL 的边界十分熟悉，迁移的收益可能没那么高。WGSL 和 WebGPU 本身还在演进，浏览器实现也有细微差异，过早迁移会引入新的兼容成本。

反过来，新的渲染项目、对 compute shader 有需求的项目、需要同时面向桌面和移动端做自定义渲染管线的团队，现在直接使用 WebGPU + WGSL 是更合理的选择。尤其是当项目需要更精细的 GPU 资源控制，或者需要绕过 WebGL 的性能天花板时，这条路径会更早产生回报。

工具链上，可以直接在浏览器里写 WGSL，也可以借助 naga 或 Tint 做离线转译。不过要记住，自动转换工具适合把现有 GLSL 资产快速跑起来，但产出的 WGSL 通常可读性较差，也不一定会利用 WGSL 的绑定模型优势。如果项目打算长期维护，还是值得在迁移后逐步重写着色器。

真要动手，从最小管线开始

如果你准备开始写 WGSL，最好的方式不是先找全套 PBR 示例，而是用一个 50 行左右的渲染循环，先渲染一个带颜色的三角形。这样你能专注理解三件事：着色器入口点怎么声明、绑定组怎么建立、数据怎么走完 CPU 到 GPU 的路径。

async function initWebGPU() {
  if (!('gpu' in navigator)) {
    console.error('当前浏览器不支持 WebGPU');
    return;
  }
  const adapter = await navigator.gpu.requestAdapter();
  const device = await adapter.requestDevice();
  console.log('WebGPU 设备已就绪');
}

这段代码本身不涉及 WGSL 语法，但它会确认你的运行环境是否具备调试的基础条件。等 GPU device 就绪后，再创建 shader module、bind group、pipeline，每一步的错误提示都会比 GLSL 时代友好很多。

一点经验：在 WGSL 中设计 uniform 结构体时，尽量把字段按 16 字节对齐来排布。显卡硬件和 WebGPU 后端都对对齐有要求，但如果你从一开始就让结构体里的字段大小对齐到 16 字节，能少很多莫名其妙的问题。

跑通这个最小管线后，再逐步加入 storage buffer、texture 和 compute pass。每一步都尽量保留独立的 @group 绑定，而不是把所有数据塞进一个全局结构体。这样后续扩展和调试都会简单很多。

WGSL 不是一个从 GLSL 演进出来的版本，它是 WebGPU 这个新图形体系的一部分，也是现代图形编程中值得认真理解的基础能力。它的语法更严格，信息更明确，学习门槛也更高。如果你抱着把 GLSL 翻译一下就完事的心态，可能会被各种类型错误和绑定问题缠住；但如果你把它当作一次重新理解 GPU 资源的机会，WGSL 会让你更清楚地看见自己的数据是怎么流动的。

回到最初的问题：WGSL 和 GLSL 之间不是单纯的语法替换，而是两种图形编程思维之间的切换。理解这一点，迁移才不会变成漫长的踩坑过程。