在 WebGPU 计算着色器中实现迭代约束求解器时，开发者面临两个核心工程挑战：其一是 barrier 同步带来的隐性开销，其二是半精度浮点数（FP16）在数值稳定性与计算吞吐之间的权衡。不同于传统桌面 GPU 编程，WebGPU 的 WGSL 语言对 barrier 语义有严格的作用域限制，这直接决定了求解器的并行结构设计方式。本文从工程化角度给出这两种约束的量化分析，并提供可直接落地的阈值参数建议。
WebGPU 中 barrier 同步的作用域模型
WGSL 提供的 barrier 同步机制分为两类：workgroupBarrier() 和 storageBarrier()。前者同步同一 workgroup 内的所有线程并使 var<workgroup> 内存对组内可见，后者同步对 storage buffer 的访问，但两者均仅作用于单个 workgroup 内部，无法实现跨 workgroup 的全局同步。这一设计哲学与 Vulkan Compute Shader 一致，但与 OpenCL 的全局 barrier 存在本质差异。
对于迭代约束求解器而言，这意味着如果算法需要所有工作项在每次迭代后达成统一状态（例如全局残差计算或约束传播），必须采用多轮调度（multi-pass）模式而非单次 dispatch 内的 barrier 链。具体而言，每次迭代对应一次独立的 compute pipeline dispatch，宿主端（CPU）通过读取全局标记或使用 compute pass 间的同步原语来驱动下一轮迭代的启动。这种设计的代价是额外的 dispatch 调用开销和 kernel 启动延迟，但换来的是正确的语义和可预测的性能。
在实际工程中，建议将单次迭代的 workgroup 数量控制在 256 至 1024 之间，每个 workgroup 的线程数设为 64 或 128。过小的 workgroup 会导致 SM 占用率不足，过大的 workgroup 则会限制可以同时调度的 wave 数量。经验上，对于中等规模的约束求解问题（变量数在 10^4 至 10^5 量级），256 个 workgroup 配合 64 线程 /workgroup 能在多数集成显卡上获得较优的吞吐。
Barrier 开销的量化评估
barrier 同步并非零成本操作。在 GPU 硬件层面，每次 barrier 调用都会导致组内所有线程等待最慢的路径成员完成，这在数据分布不均匀时会产生显著的同步倾斜开销。根据社区测试数据，对于 64 线程的 workgroup，典型 barrier 开销在 2 至 8 微秒之间浮动，具体取决于硬件代数和内存访问模式。当 workgroup 扩大到 256 线程时，开销可能翻倍。
对于迭代约束求解器，这意味着 barrier 成本会随迭代次数线性累积。假设单次迭代包含 2 次 barrier（一次用于同步中间结果，一次用于同步最终更新），迭代 100 次的累计开销即可达 400 至 1600 微秒，这在端到端延迟敏感的场景中不可忽视。工程上可以通过以下策略缓解：其一，将可以合并的同步点合并，减少 barrier 调用频率；其二，在满足收敛条件的前提下使用宽松的迭代终止准则（详见下文 FP16 精度部分），从而减少总迭代次数。
此外，storageBarrier() 的作用域比 workgroupBarrier() 更广，它不仅同步线程还确保 storage buffer 的写入对后续读取可见。如果算法仅涉及 workgroup 内存（var<workgroup>），使用 workgroupBarrier() 即可，避免不必要的作用域扩大。
FP16 精度对迭代收敛的影响
WebGPU 自 Chrome 120 起正式支持 WGSL 中的 f16 类型，使得开发者可以在支持的硬件上利用半精度进行矩阵运算和数据存储。FP16 的优势是显著的：显存带宽需求减半，寄存器占用减半，在支持 Tensor Core 的 GPU 上还能获得额外的矩阵乘加速。然而，对于迭代约束求解器，FP16 的精度限制带来了实质性的收敛挑战。
FP16 的动态范围仅为 -65504 至 65504，尾数精度约 3.3 位十进制小数。这意味着在迭代过程中，残差值的细微变化可能被舍入误差吞没，导致求解器在远未收敛时便陷入停滞。文献表明，对于条件数较高的线性系统，纯 FP16 迭代可能需要 2 至 3 倍于 FP32 的迭代次数才能达到同等残差水平。
工程上推荐采用混合精度策略：外层迭代使用 FP32 或更高精度累积残差和更新方向，内层迭代（即最计算密集的矩阵 - 向量乘积和预处理步骤）使用 FP16 以获取吞吐收益。具体阈值参数建议如下：
收敛容忍度参数：外层求解器（FP32）残差容忍度设为 1e-8 至 1e-12，内层 FP16 求解器的残差容忍度设为 1e-3 至 1e-4。这种内外层精度解耦的设计在分布式迭代精化（iterative refinement）文献中有充分验证。当内层 FP16 求解器的残差下降至设定的容忍度后，即转向外层进行精度验证和更新。
稳定性增强措施：在内层 FP16 计算前对输入数据进行动态范围缩放，将系数矩阵和右端向量的范数缩放至 FP16 的有效表示区间（建议将最大绝对值控制在 1.0 至 100.0 之间）。同时，在每 5 至 10 次外层迭代后执行一次全精度（FP32）残差计算，以检测是否出现因精度损失导致的收敛停滞。若检测到残差下降率低于 0.5（即本次迭代残差与上次残差之比大于 0.5），应触发精度提升回退：切换至 FP32 进行当前迭代或增加内层迭代次数。
端到端性能与精度的平衡
综合 barrier 同步开销和 FP16 精度权衡，以下给出迭代约束求解器的推荐工程配置：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| Workgroup 线程数 | 64 或 128 | 平衡 SM 占用与 barrier 延迟 |
| 单次 dispatch 的 workgroup 数 | 256 - 1024 | 根据问题规模调优 |
| 每轮迭代 barrier 调用次数 | ≤ 2 | 合并同步点减少等待 |
| 外层 FP32 残差容忍度 | 1e-8 ~ 1e-12 | 依据精度需求选取 |
| 内层 FP16 残差容忍度 | 1e-3 ~ 1e-4 | 宽松内层收敛条件 |
| 精度验证间隔 | 5 - 10 次外层迭代 | 检测收敛停滞 |
| 残差下降率阈值 | < 0.5 | 触发精度回退的信号 |
在实践中，建议构建可配置的性能剖面工具，在初始化阶段自动探测硬件的 FP16 支持能力和平均 barrier 延迟，据此动态调整上述参数。例如，在不支持 DP4a 或 Tensor Core 的集成显卡上，FP16 的吞吐量优势可能不足以抵消精度损失，此时可降级为全 FP32 方案。
总结
WebGPU 计算着色器的 barrier 同步仅作用域单个 workgroup，跨 workgroup 协调必须通过多轮 dispatch 实现，这使得迭代约束求解器的设计与桌面 GPU 有显著差异。配合 FP16 混合精度策略时，推荐外层使用 FP32（残差容忍度 1e-8 至 1e-12）、内层使用 FP16（残差容忍度 1e-3 至 1e-4），并辅以动态范围缩放和周期性精度验证来保证收敛稳定性。在实际部署中，应基于具体硬件能力进行参数微调，而非使用一成不变的配置。
资料来源：WebGPU WGSL 规范中关于 barrier 语义的讨论见于 gpuweb/gpuweb 的 Issue #1374 和 Discussion #3935；FP16 混合精度迭代求解器的收敛分析可参考 arXiv 论文 "Mixed precision solvers with half-precision floating point numbers"（arXiv:2602.14450）以及 Intel 关于 DP4a 加速的技术博客。