Vulkan 中的扩展是否允许添加新功能？

Question

https://www.khronos.org/registry/vulkan/specs/1.0-extensions/xhtml/vkspec.html#fundamentals-versionnum

任何 Vulkan 版本号的差异表示 API 以某种方式发生了变化，版本号的每一部分表示不同的变化范围。

补丁版本号的差异表明规范或标头的某些通常很小的部分已被修改，通常是为了修复错误，并且可能会对现有功能的行为产生影响。此版本号的差异不应影响两个版本之间的完全兼容性或向后兼容性，也不应向 API 添加其他接口。

次要版本号的差异表明添加了一些新功能。这通常会在标头中包含新接口，还可能包括行为更改和错误修复。功能可能在次要修订中被弃用，但不会被删除。当引入新的次要版本时，补丁版本重置为 0，并且每个次要版本都维护自己的一组补丁版本。此版本的差异不应影响向后兼容性，但会影响完全兼容性。

主要版本号的差异表明 API 有大量更改，可能包括新功能和标头接口、行为更改、删除不推荐使用的功能、修改或彻底替换任何功能，因此很可能会中断任何和所有的兼容性。此版本中的差异通常需要对应用程序进行重大修改才能使其正常运行。

这对扩展意味着什么？例如Swapchain

依赖关系

此扩展是针对 Vulkan API 1.0 版编写的。 此扩展需要 VK_KHR_surface。

这是否意味着此扩展程序将来不会添加任何功能？例如，如果 Vulkan 规范将其次要版本升级为 1.1.0，那么该规范是否允许向现有扩展添加新功能？

我可以假设现有扩展的新功能只会作为新扩展发布吗？

看着VkExtensionProperties

specVersion 是这个扩展的版本。它是一个整数，随着向后兼容的变化而递增。

如果在未来的修订版中可以扩展扩展，这似乎很奇怪，因为 Vulkan 使用版本格式 Major, Minor, Patch，而扩展只使用整数。我希望扩展会使用Minor, Patch，如果它们会在未来的修订版中添加功能。

Answer 1

1)
这对扩展来说意义不大，因为它（除非另有说明）是（核心）Vulkan 的版本控制方案。

目前，扩展标头是核心标头的一部分，因此扩展更改（需要更改标头）将意味着核心补丁版本在该标头中发布时会发生冲突。

2)
依赖主要意味着你不能启用扩展，除非你也启用了依赖。 （它有点未指定。例如，尚不清楚仅重用其他扩展的结构/枚举在多大程度上是一种依赖关系。以及“针对”的确切含义。但是 NVM...）

我认为你的暗示是不正确的，但有道理：

应该允许添加新功能，只要它向后兼容（实际上与核心 Vulkan 次要版本无关）。但我希望开发人员会考虑一些美学上的考虑（在扩展中添加 alt 命令等可能会变得丑陋）。

扩展应该能够在 Vulkan 转换到 1.1 时保持有效（因为它应该是向后兼容的）。

核心 Vulkan 版本 2 必须发生其他事情。但我认为目前还没有人对此感到困扰。在最坏的情况下，他们可以“欺骗”并以不同的方式指定扩展版本应该如何工作。或者更可能只是废弃所有 Vk1 扩展（因为它们会隐含地与 Vk2 不兼容）。

3)
有次要版本会很好，但不是绝对必要的。
您是否知道所需的功能是出现在 X 次要版本还是 X（仅整数）版本中，这并不重要。
考虑到大多数扩展都是版本 1，这将是过度设计。

specVersion 有点用词不当（可能是复制粘贴错误）。在规范的其余部分，它被称为 revision。