阿尔托大学与诺基亚高斯泼溅渲染新作：TileGS栅格核心加速1.44倍

龙哥导读

TileGS没有删高斯、没有改表示、没有换掉透明度合成公式，却把 RTX 4090 上的栅格核心平均提速到 1.439 倍。最反常识的是：它更快时，DRAM 流量反而增加 35.8%，占用率和 SM 吞吐也更低。真正被优化的不是“搬了多少数据”，而是每个像素为了走到提前终止，究竟绕了多少路。

3D Gaussian Splatting 已经把新视角渲染推到实时，但“实时”不等于流水线里没有硬骨头。一个画面里，高斯越密、覆盖同一像素的透明层越多，栅格核心就越像在一条很长的队伍里逐个验票：即使最后几百个候选根本不会改变像素，它也可能先走到那里才知道。

TileGS抓住的就是这段被忽略的执行顺序。它把每个 tile 的长队伍拆成按深度排列的小段，让近处贡献先发生、像素更早达到透明度终止条件，再只对容易排错的局部做精确修复。不是模型更小，也不是画质换速度，而是同一批工作被安排得更聪明。

图1｜依据论文 Table 5 与 Table 6 重绘。绿色是两张 Ada GPU 上的端到端加速，橙色是 RTX 4090 栅格核心加速。九个场景端到端均有改善；核心加速更大，说明新增的分桶与修复开销吃掉了部分收益。数据来源：TileGS，CC BY 4.0。

01 同样是 tile-based，为什么还不够“局部”

标准 3DGS 会先把三维高斯投影到屏幕，计算每个高斯覆盖哪些图像 tile，再为每个“高斯—tile”交点生成记录。随后，系统把这些记录按 tile 和深度组成一个全局排序流；每个 CUDA block 负责一个 tile，并沿属于自己的连续区间从前到后做 alpha compositing。

问题在于，“一个 block 负责一个 tile”只是所有权局部，消费工作的方式仍受全局流组织。一个 tile 可能拿到很长的候选区间，而相邻线程读取的几何属性来自相距很远的索引，形成不规则的长遍历。

常见直觉会让人先去改数据布局、压缩属性，或追求更整齐的访存。TileGS换了一个问题：既然静态候选数量暂时不变，能否改变候选被消费的粒度，让动态执行少走一些无效迭代？这就是论文所谓 execution structure——不只关心数据放在哪，也关心一段工作如何被切开、排序和提前结束。

图2｜论文 Figure 1。上方基线把 tile-depth 交点放入全局排序流，每个 tile 消费一段长区间；下方 TileGS 依次估计深度范围、分配局部 depth bin、计数与 scatter、做前缀和并构造 tile-bin-major 流，最后按近到远遍历。两条路线输入同一批投影高斯，差别在执行组织。来源：论文，CC BY 4.0。

02 第一步：先找一个不被极端深度拖坏的范围

分桶之前先要回答：当前帧的“近”和“远”到底在哪。直接拿最小值与最大值归一化看似简单，却容易被极少数离群高斯撑开范围。结果是大量 bin 浪费在几乎没有可见贡献的深度上，真正拥挤的区域反而分得不够细。

TileGS从可见投影深度里最多采样 8192 个候选，用精确顺序统计取第 1 与第 99 百分位，再给截断区间增加 5% padding。设裁剪后的范围为 [zmin, zmax]，每个高斯深度 z 先被限制在该区间，再映射到 K 个粗粒度 bin。

默认不是线性分桶，而是 log-depth mapping。近相机的高斯往往投影更大、重叠更强、透明度顺序也更敏感，因此近端需要更多分辨率。log 分桶把有限的 64 个 bin 更密地分给近景，不是为了改变几何，而是为了减少最容易出错、也最可能决定提前终止的深度混杂。

b 是 bin 编号，K 默认取 64，z 是投影后的深度。这里的公式强调计算顺序：先做稳健区间裁剪，再做对数映射与归一化，最后离散到整数 bin。它只是粗排工具，不能保证同一个 bin 内严格按深度有序，所以后面必须有 repair。

03 第二步：把长流改造成 tile-bin-major 的连续布局

每条高斯—tile 记录现在多了一个组合键 (tile_id, bin_id)。构造过程分四步：先统计每个 tile/bin 有多少条记录；再对计数做 exclusive scan，得到每个 bin 的起止偏移；接着把 Gaussian ID scatter 到对应区间；最后按 tile 优先、bin 从近到远的顺序形成扁平流。

这里有个容易误读的细节：默认 raster kernel 并不是走完一个 bin 就退出、再启动下一个 bin。所有 bin 在内存里仍然首尾相接，同一个 tile 的 block 继续线性走一个大连续区间。区别是这个区间已经被组织成短的 depth-local 子区间，bin 边界则为局部排序修复提供了天然切口。

图3｜论文 Figure 2。左侧记录先获得 tile/bin 键，中间统计各 bin 数量并用 exclusive scan 生成偏移，右侧 scatter 为连续区间。箭头表达的是地址构造，不是删掉高斯；TileGS改变分组和顺序，静态高斯—tile 记录总数不变。来源：论文，CC BY 4.0。

五种 count/scatter 实现输出相同。最终 direct atomics 成为默认；复杂聚合并不自动更快，同步也要计入成本。

04 第三步：粗排之后，只修真正危险的局部

透明度合成对前后顺序敏感。同一个粗 bin 内的两个高斯，或者靠近 bin 边界的高斯，仍可能因为局部次序不精确而改变颜色。把所有 bin 全部精排最稳，却会重新付出大笔排序成本；完全不修最快，但实验显示最大 PSNR 误差会达到 2.0346 dB。

TileGS把每个 tile/bin slice 当作 repair candidate，长度记为 ℓ，父 tile 总长度记为 ℓtile。ℓ≤1 无需修复；其余段按 2—128、129—256、257—512 与大于 512 分桶，并在短桶内部使用固定尺寸 bitonic sort。是否保留修复，则看段长、占 tile 比例和它是否位于最靠近相机的两个 bin。

五条规则中，ℓ≥320 的长段直接修；ℓ>512 的 tail 段强制修；某段占父 tile 至少 45% 时修；129—256 长度且占比至少 10% 时修；bin 0 或 1 中长度至少 16 的近景段也修。全局修复预算为总记录数 M 的 25%。这些规则的共同逻辑是：把精确排序预算集中到“长、占比高、离镜头近”的片段。

图4｜论文 Figure 3。左侧生成 tile/bin repair candidate，中间按长度落入本地或全局桶，再叠加段长、tile 占比和近景优先规则，最后受全局预算约束。图中选择规则恢复的是局部前后顺序，不会改变 alpha compositing 公式。来源：论文，CC BY 4.0。

输入：投影高斯 G、tile 交点 E、深度 bin 数 K=64
估计稳健深度范围：z_min=P1(sample(z)), z_max=P99(sample(z))
for each (gaussian, tile) in E:
    bin = log_depth_bin(z, z_min, z_max, K)
    count[tile, bin] += 1
offset = exclusive_scan(count)
scatter E into a tile-bin-major Gaussian-ID stream

for each tile/bin segment s:
    risky = len(s) >= 320
         OR len(s) > 512
         OR len(s) / tile_length >= 45%
         OR (129 <= len(s) <= 256 AND len(s) / tile_length >= 10%)
         OR (bin_id < 2 AND len(s) >= 16)
    if risky AND repair_budget_available:
        exact_sort_by_depth(s)

for each tile:
    traverse its repaired bin stream front-to-back
    stop a pixel when transmittance falls below the exit threshold
输出：与基线数值等价的渲染结果

伪代码里最关键的是 risky 分支：先用粗组织缩短工作单元，再把 exact sort 只交给高风险段。阈值是全局固定超参数；换硬件、分辨率与深度分布时仍需重新验证。

05 No-GW 为什么赢了：少搬一次，反而比压缩更重要

论文测试了两条执行路线。默认的 No-GW 只保存分桶后的 Gaussian ID，栅格时仍从原始数组读取几何属性；Packed-GW 则在栅格前多做一步 geometry write，把所需属性打包成紧凑 sidecar，希望降低后续 DRAM 压力。

Packed-GW 的 profiler 结果确实在九个场景中的七个减少了 DRAM 流量，平均减少 28.64 MB，garden 与 bicycle 分别少 92.46 MB 和 82.34 MB。看起来它应该赢，但独立 timing rerun 中，它在九个场景全部更慢，平均增加 0.208 ms，也就是慢 7.87%。

原因不是压缩无效，而是预先 materialize 属性的成本、同步与额外 kernel 启动超过了省下的带宽。No-GW保留了一条更简单的 inner loop。这个对照提醒工程团队：profile 某个指标变好，不代表端到端时间就会变好；优化必须把新引入的阶段一起计账。

06 1.44 倍核心加速，为什么端到端只有 6.9%—9.4%

主实验覆盖 Mip-NeRF 360、Tanks and Temples 与 Deep Blending 的九个场景。基线不是早期 vanilla 3DGS，而是高性能 gsplat；两条路线使用同一批投影高斯与相同 splat evaluation。

RTX 4090 上，栅格核心九场景平均加速 1.439 倍，各场景在 1.368—1.511 倍之间；RTX 1000 Ada 完成 profiler capture 的五场景平均 1.441 倍。端到端则分别是 1.069 倍和 1.094 倍，相当于平均帧时间改善约 6.9% 与 9.4%。

差距来自新增成本。bicycle 上 raster 节省 0.803 ms、sort 节省 0.441 ms，但 bin construction 增加 0.438 ms、repair 增加 0.405 ms；garden 上 raster 和 sort 分别省 0.689 与 0.640 ms，同时新阶段增加 0.736 ms。流水线账本一摊开，核心大幅提速与整帧温和提速完全可以同时成立。

重栅格场景收益更明显：bicycle 与 garden 在 RTX 4090 上端到端分别加速 1.105 与 1.110 倍，RTX 1000 Ada 上为 1.119 与 1.140 倍。轻场景 playroom 在 4090 上只有 1.032 倍，因为可省的长遍历更少，辅助阶段占比更高。TileGS不是固定税率的“白送加速”，它依赖场景是否足够 raster-heavy 来摊薄分桶与修复成本。

07 最反常识的 profiler：更慢的指标，拼出了更快的核心

如果只看常见 GPU 指标，TileGS像一次失败优化：SM throughput 从 76.94% 降到 59.61%，active-warp occupancy 从 91.32% 降到 62.18%，DRAM 从 136.65 MB 增到 185.53 MB。

然而核心 duration 从 1.299 ms 降到 0.878 ms，快 1.48 倍；SASS thread instructions 从 21.25B 降到 16.90B，降至基线的 79.5%，基线指令数是其 1.26 倍。分支发散线程仅从 5.54M 小幅变到 5.70M，thread instructions per warp instruction 也几乎不变。也就是说，占用率、SM 吞吐、流量和显式分支发散都解释不了加速。

图5｜依据论文 Table 11 重绘，灰色基线统一为 1。TileGS 的时长和 SASS 指令下降，但 SM 吞吐、active-warp occupancy 也下降，DRAM 流量上升到约 1.36 倍。它支持“减少有效遍历工作”的解释，而不是“占用更高或搬得更少”。数据来源：论文，CC BY 4.0。

论文进一步直接在 raster loop 中计数：每个像素到提前终止之前，实际测试了多少个高斯。bicycle 从 570.646 次降到 541.444 次，减少 5.12%；garden 从 571.206 降到 535.792，减少 6.20%；较轻的 kitchen 也从 473.578 降到 450.994，减少 4.77%。

这就是论文最有启发性的结论：系统不是因为“每一步更便宜”而快，而是因为按深度切成更合适的工作单元后，总共少走了一些步骤。5% 左右的 test-count 降幅不能单独解释 1.44 倍，因为 SASS 还包含 staging、同步、active mask 与 tile 级退出；但两类证据共同指向有效遍历工作减少。

08 画质没有被偷偷换掉：repair 消融最能说明问题

九场景里，TileGS与 gsplat 的差异保持在 |ΔPSNR|<0.001 dB、|ΔSSIM|<0.001、|ΔLPIPS|<0.001。这里比较的是两种渲染器输出之间的差，不是对 ground truth 的绝对质量增益。正确表述应该是“在数值噪声范围复现基线”，而不是“提升 PSNR”。

真正能验证 repair 必要性的，是 bicycle、truck 与 playroom 三场景消融。不修复时平均帧时间最快，为 2.849 ms，但最大 PSNR 误差达 2.0346 dB、最大 SSIM 误差达 0.0579；默认 selective repair 为 3.098 ms，最大 PSNR 差只剩 6×10−6 dB，SSIM 差为 0。

全量 repair 更慢，为 3.257 ms，但质量并没有产生有意义的进一步改善。选择性修复正好站在两端之间：它承认粗分桶会破坏顺序，同时拒绝为所有局部都支付精排费用。

图6｜依据论文 Table 9 重绘。左侧显示无修复最快、全量修复最慢；右侧显示无修复出现明显 PSNR 偏差，而选择性与全量修复都恢复到接近零的数值误差。三场景子集用于机制消融，不应替代九场景主结果。数据来源：论文，CC BY 4.0。

09 和 StopThePop、Speedy-Splat 放在一起，TileGS补了哪一环

StopThePop关注的是视角变化时的 popping 与 blending artifact。它通过层次化重排与 culling 改善 per-pixel 顺序一致性，核心问题是“怎么避免排序近似造成可见跳变”。TileGS也处理顺序，但目的不同：粗 bin 先服务执行结构，selective repair 再恢复与基线一致的合成。

Speedy-Splat从 sparse pixels 与 sparse primitives 下手，通过更精确的 Gaussian—tile 定位与 primitive sparsification 减少要渲染的集合。TileGS明确不减少静态高斯集合，也不改变表示；它优化的是同一集合进入 raster kernel 后如何被消费。一个回答“哪些工作不必进来”，另一个回答“已经进来的工作怎样更早做完”。

其他路线会改合成规则、引入随机采样或组合多种优化。TileGS刻意控制变量：高斯表示、投影输入与 alpha compositing 目标不变，只替换 traversal granularity。

因此它最可能的价值不是“淘汰所有高速渲染器”，而是成为可与稀疏化、压缩和更好几何布局叠加的一层执行优化。不过“可叠加”目前只是结构上的兼容判断，论文没有完成这些组合实验，真实收益还要重新测。

10 落地前必须看清的四条边界

第一，只覆盖 forward rasterization。训练需要 backward 按完全相同的 tile-bin-major 与 repair 顺序回放，因为 alpha compositing 梯度依赖前向次序。当前结果不能直接写成“训练也加速”。

第二，硬件覆盖只有 Ada。桌面 RTX 4090 与笔记本 RTX 1000 Ada 代表两个算力—带宽点，但不包含其他 NVIDIA 代际、AMD、Apple GPU 或真正的移动 TBDR。tile-local 思路与 TBDR 很相似，不等于移动端一定获得同样数字。

第三，场景覆盖仍有限。九场景没有系统测试极稀疏、极稠密或强双峰深度分布，而这些分布可能改变 log binning 与 repair budget 的行为。

第四，剩余瓶颈仍是几何属性散读。bicycle 的 source-attributed profiling 中，geometry attributes 占 raster memory pressure 的 85.8%，占 excess sectors 的 88.6%。作者尝试 in-kernel gather sort、FP16 color、sidecar materialization 与 pre-raster rejection，都未获得净收益。下一步更像是 raster-order-aware storage 或 AoSoA 布局，而不是再给现有 inner loop 塞一层技巧。

11 龙哥点评：这篇论文最值钱的是“换一个优化坐标系”

很多系统优化从熟悉指标出发：占用率不高就提 occupancy，流量太大就压 DRAM，访问太散就做 coalescing。但 TileGS的 profiler 恰恰显示，这些指标可以同时变差，而总时间仍然下降。它提醒研究者，指标是现象，不是目标；真正目标是让最终有效工作更少、更快完成。

龙哥最欣赏的是这项工作没有只晒一个 speedup。它用端到端、kernel、stage breakdown、SASS 指令、per-pixel Gaussian tests、repair ablation 和质量差异形成了闭环。漂亮数字之后，论文继续追问“为什么快”“哪部分拖后腿”“换一条看似省带宽的路线为何反而慢”。

对工程团队，最直接的启发是把 profiling 从“模块”继续下沉到“执行结构”。代码和输入集合不变，工作单元划分、局部顺序与退出时机依然可能是主优化维度；透明度合成、光线遍历与候选扫描都值得重问“什么应该先做”。

但采用前要算清收益对象。若业务主要是训练、GPU 不是 Ada、场景很轻，或整个管线瓶颈在网络与 CPU，1.44 倍核心数字不会自动变成用户侧帧率。真正值得带走的不是一个固定倍数，而是一套方法：保持语义不变，重排执行；用局部精确修复守住正确性；最后用端到端账本决定优化是否成立。

龙迷三问

第一问：为什么不直接给每个 tile 精确排序？因为全量精排会把已经省下的组织成本重新花掉。TileGS用粗 bin 建立大方向，再用风险规则修复少数局部。

第二问：DRAM 增加，为什么还能更快？内存流量不是唯一成本。更短、更有结构的深度局部区间让像素更早达到 transmittance 退出条件，SASS thread instructions 与实际 Gaussian tests 都下降，减少的动态遍历足以抵消更高流量。

第三问：这项技术能直接进训练框架吗？还不能。当前实现只覆盖前向渲染；反向传播必须复现前向的分桶与修复次序，才可保持 alpha compositing 梯度一致。把 forward speedup 写成 training speedup，会越过论文证据。

总结

TileGS把标准 3DGS 中“一条全局组织、每 tile 一段长遍历”的执行方式，改成稳健深度范围、tile-local bins、连续 offset 流与选择性精排。九场景上，它让 RTX 4090 栅格核心平均加速 1.439 倍，端到端加速 1.069 倍；RTX 1000 Ada 端到端加速 1.094 倍，同时保持与 gsplat 的输出差异在数值噪声范围。

更重要的是，它证明：系统优化不总是让每个硬件计数器都更漂亮，突破可能来自重新定义“工作怎样被组织”。若能按 raster order 重构几何属性布局，并补齐 backward 与跨架构验证，这条路线才可能成为更普遍的高斯渲染基础设施。