Vulkan工作组通过扩展机制快速推出新功能，但扩展数量激增导致API使用复杂化，开发者面临选择过多、性能路径不明确等问题。团队正逐步简化各子系统，平衡功能丰富性与易用性。

标题：逐步简化Vulkan子系统

在Vulkan®工作组中，当我们想要修改API时——无论是为了支持新的硬件功能、解决新的使用场景，还是填补规范中的空白——我们有一个非常重要的工具：扩展（extensions）！

扩展让我们能够在不等待新核心版本发布的情况下，快速为开发者提供Vulkan API的改进。它们不仅让供应商能够展示新功能，还让我们在将新特性纳入核心规范之前，能够收集社区的反馈。

然而，这种高度可扩展性也带来了代价。随着API扩展数量的增加，我们有时无意中掩盖了最简单的使用方式。开发者面临诸多问题：哪些功能始终可用？实现目标有多少种方法？哪种方法性能最佳？一个应用程序能合理支持多少种API路径？

我们戏称此为"扩展爆炸问题"。从Vulkan现有的扩展数量，以及之前OpenGL/ES™的扩展规模来看，这个问题日益严重。每新增一个扩展，它们之间的相互关联就会呈组合式增长，增加了开发者的决策复杂度。

面对这个长期挑战，我们采取了反直觉的解决方案：添加更多扩展。但这次我们采用了全新策略——子系统替换。不同于以往对API进行增量修改，我们致力于彻底重构整个API子系统，提供完整的替代方案，使开发者能够忽略旧有实现。

VKEXTdescriptor_heap是这一方法的首次实践，它完全取代了Vulkan现有的描述符集子系统。这个扩展凝聚了Vulkan工作组成员的全部心血，获得了堪比重大API修订（如Vulkan 1.0）的关注度。虽然目前以EXT形式发布，但它注定会成为未来的核心功能。

与之前尝试改进描述符模型的VKEXTdescriptor_buffer不同，新扩展完全不与旧描述符集API交互，从根本上改变了应用程序与描述符的交互方式。描述符堆只是内存，描述符只是数据，开发者几乎可以自由操作它们。这种设计更接近游戏主机的开发体验，而非传统可移植API。

该扩展获得了业界前所未有的广泛支持，几乎每个Vulkan工作组成员都参与了贡献。经过近三年的反复打磨，我们确保它不仅能用，而且好用。

为何不直接发布为KHR扩展？因为我们希望获得更广泛开发者的反馈。虽然EXT版本已经稳定可用，但通过这种形式，我们为社区提供了试用和反馈的机会。我们承诺会充分考虑所有建议，以完善最终的KHR规范。

我们明白，仅解决描述符问题远远不够。开发者的需求是我们路线图规划的核心，我们很可能已经在处理您关心的功能。如果您有任何未被重视的问题，欢迎通过Discord或GitHub向我们反馈。

子系统替换需要平衡诸多因素：开发者需求、生态系统要求、供应商路线图、未来发展方向，以及软硬件发布计划等。我们的首要任务是让Vulkan API变得更好用。虽然还有很长的路要走，但像这样的子系统替换无疑是重要的进步。我们期待听到您对这种方法的看法！

总结评论内容：

1. 支持Vulkan改进的观点：

• 认为动态渲染等新特性简化了代码："Going from render passes to dynamic rendering really simplified my code"
• 赞赏Khronos解决编程模型和功能问题："The main problem with Vulkan isn't the programming model or the lack of features. These are tackled by Khronos"

2. 对Vulkan复杂性的批评：

• 认为API过于复杂："There are so many completely needlessly complex things"
• 指出缺少简单实现路径："What's still sorely missing is a single-line device malloc...and an entirely descriptor-free code path"

3. 与OpenCL/OpenGL比较的观点：

• 从OpenCL转换困难："it's a massive pain coming from OpenCL"
• 认为OpenGL仍具优势："I'll keep enjoying OpenGL 4.6...which allows hassle-free buffer allocation"

4. 驱动支持问题：

• 指出驱动更新不统一："The problem is with coverage and update distribution"
• 提到老旧系统问题："There are always weird systems with old drivers"

5. 对Android平台的担忧：

• 批评扩展混乱："already worse than OpenGL"
• 指出Android更新滞后："most of these fixes aren't coming into Android"

6. 对未来改进的期待：

• 期待功能完善："I suspect we are only 5-10 years away until Vulkan is finaly usable"
• 希望简化API："making the explicit API optional"