Vulkan 光线追踪：逐步弃用主机端加速结构构建

Vulkan® 正在逐步淘汰主机端光线追踪加速结构构建命令，转而采用单一的、基于设备地址的路径。这使得 Vulkan 光线追踪与 DirectX 光线追踪的发展方向、现代引擎架构以及硬件趋势保持一致。

自 Vulkan 光线追踪推出以来的六年间，主机端路径的应用范围十分有限。开发者普遍认为它弊大于利，而实现者则不得不维护并行运行的主机/GPU 命令模型，这不仅增加了复杂性，也为未来光线追踪 API 的演进带来了阻碍。

哪些用户会受到影响？

仅使用主机端加速结构或微贴图命令的开发者会受到影响，这些命令通过 accelerationStructureHostCommands 或 micromapHostCommands 功能实现。大多数应用程序已经使用设备端路径，因此无需进行任何更改。

这对您意味着什么：

• 当前不会出现任何功能故障：现有应用程序仍可正常运行。主机命令目前仅被标记为弃用，并未被移除。
• 主机路径现已成为遗留方案：新的光线追踪扩展将不再添加等效的主机端命令。
• 请在条件允许时规划迁移：如果您目前仍在使用主机命令，请在更新加速结构构建管道时，过渡到设备端的等效命令。
• 请勿开始使用主机命令：新代码应从一开始就使用基于设备地址的路径。

本文将说明具体有哪些变化、如何迁移您的代码，以及 Vulkan 光线追踪为何正围绕设备端模型进行整合。

有哪些变化？

自 2020 年首次发布 VK_KHR_acceleration_structure 以来，Vulkan 光线追踪一直为多种加速结构操作支持两条并行路径：记录在命令缓冲区中并由 GPU 执行的设备端命令，以及直接在 CPU 上执行的主机端命令。VK_EXT_opacity_micromap 中的相应命令也存在同样的划分。这两个扩展中的主机端路径均将被废弃。

这仅是废弃，并非移除。在主机端构建、复制或查询加速结构的现有代码，在当前仍提供 accelerationStructureHostCommands 或 micromapHostCommands 的实现中将继续正常工作。我们不会移除相关入口点、功能，也不会移除描述它们的规范文本。

有哪些变化：

• 主机端构建功能已在 Vulkan 规范中被标记为遗留功能。
• 我们不计划在 Vulkan 路线图中启用 accelerationStructureHostCommands 或 micromapHostCommands。
• 新的加速结构功能将不再提供对应的主机命令。这包括 VK_KHR_device_address_commands 以及最近发布的 VK_KHR_opacity_micromap 扩展。主机命令的功能范围将维持在当前状态不变。
• 验证工具和最佳实践工具将逐步开始对主机侧加速结构构建命令发出“过时”警告。

如果您目前正在使用主机命令，请不必惊慌！但您应在下次调整加速结构构建管道时，计划对代码进行迁移。如果您目前尚未使用主机命令，请不要开始使用。

如何迁移

对于大多数引擎来说，这只是一个很小的变化，因为设备端的命令与主机端的命令几乎是一一对应的：

主要人机工程学差异在于：

1. 构建过程变为异步。命令会被记录到命令缓冲区中，提交后进行显式同步，而不是同步返回。对于大多数引擎来说，这已经是工作批量处理并与帧设置的其他部分重叠的方式；资源加载或流式传输代码可能需要进行一些小的修改，以便在使用该结构之前将其隔离。
2. 输入数据存储在设备内存中。几何体和实例数据必须位于由设备内存支持的缓冲区中，并且只能通过设备地址访问，而不能通过主机指针访问。通过 CPU 缓冲区传输数据的引擎将使用与纹理和顶点数据相同的暂存缓冲区模式。
3. 属性查询会被写入查询池，并通过 vkGetQueryPoolResults 读取结果（或使用 vkCmdCopyQueryPoolResults 复制到缓冲区），而非内联返回。

为什么要弃用主机端构建

生态系统和硬件的发展趋势。DirectX 光线追踪没有对应的主机端构建路径，因此那些在两种 API 上都维护单一光线追踪路径的引擎，实际上已经在使用设备端命令。Vulkan 的整体发展方向也坚定地朝着基于设备地址的 API 迈进，这种 API 与现代引擎的运行方式及底层硬件更加契合——VK_KHR_device_address_commands 扩展便是最近迈出的重要一步。这种对加速结构的简化，正是这一更大范围整合的一部分。

用户少，实际成本却很高。最初添加主机路径时，是期望 CPU 端构建能用于资产预处理、延迟加载流式传输或统一内存实现。但在生产引擎中部署光线追踪超过五年后，这一假设并未得到验证。当光线追踪子组在 2024 年底对成员进行调查时，大多数实现并未暴露 accelerationStructureHostCommands，也没有计划添加该功能；在少数已实现的案例中，其在已发布内容中的使用范围有限，且驱动程序维护成本不低。少数尝试过主机路径的应用团队反馈称，其弊大于利，主要原因在于大多数目标设备并未提供该功能。没有实现方主张保留该功能；也没有开发者要求我们保留它。

维持双轨制会阻碍 API 的发展。在建立基于设备地址的干净加速结构 API 时，若要保留主机命令，将迫使我们做出艰难的选择：要么让主机地址通过加速结构的创建过程进行路由，要么彻底消除加速结构对象。由于这两种方案在当时都不切实际且不可取，光线追踪子组提出了一个明确的选择：要么扩展主机命令以适应设备地址范式，要么弃用它们。成员们果断地选择了弃用。

实际上，VK_KHR_device_address_commands 扩展中基于设备地址的新创建调用无法与主机命令结合使用，且通过此路径创建的加速结构在设计上仅限于设备。目前正在开发中的新 Vulkan 光线追踪扩展也基于这一假设进行编写。

这不是什么

值得明确指出的是，在小组讨论中出现了一些需要澄清的问题：

• 这不是 API 的移除。不会移除任何入口点，也不会停用任何功能位。
• 这不是关于 CPU/GPU 互操作性的普遍声明。统一内存、可映射内存和主机可见缓冲区均不受影响。
• 这不会影响 VK_KHR_deferred_host_operations 作为并行化工作（如管道编译）的机制；主机侧加速结构命令只是延迟主机操作的一种用法，且并非最重要的用法。

这并非由任何单一供应商推动。该决定是由小组全体成员达成共识的，其中包括目前提供该功能的实现者。

结论

2020 年，主机端加速结构构建还有合理的理由。但到了 2026 年，这种做法就不再合理，并且限制了 Vulkan 光线追踪 API 的发展。通过此次更新，光线追踪生态系统可以采用单一、清晰、基于设备地址的加速结构构建路径向前发展。

Vulkan 光线追踪子组始终欢迎反馈和功能请求，如果您有迁移方面的疑问、我们应该了解的使用场景，或者对未来的光线追踪工作有任何想法，请在Vulkan-Docs 跟踪器上提交。Khronos 成员也可以直接在工作组会议上提出这些问题。

原文：https://www.khronos.org/blog/vulkan-ray-tracing-deprecating-host-side-acceleration-structure-builds