Vulkan 可以做什么 OpenGL 4.6+ 不能做的事情？
What can Vulkan do specifically that OpenGL 4.6+ cannot?
我正在研究是继续使用 OpenGL 还是考虑迁移 Vulkan 以解决密集的瓶颈渲染问题。
但是我不想在没有被告知的情况下跳伞。我一直在寻找 Vulkan 为我提供的好处，但通过大量谷歌搜索，我无法 确切地 找到什么可以提高性能。人们会抛出诸如 "OpenGL is slow, Vulkan is way faster!" 或 "Low power consumption!" 之类的术语，而不再谈论这个主题。
因此，我很难评估我面临的问题是否是 Vulkan 可以帮助我解决的问题，或者我的问题是否是由体积和计算引起的（在这种情况下 Vulkan 会对我帮助不大）。
我假设 Vulkan 不会神奇地使管道中的东西更快（因为三角形的阴影在 OpenGL 和 Vulkan 之间对于相同的缓冲区和制服和着色器将大致相同）。我假设 OpenGL 中所有导致悲伤的事情（例如：帧缓冲区和着色器程序更改）在 API.
中都会同样痛苦。
我认为 Vulkan 提供了一些基于在线阅读无数内容的想法（我猜这肯定不是所有优点，或者这些是否正确）：
没有[多少？任何？] 绑定（或者更确切地说 'bindless textures' 的更好版本），我注意到当我切换到无绑定纹理时我获得了显着的性能提升，但如果无绑定纹理，这可能甚至不值得一提有效地做到了这一点，因此我不确定 Vulkan 是否在此处添加了任何内容
减少了CPU/GPU 通信，方法是编写某种可以在 GPU 上执行的命令列表，而无需发送大量数据
能够以 OpenGL 无法以某种方式进行的多线程交互
但是我不确切知道人们 运行 在现实世界中遇到什么情况需要这些，以及 OpenGL 如何限制这些。到目前为止，所有在线示例都说 "you can run faster!" 但我还没有看到 如何 人们使用它来 运行 更快。
在哪里可以找到回答这个问题的信息？或者你知道一些具体的例子可以为我回答这个问题吗？也许一个更好的问题是，人们在使用 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].
上面的最后一段可能并不准确，但我试图举例说明我要寻找的内容，而不是试图写出严重错误的内容。
这存在基于意见的风险。我想我只是重申一下包装盒上写的 Vulkan 优势，希望没有争议。
- 您可以在 Vulkan 中禁用验证。它显然使用 less CPU（或 battery\power\noise）。在某些情况下，这可能很重要。
- OpenGL 确实定义不当 multi-threading。 Vulkan 在规范中明确定义了 multi-threading。这意味着您不会立即失去理智尝试使用多线程进行编码，以及更好的性能，否则单线程将成为 CPU.
上的瓶颈
- Vulkan 更明确；它不会（或试图不）暴露大魔法黑匣子。这意味着例如你可以做一些关于 micro-stutter 和搭便车的事情，以及其他 micro-optimizations.
- Vulkan 与 windowing 系统的界面更清晰。不再有奇怪的上下文和默认帧缓冲区。 Vulkan 甚至不需要 window 来绘制（或者它可以在没有奇怪的技巧的情况下实现）。
- Vulkan 更简洁、更传统 API。对我来说，这意味着它更容易学习（尽管还有其他事情）并且使用起来更令人满意。
- Vulkan 采用二进制中间代码着色器。而 OpenGL 以前不会。这应该意味着可以更快地编译此类代码。
- Vulkan 拥有移动 GPU 作为第一个 class 公民。没有更多的 ES.
- Vulkan 有开源和传统的 (GitHub) public 跟踪器。这意味着您可以改善生态系统而无需通过箍。例如。您可以 improve\implement 对经常使您感到困惑的错误进行验证检查。或者您可以改进规范，使其对非内部人员有意义。
Vulkan 在 run-time 行为方面确实有四个主要优势：
- 降低CPU负载
- 可预测CPU负载
- 更好的内存接口
- 可预测的内存负载
特别是较低的 GPU 负载不是优势之一；使用相同 GPU 功能的相同内容将具有与两个 API 非常相似的 GPU 性能。
在我看来，它在开发人员可用性方面也有很多优势 - 程序员的模型比 OpenGL 更清晰，但要达到 "something working correctly" 阶段的学习曲线更陡峭。
让我们更详细地了解每个优点：
降低CPU负载
Vulkan 中较低的 CPU 负载来自多个领域，但主要是：
- API 鼓励 up-front 构建描述符，因此您不会在 draw-by-draw 基础上重建状态。
- API 是异步的，因此可以将一些职责（例如跟踪资源依赖性）转移给应用程序。一个朴素的应用程序实现与 OpenGL 一样慢，但应用程序有更多的空间来应用高级算法优化，因为它可以知道资源是如何使用的以及它们与场景结构的关系。
- API 将错误检查转移到层驱动程序，因此发布驱动程序尽可能精简。
- API 鼓励多线程，这总是一个伟大的胜利（尤其是在移动设备上，例如，四个线程 运行 缓慢消耗的能量比一个线程 运行 快速消耗的能量少得多） .
可预测CPU负载
OpenGL 驱动程序做各种 "magic"，要么是为了性能（根据仅在绘制时才知道的状态专门化着色器），要么是为了保持同步渲染错觉（动态创建资源幻影以避免当应用程序修改仍被未决命令引用的资源时停止管道。
Vulkan 的设计理念是 "no magic"。当你要求时，你会得到你所要求的。希望这意味着不会出现随机减速，因为驱动程序正在后台执行您未预料到的操作。缺点是应用程序负责做正确的事情；）
更好的内存接口
OpenGL 设计的许多部分都基于不同的 CPU 和 GPU 内存池，这需要一个编程模型来为驱动程序提供足够的信息以保持它们同步。大多数现代硬件可以通过 hardware-backed 一致性协议做得更好，因此 Vulkan 启用了一个模型，您可以只映射一次缓冲区，然后临时修改它并保证 "other process" 将看到更改。不再有"map" / "unmap" / "invalidate" 开销（前提是平台支持coherent buffer，当然，还是不通用）。
其次，Vulkan 将内存分配的概念与内存的使用方式（内存视图）分开。这允许为帧管道中的不同事物回收相同的内存，从而减少您需要分配的中间存储量。
可预测的内存负载
与针对 CPU 性能的 "no magic" 评论相关，Vulkan 不会动态生成随机资源（例如重影纹理）以隐藏应用程序问题。资源内存占用不再随机波动，但应用程序必须再次承担起做正确事情的责任。
我正在研究是继续使用 OpenGL 还是考虑迁移 Vulkan 以解决密集的瓶颈渲染问题。
但是我不想在没有被告知的情况下跳伞。我一直在寻找 Vulkan 为我提供的好处，但通过大量谷歌搜索，我无法 确切地 找到什么可以提高性能。人们会抛出诸如 "OpenGL is slow, Vulkan is way faster!" 或 "Low power consumption!" 之类的术语，而不再谈论这个主题。
因此，我很难评估我面临的问题是否是 Vulkan 可以帮助我解决的问题，或者我的问题是否是由体积和计算引起的（在这种情况下 Vulkan 会对我帮助不大）。
我假设 Vulkan 不会神奇地使管道中的东西更快（因为三角形的阴影在 OpenGL 和 Vulkan 之间对于相同的缓冲区和制服和着色器将大致相同）。我假设 OpenGL 中所有导致悲伤的事情（例如：帧缓冲区和着色器程序更改）在 API.
中都会同样痛苦。我认为 Vulkan 提供了一些基于在线阅读无数内容的想法（我猜这肯定不是所有优点，或者这些是否正确）：
没有[多少？任何？] 绑定（或者更确切地说 'bindless textures' 的更好版本），我注意到当我切换到无绑定纹理时我获得了显着的性能提升，但如果无绑定纹理，这可能甚至不值得一提有效地做到了这一点，因此我不确定 Vulkan 是否在此处添加了任何内容
减少了CPU/GPU 通信，方法是编写某种可以在 GPU 上执行的命令列表，而无需发送大量数据
能够以 OpenGL 无法以某种方式进行的多线程交互
但是我不确切知道人们 运行 在现实世界中遇到什么情况需要这些，以及 OpenGL 如何限制这些。到目前为止，所有在线示例都说 "you can run faster!" 但我还没有看到 如何 人们使用它来 运行 更快。
在哪里可以找到回答这个问题的信息？或者你知道一些具体的例子可以为我回答这个问题吗？也许一个更好的问题是，人们在使用 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].
上面的最后一段可能并不准确，但我试图举例说明我要寻找的内容，而不是试图写出严重错误的内容。
这存在基于意见的风险。我想我只是重申一下包装盒上写的 Vulkan 优势，希望没有争议。
- 您可以在 Vulkan 中禁用验证。它显然使用 less CPU（或 battery\power\noise）。在某些情况下，这可能很重要。
- OpenGL 确实定义不当 multi-threading。 Vulkan 在规范中明确定义了 multi-threading。这意味着您不会立即失去理智尝试使用多线程进行编码，以及更好的性能，否则单线程将成为 CPU. 上的瓶颈
- Vulkan 更明确；它不会（或试图不）暴露大魔法黑匣子。这意味着例如你可以做一些关于 micro-stutter 和搭便车的事情，以及其他 micro-optimizations.
- Vulkan 与 windowing 系统的界面更清晰。不再有奇怪的上下文和默认帧缓冲区。 Vulkan 甚至不需要 window 来绘制（或者它可以在没有奇怪的技巧的情况下实现）。
- Vulkan 更简洁、更传统 API。对我来说，这意味着它更容易学习（尽管还有其他事情）并且使用起来更令人满意。
- Vulkan 采用二进制中间代码着色器。而 OpenGL 以前不会。这应该意味着可以更快地编译此类代码。
- Vulkan 拥有移动 GPU 作为第一个 class 公民。没有更多的 ES.
- Vulkan 有开源和传统的 (GitHub) public 跟踪器。这意味着您可以改善生态系统而无需通过箍。例如。您可以 improve\implement 对经常使您感到困惑的错误进行验证检查。或者您可以改进规范，使其对非内部人员有意义。
Vulkan 在 run-time 行为方面确实有四个主要优势：
- 降低CPU负载
- 可预测CPU负载
- 更好的内存接口
- 可预测的内存负载
特别是较低的 GPU 负载不是优势之一；使用相同 GPU 功能的相同内容将具有与两个 API 非常相似的 GPU 性能。
在我看来，它在开发人员可用性方面也有很多优势 - 程序员的模型比 OpenGL 更清晰，但要达到 "something working correctly" 阶段的学习曲线更陡峭。
让我们更详细地了解每个优点：
降低CPU负载
Vulkan 中较低的 CPU 负载来自多个领域，但主要是：
- API 鼓励 up-front 构建描述符，因此您不会在 draw-by-draw 基础上重建状态。
- API 是异步的，因此可以将一些职责（例如跟踪资源依赖性）转移给应用程序。一个朴素的应用程序实现与 OpenGL 一样慢，但应用程序有更多的空间来应用高级算法优化，因为它可以知道资源是如何使用的以及它们与场景结构的关系。
- API 将错误检查转移到层驱动程序，因此发布驱动程序尽可能精简。
- API 鼓励多线程，这总是一个伟大的胜利（尤其是在移动设备上，例如，四个线程 运行 缓慢消耗的能量比一个线程 运行 快速消耗的能量少得多） .
可预测CPU负载
OpenGL 驱动程序做各种 "magic"，要么是为了性能（根据仅在绘制时才知道的状态专门化着色器），要么是为了保持同步渲染错觉（动态创建资源幻影以避免当应用程序修改仍被未决命令引用的资源时停止管道。
Vulkan 的设计理念是 "no magic"。当你要求时，你会得到你所要求的。希望这意味着不会出现随机减速，因为驱动程序正在后台执行您未预料到的操作。缺点是应用程序负责做正确的事情；）
更好的内存接口
OpenGL 设计的许多部分都基于不同的 CPU 和 GPU 内存池，这需要一个编程模型来为驱动程序提供足够的信息以保持它们同步。大多数现代硬件可以通过 hardware-backed 一致性协议做得更好，因此 Vulkan 启用了一个模型，您可以只映射一次缓冲区，然后临时修改它并保证 "other process" 将看到更改。不再有"map" / "unmap" / "invalidate" 开销（前提是平台支持coherent buffer，当然，还是不通用）。
其次，Vulkan 将内存分配的概念与内存的使用方式（内存视图）分开。这允许为帧管道中的不同事物回收相同的内存，从而减少您需要分配的中间存储量。
可预测的内存负载
与针对 CPU 性能的 "no magic" 评论相关，Vulkan 不会动态生成随机资源（例如重影纹理）以隐藏应用程序问题。资源内存占用不再随机波动，但应用程序必须再次承担起做正确事情的责任。