深入底层：WebGPU Workgroup 共享内存的 Bank Conflict 隐形杀手与优化指南

在编写 WebGPU Compute Shader 时，为了提升全局内存（Storage Buffer）的读写效率，我们通常会使用 Workgroup 共享内存（在 WGSL 中通过 var<workgroup> 声明）。

共享内存的物理介质是芯片上的片上缓存（On-chip L1/SRAM），延迟极低。然而，许多开发者在启用共享内存后，发现性能不仅没有成倍提升，反而出现严重的卡顿。这背后最常见、也最隐蔽的性能杀手，就是 Bank Conflict（存储体冲突）。

本文将从 GPU 硬件架构出发，深度剖析 WebGPU 中 Bank Conflict 的产生机制，并给出切实可行的代码级优化方案。

一、 什么是 Bank Conflict？

要理解 Bank Conflict，必须先理解 GPU 共享内存的物理组织结构。

1. 存储体（Banks）的划分

在物理上，Workgroup 共享内存并不是一个连续的、能同时被任意读取的整体，而是被平均分成了若干个大小相等的、可独立访问的内存模块，这些模块被称为 Banks（存储体）。

在绝大多数现代 GPU（如 NVIDIA、AMD、Intel）上：

• 存储体数量通常为 32 个（与 NVIDIA 的 Warp 大小或 AMD 的波前 Wavefront 步长相对应）。
• 每个 Bank 的宽度通常为 4 字节（32-bit）（正好对应一个 f32、i32 或 u32 类型的变量）。

2. 理想状态：并行访问

如果一个 Subgroup（或 Warp，通常指 32 个线程）内的多个线程同时发起内存请求：

• 无冲突：若 32 个线程分别访问 32 个不同 Bank 中的数据，这些请求可以在一块时钟周期内并发完成。
• 广播/多播：若多个线程访问同一个 Bank 里的同一个地址，硬件会触发广播（Broadcast）机制，同样可以在一个周期内完成。

3. 冲突状态：串行化

如果多个线程访问了同一个 Bank 里的不同地址，就会爆发 Bank Conflict。

此时，该 Bank 无法同时处理多个不同的请求，硬件被迫将这些请求串行化（Serialized）。例如，若有 8 个线程同时冲突于 Bank 0，原本 1 个时钟周期的操作将被拉长到 8 个时钟周期。

二、 Bank Conflict 是如何产生的？（WGSL 案例剖析）

在 WebGPU (WGSL) 中，二维矩阵转置、图像卷积滤波、并行归约（Reduction）是 Bank Conflict 的高发区。

我们以最经典的**矩阵转置（Matrix Transpose）**为例。假设我们要处理一个 $32 \times 32$ 的数据块，并将其暂存到共享内存中：

// WGSL 共享内存声明
var<workgroup> tile: array<array<f32, 32>, 32>;

在 GPU 内存布局中，这个二维数组是**行优先（Row-Major）**连续排布的。其物理地址与 Bank 的映射关系（index % 32）如下表所示：

冲突场景：按列读取

假设在 Compute Shader 中，一个 Subgroup 内的 32 个线程（local_invocation_id.x 从 0 到 31）同时去读取共享内存中的某一列：

// 糟糕的写法：导致 32 路 Bank Conflict
let col = local_invocation_id.x; // 0 ~ 31
let val = tile[col][0]; // 线程 col 读取第 col 行的第 0 列

我们来推导此时每个线程访问的地址和 Bank：

• 线程 0 访问 tile[0][0] $\rightarrow$ 扁平索引 0 $\rightarrow$ Bank 0
• 线程 1 访问 tile[1][0] $\rightarrow$ 扁平索引 32 $\rightarrow$ Bank 0
• 线程 2 访问 tile[2][0] $\rightarrow$ 扁平索引 64 $\rightarrow$ Bank 0
• ...
• 线程 31 访问 tile[31][0] $\rightarrow$ 扁平索引 992 $\rightarrow$ Bank 0

结果：32 个线程同时挤在 Bank 0 上，而其他 31 个 Bank 处于闲置状态！
这触发了极端的 32-way Bank Conflict，原本极快的片上内存访问瞬间退化成了“单线程慢速轮询”，吞吐量暴跌至 1/32。

三、 如何规避 Bank Conflict？

解决 Bank Conflict 的核心思路是：打乱数据在 Bank 中的对齐方式，让并发线程的访问步长（Stride）与 Bank 数量互质。

方法 1：内存填充（Padding）技术（推荐）

这是解决二维共享内存冲突最经典、最简单的方法。

我们只需要将共享内存的列数主动增加 1 列（从 32 改为 33），但实际计算依然只用前 32 列。

// 优化后的共享内存声明（增加 1 列 Padding）
var<workgroup> tile: array<array<f32, 33>, 32>; 

此时，由于每一行变成了 33 个元素，物理内存的 Bank 映射发生了位移：

重新跑一次之前的“按列读取”逻辑：

• 线程 0 访问 tile[0][0] $\rightarrow$ Bank 0
• 线程 1 访问 tile[1][0] $\rightarrow$ Bank 1
• 线程 2 访问 tile[2][0] $\rightarrow$ Bank 2
• ...
• 线程 31 访问 tile[31][0] $\rightarrow$ Bank 31

奇迹出现了：32 个线程同时访问，刚好均匀分布在 32 个不同的 Bank 中！ 冲突率降为 0，GPU 硬件得以全速并发运行。虽然浪费了 $32 \times 4$ 字节的显存空间，但换来了数十倍的性能提升。

方法 2：优化归约算法中的访问步长（Sequential Addressing）

在进行并行归约（如求和、最大值）时，初学者容易写出“跨步式”访问，这也会引发 Bank Conflict。

❌ 产生冲突的跨步方式（Interleaved Address）：

// 步长 s 每次翻倍：1, 2, 4, 8...
// 导致 active 线程访问的物理地址差值恰好是 Bank 的倍数
if (local_id % (2 * s) == 0) {
    shared_data[local_id] += shared_data[local_id + s];
}

无冲突的连续方式（Sequential Addressing）：

将跨步形式改为“折半式连续访问”。让活跃的线程保持连续，同时让它们访问连续的数据块。

// 步长 s 从大小的一半开始，每次折半：16, 8, 4, 2, 1
// 线程 local_id 连续，访问的 index = local_id + s 也是连续的，映射到不同的 Bank
if (local_id < s) {
    shared_data[local_id] += shared_data[local_id + s];
}

在第二种写法中，由于所有活跃线程的 local_id 是连续递增的（0, 1, 2...），它们对 shared_data 的读写天然映射在相邻的 Bank 上，完美避开了冲突。

四、 总结与排查建议

在 WebGPU 性能调优的道路上，Bank Conflict 是一个看不见的瓶颈，因为 WebGPU API 层及浏览器控制台不会给出任何报错或警告。要揪出它，你需要培养底层视角：

1. 审视 var<workgroup> 数组：凡是涉及到二维数组，或者一维数组需要按大步长（尤其是 2 的幂次方，如 16, 32, 64）跨步访问时，高度警惕 Bank Conflict。
2. 应用 Padding 黄金法则：对于 $32 \times 32$ 这种块状局部缓存，无脑将列数设为 32 + 1 (如 array<array<f32, 33>, 32>)。
3. 借助工具剖析：如果条件允许，可将 WebGPU 程序打包并在 Native 端（使用 Vulkan/D3D12 后端）运行，通过 NVIDIA Nsight Graphics 或 Radeon GPU Profiler 进行内核级（Kernel）瓶颈分析，观察“Shared Memory Stall”指标。

利用好 Workgroup 共享内存并规避 Bank Conflict，是写出媲美 Native 级 WebGPU 计算着色器的关键所在。希望本文能帮助你榨干 GPU 的最后一滴算力！