Vulkan 中的扩展是否允许添加新功能？
Are extensions in Vulkan allowed to add new functionality?
Differences in any of the Vulkan version numbers indicates a change to the API in some way, with each part of the version number indicating a different scope of changes.
A difference in patch version numbers indicates that some usually small part of the specification or header has been modified, typically to fix a bug, and may have an impact on the behavior of existing functionality. Differences in this version number should not affect either full compatibility or backwards compatibility between two versions, or add additional interfaces to the API.
A difference in minor version numbers indicates that some amount of new functionality has been added. This will usually include new interfaces in the header, and may also include behavior changes and bug fixes. Functionality may be deprecated in a minor revision, but will not be removed. When a new minor version is introduced, the patch version is reset to 0, and each minor revision maintains its own set of patch versions. Differences in this version should not affect backwards compatibility, but will affect full compatibility.
A difference in major version numbers indicates a large set of changes to the API, potentially including new functionality and header interfaces, behavioral changes, removal of deprecated features, modification or outright replacement of any feature, and is thus very likely to break any and all compatibility. Differences in this version will typically require significant modification to an application in order for it to function.
这对扩展意味着什么？例如Swapchain
Dependencies
This extension is written against version 1.0 of the Vulkan API.
This extension requires VK_KHR_surface.
这是否意味着此扩展程序将来不会添加任何功能？例如，如果 Vulkan 规范将其次要版本升级到 1.1.0，是否允许该规范向现有扩展添加新功能？
我可以假设现有扩展的新功能只会作为新扩展发布吗？
specVersion is the version of this extension. It is an integer, incremented with backward compatible changes.
如果在未来的修订版中可以扩展扩展，这似乎很奇怪，因为 Vulkan 使用版本格式 Major, Minor, Patch，而扩展仅使用整数。如果扩展会在未来的修订版中添加功能，我希望扩展将使用 Minor, Patch。
1)
它对扩展的意义不大，因为它是（除非另有说明）（核心）Vulkan 的版本控制方案。
目前，扩展 header 是核心 header 的一部分，因此扩展更改（需要 header 更改）将意味着核心补丁版本的增加，当它发布于header.
2)
Dependency 主要意味着您不能启用扩展，除非您也启用依赖项。 （它有点 under-specified。例如，尚不清楚仅在多大程度上重用其他扩展的 structures/enums 是一种依赖。以及 "written against" 究竟意味着什么。但是 NVM 那...）
我认为你的含义不正确，但合理：
只要是 backwards-compatible 就应该允许添加新功能（实际上与核心 Vulkan 次要版本无关）。但我希望开发人员会做出一些美学考虑（向扩展添加 alt 命令等可能会变得丑陋）。
在 Vulkan 过渡到 1.1 时扩展应该能够保持有效（因为它应该是 backwards-compatible）。
核心 Vulkan 版本 2 必须发生其他事情。但我认为还没有人为此感到困扰。在最坏的情况下，他们可以 "cheat" 并以不同方式指定扩展版本应该如何工作。或者更可能只是废弃所有 Vk1 扩展（因为它们将隐含地与 Vk2 不兼容）。
3)
有小版本就好了，但不是绝对必要的。
您是否知道所需功能出现在 X 次要版本或 X（仅整数）修订版中并不重要。
无论如何，考虑到大多数扩展都是版本 1，这将是一种矫枉过正的设计。
specVersion 有点用词不当（可能是 copy-paste 错误）。在规范的其余部分，它被称为 revision.
Differences in any of the Vulkan version numbers indicates a change to the API in some way, with each part of the version number indicating a different scope of changes.
A difference in patch version numbers indicates that some usually small part of the specification or header has been modified, typically to fix a bug, and may have an impact on the behavior of existing functionality. Differences in this version number should not affect either full compatibility or backwards compatibility between two versions, or add additional interfaces to the API.
A difference in minor version numbers indicates that some amount of new functionality has been added. This will usually include new interfaces in the header, and may also include behavior changes and bug fixes. Functionality may be deprecated in a minor revision, but will not be removed. When a new minor version is introduced, the patch version is reset to 0, and each minor revision maintains its own set of patch versions. Differences in this version should not affect backwards compatibility, but will affect full compatibility.
A difference in major version numbers indicates a large set of changes to the API, potentially including new functionality and header interfaces, behavioral changes, removal of deprecated features, modification or outright replacement of any feature, and is thus very likely to break any and all compatibility. Differences in this version will typically require significant modification to an application in order for it to function.
这对扩展意味着什么？例如Swapchain
Dependencies
This extension is written against version 1.0 of the Vulkan API. This extension requires VK_KHR_surface.
这是否意味着此扩展程序将来不会添加任何功能？例如，如果 Vulkan 规范将其次要版本升级到 1.1.0，是否允许该规范向现有扩展添加新功能？
我可以假设现有扩展的新功能只会作为新扩展发布吗？
specVersion is the version of this extension. It is an integer, incremented with backward compatible changes.
如果在未来的修订版中可以扩展扩展，这似乎很奇怪，因为 Vulkan 使用版本格式 Major, Minor, Patch，而扩展仅使用整数。如果扩展会在未来的修订版中添加功能，我希望扩展将使用 Minor, Patch。
1)
它对扩展的意义不大，因为它是（除非另有说明）（核心）Vulkan 的版本控制方案。
目前，扩展 header 是核心 header 的一部分，因此扩展更改（需要 header 更改）将意味着核心补丁版本的增加，当它发布于header.
2)
Dependency 主要意味着您不能启用扩展，除非您也启用依赖项。 （它有点 under-specified。例如，尚不清楚仅在多大程度上重用其他扩展的 structures/enums 是一种依赖。以及 "written against" 究竟意味着什么。但是 NVM 那...）
我认为你的含义不正确，但合理：
只要是 backwards-compatible 就应该允许添加新功能（实际上与核心 Vulkan 次要版本无关）。但我希望开发人员会做出一些美学考虑（向扩展添加 alt 命令等可能会变得丑陋）。
在 Vulkan 过渡到 1.1 时扩展应该能够保持有效（因为它应该是 backwards-compatible）。
核心 Vulkan 版本 2 必须发生其他事情。但我认为还没有人为此感到困扰。在最坏的情况下，他们可以 "cheat" 并以不同方式指定扩展版本应该如何工作。或者更可能只是废弃所有 Vk1 扩展（因为它们将隐含地与 Vk2 不兼容）。
3)
有小版本就好了，但不是绝对必要的。
您是否知道所需功能出现在 X 次要版本或 X（仅整数）修订版中并不重要。
无论如何，考虑到大多数扩展都是版本 1，这将是一种矫枉过正的设计。
specVersion 有点用词不当（可能是 copy-paste 错误）。在规范的其余部分，它被称为 revision.