论文基本信息
原文标题：TileGS: Tile-Local Depth Binning for Gaussian Splatting Rasterization
首次公开：2026年9月3日（arXiv v1）
发表信息：Pacific Graphics 2026，Computer Graphics Forum 45(7)
作者单位：Aalto University、Nokia Technologies
原论文链接：https://arxiv.org/abs/2609.03613
论文许可：Creative Commons Attribution License
龙哥导读
3D Gaussian Splatting已经实现实时渲染，但标准光栅器仍让每个tile沿全局排序生成的长队列扫描。TileGS不换高斯表示，也不改颜色合成公式，而是把长队列切成tile内短深度段，只对高风险段恢复精确顺序。结果很反直觉：显存流量增加、占用率下降，光栅核反而平均快1.44倍。它提醒工程团队：瓶颈有时不是搬了多少字节，而是执行顺序制造了多少无效工作。
先把问题说得直白一点：屏幕上同一个像素可能被几百个半透明高斯覆盖，渲染器必须按前后关系把颜色逐层混合。越靠近相机的高斯通常先参与合成，累计不透明度足够高以后，后面的高斯就可以提前跳过。于是，谁先被访问，不只是“结果对不对”的问题，也决定一条线程要循环多少次才结束。
标准3DGS已经按图像tile分配任务，看上去很局部；但它先把所有“高斯—tile交叉条目”放进一条全局流，再按tile和深度组合键排序。每个CUDA block虽然只负责自己的tile，真正消费的却是从这条全局流切出来的一段长区间。论文把这种状态概括得很准确：所有权是tile级的，遍历结构却没有真正tile-local。
这正是TileGS要动刀的地方。它不重新训练场景，不裁剪高斯，不改变投影结果，也不把传统alpha合成换成近似的可交换算子；它只重新组织光栅器看到的工作顺序。问题因此变成：能不能把一条很长、很散、很难提前结束的队列，改造成若干更短、更靠近前后深度结构的局部段，同时把错序风险控制在数值噪声范围内？
一、为什么3D高斯的“排序”既不能乱，又很费
公式1：标准3DGS前向alpha合成。图片依据3DGS合成定义与TileGS沿用的基线语义重绘。
公式里的C是当前像素最终颜色，ci是第i个高斯带来的颜色，αi是它在这个像素上的不透明度，Ti则表示光线走到第i个高斯之前还剩多少透射率。Ti由前面所有“1−α”连乘得到，所以它天然依赖顺序：把前后两个高斯交换，后者拿到的透射率就会变化，颜色也可能变化。
这也是为什么“直接不排序”并不免费。若保留原来的非交换alpha合成，就必须维护足够准确的前后顺序；若把合成改成可交换的加权和，排序可以消失，但优化目标和渲染语义也跟着变化。TileGS选择的是更保守的一条路：合成数学不动，只改输入这段循环的组织方式。
图1：标准3DGS与TileGS执行流程的中文单栏重绘。依据论文Figure 1。
图1上半部分是标准路径：输入高斯、分配到tile、按tile与深度做全局排序，最后沿一条长区间光栅化。它强调的是：同一个tile的任务虽被归到一起，整个tile仍只有一条长范围。
下半部分是TileGS：增加tile内深度分桶、计数散射和前缀和偏移，再按局部顺序光栅化。最终仍是一段连续流，只是已按tile优先、桶内其次排列；桶边界主要决定数据布局和修复单元，默认光栅核仍线性扫描整个tile区间。
二、第一步：先估一个不被极端值带偏的深度范围
如果直接拿当前帧最小深度和最大深度做均匀分桶，少量极远或极近的异常高斯就可能把区间撑得很大，大多数桶会浪费在贡献很小的深度上。TileGS先从可见高斯中最多采样8192个深度候选，并对近景高斯做一个“向相机方向”的键值修正：用高斯最大投影尺度和中心深度共同决定偏移，让大而近的高斯更早进入近景桶。
随后，方法不是取极值，而是用精确次序统计选择1%和99%分位点，再在截断后的跨度两侧各留5%余量，并受相机near/far平面约束。这样得到的[zmin, zmax]更像“当前帧真正有用的深度工作区间”。论文补充材料还提到一个128桶的直方图估计备选方案，但全部报告结果使用的是精确kthvalue路径。
公式2：对数深度归一化后取整得到桶编号。图片来源：论文补充材料Algorithm 3后的定义。
逐项看这条式子：z是近深度修正后的条目深度，ε避免对零取对数；z′min和z′max是数值安全处理后的有效边界；u把对数深度压到[0,1)；K是桶数，默认64；最后对Ku向下取整得到b，并把b限制在0到K−1。
为什么用对数而不是线性？近景高斯通常投影更大、覆盖像素更多、彼此重叠更强，错序也更显眼。对数映射把更多桶分辨率留在近处，相当于把有限的64个格子优先花在更敏感的区域。它不是物理定律，也不保证桶内严格有序；它只是一个让局部工作更容易组织的性能装置。
三、第二步：count、scatter、scan，把长队列改造成局部短段
图2：从深度范围估计到连续局部段的中文单栏重绘。依据论文Figure 2与Algorithm 3。
图2从上到下依次是：估计有效深度范围；把条目映射到0到K−1号桶；对每个(tile t, bin k)计数并散射；对计数数组做exclusive scan得到binOffsets；最后按近到远连续回放。
binOffsets[t,k]不是装饰性元数据。相邻两个偏移量直接定义了某个tile、某个深度桶在扁平流中的[begin,end)区间；同一tile的所有桶又首尾相接。因此，光栅核只需读取binOffsets[t,0]到binOffsets[t,K]这一段，就能按从近到远的桶顺序消费数据。
构造完成后有两条执行路径。No-GW只保存新顺序，光栅时仍按高斯ID读取原属性；Packed-GW提前物化紧凑属性sidecar。后者曾让7/9场景DRAM流量下降，平均少28.64 MB，但计时复测却九场景全部变慢，平均增加0.208 ms。于是默认选No-GW：减少内存流量不是目标，减少总时间才是。
四、第三步：粗分桶会错序，为什么只修一小部分就够
粗深度桶只能保证“桶与桶大致从近到远”，不能保证同一桶里的每个高斯严格有序。两个高斯可能落在同一桶，也可能因为归一化边界而跨桶；当它们颜色差异大、透明度高、且此前累计透射率仍高时，交换顺序就会明显改变像素。若完全忽略这个问题，速度会更快，但结果不再等价。
公式3：每个tile-bin切片是一个局部段；全帧精确修复条目预算默认为总条目数的25%。图片来源：论文正文与补充材料Algorithm 4。
ℓ是一个局部段的长度，也就是end减begin；M是全帧高斯—tile条目总数；Brep是修复预算，默认取⌊0.25M⌋。预算不是说固定修复25%，而是说被选中的段按tile、桶顺序做原子预留，累计条目不能超过这个上限。这样即使某一帧出现大量歧义段，修复成本也不会无限扩张。
图3：选择性精确修复的中文单栏重绘。依据论文Figure 3与Algorithm 4。
图3从上到下先按长度把候选段分组，再执行五条保留规则，之后受全局25%修复预算约束。入选段按基线键恢复精确顺序；未入选段继续走普通分桶光栅。实际实现还把2–128细分为2–32、33–64、65–128，以匹配固定尺寸bitonic sort内核。
论文给了五条默认规则，只要任一命中就标记修复：段长至少320；段长大于512；段长占父tile条目至少45%；129到256长度的段占tile至少10%；或者位于最近的两个桶且段长至少16。前三类抓“大段”和“集中段”，最后一类优先保护近景，因为近景高斯覆盖大、透明度影响强、错序更容易被看见。
被选中的段按原始基线排序键恢复精确顺序；没被选中的段保持原子scatter产生的局部顺序。修复发生在光栅前，所以最终光栅循环仍然可以朴素地线性扫描一个tile的连续区间。换句话说，复杂性被挪到了“怎样准备数据”，而不是塞进每个像素反复执行的热循环。
为什么多数段不修也能接近精确？因为交换两个相邻高斯造成的颜色误差，会在两种情况下被压小：它们本身透明度很低，或者前面已经积累了很低的透射率。TileGS并没有把这条经验当成严格证明，而是用选择规则锁定最可能产生可见误差的段，再用实验确认输出与基线只剩数值噪声。这个表述必须克制：它是报告基准上的经验等价，不是对所有场景的数学保证。
五、实验怎么做：两块Ada GPU、九个经典场景、同一套输入
主实验使用桌面RTX 4090和笔记本RTX 1000 Ada，两边都锁定时钟与功耗设置，减少动态加速、温度和功耗管理带来的波动。基线是广泛使用的高性能开源实现gsplat，固定在同一commit；比较双方使用相同的投影后高斯输入、相同的tile分配与alpha合成目标。
九个场景来自Mip-NeRF 360、Tanks and Temples与Deep Blending，覆盖户外重负载、室内和复杂混合场景。端到端时间包含投影、tile相交、排序、光栅以及TileGS新增的深度估计、分桶和修复；不包含CPU到GPU传输、Python侧开销和反向传播。
图4A：RTX 4090与RTX 1000 Ada九场景结果分上下两栏展示。依据论文Table 5重绘。
图4A显示九个场景全部加速：例如bicycle在RTX 4090上从4.395 ms降到3.979 ms，在RTX 1000 Ada上从38.92 ms降到34.78 ms；两块卡的端到端均值分别为1.069倍和1.094倍。
图4B：深度桶数量消融按单栏大字展示。依据论文Table 7重绘。
图4B回答“为什么默认64桶”。K=64时平均frame为3.0144 ms；32桶是3.0338 ms，128桶是3.0641 ms，16、8、4桶继续变慢。桶太少时局部段仍长，桶太多则管理开销上升；64只是当前设置的最佳固定折中。
图5：根据论文Table 5重绘。蓝色为RTX 4090，橙色为RTX 1000 Ada；纵轴从1.00开始，超过1表示加速。
图5最值得看的不是平均线，而是场景差异。bicycle、garden、stump等户外场景的长tile范围更重，新结构更容易摊薄辅助开销；train、truck、playroom等较轻场景仍加速，但幅度较小。笔记本卡上的kitchen达到1.162倍，是表中最高端到端收益；桌面卡上的truck只有1.039倍。所以TileGS更像“光栅瓶颈越重越划算”的优化，而不是固定百分比加速器。
把主光栅核单独拿出来，RTX 4090九场景平均加速1.439倍。RTX 1000 Ada能完成完整profiler捕获的五个场景平均1.441倍，但bicycle、garden、stump、drjohnson四个重场景因驱动或profiler资源获取问题缺失，因此这1.441倍只能称为五场景子集，不能外推成完整架构结论。论文对此没有藏着掖着，这是实验可信度上的加分项。
六、画质与消融：不修最快，但会把正确性一起丢掉
图6：bicycle场景的gsplat基线、TileGS输出与放大100倍的绝对RGB差异。图片来源：论文Figure 4。
图6左、中两幅肉眼几乎无法区分；右侧不是普通误差图，而是把绝对RGB差异放大100倍再叠回TileGS结果，目的就是让极小偏差可见。全九场景上，相对gsplat的|ΔPSNR|、|ΔSSIM|、|ΔLPIPS|都小于0.001。这里的结论应准确表述为“在报告基准上与基线数值等价”，而不是“任何场景都完全逐像素相同”。
图7：左侧根据论文Table 9重绘修复消融，右侧根据Table 11重绘关键硬件计数变化。
图7左侧来自bicycle、truck、playroom三个代表场景。完全不修复时平均帧时间只有2.849 ms，确实最快，但最大PSNR误差达到2.0346 dB，最大SSIM误差0.0579，已经不是“数值抖动”。默认选择性修复为3.098 ms，最大PSNR误差仅6×10−6 dB；全修复进一步慢到3.257 ms，误差只从6×10−6降到2×10−6。这说明默认策略抓住了影响最大的错序段，继续全量修复几乎只增加成本。
七、最反直觉的结果：DRAM多搬35.8%，为什么还能更快
如果只看常见GPU优化经验，图7右侧几乎像一张“反面教材”：RTX 4090九场景聚合中，光栅核DRAM流量从136.65 MB升到185.53 MB，增加35.8%；SM吞吐率从76.94%降到59.61%；活跃warp占用从91.32%降到62.18%。这些指标都没有变漂亮。
但同一组测量里，核耗时从1.299 ms降到0.878 ms，相当于1.48倍更快；SASS线程指令从212.5亿条降到169.0亿条，相当于少1.26倍。分支发散线程数从554万变到570万，几乎不变；每条warp指令对应的线程指令比例也从78.17%到77.75%，没有显示“发散突然被治好”。
论文因此排除了几种听起来顺耳、却不符合计数器的解释：不是因为占用率更高，不是因为SM更忙，不是因为字节更少，也不是因为高斯索引突然连续。最有支持的解释是，深度局部化让像素更早积累足够不透明度，减少了有效内循环工作。
论文还统计每像素在提前终止前执行的候选高斯测试：bicycle少5.12%，garden少6.20%，kitchen少4.77%。这个降幅小于1.44倍核加速，因为测试数未覆盖批处理、同步、活跃掩码和tile级退出；SASS指令更接近完整动态工作。
分阶段看，bicycle的光栅与排序分别省0.803 ms和0.441 ms，但分桶、修复新增0.438 ms和0.405 ms，整帧净省0.307 ms；garden也呈现相同结构。核级收益被准备工作吃掉一部分，所以融合分桶与修复小内核，是最直接的下一步。
剩余带宽压力也被定位出来：在RTX 4090的bicycle代表性捕获中，几何属性占来源归因光栅流量的85.8%，占无效额外sector的88.6%；bin和索引结构只占10.2%，帧缓冲占4.0%。下一步若要继续压时间，重点不是继续抠几个桶，而是让圆锥参数、投影均值、颜色和透明度的存储布局更贴合tile内遍历，例如按光栅顺序重排或采用AoSoA结构。
八、放到相似工作里看：它不是“取消排序”，而是重新决定哪里值得精排
图8：三条排序优化路线。依据三篇论文的官方论文页与项目资料重绘，不代表三者在统一硬件上的直接排名。
StopThePop解决的是“排序不够精确”。它用分层光栅化在多个空间层级重排并裁剪，逼近逐像素排序，重点消除镜头旋转时的popping。官方资料报告，严格一致性设置平均只慢约4%；结合opacity decay把高斯数量减半后，可达1.6倍渲染速度和约50%内存下降。
Sort-Free Gaussian Splatting解决的是“非交换合成导致必须排序”。它用Weighted Sum Rendering近似传统alpha blending，从源头取消排序；论文在Snapdragon 8 Gen 3移动GPU上报告平均1.23倍加速，并通过重新优化表示取得有竞争力的画质。代价是合成规则已经改变。
放在一起看，StopThePop把排序做得更细，Sort-Free GS改写合成规则，TileGS则保留原表示和原合成，用粗分桶重排执行，再把有限精排预算花在高风险局部段。TileGS最独特的卖点不是绝对倍数最大，而是改动边界窄、输出语义保守、机制证据完整。
九、对工程团队和普通用户，真正的价值在哪里
第一，已有3DGS系统更容易评估它。TileGS不要求更换场景表示或重新定义最终颜色公式，输入仍是投影后的高斯属性和tile交叉条目。对维护自研光栅器、gsplat分支或数字孪生渲染后端的团队，这种“只动前向执行结构”的方案，比重新训练一套表示更容易做A/B验证。
第二，收益会集中在真正被光栅拖住的场景。大户外场景、视野里高斯重叠多、tile范围长时，分桶更容易减少无效遍历；如果整帧主要花在投影、球谐计算、数据传输或其他模块，1.44倍光栅核加速不会自动变成1.44倍整帧加速。论文的6.9%和9.4%端到端均值，反而比只喊核级数字更接近产品预算。
第三，它提供了一种可迁移的系统优化思路。面对“数据量没少、内存流量还涨了”的结果，不应立即判定优化失败。若重新组织顺序能让线程更早退出、减少动态指令或缩短关键路径，整体仍可能更快。这个思路不只属于3DGS，也适用于带提前终止、透明合成、稀疏访问和局部工作集的GPU管线。
第四，用户侧价值主要是更稳的交互余量，而不是画质升级。TileGS没有提高场景重建PSNR，也没有生成更多细节；它把相同输出更快地送到屏幕。对VR/AR浏览、三维内容预览、机器人环境可视化和交互式编辑，这意味着同一硬件上可以争取更高帧率、更低延迟，或者给其他模块留下更多GPU时间。但这些应用方向并未在论文中逐项落地验证，不能直接写成产品成熟度。
十、局限与落地边界：这不是通用GPU结论，也还不是训练加速器
第一，硬件范围窄。主实验只有两块NVIDIA Ada GPU，没有覆盖Ampere、Blackwell、AMD、Apple GPU、移动GPU或真正的Tile-Based Deferred Rendering架构。TileGS依赖调度、缓存和内存服务的具体行为，不能把Ada上的收益直接复制到所有平台。
第二，笔记本卡的机制证据不完整。RTX 1000 Ada上四个重场景无法完成全分辨率Nsight捕获，所以完整的“流量更高但指令更少”来源归因主要来自RTX 4090；笔记本卡只有五场景核级子集和50%高斯诊断提供方向一致的支持。这足以说明跨设备有相似迹象，不足以证明机制完全架构无关。
第三，数据分布仍有限。九个场景来自三套经典自然场景基准，缺少系统性的稀疏、极密集、强双峰深度压力测试；补充材料只有bicycle单视图从500万到3000万条目的合成扩展诊断。分辨率和视图数量也没有独立扫描，因此K=64和修复阈值不应被当成跨产品的永久默认值。
第四，当前工作只覆盖前向光栅化。训练阶段的反向传播依赖与前向一致的合成顺序，需要沿tile-bin-major且修复后的顺序计算梯度，论文明确把这部分留给未来工作。因此，它更接近推理、浏览和渲染路径优化，不能据此宣称3DGS训练也会同步提速。
十一、龙哥点评：一篇把“为什么快”讲明白的系统论文
龙哥的第一判断是：这篇论文最强的地方不是1.44倍，而是没有用错误指标解释1.44倍。如果作者只展示帧时间，很容易把故事讲成“分桶改善局部性”；但计数器偏偏显示DRAM流量增加、占用率下降、索引合并访存几乎没变。论文接受了这个反直觉结果，再用SASS指令和每像素测试数把“有效遍历工作下降”补成一条闭环证据。
第二个判断是：它对正确性的态度值得肯定，但还没有走到普适证明。不修复版本明确暴露2.03 dB误差，默认修复与全修复的速度、误差都公开；这比把近似误差藏在平均画质里更可信。不过，选择规则仍依赖固定阈值和25%预算，当前结论建立在所测场景之上，未来需要更极端分布和更多GPU架构检验。
第三个判断是：它不是一项会单独改变3D内容生产的技术，却可能成为渲染后端里很有价值的一块积木。用户不会因为“tile-local depth binning”购买产品，但会为更稳的帧率、更低的交互延迟和更省的算力预算买单。系统团队真正要做的，是先确认自己的瓶颈确实在光栅遍历，再判断新增构造与修复成本能否被重场景摊薄。
十二、龙迷三问
问题一：既然Sort-Free GS能取消排序，为什么还要研究TileGS？
因为两者优化契约不同。Sort-Free GS通过改变合成算子换取可交换性，需要围绕新渲染公式重新优化表示；TileGS保留现有alpha合成与投影输入，更适合希望维持基线语义的系统。一个追求“从根上不要排序”，一个追求“只在真正必要处精确排序”。
问题二：DRAM流量增加，是否意味着能耗一定更差？
不能直接下结论。论文测了时间、流量、占用和指令，没有给出板级能耗。更短核时间可能抵消更高瞬时流量，也可能在不同平台产生不同结果。要回答能耗问题，需要在统一功耗采样方法下测每帧能量，而不是拿DRAM字节数代替。
问题三：下一步最值得做的是更多桶，还是更聪明的repair？
从现有证据看，两者都不是最大杠杆。64桶附近已经接近最佳，repair阈值激进或保守变化的整帧差异不足1%；真正大的空间在辅助阶段融合和几何属性布局。若能降低分桶、修复的固定成本，并让属性存储更匹配tile顺序，核级收益才更可能传到整帧。
十三、总结：别只优化数据结构，也要优化“先做什么”
TileGS把每个tile的一条长全局排序区间重组成短深度桶，再用有限预算修复高风险错序。九场景上，两块Ada GPU端到端平均加速6.9%和9.4%，RTX 4090光栅核平均快约1.44倍，画质差异低于0.001。它揭示的系统事实是：tile-based不等于tile-local，连续数组不等于有效执行，低流量也不等于低延迟。当表示和数学不方便改时，重写执行顺序本身仍可能产生真实价值。
主要参考资料
TileGS论文与补充材料：arXiv 2609.03613
Sort-Free Gaussian Splatting：arXiv 2410.18931
本文基于龙哥读论文PaperDaily数据库及PaperMiner的MCP进行汇总整理。
本文仅作论文解读与工程讨论，不替代原论文；关键数字、适用范围和实验设置请以原文及补充材料为准。
