Vulkan 2025：Vulkan API的未来路线图、挑战与易用性改进策略

Vulkan

总结：

Vulkan战略官Tobias Hector阐述了Vulkan的未来发展方向。

• Vulkan 1.0的设计目标：主要为AAA游戏和现代硬件设计，强调直接暴露硬件能力和明确的API路径。
• 2025年Vulkan的现状：主要成功在于作为可移植性目标和分层技术，许多AAA游戏通过转换层使用Vulkan，而非直接集成。这导致了API使用上的“脱节”和碎片化。
• 路线图的作用：路线图旨在通过标准化最低要求、提供推荐的API路径以及协调硬件供应商来解决这些问题，确保Vulkan的未来发展能够跟上生态系统的需求。
• 提高易用性：一个关键目标是让Vulkan变得“易用”，这包括指导硬件发展以简化API、进行更周全的设计、收集广泛反馈，并明确弃用不推荐的旧功能。
• Vulkan 2.0的考量：目前不考虑推出Vulkan 2.0，因为其定义不明确且与现有Vulkan 1.x版本不兼容的缺点远大于优点。重点是在1.x框架内进行迭代和改进。

Vulkan 1.0 的设计理念 [0:01:04]

Vulkan 1.0 的设计初衷是为了更好地适应现代硬件，并与 AAA 游戏开发者紧密合作。

• 为现代硬件优化
  • 明确设计以更直接地暴露硬件
  • 通过 API 提供明确的“最佳实践”路径
  • 重新思考规范的编写方式，例如：更清晰的正式约束
• 与AAA游戏开发者共同设计
  • 暴露所有位以实现最大性能
  • 多位开发者参与设计
  • 在早期游戏中取得多项成功，例如：《塔罗斯的法则》、《Dota 2》、《毁灭战士》

2025年的Vulkan现状与挑战 [0:02:07]

当前，Vulkan 的主要成功并非直接来自 AAA 游戏引擎，其作为可移植性目标和分层技术的兴趣日益增长，但也面临着API碎片化的挑战。

• 主要成功案例并非直接来自AAA游戏引擎
  • AAA 游戏仍然是重要的使用案例
  • 但许多游戏并不直接使用 Vulkan
  • 许多 AAA 游戏通过诸如 Steam Deck 上的 dxvk、vkd3d-proton 或 Android 平台上的 ANGLE 运行 OpenGL ES 游戏来间接使用 Vulkan。
• 作为可移植性目标和分层技术
  • 对 OpenGL ES (ANGLE)、OpenGL (Zink)、WebGPU 和 DirectX (vkd3d-proton, dxvk) 的兴趣浓厚。
  • Steam Deck 和 Proton 的关键组成部分
  • 许多 Adobe/Autodesk 产品和开源工具（如 Blender）使用 Vulkan 作为专业图形可移植性目标。
• API的“脱节”与碎片化
  • 新受众需要新工具：引入了许多新的做事方式，Vulkan 不再是精简、有主见的 API，选择变得令人望而生畏。
  • 用例已经演变：十年前的设计选择开始造成问题，例如渲染通道对象、管道和图像布局。
  • 碎片化问题日益严重：存在许多来自大多数（但不是所有）供应商支持的 EXT 扩展，核心中的重要限制和功能仍然是可选的。

    

超越API本身的标准化 [0:04:21]

为了解决当前面临的挑战，Vulkan 团队需要更广泛地进行标准化，而不仅仅局限于 API 本身。

• 标准化最低要求
  • 减少可选功能和限制
  • 确保跨平台可靠支持
• 标准化API路径
  • 再次赋予 Vulkan “主见”
  • 使做正确的事情变得容易，例如：在 2025 年使用动态渲染（Dynamic Rendering）进行渲染。
• 标准化硬件要求
  • 鼓励供应商为新功能设计新硬件
  • 而非围绕旧硬件设计新功能

Vulkan路线图的制定与目的 [0:05:15]

Vulkan 路线图的制定是一个多年的努力成果，旨在设定行业方向、确保问责制并支持更具雄心勃勃的项目。

• 路线图并非开发者配置文件 [0:05:30]
  • 路线图里程碑不是开发者配置文件，它们不适合开发者直接作为目标。
  • 开发者配置文件工具（SDK的一部分）用于检查设备是否支持一组特定的功能，开发者仍应使用这些工具。

    

• 设定行业方向 [0:06:30]
  • 路线图为新硬件设定了前瞻性目标，并为新中高端 GPU 设定了里程碑，使其在发布当年实现。
  • 确保所有硬件供应商在解决问题、确定解决方案以及如何实现方面达成一致，并设定时间表。
  • 核心规范支持当前 GPU，可支持当前 GPU 的功能被整合到核心中。

    

• 用于问责制和雄心勃勃的项目 [0:07:03]
  • 里程碑对开发者在发布时并无用处：它们引导我们走向未来的支持，最终其内容将变得可靠可用（例如，五年后的路线图里程碑可能成为有用的开发者目标）。发布里程碑有助于更快实现这些目标。
  • 更具雄心勃勃的项目：提供空间和时间来正确设计功能，避免在最后一刻仓促推出功能，并将多个功能协调成一个单一解决方案。
  • 公开发布可确保问责制：确保我们会交付产品，确保我们努力修复问题，并确保我们的硬件路线图有目标。

    

利用路线图解决碎片化问题 [0:08:46]

Vulkan 团队正在利用路线图来协调市场压力，并与合作伙伴紧密合作，以解决生态系统中的碎片化问题。

• 广泛的生态系统差距 [0:08:49]
  • 例如，Android 基线配置文件与最新独立 GPU 之间存在巨大的功能支持差距。

    

• 对应用程序的影响 [0:09:04]
  • 应用程序开发者需要处理代码分歧、大量的特性开关、不同的扩展集以及完成常见任务的多种路径。
  • 这可能导致应用程序在意外的设备或条件下崩溃。
  • 通过简单地添加更多功能无法解决问题，因为旧的驱动程序不会更新，差距会因此扩大。

    

    

• 通过提高基线来缩小差距 [0:10:04]
  • 路线图可以提高要求，例如要求可选功能和增加最低限制（仅限于高端）。
  • 核心 API 源自路线图，设定行业最低标准，旨在缩小差距。
  • 对于旧设备、旧平台或嵌入式设备，路线图无法直接提供帮助，但其长期目标是预防未来发生类似问题。

    

• 与合作伙伴协调 [0:11:18]
  • 公开路线图协调市场压力：OEM 合作伙伴希望确保拥有最好的产品，并通常希望提供最新最强大的功能，路线图里程碑能够清晰地打包这些功能。
  • 定义明确的路线图有助于与合作伙伴协调：确保可以与平台供应商对齐（例如，Android 要求与 Vulkan 核心和路线图协同开发），并协调新功能发布，以允许软件项目进行切换。
  • 这为硬件供应商和大型软件项目（如 vkd3d-proton/Steam Deck）提供了共同的语言和明确的未来目标，减少了意外的功能不兼容。

    

让Vulkan变得“易用” [0:14:14]

“让 Vulkan 变得易用”是 Vulkan 工作组的一个关键目标，虽然这听起来像是一个巨大的方向转变，但实际上是在“不妥协地关注性能”的基础上增加了新的约束。

• Vulkan使用困难的现状 [0:14:14]
  • Vulkan 众所周知难以使用，令人沮丧。
  • Vulkan 过去一直强调“不妥协地关注性能”，这意味着需要暴露硬件的每一个细节以实现性能，但这也导致了使用的复杂性。
• 实现性能与易用性兼得的目标 [0:14:59]
  • 目标是让 Vulkan 在提供高性能的同时，也能变得易于使用，甚至“令人愉快”。
  • 这并非巨大的方向性转变，而是在性能优先的基础上增加了一个新的约束。

    

• 如何实现 [0:16:17]
  • 通过硬件演进来简化API：利用路线图引导硬件在未来版本中简化 API，例如简化描述符（Descriptors）。这意味着硬件将不再需要依赖 API 中某些复杂、难以处理的“角落”信息。
  • 更周全的设计：在设计新功能时，更多地考虑实际用例，使其更易于获得性能，例如 VK_KHR_dynamic_rendering[local_read] 的设计，旨在简化渲染通道的使用。
  • 收集更广泛、更详细的反馈：利用 EXT 扩展进行公开测试，并与 ISV 合作伙伴协商，确保核心/KHR 功能获得多样化的反馈。例如，通过 Graphics Pipeline Library 和 Shader Object 两个不同扩展的经验，整合出一个更好的 KHR 解决方案。
  • 弃用旧功能并升级规范：明确指出可以或应该避免的功能。例如，渲染通道对象（Render Pass Objects）虽然仍在规范中，但开发者应使用动态渲染（Dynamic Rendering）或动态本地读取（Dynamic Rendering Local Read），因为它们提供了更简单且性能相当的替代方案。

    

方向性改变与未来展望 [0:22:41]

Vulkan 工作组正在从被动应对转向主动规划，通过多年的努力和路线图的引导，已经开始看到积极的成果。

• Vulkan 工作组是一个由数十个成员组织组成的协作机构。
• 路线图是多年努力的产物，最初的想法内核已有 5-6 年历史，第一个路线图里程碑在 4 年前发布。
• 我们正在从被动转向主动，旨在走在生态系统需求的前面，而不仅仅是应对它们。
• 已经开始看到好处：一些硬件路线图已经发生变化，许多复杂项目正在进行中。
• 未来将继续通过 Discord 和 GitHub 渠道收集开发者反馈，以持续改进 Vulkan。