光线追到一半卡住了——给 GPU 安一个能预判的预取器

想象你站在一间巨大的图书馆里。你要找一本书，但图书馆的每本书里都写着下一本书的位置。你翻一本，查到下一个目标，跑过去，再翻一本，再跑。这就是 GPU 做光线追踪时的日常——每一条光线都要遍历一棵巨大的 BVH 树，遍历的过程中绝大部分时间不是在计算，而是在等内存把下一层树节点的数据送过来。 问题不在光线，在树。 这套叫 Bounding Volume Hierarchy 的数据结构把 3D 场景编码成一棵大二叉树。GPU 每发射一条光线，就要从树根开始向下搜索，一层一层判断光线和哪个包围盒相交，直到找到最底层的三角形。一次遍历要读几十个树节点，而每个节点都散落在显存的不同角落。GPU 号称拥有数千个计算核心，但 BVH 遍历时大部分核心都在空等——等数据从内存搬过来，等缓存命中，等下一波访存请求回来。 Tozlu、Naithani 和 Zhou 提出的 TTP 预取器做了一个非常简单的观察：GPU 光线追踪硬件单元在遍历 BVH 树的时候，内部其实维护了一个栈结构。栈里存着当前路径上尚未访问的节点地址。既然地址已经在那里了，为什么不提前把它们取到缓存里来？ 这就不是复杂的预测算法了，更像是在已有的数据结构里捡现成的便宜。 TTP 的做法是：当光线在做深度优先遍历时，会连续从栈里弹出（pop）节点。每次弹出代表向上回溯了一层。TTP 检测到这种连续弹出动作——意味着光线刚刚完成了某个子树的遍历准备往上走——于是就提前把下一层会被访问到的节点预取到 L1 缓存。不需要专门的预测器，不需要额外记录历史访问模式，纯粹靠硬件遍历栈里现成的地址信息来猜下一步要什么。 在 Vulkan-sim 2.0 周期精确模拟器上的测试显示，TTP 将性能平均提升了 1.48 倍，最高 1.89 倍。L1 预取精度 98.92%——这意味着它预取进来的数据中，将近 99% 都被后续的访存请求真正用到了，几乎没有浪费的带宽。L1 缺失降低了 31.54%，和加速比吻合得很好。 不清楚的地方：论文在模拟器层面验证了效果，但没有在真实芯片上跑。模拟器和真实硬件之间的差距可能不小——尤其是 L1 和 L2 之间的带宽、延迟参数在实际芯片上会有不同的临界值。另外，TTP 依赖 DFS 遍历中连续弹出这个特定模式，如果在未来非 DFS 遍历算法下是否仍有效，论文没有讨论。 --- **参考文献** 1. Tozlu, Y. S., Naithani, A., & Zhou, H. (2026). *TTP: A Hardware-Efficient Design for Precise Prefetching in Ray Tracing*. arXiv:2605.16253 [cs.AR]. 2. Wald, I., et al. (2019). *Embree: A Kernel Framework for Efficient CPU Ray Tracing*. ACM Transactions on Graphics. 3. Mehta, D. U., et al. (2023). *Vulkan-Sim: A GPU Architecture Simulator for Vulkan*. IEEE International Symposium on Performance Analysis of Systems and Software.