Vulkan扩展:谁支持哪个?

有一个 website 致力于跟踪这些信息。

也许还有其他的

有 lots

但是KHR和EXT呢?每个人都必须支持它们吗?

KHR扩展通常是折叠到规范中的东西(如vk_khr_外部存储器如何成为1.1中核心vulkan规范的一部分),或者可能是由广泛的供应商和硬件支持的东西,但不一定是所有硬件(如vk_khr_swapchain)。

KHX扩展基本上是KHR扩展的实验版本。它们可能成为KHR扩展,或者被折叠到规范中,但是在它们之前它们也可能发生巨大的变化。

ext扩展并不是特定于供应商的,但它们通常针对一些不太常见的用例,或者更具实验性的用例。它们通常不会成为规范的一部分,而且它们是您在依赖之前需要检查的类型,如果不支持它们的话,还可以计划依赖其他机制。有时候,ext扩展可以演变为khr扩展。

供应商特定的扩展基本上与ext扩展在同一条船上,但由特定的供应商控制。它们也可以演变成KHR扩展或核心规范。例如,khr_external_memory开始时是nv_external_memory。

每个人都必须支持它们吗?

它们只是核心规范所说的强制性的东西。

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

供应商代码标记维护扩展规范的(主要)供应商。通常,允许其他人实现它(尽管通常不会,尤其是在扩展太具体的情况下)。Afaik供应商标记的扩展对包含在规范中的要求最低(我认为只要供应商不破坏任何其他东西,他实际上就有自由的双手)。

可能会有一些实验性/临时性的扩展,即 NVX 以及那些标记的 provisional="true" 在 registry . 从历史上看,它们随后完全从规范中删除,并由最终的继承者替换。

EXT 是特殊的。这意味着多个供应商的协作。这里有许多重要的扩展,例如 VK_EXT_debug_utils 与我们使用的验证层交互。在 extension appendix 你可以看到Valve\Lurg、Google、AMD、NV、renderDoc、Epic和oxide的人在上面签名。

KHR 也是特别的。它类似于 额外的 .它和Khronos(规范组)的建议一样好;它是一个“认可的”扩展。可能有一些更困难的需求(我认为需要有三个现有的实现)。正如@jherico所说,它们很有可能成为Vulkan未来版本的核心功能。

扩展按设计可选。唯一必须的是 VK_KHR_sampler_mirror_clamp_to_edge 因为历史原因。