DirectX光追迎来最大更新，聚类几何帧率提升66倍显存降90%

微软已经发布了 DirectX 12 Agility SDK 1.722 预览版，这次更新的分量不轻——它是 DirectX 光线追踪（DirectX Raytracing）自 2018 年首次亮相以来最重要的一次迭代。

新版引入了 Clustered Geometry（聚类几何）、PTLAS（分区顶层加速结构）等核心能力，目标直指复杂场景下光追计算开销大、显存占用高的老问题。

Clustered Geometry 的思路

Clustered Geometry 的做法很直接：把 3D 模型拆成不超过 256 个三角形和 256 个顶点的小簇。这样做的好处是，开发者不再需要每次几何体发生变化时都重建整个加速结构，只要复用或重建实际发生变动的那部分就够了。

这个思路并不复杂，但它的效果相当可观。过去在复杂场景里，一个物体的局部变动常常意味着整个加速结构要跟着重新构建，帧时间就这么被拖垮了。按簇更新的方式，相当于把“牵一发动全身”变成了“哪里变了修哪里”。

PTLAS：把同样的逻辑搬到场景级别

PTLAS（Partitioned Top-Level Acceleration Structures，分区顶层加速结构）把这套思路进一步扩展到了场景层面。GPU 只需要更新发生变化的区域，而不是全场景重新处理。对于开放世界游戏和动态物体密集的场景，这种按需更新的策略尤其有效。

在计算机图形学里，加速结构本质上是一套空间索引，用来帮 GPU 快速判断光线和哪些几何体相交。场景越复杂、动态物体越多，加速结构的维护成本就越高。PTLAS 的价值在于把维护成本从“全场景”压低到“局部区域”，这跟 Clustered Geometry 在物体层面的优化逻辑是一致的。

性能数据：从 1.2 FPS 到 79 FPS

微软在 AMD Radeon RX 9070 上做了一组对比演示。在传统加速结构重建模式下，测试场景只能跑到 1.2 FPS；切换到 Clustered Geometry 之后，帧率直接拉到了 79 FPS，大约 66 倍的提升。

GPU 加速结构构建时间从 788 ms 压缩到 3.11 ms，缩短了约 253 倍。光追渲染单帧耗时从 72.6 ms 降到 9.27 ms，大约快了 7.8 倍。

显存方面的变化同样显著。加速结构总显存占用从 7519 MiB 降到了 774 MiB，降幅约 90%。其中动态物体加速结构显存从 6794 MiB 骤降到 244 MiB，缩减了 96.4%。不过这里有个代价：构建过程中的临时显存需求会有所增加，这是按簇重建机制带来的额外开销。

如果你之前关注过光追性能优化，应该知道加速结构重建一直是动态场景里的硬伤。这组数据最值得注意的地方，不是单纯的帧率提升，而是构建时间的大幅压缩——因为这才是决定帧率下限的关键路径。

硬件支持格局

硬件支持方面，NVIDIA 确认全系 GeForce RTX 显卡均可支持，从最早的 RTX 20 系开始就在名单里。AMD 目前支持 Radeon RX 9000 系列，Intel 则覆盖锐炫 B 系列以及酷睿 Ultra 200V/300 处理器的核显。

高通也有计划，预计在 2027 年上半年为 Snapdragon X2 提供支持。微软特别强调，这些新功能不需要全新的光追硬件，只要驱动适配到位就能跑起来。

此外，这次更新还把 NVIDIA 此前推出的 RTX Mega Geometry 技术纳入了标准化的 DirectX 实现。落地速度已经不算慢了——《战争机器：事变日》已经率先采用了类似技术。微软和 NVIDIA 还联合发布了一个路径追踪森林示例项目，包含 2500 万平方米的地形和超过 6000 万株植物，规模相当夸张。

配套 SDK 的进度

同期的 Agility SDK 1.620 正式版还带来了 Partial Graphics Programs 等高级着色器交付改进。不过这项能力目前仅限 Radeon RX 7000 和 RX 9000 系列支持。Shader Model 6.10 还在预览阶段，正式版预计会随 SDK 1.621 在 12 月初推出。

微软也留了退路：上述性能数据来自特定的开发示例和配置，实际游戏里的提升幅度会受到工作负载、实现方式和 GPU 架构的影响。这个说明不算客套——光追性能优化落到具体项目里，效果往往和环境强相关。

一个老问题：为什么任务管理器也会卡死？

跟这次 DirectX 更新一起被讨论的，还有一个不少资深玩家反复提起的问题：系统卡到不行的时候，为什么把任务管理器设成最高优先级也没用？

微软资深工程师 Raymond Chen 从技术角度给出了解答。核心结论一句话：在系统资源极度紧张的情况下，单纯提升进程优先级并不能保证响应及时，共享资源导致的阻塞才是真正的性能杀手。

Windows 的调度逻辑里，哪怕一个线程拿到了高优先级通行证，它也没法绕过对共享资源的依赖。打个比方——你在超市结账时确实有优先权，但如果排在前面的人推着满满一车东西占着唯一的收银机，你还是只能干等。

在计算机内部，这些“收银机”就是互斥锁、文件句柄或者网络请求。Windows 确实有优先级反转保护机制，会临时把占用资源者的优先级往上提，好让它尽快释放。但要是这个线程正在执行某些不可中断的耗时操作，高优先级的任务管理器照样会长时间卡在未响应状态里。

对 UI 程序来说这个问题尤其棘手。任务栏和任务管理器本质上都是界面程序，最终必须进入 Windows 统一的 UI 调度体系。这意味着它们要和系统中所有正在运行的界面线程竞争资源。一旦底层界面子系统被某个失控程序锁死，任务管理器也很难独善其身。

从本质上看，想在一个已经失控的系统内部用软件工具来修复问题，本身就是件极具挑战的事。如果修复工具必须和那个让系统崩溃的“罪魁祸首”共享核心资源，那给它再高的优先级也无济于事。目前 Windows 采取的策略是优先照顾处于焦点状态的程序，这在多数场景下已经逼近调度效率的极限。

这篇技术解析虽然和 DirectX 更新本身无关，但它解释了一个困扰很多玩家的实际现象。更多关于开发者效率、底层系统调优的话题，也欢迎到云栈社区一起交流。