DirectX 采用 SPIR-V 作为未来的交换格式

2024 年 9 月 19 日，DirectX 开发博客上发表文章表示，Direct3D 和 HLSL 团队分享了 GPU 可编程性的下一大步。一旦着色器模型 7 发布，DirectX 12 将接受编译为 SPIR-V™ 的着色器。HLSL 团队致力于开放开发流程，并与 Khronos® Group 和 LLVM 项目合作。团队正在与 Khronos SPIR™ 和 Vulkan® 工作组合作，以确保这一过渡有利于整个开发生态系统。

以下为全文内容。

作者：Chris , Cassie
原文：https://devblogs.microsoft.com/directx/directx-adopting-spir-v/

拥抱开放技术和标准

我们的使命是让 HLSL 成为为任何设备或 GPU 运行时 API 编译图形和计算着色器的最佳语言。为了实现这一目标，HLSL 团队积极拥抱开放技术并与行业标准合作。我们将继续采用和支持最好的开源工具，同时贡献我们自己的创新，使 Direct3D 和其他 Microsoft 技术成为同类最佳。

自 Shader Model 6.0 首次推出以来的 8 年里，Direct3D 和 HLSL 在功能和采用方面都取得了长足的发展。在 GitHub 上发布 DXC 以及来自开源协作者和合作伙伴的巨大贡献在扩大 HLSL 的用户群以包括 Vulkan 和 Metal 开发人员方面发挥了重要作用。作为这一扩展的结果，团队正专注于在 Clang 中开发 HLSL 支持，以使我们能够满足行业对开放性和新功能的需求。当我们从头到尾寻找支持所有用户的最佳方式时，我们正在努力使用 Clang 和 LLVM 支持 DXIL 和 SPIR-V 的 HLSL。

为了更好地实现 HLSL 对 Vulkan 的支持，HLSL 团队现在正在参与 Khronos Group 的 SPIR 和 Vulkan 工作组。这种直接参与将使协作更加顺畅，并更快地采用 Vulkan 功能。我们相信这将确保 HLSL 成为为每个 GPU 运行时环境编写着色器的最佳语言。

HLSL 是业界广泛使用的一种关键着色语言，Khronos 热烈欢迎微软参与并接受 SPIR-V 开放标准，这将使 HLSL、Direct3D 和整个图形生态系统受益。Khronos 将努力确保 SPIR-V 不断发展，并继续满足其所有客户端 API 和语言的需求，现在包括 DX12 和 HLSL。— Khronos 集团总裁 Neil Trevett。

我们致力于支持行业的一个例子是与 Google 建立牢固的合作伙伴关系，共同开发核心 HLSL 语言功能（例如运算符重载）以及用于公开 Vulkan 功能的功能（例如内联 SPIR-V）。我们非常重视这种持续的合作关系，并将在未来继续与 Google 和其他合作伙伴合作。

替代 DXIL 之路

Shader Model 6 及其后续版本极大地扩展了 Direct3D 的功能。如果没有采用基于 LLVM 的 IR 和编译器为 Shader Model 6 带来的功能，光线追踪和工作图等功能就不可能实现。如果您想了解有关交换格式的更多信息，请阅读附录。

展望未来，维护专有 IR 格式（即使基于开源项目）也违背了我们对开放技术的承诺，因此 Shader Model 7.0 将采用 SPIR-V 作为其交换格式。在接下来的几年里，我们将致力于为 Direct3D 定义一个 SPIR-V 环境，以及一组 SPIR-V 扩展，以通过 SPIR-V 支持 Direct3D 当前和未来的所有着色器编程功能。这将使开发人员能够更好地利用现有工具并围绕投资一个 IR 统一生态系统。

除了提供 HLSL 到 Direct3D 的 SPIR-V 的编译器外，我们还将构建和提供转换工具，以将 SPIR-V 转换为 DXIL 以及将 DXIL 转换为 SPIR-V。这些工具将允许驱动程序开发人员逐步过渡并顺利调整工具和驱动程序。

对于使用 AgilitySDK 构建 Direct3D 应用程序的开发人员来说，工作流程基本保持不变。我们确实希望维护操作或编辑已编译着色器的工具的开发人员能够做出一些改变，但我们相信，可用于处理 SPIR-V 二进制文件的强大工具将带来的好处超过过渡成本。

SPIR-V 的核心设计支持可扩展性，这将使 GPU API 功能能够更快地进行创新。使用通用格式来表示编译后的着色器将使多个 API 能够更快地采用这些功能。我们认为，这对于提高整个行业的开发人员生产力来说是一大进步。

这一转变将需要几年时间，我们希望通过尽早公开我们的计划，让开发人员和合作伙伴能够尽可能提前做好适当的规划。

解锁 Direct3D 中的创新

我们对 Shader Model 7 的计划代表着 Direct3D 创新新篇章的开始。通过遵循开放标准并采用最佳开源技术，我们将加速新功能的开发并快速推出尖端硬件功能。

利用行业标准交换格式将允许微软和硬件供应商将他们的工程努力集中在为下一代应用程序提供支持的差异化功能上，而不是重复常见的功能。

随着这些即将到来的变化以及我们对 Direct3D 的持续投资，DirectX 的未来从未如此光明。

附录：GPU 交换格式简史

与 CPU 不同，GPU 并未采用常见的长寿命架构。这意味着，虽然 10 多年前编译过一次的应用程序的 CPU 代码可能在全新设备上运行，但如果 GPU 代码被编译为 GPU 的原生指令集架构 (ISA)，则不会具有相同的可移植性。

为了解决这个问题，当 GPU 驱动程序可以针对 GPU 的特定硬件功能进行优化时，GPU 编程模型通常会将生成本机 ISA 推迟到运行时。图形编程 API 支持以源代码形式或以虚拟 ISA（在更高级别抽象常见硬件功能）的形式交付着色器程序。这两种形式都允许 GPU 驱动程序更有效地降低和优化程序，但使用虚拟 ISA 可以减少驱动程序生成本机代码所需的时间。因此，虚拟 ISA 已成为为高性能应用程序交付着色器程序的首选方法。

自从 Direct3D 8 中引入着色器可编程性以来，Direct3D 就支持着色器程序的虚拟 ISA。最初的虚拟 ISA DirectX 字节码 (DXBC) 经过演变，最终被基于 LLVM 的 DirectX 中间语言 (DXIL) 所取代。

LLVM 的中间表示 (IR) 为 GPU 可编程性带来了一些重大优势。LLVM 的 IR 可以视为虚拟 ISA，但它本质上是静态单分配 (SSA) IR。大多数著名且广泛使用的优化编译器都使用 SSA IR，因为它们通过简化的程序表示提供了显著的优势，从而更容易编写优化转换。

使用 SSA IR 作为 GPU 程序的交换格式简化了从交换表示到 GPU 驱动程序编译器内部表示的转换，这对于优化和降低到本机 ISA 是必需的。

LLVM 长期以来一直被用作 GPU 交换格式。最初的标准可移植中间表示 (SPIR) 是 LLVM 3.2 的 IR 序列化为 LLVM 的位码格式。

LLVM 的位码格式有一些明显的缺点。值得注意的是，它不是版本稳定的。新版本的 LLVM 支持对旧版 LLVM IR 模块进行有损升级，但新版 LLVM 无法编写可由旧版 LLVM 读取的 IR 模块。此外，LLVM 位码是一种位打包文件格式，它有两个大缺点 (1) 压缩率很差，(2) 很难用非 LLVM 工具读取或写入。

为了解决这些问题，Khronos Group 开发了 SPIR-V 作为 SPIR 的后继者。SPIR-V 在思想上与 LLVM 的 IR 一致，但它支持稳定而简单的二进制序列化。这使得 SPIR-V 比 LLVM IR 更易于通过更简单的工具读取和写入。SPIR-V 是 Khronos Group 开发的各种 GPU 编程技术（包括 Vulkan、OpenCL 和 SYCL）使用的交换格式。

Khronos 和 Khronos Group 徽标是 Khronos Group Inc. 的注册商标。SPIR、SPIR-V 和 SPIR 徽标是 Khronos Group Inc. 的商标。Vulkan 和 Vulkan 徽标是 Khronos Group Inc. 的注册商标。