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

Question

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

但是，我不想在没有被告知的情况下进行跳跃。我一直在查找 Vulkan 为我提供了哪些好处，但是通过大量的谷歌搜索，我无法准确找到能够提升性能的确切原因。人们会抛出诸如“OpenGL 很慢，Vulkan 更快!”之类的术语。或“低功耗!”并且在这个问题上不再多说。

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

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

我认为 Vulkan 提供了一些基于在线阅读无数内容的东西(我猜这肯定不是所有优点，或者这些是否是真的):

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

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

能够以 OpenGL 无法以某种方式实现的多线程方式进行接口(interface)

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

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

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

You can multithread and submit things to Vulkan quicker.

但更令人满意的回应是

In Vulkan you can multithread your submissions to the GPU. In OpenGL you can't do this because you rely on the implementation to do the appropriate locking and placing fences on your behalf which may end up creating a bottleneck. A quick example of this would be [short example here of a case where OpenGL doesn't cut it for situation X] and in Vulkan it is solved by [action Y].

上面的最后一段可能并不准确，但我试图给出一个我正在寻找的例子，而不是试图写出严重错误的东西。

Answer 1

Vulkan 在运行时行为方面确实有四个主要优势:

降低 CPU 负载

可预测的 CPU 负载

更好的内存接口(interface)

可预测的内存负载

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

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

让我们更详细地看一下每个优点:

降低 CPU 负载

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

API 鼓励预先构建描述符，因此您不会在逐个绘制的基础上重建状态。

API 是异步的，因此可以将一些职责(例如跟踪资源依赖关系)转移到应用程序。一个简单的应用程序实现与 OpenGL 一样慢，但应用程序有更多的空间来应用高级算法优化，因为它可以知道资源是如何使用的以及它们与场景结构的关系。

API 将错误检查移至层驱动程序，因此发布驱动程序尽可能精简。

API 鼓励多线程，这总是一个巨大的胜利(特别是在移动设备上，例如，四个运行缓慢的线程将比一个快速运行的线程消耗更少的能量)。

可预测的 CPU 负载

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

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

更好的内存接口(interface)

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

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

可预测的内存负载

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