3D Gaussian Splatting分块渲染：让百万级高斯实时跑起来的核心工程

提到3D Gaussian Splatting很多人第一反应是“那个效果惊艳的NeRF接班人”但真正让它在消费级显卡上实时跑起来的其实是背后那套非常务实的渲染工程。这个系列叫3D Gaussian之前聊过数据表示和场景初始化这次进入第三篇专门拆一个最容易被忽略、却决定了帧率的核心功能分块渲染。这里说的分块不是算法比赛里那种为了并行而做的简单切分而是一套完整的“屏幕Tile化数据流”从3D高斯投影、建立Tile索引、块内排序到最终逐像素合成每一步都在为“局部性”服务。本文不打算只讲口号会把每个环节的原理、工程取舍、以及我踩过的坑都摆出来希望能给正在读源码或准备复现的朋友一点参考。1. 为什么3D Gaussian绘制非要“分块”不可1.1 直接逐像素算为什么算不动先看最朴素的渲染思路场景里有N个3D高斯屏幕上有M个像素。对每个像素遍历所有N个高斯计算投影后的贡献并合成颜色。这个复杂度是O(N×M)。一个中等规模的场景高斯数量大概在50万到200万之间1080p屏幕有约200万个像素两者相乘就是10的12次方量级的操作。即便每个高斯只做一次简单的指数计算这个数量也足够让显卡瞬间卡成PPT。有人会说每个高斯投影后只覆盖一小块区域可以提前裁剪。确实3D高斯是带协方差矩阵的椭球经过透视投影后在图像空间也是一个椭球而且几乎所有实现都会用3σ截断来定义有效覆盖区域。这就是局部性的来源。但如果不在架构层面把这个局部性利用起来单纯靠逐像素循环里加if判断性能依然不行。因为GPU的并行方式是SIMT不同像素执行不同的分支warp divergence会严重拖低吞吐而每个高斯的数据也要反复从内存搬进搬出。1.2 16x16的Tile把渲染从“全局”变成“本地”于是就有了分块渲染Tile-based Rendering。做法很直接把屏幕划分成一组不重叠的小方块tile每个tile大小通常是16×16像素。对每个3D高斯计算它投影后覆盖的屏幕范围找到它与哪些tile相交然后把它的索引塞进这些tile维护的列表中。渲染某个像素时只遍历这个像素所在tile的高斯列表而不是全场高斯。这个思路在日常配送里很容易理解你不是让每个快递员把全市所有包裹都送到每个小区而是先按小区分拣再由对应几个快递员派送。3D Gaussian渲染也一样每个tile相当于一个小区高斯列表就是这个小区的包裹清单。于是像素和像素之间不再因为遍历不同数量、不同身份的高斯而互相拖累每个像素只关心自己所在tile内的那几十个高斯。1.3 分而治之的思路和分块矩阵求逆很像如果你学过线性代数里的分块矩阵应该会觉得这很眼熟。分块矩阵求逆不是直接对整个大矩阵做一次求逆而是把矩阵切成子块先在子块内部做分解再处理子块之间的耦合好处是子块运算可以独立并行且能利用“大部分子块对最终结果影响有限”这一局部性。3D Gaussian里的分块渲染在精神上是同一类思路屏幕空间被切成tile每个tile内部只处理与它重叠的高斯块与块之间的耦合通过“高斯会跨tile”这一事实来兜底——一个大高斯可以同时出现在若干tile的列表中但这不影响每个tile独立执行排序和合成。这种局部性抽象让我们可以把原本全局的O(N×M)问题拆解成一组规模很小的独立问题。2. 分块渲染的完整数据流水线2.1 投影把3D高斯变成屏幕上的椭圆分块渲染的第一步是把世界空间里的3D高斯投影到屏幕空间。每个3D高斯通常用均值μ和协方差矩阵Σ描述。要把它渲染成图像需要经过视图变换和透视投影。协方差矩阵的变换不是简单的“乘以旋转矩阵”就行因为透视投影是非线性变换需要一个雅可比矩阵来近似局部线性化。具体来说屏幕空间的协方差矩阵可以写成Σ J W Σ W^T J^T其中W是视图变换矩阵J是投影变换的雅可比矩阵。这一步通常在一个CUDA kernel里完成每个线程处理一个高斯并行度非常高。投影完成后每个高斯就有了屏幕空间的位置、尺度、旋转角度以及一个“可见性”标志——如果它在视锥体外面或者深度异常就标记为不可见。2.2 Binning决定每个高斯属于哪些块投影之后要做的事情叫Binning为每个可见高斯计算它在屏幕上的包围盒根据包围盒找到它覆盖的tile集合再把高斯ID写入这些tile对应的列表。注意一个高斯通常会覆盖多个tile尤其当高斯尺寸很大、覆盖半屏的时候。所以同一个高斯ID会出现在很多tile的列表里这是设计层面的冗余也是局部性和索引开销之间的交换。实现时这一步要非常小心并发写入。多个线程可能同时往同一个tile的列表里写数据所以一般会先为每个tile统计收到的高斯数量再用前缀和算好写入偏移最后按偏移写入避免用锁或者原子操作反复竞争。有的实现甚至会用两轮循环第一轮只统计第二轮再把数据写入扁平数组。这种“分桶”过程其实是整个渲染管线里最容易被低估的一步因为它的内存访问模式是散乱的直接决定后续所有阶段的缓存命中率。2.3 块内排序与合成真正的渲染发生在这里有了每个tile的高斯列表接下来要做的是按深度排序。绝大多数实现会为每个tile内的高斯按深度从小到大排序也就是从近到远。为什么排序重要因为最终合成是一个顺序相关的alpha混合过程。一个像素的最终颜色是所有覆盖它的高斯在这个像素上按深度从近到远的累加C Σ_i c_i α_i Π_{j1}^{i-1} (1 - α_j)其中c_i是第i个高斯的颜色α_i是由2D高斯覆盖率和该点不透明度共同决定的alpha值。因为每个tile都有自己的独立列表排序可以在tile级别并行做而不需要对全场景的高斯做一次全局排序。全局排序的长度动辄百万而tile内的列表长度通常在几到几百之间排序成本小了好几个数量级。这里有个容易被忽略的细节排序的key并不只是深度值本身。深度值由世界坐标经透视除法得到浮点精度有限如果两个高斯的深度值非常接近排序结果就不稳定。后面我会单独讲这个坑。总之渲染kernel会在每个像素上遍历自己所在tile的高斯列表取出预排序好的高斯属性计算2D高斯在该像素位置的覆盖率和颜色然后不断累积合成。3. 分块方案背后的工程取舍与并行优化3.1 为什么Tile尺寸默认是16×16而不是8×8或32×32分块渲染里最核心的超参数就是tile尺寸目前论文和主流开源实现几乎清一色选16×16。这不是随便定的。tile越小局部性越强每个像素需要遍历的高斯越少但tile总数会变多每个高斯的重复写入次数也会相应增加Binning阶段的索引开销会变大。tile越大一个block能覆盖的像素更多但tile内的高斯列表会更长排序和alpha合成的串行部分会变重。16×16恰好落在了一个非常平衡的位置。它对应CUDA线程块中256个线程正好是8个warp和GPU调度单元天然对齐16也是个比较“整”的数让屏幕坐标到tile坐标的除法变成移位操作省一点指令开销。我实际测过8×8和32×328×8时Binning开销肉眼可见地变多32×32时排序阶段的时间占比明显上升。所以除非你明确知道自己场景的Gaussian分布特征否则先别改这个参数。3.2 渲染kernel和CUDA线程块的映射关系分块渲染在CUDA里的映射很有讲究。第一阶段的投影kernel每个线程处理一个高斯第二阶段Binning通常每个block处理若干个tile第三阶段渲染kernel可以是每个像素一个线程也可以是每个tile的block先做块内排序再按像素取数据。其中一个常见做法是每个线程块对应一个tile线程块内有256个线程每个线程负责16×16 tile里的一个像素。渲染线程遍历的列表正是前面Binning阶段给这个tile生成的。一个block里的所有线程共享同一个高斯列表这天然拿到了极高的“列表复用率”。如果换成逐像素全局遍历缓存里装的全是别的像素需要的高斯带宽浪费会非常严重。这里我特别想提一点不要试图在一个block里一次性装载tile内所有高斯的所有属性因为一个tile内的可见高斯数量是不固定的有时甚至能超过1000个。更稳的做法是循环分批读取或者把属性按“预排序后的索引”紧凑存放在全局内存让block内的线程以协同方式去读取。3.3 内存带宽与中间缓冲区的平衡分块渲染的中间产物很多每个高斯的投影参数、每个tile的高斯ID列表、排序后的key-value数组、每个像素的累计颜色和透明度。这些数据如果不控制好带宽压力比计算压力还大。实际工程里常用这么几个手段一是把不那么关键的属性位置、颜色、旋转压成half或低比特类型二是不要在每个tile里重复存储完整的高斯副本而是只存高斯ID属性统一查全局表三是利用共享内存做块内的索引缓存。还有一点Binning出来的列表如果直接用全局内存散落的写入很容易造成缓存颠簸。很多实现会先用共享内存累积当前block负责的tile列表块处理完后再刷回全局内存。这样虽然增加了一点代码复杂度但能显著降低原子操作的数量。复现的时候可以留意一下profiler里local memory和atomic操作的比例往往能看出实现是不是健康。4. 我在复现过程中踩过的几个坑4.1 排序不稳定导致的重影问题先说最折磨人的一个问题画面闪烁。我在刚开始实现分块渲染时渲染出来的每一帧边缘都会出现类似毛发一样的重影画面稍微转动就疯狂闪烁。第一反应是投影算错了查了半天才发现是排序不稳定。原因其实很简单两个高斯在同一个像素上的投影覆盖区域可能有很大重叠深度差异又只有小数点后几位。如果排序的key只用了float深度它们的相对顺序会随着相机小幅移动而翻转而alpha混合又对顺序极度敏感顺序一翻结果自然跳变。解决方法是让排序key带上高斯的唯一ID作为次级比较键深度相同或接近时按ID排序保证一次渲染内的顺序稳定。这也解释了为什么源码里排序key经常是64位的——高32位存深度低32位存ID。4.2 半精度精度不足导致远近穿插第二个坑和精度有关。为了省显存我把一部分属性压成了half精度结果在远景和近景交界的地方经常出现“穿帮”远处的山体偶尔会突然跑到近处建筑前面。调试时发现是深度精度不足把一个很大的深度值存成half后相邻级别之间的间隔可能达到好几米排序时几个远处的高斯深度完全分不出先后。排查时我把半精度改成float重新跑问题消失了。后来换了一种更聪明的量化方式不是对原始深度做half而是对逆深度1/z做half。逆深度在透视投影后是线性分布的相邻级别对应的实际深度变化也更接近视觉感知。这样既能保精度又能继续享受半精度带来的带宽收益。如果你不想大动数据结构至少也应该在排序阶段把深度值还原成float而不是直接拿half值排序。4.3 如何在真机上定位“少了哪块”的问题还有一种很隐蔽的Bug画面里某个区域突然出现空洞或者整块内容消失。这种问题通常不是算法错而是数据被“丢”了。最典型的原因是tile列表容量不足。有的早期实现会给每个tile预设一个最大高斯数量超出就直接截断超出的高斯不参与渲染。当场景中有很大的高斯或者多视角合并导致局部密度很高时列表很容易打满于是出现空洞。定位这种问题我会写一个调试kernel对每个tile统计实际高斯数量输出成一张热力图。看到某个区域的热力值顶到了上限就能立刻判断是不是被截断了。还有一招是把tile边界可视化——把tile的边界线画成亮色如果空洞恰好出现在某个tile内部说明是这个tile的列表有问题如果空洞沿tile边界扩散说明可能是Binning阶段边界判定出错。5. 分块渲染的调参经验与现实边界5.1 什么时候改tile size有收益虽然默认16×16但并不意味着任何场景都不该动它。如果你的场景是无人机扫描出来的建筑工地点云很密、高斯碎片很多8×8的tile往往能让排序更轻因为每个tile里的高斯数会明显减少代价是Binning阶段的原子操作变多。反过来如果你的场景大部分是大尺度的天空、背景板这类“大型高斯”32×32反而能减少列表写入次数缓解Binning瓶颈。判断依据不是感觉而是profiler。把投影、Binning、排序、渲染四个阶段的时间单独拆出来看哪一段占比最高。如果排序占20%以上试试缩小tile如果Binning占20%以上试试增大tile。我遇到的大部分项目瓶颈最终都落在Binning和合成阶段而不是投影。5.2 和密度控制配合分块渲染的效率和场景里高斯的“块大小分布”关系很大。如果所有高斯都是小碎块那么每个tile的列表都不会太长局部性极佳如果存在一批特别大的高斯它们会污染大量tile的列表导致很多tile必须遍历一个很长的列表但其中大部分贡献几乎为0。这也是为什么很多训练流程里会做“密度控制”把覆盖范围超过一定阈值的大高斯分裂成若干小高斯。在接入分块渲染管线之前我建议先做一遍高斯压缩/剪枝把那些贡献小、方差大的高斯删掉或者分裂掉。实测下来一次合理的密度控制能让最终渲染帧率提升30%以上而且画质几乎不受影响。这不是分块渲染本身的问题而是分块渲染会把“高斯分布不健康”这个问题放大给你看。5.3 分块不是银弹小场景里的逆向选择最后说点可能反直觉的结论场景如果只有几千个高斯分块渲染反而可能是负优化。因为Binning和排序都是有固定开销的哪怕每个tile里只有两三个高斯也要走一遍统计、写索引、排序的过程。这种情况下传统的前向渲染直接遍历所有高斯画椭球更快代码也更简单。我自己做过一个自动开关当场景可见高斯数低于某个阈值时退回逐高斯光栅化高于阈值时才启用分块渲染。这个阈值在不同硬件上不太一样一般在2万到5万之间。所以如果你只是在一个小场景里做实验没必要强行套分块框架真正让它发挥价值的是那种几十万、上百万高斯的大场景那一刻你才会发现分块不只是一个优化技巧而是让实时渲染成为可能的支柱。回头再看整个分块渲染链路最值得记住的其实就一句话它没有用什么复杂数学而是老老实实把“局部性”写到了每一步流程里。项目写到这里我自己复现时最大的体会是这种工程里的取舍通常比算法本身更影响最终效果。希望这篇能把分块渲染的门道讲清楚如果后面有时间我打算再写写排序那部分的极致优化。