本文翻译自 Simplifying Vulkan One Subsystem at a Time，原载于 Hacker News。

引言

当我们 Vulkan® 工作组想要修改 API 时——无论是为了暴露新的硬件特性、解决新的用例，还是填补规范中的空白——我们都有一个不可或缺的工具：扩展（Extensions）！

扩展让我们能够快速将 Vulkan API 的改进交付给开发者，而无需等待新的核心版本发布。它允许供应商暴露新功能，并让我们在将这些特性固化为核心规范之前收集社区反馈。

这听起来很棒！开发者能快速获得新功能——有什么不喜欢的呢？嗯……

扩展爆炸问题 💥

拥有如此强大的扩展性是有代价的。随着我们向 API 添加越来越多的扩展，有时会无意中掩盖使用它的最简单方式。你可以依赖哪些功能始终存在？有多少种方法可以做你想做的事情？其中哪些方法能提供最佳性能？在一个应用程序中合理支持多少条 API 路径？

由于我们现在拥有的扩展数量——以及之前在 OpenGL/ES™ 中存在的扩展数量——我们有时”亲切地”称之为”扩展爆炸问题”。我们添加的越多，它们之间的相互依赖和交互就越多，为开发者的决策空间呈指数级增长。

这是我们从 Vulkan 开发者群体中听到的一个持久挑战，但直到现在我们还没有一个好的解决方案。

当我们发布 Vulkan 1.0 时，它给了我们从 OpenGL® 转型的全新起点，但现在 Vulkan 走过十年后，我们再次面临同样的问题。那么，答案是什么？我们应该每隔几年就从头重建整个 API 吗？

不——信不信由你，我们添加更多扩展！

…🤨？

子系统替换策略

这似乎有悖常理，但添加更多扩展确实是改善局势的一种方式。然而，这不能只是照常营业。我们必须采取不同的方法。

不是增量式地添加或更改 API 并增加复杂性，而是要整体修订 API 子系统，制造完整的替代方案，让你可以忽略之前的所有内容，并配合支持工具和行业支持，确保新方法无处不在地部署。

VK_EXT_descriptor_heap 是这种方法的第一次具体尝试，完全替换了 Vulkan 中现有的 descriptor set 子系统。Vulkan 工作组成员为此倾注了所有心血，它获得了我们在主要 API 修订（如 Vulkan 1.0）中历史上才会看到的那种关注。虽然它目前以 EXT 形式发布，但它非常有可能成为未来的核心功能。

我们之前曾尝试用 VK_EXT_descriptor_buffer 修复 descriptor 模型，开发者在这方面取得了一些成功，但我们对现有的 descriptor set 功能使用了增量式（尽管很大！）的改进，这使得必须检查各种 descriptor set 扩展。这种增量方法也没有吸引广泛的行业支持，导致跨供应商的可移植性问题。我们知道我们拥有重要内容的核心，但它需要重新思考才能坚持下去。因此，我们从 VK_EXT_descriptor_buffer 中吸取了教训，设计了一个全新的子系统。

新的 VK_EXT_descriptor_heap 扩展不与之前的 descriptor set API 交互，包括 layouts、push descriptors 或 descriptor buffers——它完全替换了所有这些。这个扩展不仅仅是试图稍微整理一下 API，它从根本上改变了 Vulkan 应用程序与 descriptors 交互的方式。Descriptors 不再是你通过一系列笨拙的 API 命令和限制性着色器绑定管理的某种不透明的东西。Descriptor heaps 只是内存，descriptors 只是数据，你几乎可以随心所欲地做任何你想做的事情。虽然存在一些限制，但它更接近于你在主机上所期望的，而不是在可移植 API 中。

这个扩展也有来自行业各方的贡献，远超我们的典型扩展。随意查看贡献者名单——它非常广泛。这个扩展几乎得到了 Vulkan 工作组中每个人的有意义投入。我们一起花了过去三年的大部分时间迭代和改进这个扩展，确保它不仅有效，而且运作良好。

既然有这么多支持，为什么不是 KHR？

我们也希望确保得到你的支持。

对于如此重要的功能，我们希望确保正确无误。我们确信我们所构建的内容已经是一个巨大的改进和出色的功能，但通过将其作为 EXT 发布，我们让更广泛的社区有机会试用它，弄清楚其复杂性，并可能建议使其变得更好的方法。

EXT 不会改变，所以你今天就可以在发布的应用程序中使用它；当我们最终发布 KHR 版本时，如果你选择使用它，我们的目标是让过渡尽可能简单。

如果你确实在新扩展中发现任何你认为可以简化或改进的内容，我们在最终确定 KHR 规范时会考虑任何反馈。通过这样做，我们将努力使所有内容尽可能完美，避免以后添加额外的扩展来修复问题。

虽然我们无法保证最终的 KHR 何时会出现，但在接下来的 9 个月内获得反馈将给我们最好的机会来整合你的意见。

请使用这个扩展并让我们知道进展如何！

很好。你解决了 descriptors 的问题。那么 呢？

开发者的需求是我们路线图规划的核心，我们致力于解决我们听到的请求。很有可能我们已经在处理你想要的功能。

如果我们没有在某处记录你的问题，或者你认为它没有得到足够的关注，我们鼓励你加入我们的 Discord 或在 GitHub 上提交 issue，让我们知道！

为了替换这样的子系统，我们需要平衡许多考虑因素——开发者需求、生态系统需求、供应商路线图、未来方向以及即将推出的硬件和软件发布等等。处理所有这些需求需要仔细尝试以在第一次就做对。但这并不意味着其中任何需要很慢！我们正在积极研究如何使用这种方法来升级 Vulkan API 的关键部分，并获得强有力的行业支持。

我们现在最重要的优先事项之一是让 Vulkan API 成为一种乐趣。我们知道还有很长的路要走，但我们希望这样经过深思熟虑的子系统替换是朝着这个方向迈出的重要积极步骤。请让我们知道你对这种方法的看法——我们很想听到你的声音！

关键要点

Vulkan 的演进困境：作为从 OpenGL 重构的现代图形 API，Vulkan 在十年发展过程中遇到了与 OpenGL 类似的”扩展爆炸”问题——过多的扩展导致开发者难以选择最佳实践。

创新解决方案：Khronos 工作组提出的”子系统替换”策略不是简单的增量改进，而是整体性地重新设计特定子系统。VK_EXT_descriptor_heap 就是这一策略的首个实践，它完全替换了原有的 descriptor set 机制。

实用主义考量：将新功能先以 EXT（供应商扩展）形式发布，而不是直接作为 KHR（Khronos 标准），给了社区试用和反馈的机会。这种渐进式标准化既保证了稳定性，又能收集真实使用场景的改进建议。

行业协作价值：这个扩展得到了来自 Vulkan 工作组几乎所有成员的贡献，花了三年时间迭代。这种广泛的行业参与是确保跨平台兼容性和实际可用性的关键。

给开发者的启示：如果你正在使用或考虑使用 Vulkan，现在就可以试用 VK_EXT_descriptor_heap。这不仅是技术升级，更是图形 API 设计思维的一次重要进化——从增量修补到系统性重构。

未来展望：这种子系统替换的方法很可能会应用到 Vulkan API 的其他部分。如果你有特定痛点，通过 Discord 或 GitHub 反馈给 Khronos 团队，你的意见可能会影响下一轮改进。