Vulkan API 的简要概述

那么，这个新的 Vulkan API 有什么大不了的，我们为什么要关心呢？

这是 100 字以内的 Vulkan API：它是用于 3D 图形和计算应用程序的低开销、接近金属的 API。 Vulkan 基本上是 OpenGL 的后续版本。 它最初被称为“下一代 OpenGL 计划”，它包括来自 AMD 的 Mantle API 的一些零碎的东西。 Vulkan 应该提供优于其他 GPU API 的众多优势，实现卓越的跨平台支持、对多线程处理器的更好支持、更低的 CPU 负载以及少量操作系统不可知论。 它还应该使驱动程序开发更容易，并允许对驱动程序进行预编译，包括使用以各种语言编写的着色器。

那是 93 个字，所以如果您不感兴趣，可以跳过接下来的 3,500 个字。 另一方面，如果您想了解更多关于未来几年将与我们一起推出的图形 API，我将从基础开始。

Vulkan API 是如何诞生的

Vulkan 最初由 Khronos 集团于 2015 年 3 月宣布，暂定于 2015 年底推出。如果您不熟悉 Khronos，它是 15 年前由业内一些知名人士创立的非营利性行业联盟。图形行业，包括 ATI（现在是 AMD 的一部分）、Nvidia、Intel、Silicon Graphics、Discrete 和 Sun Microsystems。 即使您没有听说过 Khronos，您也可能听说过他们的一些标准，例如：OpenGL、OpenGL ES、WebGL、OpenCL、SPIR、SYCL、WebCL、OpenVX、EGL、OpenMAX、OpenVG、OpenSL ES、流输入、COLLADA 和 glTF。

到现在为止，您可能在想“啊，是那些家伙”，所以我可以跳过其余的介绍并专注于 API 本身。

与它的前身或前身不同，Vulkan 的设计初衷是为了在各种平台上运行，从手机和平板电脑到游戏机和高端台式机。 API 的底层设计是分层的，或者我们应该说是模块化的，因此它可以创建一个通用但可扩展的架构，用于代码验证、调试和分析，而不会影响性能。 Krhonos 声称分层方法将提供更大的灵活性，促进跨供应商 GPU 工具的强大创新，并提供复杂游戏引擎所需的更直接的 GPU 控制。

现在，我了解到许多技术爱好者对“灵活”、“可扩展”和“模块化”等营销术语持保留态度，但这次我们要处理的是真正的 McCoy。 事实上，这就是 Vulkan 背后的基本理念：它被设想为一个面向大众的 API，从孩子们在智能手机上玩游戏，到他们的父母在工作站上设计建筑和游戏。

从理论上讲，Vulkan 可用于并行计算硬件，控制数百亿个 GPU 内核，用于微型可穿戴设备和玩具无人机，用于 3D 打印机、汽车、VR 套件，以及几乎任何其他内置兼容 GPU 的东西。

有关更多详细信息，我建议您查看 PDF 中的官方 Vulkan 概述。

AMD 地幔 DNA

如果接近金属的方法听起来非常熟悉，那么您可能在过去两年左右一直在关注 AMD 的 GPU 公告。 AMD 在 2013 年宣布其 Mantle API 时令行业观察家感到惊讶，当它决定取消 API 的插件时再次让他们感到惊讶，并在 2015 年 3 月宣布不会将 Mantle 1.0 作为公共 SDK 发布。 简而言之，Mantle 承诺在某些情况下提供显着的性能和效率改进，尤其是在 CPU 前端，因为它会减少处理开销。 这听起来是个好主意，因为游戏玩家可以将定制 PC 与稍慢的处理器放在一起，并在顶级显卡上投入更多资金。 这对 AMD 来说听起来也很方便，因为该公司多年来一直没有有竞争力的高端 CPU，尽管它仍然有很好的 GPU 产品。

当哭泣的 AMD 粉丝聚集在一起哀悼他们的救世主去世时，Mantle 奇迹般地复活了。 好消息来自 AMD 视觉和感知计算副总裁 Raja Koduri 撰写的博客文章。 巧合的是，为了与宗教主题保持一致，有一次 Koduri 在 2013 年 AMD 的夏威夷发布会期间举行了一次登山布道，但我离题了。

一边开玩笑，科杜里的团队做得很好。 虽然 Mantle 没有成为新的行业标准，但它确实成为了 Vulkan 的基础。 最大的不同是 Vulkan 不会仅限于 AMD GCN 硬件； 它将适用于来自不同供应商的更多 GPU。 您可能会看到我的目标； 拥有一个可在不同操作系统和硬件平台上运行的单一低开销图形 API 比拥有用于不同 GPU 架构、操作系统等的专有 API 更好一些。

Vulkan API 只是从 Mantle 蛋糕中分一杯羹，并与所有人分享，无论操作系统、硬件、种族或宗教如何。

哦，还有一件事：Mantle 最终迫使微软和 Khronos 最终对 DirectX 和 OpenGL 的膨胀和低效采取了一些措施。 正如 Toptaler 的一位同事喜欢说的那样，这是一种温和、友好的后踢，或“badonkadonk”。

Vulkan 与 OpenGL 相比如何？

显然，我需要概述 Vulkan 和 OpenGL 之间的基本区别。 Khronos 提出了一个简单的说明，展示了使用新 API 可以消除多少驱动程序膨胀。

Vulkan 允许应用程序更接近金属，从而消除了对大量内存和错误管理以及大量着色语言源的需要。 司机会更轻、更瘦、更刻薄。 Vulkan 将只依赖 SPIR-V 中间语言，并且由于它具有针对移动、桌面和控制台市场的统一 API，它也应该得到开发者更多的温柔和关爱。

但是等等，这不是简单地把更多的工作交给了游戏开发者吗？ 当然，他们将能够更有效地使用硬件，但他们自己的工时呢？ 这就是分层生态系统方法进入竞争的地方。

开发人员将能够选择 Vulkan 生态系统的三个不同级别或层级。

• 直接使用 Vulkan 以获得最大的灵活性和控制力。
• 使用 Vulkan库和层来加速开发。
• 通过对新 API 进行全面优化的现成游戏引擎使用 Vulkan。

第一个选项显然不适合所有人，但我怀疑它会成为一些不错的基准测试软件。 Khronos 预计第二个选项将成为“丰富的创新领域”，因为许多实用程序和层将是开源的，并且将简化从 OpenGL 的过渡。 如果出版商有一些需要调整和更新的 OpenGL 标题，这就是他们会使用的。

最后一个选项也许是最诱人的，因为繁重的工作已经由 Unity、Oxide、Blizzard、Epic、EA、Valve 等行业巨头完成。

这是一个快速的 OpenGL 与 Vulkan 表：

老实说，我认为将两者进行比较是不公平的。 Vulkan 是 Mantle 的衍生产品，而 OpenGL 是拥有 20 年包袱的乳齿象。 Vulkan 应该抛弃大量遗留的东西。 这就是重点。 Vulkan 应该通过 SPIR-V 中间语言简化测试和实施，使驱动程序更精简，并提高着色器程序的可移植性。

这将我们带到下一个问题。 Vulkan 对开发人员的真正意义是什么？

SPIR-V 有望改变语言生态系统

那么 SPIR-V 在哪里发挥作用，旧的 GLSL 会发生什么？

GSLS 将暂时保持活力，它将成为 Vulkan 支持的第一个着色语言。 GLSL 到 SPIR-V 的翻译器将完成繁重的工作，瞧！，您将准备好 SPIR-V 来满足饥饿的 Vulkan 运行时。 游戏开发者将能够使用 SPIR-V 和 Vulkan 后端，可能依赖于开源编译器前端。 除了 GLSL，Vulkan 还可以支持 OpenCL C 内核，同时增加对 C++ 的支持的工作正在进行中。 未来的特定领域语言、框架和工具是另一种选择。 Khronos 甚至提到了开发新的实验性语言的可能性。

无论开发人员选择做什么，所有的道路都通向 Vulkan，通过 SPIR-V，然后通向众多不同的设备。

SPIR-V 应该以三种方式提高可移植性：

• 共享工具
• 单一 ISV 的单一工具集
• 简单

由于不需要每个硬件平台都配备高级语言翻译器，因此开发人员将处理更少的翻译器。

单个 ISV 可以使用单个工具集生成 SPIR-V，从而消除高级语言的可移植性问题。

SPIR-V 比典型的高级语言更简单，实现和处理更容易。

性能将通过多种方式得到改善，具体取决于 Vulkan 的实现方式：

• 没有编译器前端，很多处理都可以离线完成
• 优化通过可以更快地解决，优化离线执行
• 多个源着色器减少到相同的中间语言指令流

Khronos 没有指定任何性能数据，并指出“里程肯定会有所不同”。 这完全取决于如何使用 Vulkan。 如果您想查看详细信息，请务必查看 SPIR-V 白皮书。

从开发人员的角度来看，Vulkan 看起来很有前途

我已经概述了一些应该使 Vulkan 和 SPIR-V 在开发社区中流行的特性，而 Khronos 也热衷于传达这一点。 使用相同的工具和技能为多个平台进行开发的前景似乎很有趣，尤其是现在各种平台之间的性能差距正在缩小。

当然，为 PC 开发大预算的 AAA 级游戏仍将是一个极其复杂和耗时的过程，涉及大量现金和人力资源，但最新的英特尔和 AMD 处理器中采用的移动平台和集成 GPU 已经提供了大量的休闲游戏玩家的 GPU 性能。 此外，小型独立开发者或自由职业者更有可能从事跨平台休闲游戏，而不是主要发行商生产的 AAA 游戏。

Khronos 概述了 SPIR-V 带来的以下优势：

• 开发人员可以跨多个平台使用相同的前端编译器来消除跨供应商的可移植性问题
• 运行时着色器/内核编译时间将减少，因为驱动程序只需要处理 SPIR-V
• 开发人员不必分发着色器/内核源代码，因此他们享有更高级别的 IP 保护
• 驱动程序更简单、更可靠，因为不需要包含前端编译器
• 开发人员对内存分配有更好的了解，并可以相应地调整他们的内存分配方法

我相信你会同意这听起来不错，但还有很长的路要走。

Vulkan：它有效，但它正在进行中

正如我所说，Vulkan 仍然是一项正在进行的工作，我们应该在今年年底之前拥有完整的规范。 然而，从我们目前看到的情况来看，即使使用当前一代的硬件，新的 API 也可以释放很多性能。

到目前为止，我所看到的关于 Vulkan 的最佳示例来自 Imagination Technologies，它是目前领先的移动 GPU 设备之一。 Imagination Technologies GPU IP 用于所有 iOS 小工具，以及许多其他基于 ARM 的片上系统设计，甚至用于一些低压 Intel x86 芯片。

上周，Imagination 发表了一篇博文，详细介绍了 Vulkan 带来的性能提升。 它的硬件选择有些不同寻常：Google Nexus Player，基于很少使用的 Intel 四核处理器和 PowerVR G6430 GPU。 该设备使用用于 PowerVR GPU 的最新 Vulkan API 驱动程序进行了测试，而参考运行是在 OpenGL ES 3.0 上执行的。 性能差距简直是惊人的。

该场景总共包括 400,000 个对象，具有不同的细节层次，从 13,000 到 300 个顶点不等。 广角镜头显示了大约一百万个三角形，植物上的一些 alpha 以及侏儒和植物的大约十种不同的纹理。 每种对象类型使用不同的着色器并且没有实例化 gnome，每个绘制调用可能是完全不同的对象，具有不同的材质，但最终结果将是相似的。

尽管如此，还是有一个很大的警告：这不是您在现实生活中可以期待的那种性能提升。 Imagination Technologies 团队使用夸张的场景来突出 Vulkan 的优势，将其推向极限，在这个特定场景中，极限有利于 Vulkan 与 OpenGL ES。 另外，请记住，这个测试是 GPU 绑定的，但它仍然是 Vulkan 出色的 CPU 利用率的一个很好的例证。

Vulkan 如何降低 CPU 使用率？

还记得我们之前的 OpenGL 与 Vulkan 表，或者更具体地说，是平铺渲染位吗？ 可能不是，简而言之就是这样：Imagination 使用 Vulkan 将绘制调用批处理到图块中并一次渲染一个图块。 根据渲染帧时瓦片的位置，它可以进入或退出视图，更改其细节级别等等。 在 OpenGL ES 中，所有的绘制调用都是动态的，它们根据视野中的内容随每一帧一起提交。 已经执行的绘图调用不能被缓存。

因此，OpenGL ES 需要多次调用内核模式来更改驱动程序的状态并对其进行验证。 Vulkan 没有，因为它依赖于预先生成的命令（命令缓冲区）来减少 CPU 开销并消除在渲染循环期间验证或编译的需要。 Imagination 团队将重用命令缓冲区的能力描述为“在某些情况下很有用”，并且可以在许多游戏和应用程序中“在很大程度上”使用。

第二个改变游戏规则的是并行缓冲区生成，它使 Vulkan 能够利用所有 CPU 内核的能力。 OpenGL ES 是在多核移动芯片出现之前设计的，但在过去三年中，该行业已经从两个、四个、到八个和十个 CPU 内核，使用 Apple 的 A 系列 SoC 和基于丹佛的 Nvidia Tegra芯片是唯一值得注意的例外。 我在之前的一篇博客文章中谈到了移动 SoC 趋势，涵盖了即将推出的优化Android 编译器，因此您可以查看它以获取更多信息。

让我们打个比方：如果 Vulkan 是内燃机，它将存储和重复使用部分动力，就像涡轮增压器和中冷器（命令缓冲器）一样，它可以使用四个、六个、八个甚至十个气缸而不会降低效率（并行缓冲生成）。 将 Vulkan 与 OpenGL ES 进行比较听起来有点像在您祖父的 Triumph Trophy 中将新的小型涡轮发动机与旧的单缸发动机进行比较。

好吧，至少爷爷是一个真正的摇滚乐手，而不是一个模特。

最终结果是一个更加高效的环境，能够充分利用所有可用的硬件，这与在大多数情况下受 CPU 限制的 OpenGL ES 不同。 这意味着 Vulkan 可以提供类似水平的性能，同时将 CPU 保持在较低的时钟频率，从而降低功耗和节流。

潜在的 Vulkan API 缺点（剧透警告：没有那么多）

我不是吹毛求疵； 我觉得列出 Vulkan API 的优缺点也很重要。 幸运的是，除了一些小问题，可能还有一两个大问题，没有那么多缺点。 如果您认为 Vulkan 是自切片面包以来最好的东西，并且您渴望在下一个项目中尝试一下，您可能需要考虑以下几点：

• 在某些情况下增加了代码复杂性
• 上市时间
• 行业支持水平
• Vulkan 在某些平台（桌面）上可能不那么相关或有效
• 说服开发人员在某些平台上使用 Vulkan
• 与旧硬件的有限兼容性

如果开发人员想要实现本文中概述的一些简洁功能，则将涉及大量工作。 每个都必须在代码中实现，但好消息是行业领导者将通过新的驱动程序更新使流程更容易。

上市时间是另一个问题，Vulkan 在较旧的应用程序和游戏中的实施也是如此。 Vulkan 仍然是技术预览版； 最初的规范和实施预计在 2015 年底之前完成，因此，实际上，在 2016 年年中之前，我们可能不会看到很多实际应用。

行业支持不应该成为问题； 毕竟，这是一个 Khronos 标准，但可能需要一段时间。 这就是我将这篇文章重点放在移动领域的原因之一； 移动软件和硬件发展得更快，我们可能需要再过几个季度才能看到 Vulkan 对桌面平台产生影响。 这就是这个行业的运作方式，在桌面领域还有更多需要担心的事情：对专业应用程序的支持、成群的手持干草叉的游戏玩家在每一个被撕裂的框架上猿猴，等等。 然而，Vulkan 源自 AMD 的 Mantle 的事实令人鼓舞。

虽然 Vulkan 可以在 CPU 密集型环境中创造奇迹，尤其是多核移动 SoC，但这些性能提升在桌面平台上将受到限制。 台式机以更高的效率处理多核处理器，并且大多数图形要求高的应用程序都受 GPU 限制。

在所有的拼图都到位之前，一些开发人员可能不愿意冒险和 Vulkan 混在一起。 很多人根本没有时间进行实验，他们只有在绝对必要时才学习新技能。 在早期阶段烧掉大量资金并浪费工时来调整现有手机游戏以使用 Vulkan，这对于许多开发商和发行商来说并不是一个选择。

与旧硬件的兼容性可能是另一个令人担忧的问题。 Vulkan 将需要 OpenGL ES 3.1 或 OpenGL 4.1 硬件以及新的驱动程序。 例如，Imagination Technologies 的 PowerVR series 6 GPU 可以支持它，但 series 5 不能。 高通的 Adreno 400 系列支持 OpenGL ES 3.1，但 300 系列不支持。 ARM 的 Mali T600 和 T700 系列支持 OpenGL ES 3.1，但较旧的 T400 系列设计缺乏支持。 幸运的是，当 Vulkan 变得相关时，大多数具有不受支持的 GPU 的设备都将被排除在外。 其中包括基于某些 5000 系列 Exynos 芯片的 iPhone 5/5C、第四代 iPad 和三星设备。 基于高通的设备可能没有那么幸运，因为 Adreno 300 系列 GPU 用于相对较新和多产的设计，例如 Snapdragon 410、Snapdragon 600、Snapdragon 800 和 801。但是，我怀疑它们中的大多数到时候都会消失Vulkan 变得真正相关。

长寿和渲染

现在说 Vulkan 是否会改变游戏规则还为时过早，但我想你会同意它有很大的潜力。 我认为这将是一件大事，我的假设是基于 GPU 行业十年的经验。 然而，这需要时间，而且我怀疑 Vulkan 在开始改变桌面环境之前会在移动设备中感受到它的存在。

几乎在同一时间，经过 Vulkan 优化的驱动程序、游戏引擎和游戏，我们将获得新的硬件来玩，我指的不仅仅是轻微的硬件调整。 移动 SoC 开发停滞不前的原因有很多，我现在不谈，但 2016 年对于行业来说将是重要的一年，因为 14/16nm FinFET 节点可供更多制造商使用，并且对于主流硬件而不是在经济上可行旗舰芯片。

开发人员将拥有更强大、更高效的硬件，而新的低开销图形 API 将是锦上添花。 我真诚地希望硬件供应商不要将显示分辨率用作营销噱头，因为毫无意义的高分辨率对视觉质量没有任何帮助，但仍然会浪费电力。 不幸的是，由于普通消费者不明白这一点，并且希望在盒子上看到更大的数字，我怀疑这不会很快发生。 我打算在我即将发布的一篇文章中研究这个奇怪的问题，所以如果你对此感到恼火，请继续关注并随时在评论部分发泄。