WEBKT

避免 Context Lost：多 WebCanvas 场景下的 WebGPU 全局调度器设计

10 0 0 0

在开发复杂的 Web 端可视化系统（如多视口 3D 编辑器、多路视频分析监控墙、或者低代码大屏配置系统）时，我们经常需要在同一个页面中渲染多个 Canvas。

如果使用 WebGL，每一个 Canvas 通常对应一个独立的 WebGLRenderingContext。当 Canvas 数量超过浏览器限制（通常为 8 到 16 个）时，最先创建的上下文就会被强制回收，触发著名的 Context Lost 错误。

WebGPU 带来了更现代的架构。它允许我们共享同一个 GPUDevice，并将其呈现（Present）到多个 GPUCanvasContext 上。然而，这并不意味着多 Canvas 场景可以高枕无忧。如果不对 GPUCommandEncoder 的创建、指令录制和队列提交（Submit）进行全局调度，当页面并发 Canvas 数量增加时，依然会面临以下问题：

  1. GPU 内存与命令缓冲区耗尽：同时为数十个 Canvas 创建 GPUCommandEncoder，如果不加限制地录制并保留大量未提交的命令，会瞬间拉爆浏览器的 command buffer 限制或引发 GPU 内存溢出（OOM），最终导致 GPUDevice 丢失。
  2. GPU 掉死与 TDR（超时检测与恢复）：单帧内提交了过多或过重的渲染任务，导致 GPU 执行时间超过系统阈值（Windows 下通常为 2 秒），被操作系统判定为“显卡无响应”从而重置驱动，触发物理级别的 Context Lost。
  3. 帧率不均衡与渲染卡顿：缺乏优先级的排队机制，会导致关键看板（如用户当前交互的画布）与背景低频更新的画布争抢显卡计算资源。

为了解决这些痛点，我们需要在应用层设计一个全局 GPUCommandEncoder 调度器。本文将探讨其核心架构与具体的代码实现。

1. 核心架构设计

该调度器的核心思想是：收敛物理设备，隔离渲染任务，统一生命周期，控制执行并发。

+-------------------------------------------------------------+
|                     WebGPUScheduler                         |
|  +-------------------------------------------------------+  |
|  | Task Queue (Priority Queue)                           |  |
|  |  [Canvas1_Task (High)] -> [Canvas2_Task (Low)]        |  |
|  +-------------------------------------------------------+  |
|                           |                                 |
|                           v (Frame Tick / Backpressure Lock)|
|  +-------------------------------------------------------+  |
|  | Command Encoder Pool (Reusable & Limited Concurrency) |  |
|  +-------------------------------------------------------+  |
|                           |                                 |
|                           v (Batch Submit)                  |
|                      GPUDevice.queue                        |
+-------------------------------------------------------------+

1.1 单例物理设备与多 Canvas 绑定

禁止每个 Canvas 组件自己去 requestDevice。整个应用生命周期内，只存在一个全局的 GPUDevice。所有的 Canvas 通过 canvas.getContext('webgpu') 获取上下文后，统一向全局调度器注册。

1.2 渲染任务（Render Task）抽象

我们将每个 Canvas 的一帧渲染逻辑抽象为一个 RenderTask。它不直接操作 GPUDevice，而是接受调度器分配的 GPUCommandEncoder，完成指令录制后将控制权交还。

1.3 串行与并发限制（背压控制）

调度器利用 requestAnimationFrame (rAF) 驱动。在每一帧中，调度器根据当前的 GPU 负载、队列积压情况（通过 device.queue.onSubmittedWorkDone() 监测），动态决定本帧允许执行多少个 RenderTask。

2. 调度器核心实现

以下是用 TypeScript 实现的全局 WebGPU 调度器核心代码。它包含了任务队列、优先级管理、背压控制（Backpressure）以及设备丢失自愈机制。

type TaskPriority = 'high' | 'medium' | 'low';

interface RenderTask {
  id: string;
  priority: TaskPriority;
  // 核心执行回调，调度器为其分配当前的 encoder
  render: (device: GPUDevice, encoder: GPUCommandEncoder) => void;
  // 渲染完成后的回调（如用于计算帧率）
  onComplete?: () => void;
}

export class WebGPUScheduler {
  private device: GPUDevice;
  private taskQueue: RenderTask[] = [];
  private isProcessing = false;
  private activeEncodersCount = 0;
  
  // 限制单次 submit 承载的最大任务数，防止 TDR
  private readonly MAX_BATCH_SIZE = 4;
  // 限制同时处于 pending 状态的提交数（背压阀）
  private pendingSubmits = 0;
  private readonly MAX_PENDING_SUBMITS = 2;

  constructor(device: GPUDevice) {
    this.device = device;
    this.setupDeviceLossListener();
  }

  /**
   * 监听物理设备丢失，进行全局降级或重建
   */
  private setupDeviceLossListener() {
    this.device.lost.then((info) => {
      console.warn(`WebGPU Device lost: ${info.message}`, info.reason);
      this.isProcessing = false;
      this.taskQueue = [];
      if (info.reason !== 'destroyed') {
        // 在此处触发全局的重连与资源重建逻辑
        this.handleDeviceRestoration();
      }
    });
  }

  private handleDeviceRestoration() {
    // 实际生产中，这里需要通知上层应用重新获取 GPUDevice 并重建所有 GPUBuffer/GPUPipeline
    console.log('Initiating GPU device restoration pipeline...');
  }

  /**
   * 注册渲染任务
   */
  public addTask(task: RenderTask) {
    // 避免重复任务堆积
    const existingIndex = this.taskQueue.findIndex(t => t.id === task.id);
    if (existingIndex !== -1) {
      this.taskQueue[existingIndex] = task;
      return;
    }

    this.taskQueue.push(task);
    this.sortQueue();
    
    if (!this.isProcessing) {
      this.isProcessing = true;
      requestAnimationFrame(() => this.tick());
    }
  }

  /**
   * 按优先级排序：high > medium > low
   */
  private sortQueue() {
    const priorityMap: Record<TaskPriority, number> = { high: 3, medium: 2, low: 1 };
    this.taskQueue.sort((a, b) => priorityMap[b.priority] - priorityMap[a.priority]);
  }

  /**
   * 帧循环驱动
   */
  private async tick() {
    if (this.taskQueue.length === 0) {
      this.isProcessing = false;
      return;
    }

    // 背压控制：如果 GPU 积压了太多提交，延迟本帧的录制，防止阻塞主线程与 GPU
    if (this.pendingSubmits >= this.MAX_PENDING_SUBMITS) {
      requestAnimationFrame(() => this.tick());
      return;
    }

    const batch: RenderTask[] = [];
    const batchSize = Math.min(this.taskQueue.length, this.MAX_BATCH_SIZE);
    
    // 取出本批次要执行的任务
    for (let i = 0; i < batchSize; i++) {
      batch.push(this.taskQueue.shift()!);
    }

    if (batch.length > 0) {
      this.executeBatch(batch);
    }

    requestAnimationFrame(() => this.tick());
  }

  /**
   * 执行批次任务
   */
  private async executeBatch(tasks: RenderTask[]) {
    // 多个任务共享同一个 CommandEncoder，或者为每个任务创建，但统一 Submit
    // 这里采用单个 Encoder 承载整批任务，极大减少 Submit 的 CPU 交互开销
    const encoder = this.device.createCommandEncoder();
    this.activeEncodersCount++;

    for (const task of tasks) {
      try {
        // 执行用户的具体录制逻辑（如 beginRenderPass 等）
        task.render(this.device, encoder);
        if (task.onComplete) task.onComplete();
      } catch (err) {
        console.error(`Error executing RenderTask [${task.id}]:`, err);
        // 单个任务录制失败，不应影响后续任务，继续执行
      }
    }

    const commandBuffer = encoder.finish();
    this.activeEncodersCount--;

    // 提交到队列
    this.pendingSubmits++;
    this.device.queue.submit([commandBuffer]);

    // 监控 GPU 执行完成情况，释放背压计数
    this.device.queue.onSubmittedWorkDone().then(() => {
      this.pendingSubmits = Math.max(0, this.pendingSubmits - 1);
    });
  }
}

3. 在 Canvas 组件中接入调度器

有了全局调度器后，各个 Canvas 组件不再拥有自主更新视图的权力，而是作为“任务提供者”向调度器注册更新请求。

3.1 基础 Canvas 组件实现示例

export class CanvasViewer {
  private canvas: HTMLCanvasElement;
  private ctx: GPUCanvasContext;
  private scheduler: WebGPUScheduler;
  private id: string;

  constructor(canvas: HTMLCanvasElement, scheduler: WebGPUScheduler) {
    this.canvas = canvas;
    this.scheduler = scheduler;
    this.id = `canvas_${Math.random().toString(36).substr(2, 9)}`;
    
    const context = canvas.getContext('webgpu');
    if (!context) throw new Error('WebGPU not supported');
    this.ctx = context;
  }

  public configure(device: GPUDevice, format: GPUTextureFormat) {
    this.ctx.configure({
      device,
      format,
      alphaMode: 'opaque'
    });
  }

  /**
   * 触发视图更新。这里不直接写 render 逻辑，而是将其封装为 Task 提交给调度器
   */
  public requestUpdate(priority: TaskPriority = 'medium') {
    this.scheduler.addTask({
      id: this.id,
      priority: priority,
      render: (device, encoder) => {
        const currentTexture = this.ctx.getCurrentTexture();
        const renderPassDescriptor: GPURenderPassDescriptor = {
          colorAttachments: [{
            view: currentTexture.createView(),
            clearValue: { r: 0.1, g: 0.2, b: 0.3, a: 1.0 },
            loadOp: 'clear',
            storeOp: 'store'
          }]
        };

        const passEncoder = encoder.beginRenderPass(renderPassDescriptor);
        
        // 在这里执行你具体的绘制逻辑：setPipeline, setVertexBuffer, draw...
        // passEncoder.setPipeline(this.pipeline);
        // passEncoder.draw(3);

        passEncoder.end();
      }
    });
  }
}

4. 关键避坑与深度优化策略

仅仅完成了任务调度，在超多 Canvas 或者高动态场景下，还需要配合以下精细化内存与资源管理策略：

4.1 避免高频、重复的对象创建（GC 引起的丢帧）

在上面的 RenderTask 回调中，我们调用了 currentTexture.createView()。在 WebGPU 中，虽然 createView() 的开销远小于 WebGL 的 FBO 切换，但在高频渲染下，每一帧都为几十个 Canvas 创建 TextureView 会给垃圾回收（GC）带来极大压力。

  • 优化方案：在组件内部缓存 GPUTextureView，只有当 Canvas 尺寸发生改变、或者重新配置了 SwapChain（configure）时，才重新创建并缓存 TextureView。

4.2 统一复用 Uniform Buffer（大内存分配导致的 Context Lost）

若有数十个 Canvas 独立绘制，且每个 Canvas 的模型矩阵、投影矩阵各不相同。如果对每个 Canvas 都在帧循环中 createBuffer，不仅会耗尽 GPU 描述符数量，更会导致频繁的显存碎片整理，最终诱发物理级 Context Lost。

  • 优化方案：
    • 使用大缓冲区（Big UBO / Ring Buffer）。分配一个足够大的 GPUBuffer（如 4MB），利用 device.queue.writeBuffer 的 bufferOffset 参数，向该大内存的不同偏移量写入每个 Canvas 的独立数据。
    • 在 BindGroup 绑定时，使用带有 hasDynamicOffset: true 的 layout，通过动态偏移值在单次 DrawCall 中更新不同的 Canvas 状态。

4.3 显式管理组件销毁时的资源释放

当页面发生路由跳转、或者用户关闭某个配置弹窗时，对应的 Canvas 节点会被销毁。如果不手动释放绑定的 GPU 资源，显存并不会立刻被 V8 回收。

  • 优化方案：
    • 在 Canvas 组件的 onDestroy / unmount 生命周期中，显式调用 this.ctx.unconfigure()。
    • 同时，清除调度器中由于背压控制尚未执行完毕的挂起任务，防止无效渲染继续占用 GPU 带宽。

4.4 渲染超时防御（TDR Guard）

对于用户自定义着色器或特别复杂的 3D 场景，我们在任务调度器中可以加入**时间戳查询（Timestamp Query）**机制。

  • 在执行批次任务前后植入 writeTimestamp。
  • 如果监测到某一个 RenderTask 的 GPU 耗时连续数帧超过 16ms（或者总执行时间过长），调度器应当主动将其“降级”——例如限制其渲染分辨率、强制降低其帧率（如隔帧渲染），或者暂停其自动更新，以此保护整个浏览器的显卡上下文不被操作系统强行杀掉。

5. 总结

WebGPU 的底层设计给予了前端开发者操纵 GPU 硬件的极高自由度，但也将资源的管控责任交到了我们手中。在多 WebCanvas 的复杂场景下，不要依赖浏览器的默认行为。设计一个精简、可控、具备背压控制与自愈能力的全局 GPUCommandEncoder 调度器，是构建工业级 Web 端图形/可视化应用的核心基石。

极客视界 WebGPU图形学前端架构

评论点评