Vulkan 可以做哪些 OpenGL 4.6+ 不能做的具体事情？

Question

我正在研究继续使用 OpenGL 还是考虑使用 Vulkan 迁移来进行密集的瓶颈渲染对我来说是否更好。

但是，我不想在没有被告知的情况下进行跳跃。我一直在寻找 Vulkan 为我提供的好处，但是通过大量的谷歌搜索，我无法确切地找到可以提高性能的原因。人们会抛出诸如“OpenGL 慢，Vulkan 快得多！”之类的术语。或“低功耗！” 对这个话题不再多说。

因此，我很难评估我面临的问题是否是 Vulkan 可以帮助我解决的问题，或者我的问题是否是由于数量和计算造成的（在这种情况下，Vulkan 对我帮助不大） .

我假设 Vulkan 不会神奇地使管道中的事情变得更快（因为对于相同的缓冲区、制服和着色器，OpenGL 和 Vulkan 之间的三角形着色将大致相同）。我假设在 OpenGL 中导致悲伤的所有事情（例如：帧缓冲区和着色器程序更改）在任何一个 API 中都将同样痛苦。

我认为 Vulkan 提供了一些基于在线阅读无数内容的想法（我猜这肯定不是所有优点，或者这些是否属实）：

• 没有[多？任何？] 绑定（或者更确切地说是“无绑定纹理”的更好版本），当我切换到无绑定纹理时我注意到我获得了显着的性能提升，但如果无绑定纹理有效，这甚至可能不值得作为一个点这样做，因此我不确定 Vulkan 是否在这里添加了任何内容

• 通过组合某种可以在 GPU 上执行而无需发送大量数据的命令列表来减少 CPU/GPU 通信

• 能够以 OpenGL 无法实现的多线程方式进行接口

但是，我不知道人们在现实世界中遇到哪些需要这些的情况，以及 OpenGL 如何限制这些情况。到目前为止，网上的所有例子都说“你可以跑得更快！” 但我还没有看到人们如何使用它来跑得更快。

我在哪里可以找到回答这个问题的信息？或者你知道一些具体的例子可以为我回答这个问题吗？也许更好的问题是人们在使用 OpenGL（或 D3D）时导致 Vulkan 成为一种东西的典型痛点在哪里？

一个不令人满意的答案的例子是这样的回应

您可以多线程并更快地向 Vulkan 提交内容。

但更令人满意的回应将类似于

在 Vulkan 中，您可以多线程处理您对 GPU 的提交。在 OpenGL 中，您不能这样做，因为您依靠实现来代表您进行适当的锁定和放置围栏，这可能最终会造成瓶颈。一个简单的例子是[这里的简短示例，OpenGL 没有针对情况 X 切断它]，而在 Vulkan 中，它由 [动作 Y] 解决。

上面的最后一段可能并不准确，但我试图举例说明我要寻找的内容，而不会试图写出非常错误的东西。

Answer 1

Vulkan 在运行时行为方面确实有四大优势：

• 降低 CPU 负载
• 可预测的 CPU 负载
• 更好的内存接口
• 可预测的内存负载

特别是较低的 GPU 负载并不是优势之一；使用相同 GPU 功能的相同内容将具有非常相似的两个 API 的 GPU 性能。

在我看来，它在开发人员的可用性方面也有很多优势——程序员的模型比 OpenGL 干净得多，但要达到“某些东西正常工作”的阶段有更陡峭的学习曲线。

让我们更详细地了解每个优点：

降低 CPU 负载

Vulkan 中较低的 CPU 负载来自多个方面，但主要是：

• API 鼓励预先构建描述符，因此您不会在逐个绘制的基础上重建状态。
• API 是异步的，因此可以将一些职责（例如跟踪资源依赖关系）转移到应用程序。这里的一个简单的应用程序实现将和 OpenGL 一样慢，但应用程序有更多的空间来应用高级算法优化，因为它可以知道如何使用资源以及它们与场景结构的关系。
• API 将错误检查移至层驱动程序，因此发布驱动程序尽可能精简。
• API 鼓励多线程，这总是一个巨大的胜利（特别是在移动设备上，例如，四个线程运行缓慢将比一个线程快速运行消耗更少的能量）。

可预测的 CPU 负载

OpenGL 驱动程序执行各种“魔法”，要么是为了性能（基于仅在绘制时间后期才知道的状态的特殊着色器），要么是为了保持同步渲染错觉（动态创建资源幻影以避免在应用程序修改时停止管道）仍被挂起命令引用的资源）。

Vulkan 的设计理念是“没有魔法”。当你提出要求时，你就会得到你所要求的。希望这意味着没有随机减速，因为驱动程序正在做一些你在后台没有预料到的事情。缺点是应用程序承担了做正确事情的责任;)

更好的内存接口

OpenGL 设计的许多部分基于不同的 CPU 和 GPU 内存池，它们需要一个编程模型，该模型为驱动程序提供足够的信息以保持它们同步。大多数现代硬件可以通过硬件支持的一致性协议做得更好，因此 Vulkan 启用了一个模型，您只需映射一次缓冲区，然后临时修改它并保证“其他进程”将看到更改。没有更多的“映射”/“取消映射”/“无效”开销（前提是平台支持一致的缓冲区，当然，它仍然不是通用的）。

其次，Vulkan 将内存分配的概念和内存的使用方式（内存视图）分开。这允许为帧管道中的不同事物回收相同的内存，从而减少您需要分配的中间存储量。

可预测的内存负载

与 CPU 性能的“无魔法”评论相关，Vulkan 不会动态生成随机资源（例如重影纹理）来隐藏应用程序问题。资源内存占用不再随机波动，但应用程序必须再次承担做正确事情的责任。

Answer 2

这是基于意见的风险。我想我只是重申一下包装盒上写的 Vulkan 优势，希望是没有争议的。

• 您可以在 Vulkan 中禁用验证。它显然以这种方式使用更少的 CPU（或电池\电源\噪音）。在某些情况下，这可能很重要。
• OpenGL does have poorly defined multi-threading. Vulkan has well defined multi-threading in the specification. Meaning you do not immediately lose your mind trying to code with multiple threads, as well as better performance if otherwise the single thread would be a bottleneck on CPU.
• Vulkan is more explicit; it does not (or tries to not) expose big magic black boxes. That means e.g. you can do something about micro-stutter and hitching, and other micro-optimizations.
• Vulkan has cleaner interface to windowing systems. No more odd contexts and default framebuffers. Vulkan does not even require window to draw (or it can achieve it without weird hacks).
• Vulkan is cleaner and more conventional API. For me that means it is easier to learn (despite the other things) and more satisfying to use.
• Vulkan takes binary intermediate code shaders. While OpenGL used not to. That should mean faster compilation of such code.
• Vulkan has mobile GPUs as first class citizen. No more ES.
• Vulkan have open source, and conventional (GitHub) public tracker(s). Meaning you can improve the ecosystem without going through hoops. E.g. you can improve\implement a validation check for error that often trips you. Or you can improve the specification so it does make sense for people that are not insiders.