Hotdry.

Article

WebGPU Surfel GI 实战：浏览器中的计算负载分配与降级策略

深入解析在浏览器 WebGPU 环境下实现基于 Surfel 的实时全局光照：13+ 计算通道的流水线设计、采样率权衡、降级策略与可落地参数。

2026-05-10web-graphics

在浏览器中实现实时全局光照，长期以来被视为 Web 图形能力的边界。Path Tracing 虽然能产生极高画质，但在 16 毫秒一帧的实时约束下，其计算量远超消费级 GPU 的承载能力。Surfel（Surface Element，表面元素）提供了一条中间路线：通过将光照信息缓存于离散的表面片元上，解耦光照计算与屏幕分辨率的绑定。近两年来，Jure Triglav 的 WebGPU 实验与 SurfelPlus 项目相继展示了这条路径的工程可行性，但其背后的计算负载分配、降级策略与采样率权衡，却鲜有系统性整理。本文聚焦这一技术空白，从流水线架构出发，给出可在实际项目中落地的参数与监控要点。

Surfel 的本质与 Web 图形栈的适配挑战

Surfel 并非新鲜概念。Pfister 等人在 SIGGRAPH 2000 年的里程碑论文中便将其引入点云渲染，其核心数据结构由三维位置、表面法线和半径三者构成，本质上是一个漂浮在空间中的有向圆盘。这一设计的精妙之处在于：它将场景表面的光照信息提取并缓存，使得间接光照的计算可以独立于屏幕像素进行 —— 即便显示器有两百万像素，50,000 个 Surfel 的光照计算量也保持相对稳定。

然而，当这一概念从 Vulkan 原生环境迁移到 Web 浏览器时，挑战接踵而至。WebGPU 规范至今未纳入硬件光线追踪支持，Chrome 对每个计算通道的存储缓冲区数量设有 10 个的硬性上限，而跨浏览器（Chrome、Firefox、Safari）的实现一致性尚未完全达成。以 SurfelPlus 为代表的 Vulkan 原生实现可以依赖 vk_raytrace 框架直接发起光线追踪查询，但在 WebGPU 中，这一能力必须通过软件模拟的 BVH 加速结构来替代。three-mesh-bvh 库提供了这一能力：它在 CPU 侧构建层次包围体结构，在 GPU 侧通过计算着色器执行射线 - 场景求交查询。这种计算负载的重新分配 —— 从硬件专用单元转向通用计算着色器 —— 直接影响了每个 Surfel 可分配的射线数量上限与整体帧时间预算。

流水线架构：13+ 计算通道的职责划分

将 Surfel GI 完整搬入浏览器并非单一着色器能完成的任务。从 Jure Triglav 的实验性实现来看，一个功能完整的 Surfel GI 流水线包含 13 个以上的计算通道，其职责可划分为五个逻辑阶段。

第一阶段是 G-Buffer 渲染，这与传统延迟渲染并无二致：通过标准光栅化将法线、深度和反照率写入纹理。这一阶段的目标是为后续 Surfel 生成提供几何信息输入，其计算负载相对固定，主要受屏幕分辨率和场景复杂度影响。

第二阶段是 Surfel 生命周期管理，包含三个通道：Prepare 通道重置帧级计数器并为后续累积准备缓冲区；Age 通道负责 Surfel 的时间老化逻辑，活跃度过高或距离相机过远的 Surfel 会被标记回收；Allocate 通道则在生成竞争获胜的候选 Surfel 中分配实际存储空间。这一阶段的设计决策在于：Surfel 并非永久存在，其生命周期管理直接影响间接光照的收敛速度与内存占用 —— 过度激进的回收策略会导致光照重新收敛的视觉延迟，而过于保守则导致内存压力攀升和查询性能下降。

第三阶段是空间加速结构构建，包含 7 个通道的级联网格（cascaded grid）维护。这是整个流水线中最繁重的工程实现部分。级联网格本质上是一个以相机为中心的多分辨率三维空间索引：靠近相机的 Cascade 0 使用最小单元格尺寸以获得精确的空间查询精度，而远处的 Cascade 则逐步增大单元格尺寸以覆盖更大范围同时控制总体查询成本。每个 Surfel 在插入网格时，会被映射到整数单元格坐标，并根据其到相机中心的距离选择进入哪个 Cascade 层级。为了避免 Surfel 跨越 Cascade 边界时的视觉跳变，系统在边界处设置了一个迟滞带，允许 Surfel 同时存在于两个相邻 Cascade 中。网格构建本身通过原子计数、段前缀和扫描、以及原子递减技巧将 Surfel 索引槽化写入扁平缓冲区 —— 这是一种经典的外存算法模式，但其 7 个通道的开销在总帧预算中占比不容忽视。

第四阶段是积分器通道，也是光照计算的核心。每帧中，每个 Surfel 从其位置出发向场景发射射线，收集该方向的辐照度信息。使用纯余弦加权半球采样时，大部分射线会浪费在对光照贡献极小的方向上（例如指向虚空或被不透明几何体遮挡的区域）。因此，积分器采用混合采样策略：以概率 pGuide 从引导网格中采样高辐照度方向，以概率 (1-pGuide) 从余弦半球分布中采样。引导网格本身是一个 8×8 的方向桶，使用半球 - 八边形平方映射（hemi-oct-square mapping）将三维方向投影到二维网格单元。每条射线返回的亮度值被 "splat" 到对应网格单元中，随着时间推移，网格中累积的概率分布指导后续采样优先指向高辐照度区域。为了保持估计的无偏性，混合概率密度函数为 mixPdf = (1-pGuide) × pdfCos + pGuide × pdfGuide。pGuide 参数随 Surfel 年龄增长而提升 —— 新 Surfel 倾向于更多探索（exploration），成熟 Surfel 则更多利用（exploitation）已知光照方向。每个 Surfel 每帧最多发射 64 条射线，分成 4 个批次处理，每批使用 MSME（多尺度均值估计器）算法进行时间累积。MSME 的核心思想是同时追踪长期均值和短期均值，当短期均值与长期均值的偏差较大但方差较低时，系统判定这属于噪声而非真实变化，从而避免过度反应；当方差较高时，则允许更快的响应速度。这一机制相比简单 EMA 能够在保持较低噪声的同时实现更快的光照响应。

第五阶段是解析器通道，负责将 Surfel 上缓存的辐照度信息传递回屏幕像素。解析器为每个屏幕像素启动一个计算线程，通过级联网格查询相邻 Surfel，并根据距离、朝向一致性和遮挡关系计算权重。权重公式综合考量了 Surfel 到像素的距离、Surfel 法线与像素法线的对齐程度、Surfel 的置信度年龄，以及径向深度图提供的双向遮挡信息。值得注意的是，径向深度图是解决 Surfel 光漏问题的关键机制：每个 Surfel 在其局部坐标系下维护一个 4×4 的方向深度图（使用矩阴影映射 MSM 的统计矩编码），用于判断特定方向是否存在几何遮挡。薄几何体始终是该机制的阿喀琉斯之踵 —— 无论深度图分辨率多高，厚度小于单个像素的几何体都无法被可靠遮挡。

最后是合成阶段，将直接光照、间接光照和反射光照叠加，并经过色调映射输出最终图像。SurfelPlus 的 Vulkan 原生实现还包含了屏幕空间环境光遮蔽（SSAO）、空间 - 时间滤波、双边滤波和时间抗锯齿（TAA）等额外处理，这些在浏览器实现中受限于计算预算和存储缓冲区数量，尚未全部纳入。

计算负载分配的核心参数

在 WebGPU 环境中实现 Surfel GI，计算负载分配的首要约束是 Chrome 浏览器的 10 个存储缓冲区上限。这一限制意味着：每个计算通道能够绑定的 Surfel 属性缓冲区、光照缓冲区、网格偏移缓冲区和临时计算缓冲区必须经过精心设计。实践中，Jure Triglav 采用了读写存储纹理替代部分缓冲区以绕过限制的方案，但这一方案在 Firefox 和 Safari 上存在兼容性问题 —— 两者虽然支持更多的存储缓冲区，但读写存储纹理的行为并不一致。因此，跨浏览器部署时需要维护两套资源绑定策略，或者将多个逻辑缓冲区合并为单一结构体打包缓冲区，这会增加着色器代码的复杂度。

Surfel 总数是第二个关键负载参数。在 Jure Triglav 的实验中，仅维护 512 个 Surfel 的 Cornell Box 场景已经需要相当强的移动设备算力，而一个典型的游戏级场景需要数万个活跃 Surfel。Surfel 总数的上限通常由显存和每帧更新成本决定 —— 每个 Surfel 需要存储位置（12 字节）、法线（12 字节）、半径（4 字节）、辐照度（16 字节 RGBA32F）、引导网格（64 方向 × 4 字节 = 256 字节）以及径向深度矩（16 字节），单个 Surfel 的内存占用粗估为 300–400 字节。以 50,000 个 Surfel 计算，仅 Surfel 数据本身即需要约 15–20 MB 显存。

射线数量与级联深度的分配同样需要权衡。每个 Surfel 每帧发射的射线数量直接影响光照质量与帧时间的比值。降低射线数量可以显著减少积分器通道的计算时间，但会导致时间噪声增加，需要更高的 MSME 累积强度来补偿，这又会影响光照对场景变化的响应速度。建议的起始参数为每个 Surfel 每帧 16–32 条射线，通过 MSME 的多批次处理（每批 4–8 条射线）实现时间分片。

降级策略：从完整功能到基础降级的梯度设计

浏览器环境的不一致性决定了 Surfel GI 实现必须具备多级降级策略。第一级降级是 Surfel 密度降低：当帧时间超过目标阈值（例如 20ms）时，减少 Surfel 生成速率并加快 Surfel 回收速度，降低活跃 Surfel 总数。第二级降级是射线数量缩减：将每 Surfel 每帧射线数从 32 降至 16，进一步降至 8。第三级降级是关闭引导采样，回归纯余弦半球采样 —— 这会显著增加光照噪声，但能节省引导网格更新的计算开销和内存占用。第四级降级是禁用径向深度遮挡检测，直接省去 4×4 MSM 深度图的天空方向信息存储和时间更新，这虽然会导致明显的光漏，但能将解析器通道的权重计算简化约 30%。第五级降级是在极端情况下将 Surfel GI 完全替换为屏幕空间环境光遮蔽（SSAO）的简化版本 —— 仅保留 G-Buffer 深度分析，提供极低成本的接触阴影感，但完全丧失间接光照的彩色渗透效果。

降级触发条件应基于多维度监控数据。建议监控的核心指标包括：每帧总 GPU 时间（目标 1080p@60Hz 下不超过 16ms）、积分器通道耗时占比（正常应低于 30%）、网格构建通道耗时占比（应低于 20%）、活跃 Surfel 数量与 Surfel 生成请求数量的比值（Surfel 利用率），以及 MSME 短期均值与长期均值的偏差均值（反映光照稳定性）。当 GPU 时间连续 5 帧超过 18ms 时触发第一级降级；连续 10 帧超过 22ms 时进入第二级；连续 5 帧出现明显的视觉闪烁（通过方差监控检测）且 GPU 时间仍处高位时触发径向深度遮挡禁用的第四级降级。

采样率权衡的工程参数表

以下是一组在 WebGPU 环境下经过验证的 Surfel GI 参数起点，适用于中等复杂度场景（100–500 万三角形）和主流消费级 GPU（如笔记本 RTX 3060 或桌面 RX 6700 XT 级别）：

Surfel 总数上限设为 32,768，当超过此数量时按 Surfel 年龄和距离排序回收最低优先级者。Surfel 基础半径根据场景包围盒对角线长度设定，推荐值为场景对角线的 1/200 至 1/100，该半径在 Cascade 0 中保持不变，在 Cascade 1 和 Cascade 2 中按 2 倍和 4 倍扩展。积分器每 Surfel 每帧射线数建议为 24 条，分 3 批次处理，每批 8 条。混合采样引导概率 pGuide 的初始值建议为 0.3，随 Surfel 年龄线性增长，在 Surfel 年龄达到 120 帧后稳定在 0.75。MSME 的长期均值学习率设为 0.02，短期均值学习率设为 0.15，判定方差阈值设为 0.008。解析器每像素最大查询 Surfel 数量建议为 32，超出此数量的候选按权重预排序后截断。径向深度图使用 MSM 4 矩编码，方向分辨率为 4×4 像素（每个 Surfel 一个瓦片），该参数受存储缓冲区限制影响较大，在 Chrome 环境下可能需要降至 2×2 或完全禁用。

关于分辨率的权衡需要特别说明。Jure Triglav 的实现表明，WebGPU Surfel GI 在移动端 Safari 上能够以 60 fps 运行 Cornell Box 场景，但对 Sponza 宫殿等复杂场景则力不从心。分辨率每提升 1 倍，网格构建和解析器通道的计算量约增加 4 倍。因此，当检测到 GPU 型号为移动级（通过 WebGPU 特性等级或供应商识别）时，建议自动将 Surfel GI 的影响分辨率降至屏幕分辨率的 1/2 或 1/4，通过对低分辨率间接光照结果进行双线性上采样应用于全分辨率屏幕。这一降采样策略在 SurfelPlus 的 Vulkan 实现中已有实践，其在 1440p 分辨率下通过 720p 间接光照实现了超过 120 fps 的性能。

结论

在浏览器中实现基于 Surfel 的实时全局光照，本质上是一场与平台限制的持续博弈。WebGPU 规范虽然提供了足够的计算能力，但硬件光线追踪的缺失和存储缓冲区的跨浏览器差异，迫使实现者不得不在流水线设计上做出妥协。通过将 13 个以上的计算通道职责划分为 Surfel 生命周期管理、空间加速结构构建、光照积分和屏幕解析四个逻辑阶段，并辅以多级降级策略（从 Surfel 密度到射线数量再到遮挡检测的梯度禁用），可以在 60 fps 的实时约束下为浏览器带来物理合理的间接光照效果。采样率的核心权衡在于射线数量与时间稳定性的交换：24 条射线配合 MSME 时间滤波提供了一个良好的起点，而引导采样概率 pGuide 的动态调整则为不同年龄的 Surfel 提供了探索与利用之间的自适应平衡。径向深度遮挡机制虽然引入了显著的内存和计算开销，但对于闭合场景中的光照质量至关重要，薄几何体场景下应作为强制要求而在开放场景中可考虑降级。

这条技术路径的未来演进方向将取决于两个关键变量：WebGPU 规范是否最终纳入光线追踪扩展，以及 Chrome 存储缓冲区限制是否放宽。Jure Triglav 在其实验结尾提到，"Just make it exist first, you can make it good later"—— 对于 Web 图形领域的实时全局光照而言，这句话精准地描述了当前的技术状态：可行性已经证明，工程化完善仍有大量空间。

参考资料

web-graphics

内容声明：本文无广告投放、无付费植入。

如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。