vulkan扩展名：哪些人支持？

Question

有EXT，KHR或AMD或NV扩展名。也许还有一些。我知道NV的意思是Nvidia，而且nv扩展不太可能被AMD支持。但是，khr或ext呢？他们是否受到所有人的强制支持？

Answer 1

有一个website专门用于跟踪此信息。

  

也许还有一些

有lots

  

但是khr或ext呢？他们是否受到所有人的强制支持？

KHR扩展通常是可以折叠到规范中的内容（例如VK_KHR_external_memory如何成为1.1版核心Vulkan规范的一部分），或者是可能被广泛的供应商和硬件支持的东西，但不一定所有硬件（例如VK_KHR_swapchain）。

KHX扩展基本上是KHR扩展的实验版本。它们可能会成为KHR的扩展，也可能会被纳入规范中，但是在这样做之前，它们也可能会发生巨大变化。

EXT扩展不是特定于供应商的，但是它们通常针对的是一些不太常见的用例，或者更具实验性的东西。它们通常永远不会成为规范的一部分，它们是您在依赖之前需要检查的事情，并且如果不支持它们，则有计划依靠其他某种机制。有时EXT扩展可以演变为KHR扩展。

特定于供应商的扩展基本上与EXT扩展在同一条船上，但是由特定供应商控制。它们也可以演变为KHR扩展或核心规范。例如，KHR_external_memory最初是NV_external_memory。

  

他们是否受到所有人的强制支持？

它们只是强制性的，核心规范说的是强制性的。

Answer 2

还有其他供应商代码。当前所有的供应商代码都在官方registry list中。

供应商代码标记（主要）供应商维护扩展规范。通常，允许其他人实现它（尽管通常不这样做，尤其是在扩展过于具体的情况下）。相信供应商标记的扩展对规范中包含的要求最低（我认为供应商只要不破坏其他任何东西，实际上就可以放手）。

可能会有一些实验性的\ provisional扩展名，即NVX，以及在registry中标有provisional="true"的扩展名。从历史上看，它们随后会从规格中完全删除，并由最终的后继产品取代。

EXT很特殊。这意味着多个供应商的协作。这里有许多重要的扩展，甚至例如基本VK_EXT_debug_utils，它与我们都使用的验证层进行交互。在extension appendix中，您可以看到在Valve \ LunarG，Google，AMD，NV，RenderDoc，Epic和Oxide上签名的人。

KHR也很特殊。它类似于EXT。它和Khronos（规范组）的建议一样好；这是“已批准”的扩展名。可能会有一些更严格的要求（我认为需要三个现有的实现）。正如@Jherico所说，他们很有可能成为Vulkan未来版本中的核心功能。

扩展名是设计使然是可选的。出于历史原因，VK_KHR_sampler_mirror_clamp_to_edge仅是必填项。