WebGPU 多线程架构：基于 Web Worker 的 Buffer 共享与高性能同步设计

在 Web 端构建大型 3D 引擎、物理模拟或高性能计算（GPGPU）应用时，单线程的 JavaScript 往往会成为吞吐量瓶颈。WebGPU 的引入释放了 GPU 端的并行能力，但如何配合 Web Worker 榨干 CPU 的多核性能，依然是前端架构师面临的硬核挑战。

由于 WebGPU 的原生资源对象（如 GPUBuffer、GPUDevice）无法直接通过 postMessage 进行跨线程 Transfer（传输），我们无法在 Worker A 中创建 Buffer，然后直接塞给 Worker B 去提交渲染。

为了解决这一限制，本文将深度剖析如何在 Web Worker 架构下，利用 SharedArrayBuffer、Atomics 原子操作以及双/三缓冲区（Double/Triple Buffering）机制，设计一套高吞吐、低延迟的 WebGPU Buffer 共享与同步方案。

一、 核心架构：多线程协作模型

由于 WebGPU 资源无法跨线程共享，主流的高性能 WebGPU 多线程架构通常采用 “多 CPU 工作线程 + 单 WebGPU 渲染线程” 的拓扑结构。

+-------------------------------------------------------------+
|                         Main Thread                         |
|  - UI / DOM Events                                          |
|  - OffscreenCanvas Control                                  |
+------------------------------+------------------------------+
                               | Transfer Canvas
                               v
+-------------------------------------------------------------+
|                     WebGPU Render Worker                    |
|  - Owns GPUDevice, Pipelines, GPUBuffers                    |
|  - Execute commandEncoder.finish() & queue.submit()         |
+------------------------------+------------------------------+
                               ^
        Read Control / Atomics | (SharedArrayBuffer)
                               v
+-------------------------------------------------------------+
|                     CPU Compute Workers                     |
|  - Physics Simulation, Mesh Generation, Particle Updates    |
|  - Write raw data into SharedArrayBuffer directly           |
+-------------------------------------------------------------+

1. 为什么不用 postMessage 传输普通 ArrayBuffer？

普通的 postMessage 在传输大容量数据时有两种选择：

• Structured Clone（结构化克隆）：深拷贝，带来巨大的 CPU 耗时和内存垃圾回收（GC）压力。
• Transferable Objects（可转移对象）：虽然是零拷贝，但主线程会立即失去该 Buffer 的控制权。对于需要频繁双向同步、持续更新的帧数据（如粒子位置、骨骼矩阵），频繁转移会导致内存分配开销和复杂的生命周期管理。

2. 破局者：SharedArrayBuffer (SAB)

SharedArrayBuffer 允许多个 Worker 共享同一块物理内存。CPU 计算线程可以直接往 SAB 里写数据，WebGPU 渲染线程直接从 SAB 读取并写入 GPU，实现真正的多线程零拷贝数据流水线。

二、 共享 Buffer 同步机制设计

共享内存带来了竞争问题。如果 CPU Worker 正在写入顶点数据，而 GPU Worker 此时读取该内存并执行 writeBuffer，就会导致画面撕裂（Data Race）。

我们需要在 JS 层设计一套基于 Atomics（原子操作）的无锁/偏向锁同步机制。

1. 环形缓冲区（Ring Buffer）设计

为了避免读写冲突，推荐使用环形缓冲区（Ring Buffer）或多缓冲区（Multi-Buffering）。我们将一块大 SharedArrayBuffer 划分为 $N$ 个 Frame Slots。

SharedArrayBuffer 内存布局:
+-------------+-------------+-------------+------------------+
| Slot 0      | Slot 1      | Slot 2      | Control Headers  |
| (Frame Data)| (Frame Data)| (Frame Data)| (State Atomics)  |
+-------------+-------------+-------------+------------------+

在 SAB 的尾部，我们保留几个字节作为控制头（Control Headers），通过 Int32Array 映射，利用 Atomics 进行原子读写：

• State[0] (Write Index): 生产者（CPU Worker）当前写入的 Slot 索引。
• State[1] (Read Index): 消费者（WebGPU Worker）当前读取的 Slot 索引。
• State[2] (Lock Flag): 互斥锁标志或状态计数。

2. 无锁环形队列同步算法

以下是基于 Atomics.wait 和 Atomics.notify 实现的单生产者-单消费者（SPSC）同步逻辑：

CPU 生产者线程 (Worker)

// physics-worker.js
let sab;
let stateArray; // Int32Array, 共享状态
let dataSlots;  // Float32Array 数组，指向不同的 Slot

self.onmessage = (e) => {
    if (e.data.type === 'INIT') {
        sab = e.data.sab;
        stateArray = new Int32Array(sab, e.data.stateOffset, 3);
        // 初始化每个 Slot 的视图
        dataSlots = e.data.slots.map(slot => new Float32Array(sab, slot.offset, slot.length));
        loop();
    }
};

function loop() {
    // 1. 计算下一个可写的 Slot
    const writeIdx = Atomics.load(stateArray, 0);
    const readIdx = Atomics.load(stateArray, 1);
    const nextWriteIdx = (writeIdx + 1) % 3; // 假设是三模缓冲

    if (nextWriteIdx === readIdx) {
        // 缓冲区满了，等待渲染线程消费
        // 这里的 3 代表 stateArray[0]
        Atomics.wait(stateArray, 1, readIdx); // 等待 readIdx 发生变化
        return requestAnimationFrame(loop);
    }

    // 2. 写入物理/粒子模拟数据
    computePhysics(dataSlots[writeIdx]);

    // 3. 更新写入索引并通知 WebGPU 渲染线程
    Atomics.store(stateArray, 0, nextWriteIdx);
    Atomics.notify(stateArray, 0, 1);

    setTimeout(loop, 16); // 模拟 tick
}

WebGPU 渲染线程 (Worker)

// webgpu-worker.js
let device;
let gpuBuffer; // 预先创建的 GPUBuffer
let stateArray;
let dataSlots;

async function initWebGPU(canvas, sabData) {
    const adapter = await navigator.gpu.requestAdapter();
    device = await adapter.requestDevice();
    
    // 初始化共享内存
    stateArray = new Int32Array(sabData.sab, sabData.stateOffset, 3);
    dataSlots = sabData.slots.map(slot => new Float32Array(sabData.sab, slot.offset, slot.length));

    gpuBuffer = device.createBuffer({
        size: dataSlots[0].byteLength,
        usage: GPUBufferUsage.VERTEX | GPUBufferUsage.COPY_DST,
    });

    renderLoop();
}

function renderLoop() {
    const writeIdx = Atomics.load(stateArray, 0);
    const readIdx = Atomics.load(stateArray, 1);

    if (readIdx === writeIdx) {
        // 没有新数据，等待生产者写入
        // 在实际渲染中，为了不阻塞主线程，这里可以使用非阻塞轮询，或者在没数据时渲染上一帧
        requestAnimationFrame(renderLoop);
        return;
    }

    // 1. 获取当前有数据的 Slot
    const activeSlot = dataSlots[readIdx];

    // 2. 将 SharedArrayBuffer 中的数据上传至 WebGPU Buffer
    // 核心优化点：直接传递 TypedArray 子视图，底层会进行零拷贝的高效 CPU->GPU 传输
    device.queue.writeBuffer(
        gpuBuffer,
        0,
        activeSlot.buffer,
        activeSlot.byteOffset,
        activeSlot.byteLength
    );

    // 3. 执行渲染 Pipeline
    renderFrame();

    // 4. 释放当前 Slot，更新读索引，并唤醒可能正在等待的 CPU 线程
    const nextReadIdx = (readIdx + 1) % 3;
    Atomics.store(stateArray, 1, nextReadIdx);
    Atomics.notify(stateArray, 1, 1);

    requestAnimationFrame(renderLoop);
}

三、 高性能数据上传：避免 WebGPU 内存拷贝瓶颈

在多线程同步机制就绪后，另一个决定性能上限的因素是 CPU 内存到 GPU 显存的传输效率。

1. device.queue.writeBuffer 还是 GPUBuffer.mapAsync？

在 WebGPU 中，将 CPU 数据传到 GPUBuffer 有两种主流方式：

• device.queue.writeBuffer（推荐用于动态数据更新）：

  • 机制：浏览器内核（通常是 C++ 实现层）接管数据，并在最合适的时机（通常在下一次 submit 之前）通过 DMA（直接内存访问）将数据复制到 GPU。
  • 优点：不需要管理 Buffer 的 Map/Unmap 状态，不会阻塞 JS 运行，支持传入 SharedArrayBuffer 的视图。
  • 缺点：会发生一次从 JS 堆内存（SAB）到浏览器内核临时内存的 Copy（在部分浏览器实现中）。

• GPUBuffer.mapAsync + getMappedRange（适用于大容量、低频初始化）：

  • 机制：直接将 GPU 内存或 staging 内存映射到 JS 空间。
  • 优点：如果是普通 ArrayBuffer，可以实现“近乎零拷贝”的写入。
  • 缺点：不支持 SharedArrayBuffer。你无法直接把 getMappedRange() 得到的 ArrayBuffer 替换为 SAB。同时，频繁的 map/unmap 异步 Promise 链会带来极大的调用开销，直接拖垮帧率。

结论：在多线程 Worker 架构下，唯一可行且高效的方案是：CPU Worker 将数据写入 SharedArrayBuffer $\rightarrow$ 通过 postMessage（仅发送指针/索引通知）告知渲染 Worker $\rightarrow$ 渲染 Worker 使用 device.queue.writeBuffer 将 SAB 的子切片（Slice）写入 GPU。

四、 极致优化：对齐与跨域安全限制

1. 256 字节对齐限制（Alignment）

如果你在渲染线程中使用动态偏移量（Dynamic Offsets）或通过一个大 GPUBuffer 来存储多个 Worker 提交的数据，必须注意 WebGPU 的对齐规范：

• minUniformBufferOffsetAlignment 限制（通常为 256 字节）。
• COPY_BUFFER_TO_BUFFER 等操作要求 4 字节对齐。

在划分 SharedArrayBuffer 物理 Slot 时，请务必保证每个 Slot 的起始 byteOffset 是 256 字节的整倍数，否则在执行 writeBuffer 或绑定 BindGroup 时会直接触发 WebGPU Validation Error。

2. 浏览器安全沙箱（COOP & COEP）

由于 SharedArrayBuffer 存在 Spectre 等幽灵漏洞攻击风险，现代浏览器要求开启强隔离模式才能启用该 API。

你必须在托管网页的 Web 服务器上配置以下 HTTP 响应头：

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

如果不配置，JS 引擎会直接抛出 SharedArrayBuffer is not defined 异常。

五、 总结：设计决策检查清单

在落地 WebGPU 多线程架构时，可以通过以下清单指导设计：