简介
本文档，后文称为“Vulkan 规范”或简称“规范”，描述了 Vulkan 应用程序编程接口 (API)。Vulkan 是一个为显式控制底层图形和计算功能而设计的 C99 API。
规范的规范版本可在官方 Vulkan 注册表（https://registry.khronos.org/vulkan/）中找到。用于生成 Vulkan 规范的源文件存储在 Vulkan 文档存储库（https://github.com/KhronosGroup/Vulkan-Docs）中。
该源存储库还具有公共问题跟踪器，并允许提交改进规范的拉取请求。
文档约定
Vulkan 规范旨在供 API 的实现者和寻求使用 API 的应用程序开发人员使用，从而在双方之间形成合同。规范文本可能会针对任何一方；通常，目标受众可以从上下文中推断出来，尽管某些部分定义为仅针对其中一方。（例如，有效用法部分仅针对应用程序开发人员）。规范文本中定义的任何要求、禁止、建议或选项仅对该文本的受众施加。
规范性要求
Vulkan 规范结合使用规范术语和规范描述来表达其对应用程序和实现施加的要求。符合对应用程序施加的所有规范性要求的应用程序被称为对 API 进行**有效使用**；未能遵守此类要求会导致**未定义**的行为，如下面的有效用法部分所述。在本文档的上下文中，符合对实现施加的所有规范性要求的实现被称为**一致**的。
|
Khronos 组织对希望公开声明其 Vulkan 实现是一致的实现者施加了额外的要求。其中包括签署 Vulkan 采用者协议，支付相关费用，并向 Khronos 一致性流程成功提交一致性测试。有关详细信息，请参阅 Khronos 商标指南（https://www.khronos.org/legal/khronos-trademark-guidelines）。 |
规范术语
在本规范中，关键字 必须、必需、应该、可能 和 可选 的解释应如 RFC 2119 - RFC 中用于指示要求级别的关键字（https://www.ietf.org/rfc/rfc2119.txt）中所述。附加关键字 可选地 是 可选 的另一种形式，用于语法上适当的地方。这些关键字在规范中突出显示，以表明它们正在以特定的技术含义使用。
附加关键字 可以 和 不能 的解释应为描述应用程序的功能，如下所示
- 可以
-
这个词表示应用程序能够执行所描述的操作。
- 不能
-
这个词表示 API 和/或执行环境没有提供应用程序可以表达或完成所描述的操作的机制。
这些关键字永远不会用于针对实现者的文本中。
|
本规范中使用的 不能 和 禁止 之间存在重要区别。不能 指的是 API 没有提供任何方法供应用程序表达或完成的内容。禁止 描述的是应用程序能够表达的内容，但这并不是对 API 的有效使用，并且会产生**未定义**且可能无法恢复的后果。 |
规范性描述
在 Vulkan 规范中，规范性术语 必须 主要用于描述**应用程序**行为，特别是限制应用程序向实现发出的哪些输入或命令被认为是有效的。
为了约束**实现**行为，规范有时使用 必须，但更常见的是简单地描述实现响应指定命令和输入时的行为。除非另有明确说明，否则此类对实现行为的引用描述的是**一致**实现的行为，并表达了实现为了符合规范而必须满足的规范性要求。例如，如果规范说“在**指定条件**下，返回错误代码 VK_ERROR_FEATURE_NOT_PRESENT”，则该行为是规范的要求，并且在该条件下不返回该错误代码的实现是不一致的。
当使用规范性术语 may、should 或 optional 来描述实现行为时，它们定义了符合规范的实现可能表现或可能不表现的可选或替代行为。这些陈述也是规范性的。例如，如果规范说“在特定条件下，实现应该返回 A，但可能改为返回 B”，那么在该条件下返回 A 或 B 的实现是符合规范的（假设它没有违反其他规范性要求），而返回其他任何内容的实现则不符合规范。
规范性引用
以下文档被规范部分的规范引用：
IEEE。2008 年 8 月。浮点算术 IEEE 标准。IEEE Std 754-2008。https://dx.doi.org/10.1109/IEEESTD.2008.4610935 。
Andrew Garrard。Khronos 数据格式规范，版本 1.3。https://registry.khronos.org/DataFormat/specs/1.3/dataformat.1.3.html 。
John Kessenich。用于 GLSL 的 SPIR-V 扩展指令，版本 1.00 (2016 年 2 月 10 日)。https://registry.khronos.org/spir-v/ 。
John Kessenich、Boaz Ouriel 和 Raun Krisch。SPIR-V 规范，版本 1.5，修订版 3，统一（2020 年 4 月 24 日）。https://registry.khronos.org/spir-v/ 。
ITU-T。用于通用视听服务的 H.264 高级视频编码（2021 年 8 月）。https://www.itu.int/rec/T-REC-H.264-202108-I/ 。
ITU-T。H.265 高效视频编码（2021 年 8 月）。https://www.itu.int/rec/T-REC-H.265-202108-S/ 。
开放媒体联盟。AV1 比特流和解码过程规范（2019 年 1 月 8 日）。https://aomediacodec.github.io/av1-spec/av1-spec.pdf 。
Jon Leech。Khronos Vulkan API 注册表（2023 年 2 月 26 日）。https://registry.khronos.org/vulkan/specs/latest/registry.html 。
Jon Leech 和 Tobias Hector。Vulkan 文档和扩展：程序和约定（2023 年 2 月 26 日）。https://registry.khronos.org/vulkan/specs/latest/styleguide.html 。
Vulkan 加载器接口的架构（2021 年 10 月）。https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md 。
信息性语言
规范中的某些语言纯粹是信息性的，旨在提供背景信息或向实现者或开发人员提出建议。此类语言不对实现或应用程序施加规范性要求。
所有“注意”都是隐含的信息性内容。
如果整个章节、小节或附录仅包含信息性语言，则其标题将附加“(信息性)”。除非在标题中注明，否则本文档中的所有章节、小节和附录均为规范性的。
批准
Vulkan 核心版本或扩展的批准是指由 Khronos 推广委员会投票授予的状态，该状态将该核心版本或扩展置于 Khronos IP 权利政策的保护伞下。
所有 Vulkan 核心版本和 KHR 扩展（包括临时规范）都已批准，一些多供应商 EXT 扩展也已批准。扩展的批准状态在层 & 扩展 (信息性)附录中描述。
|
批准状态主要对开发 GPU 硬件和 Vulkan 实现的 IHV 感兴趣。对于开发人员来说，批准并不一定意味着扩展“更好”、具有更稳定的 API，或者比实现该功能的替代方法得到更广泛的支持。 已批准和未批准的扩展之间的交互本身未获批准。 |