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

Question

我正在考虑是继续使用 OpenGL 还是考虑迁移 Vulkan 以进行密集的瓶颈渲染。

但是，我不想在没有被告知的情况下跳槽。我一直在查找 Vulkan 为我提供了哪些好处，但是通过大量的谷歌搜索，我无法找到确切什么可以提高性能。人们会抛出诸如“OpenGL 很慢，Vulkan 更快！”之类的术语。或“低功耗！”就这个话题不要再说什么了。

因此，我很难评估我所面临的问题是否是 Vulkan 可以帮助我解决的问题，或者我的问题是由于数量和计算问题（在这种情况下 Vulkan 将无济于事）我很）。

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

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

• 没有 [much?任何？] 绑定（或者更确切地说是“无绑定纹理”的更好版本），当我切换到无绑定纹理时我注意到了这一点，我获得了显着的性能提升，但如果无绑定纹理有效，这甚至可能不值得一提这样做，因此不确定 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 启用了一个模型，您可以只映射一次缓冲区，然后对其进行临时修改，并保证“其他进程”将看到更改。不再有“map”/“unmap”/“invalidate”开销（前提是平台支持一致性缓冲区，当然，它仍然不是通用的）。

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

可预测的内存负载

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

Answer 2

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

• 您可以在 Vulkan 中禁用验证。这种方式显然使用更少的 CPU（或电池\电源\噪音）。在某些情况下，这可能很重要。
• OpenGL 确实有定义不明确的多线程。 Vulkan 在规范中有明确定义的多线程。这意味着您不会立即失去尝试使用多线程进行编码的想法，并且如果单线程会成为 CPU 的瓶颈，那么性能也会更好。
• Vulkan 更加明确；它不会（或试图不）暴露大魔法黑匣子。这意味着例如您可以针对微卡顿和搭便车以及其他微优化做一些事情。
• Vulkan 对窗口系统的界面更加简洁。不再有奇怪的上下文和默认帧缓冲区。 Vulkan 甚至不需要窗口来绘制（或者它可以在没有奇怪的 hack 的情况下实现它）。
• Vulkan 是更简洁、更传统的 API。对我来说，这意味着它更容易学习（尽管有其他东西）并且使用起来更令人满意。
• Vulkan 采用二进制中间代码着色器。而 OpenGL 过去不这样做。这应该意味着更快地编译此类代码。
• Vulkan 将移动 GPU 作为一等公民。没有 ES。
• Vulkan 具有开源和传统 (GitHub) 公共跟踪器。这意味着您可以改善生态系统而无需费力。例如。您可以改进\实施对经常让您感到困惑的错误的验证检查。或者您可以改进规范，使其对非内部人员有意义。