很多人说，一旦扩展成为核心，就不能再指望它出现在设备的扩展列表中。为了举个例子：

VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME

这个在1.3版本时成为核心。

因此如果设备此时符合1.3标准，它将会在VkPhysicalDeviceVulkan13Features结构中指示它是否支持该特性，而不是VkPhysicalDeviceExtendedDynamicStateFeaturesEXT。传闻是，一旦发生这种情况，我就再也不能指望设备具备该扩展：

VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME

因为从设备的角度来看，它现在已经成为核心功能。但这会带来一个巨大的问题。如果我用实例版本是1.2来创建一个Vulkan应用，以便支持较旧的系统：

vkAppInfo.apiVersion = VK_API_VERSION_1_2;

那么从技术上讲，我不能使用用于查询核心版本的新结构体，连非EXT的函数指针也无法使用，只能走旧的做法：通过查询设备扩展VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME并使用EXT的函数指针。鉴于一旦成为核心，该扩展就可能从设备中被移除，这难道不几乎把一切都搞砸了吗？

编辑：一些AI助手对我说过：

未来可预见性：即使在2028年的驱动开发者决定在应用请求1.4实例时隐藏1.2扩展， 他们也不会对你隐藏，因为你明确要求了1.2实例。

我只是想知道这是否属实。

解决方案

Vulkan接口设计为向前兼容和向后兼容。你可以用Vulkan 1.3的加载器和Vulkan 1.2的驱动来创建一个能使用Vulkan 1.4的应用。或者你也可以用Vulkan 1.4的加载器和Vulkan 1.3的驱动来创建一个Vulkan 1.1的应用。

如果你创建的实例或设备版本较高，就不一定需要提供那些已经主流化的扩展；然而如果你创建的实例或设备版本较低，且驱动之前提供过某个扩展，通常预计它会继续提供该扩展。把它保留在驱动中几乎不需要额外工作，因此移除它几乎没有道理。

唯一真正可能遇到困难的情况是，如果驱动实现了原本属于扩展的核心功能，但他们从未实现过该扩展。在这种情况下，他们没有义务为较旧的Vulkan版本重新添加该扩展。不过在实际操作中，这些公司规模足够大，向后移植一个扩展也并不费太多功夫。

从本质上讲，这确实是一种担忧：驱动厂商可以做任何他们想做的事，但如果他们这么做，产品就会变得不那么受欢迎，因此市场力量实际上会推动他们提供显卡所具备的全部图形功能。