Vulkan API的简要概述

本文概述

• Vulkan API如何成为现实
• AMD Mantle DNA
• Vulkan与OpenGL相比如何？
• SPIR-V有望改变语言生态系统
• 从开发人员的角度来看, Vulkan看起来很有前途
• Vulkan：可行, 但仍在进行中
• Vulkan如何减少CPU使用率？
• Vulkan API的潜在缺点(扰流板警报：没有那么多)
• 活到老，学到老

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

以下是一百字以内的Vulkan API：这是一种用于3D图形和计算应用程序的开销低, 接近金属的API。 Vulkan基本上是OpenGL的后续产品。它最初被称为”下一代OpenGL计划”, 其中包括AMD Mantle API的一些细节。与其他GPU API相比, Vulkan应该具有许多优势, 从而能够提供出色的跨平台支持, 对多线程处理器的更好支持, 更低的CPU负载以及一些不可知的OS。它还应使驱动程序开发更容易, 并允许驱动程序的预编译, 包括使用以各种语言编写的着色器。

满足新的Vulkan API：持久渲染！

鸣叫

这是93个字, 因此, 如果你不感兴趣, 可以跳过下一个3500个字。另一方面, 如果你想进一步了解即将到来的图形API, 那么我将开始介绍基础知识。

Vulkan API如何成为现实

Vulkan最初由Khronos集团于2015年3月宣布, 暂定发布日期定于2015年底。如果你不熟悉Khronos, 它是一个非盈利性行业财团, 由15年前的一些知名人士成立。图形行业, 包括ATI(现在是AMD的一部分), Nvidia, Intel, Silicon Graphics, Discrete和Sun Microsystems。即使你没有听说过Khronos, 你也可能已经听说过它们的一些标准, 例如：OpenGL, Op​​enGL ES, WebGL, Op​​enCL, SPIR, SYCL, WebCL, OpenVX, EGL, Op​​enMAX, OpenVG, OpenSL ES, StreamInput, COLLADA和glTF。

到目前为止, 你可能正在考虑”啊, 就是这些家伙”, 因此我可以跳过其余的介绍, 而专注于API本身。

与以前的产品不同, Vulkan的设计完全可以在多种平台上运行, 从手机和平板电脑到游戏机和高端台式机。 API的基础设计是分层的, 或者可以说是模块化的, 因此它可以创建通用但可扩展的体系结构, 以进行代码验证, 调试和分析, 而不会影响性能。 Krhonos声称, 这种分层方法将提供更大的灵活性, 促进跨供应商GPU工具的强大创新, 并提供复杂游戏引擎所需的更直接的GPU控制。

现在, 我了解到许多技术爱好者对诸如”灵活”, “可扩展”和”模块化”等营销术语持保留态度, 但是这次我们正在与真正的McCoy进行交易。实际上, 这就是Vulkan的基本思想：它被设想为面向大众的API, 从智能手机上的儿童游戏到父母在工作站上设计建筑物和游戏的父母。

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

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

AMD Mantle DNA

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

当哭泣的AMD迷们聚集哀悼救世主的逝世时, Mantle奇迹般地复活了。好消息以博客文章的形式出现, 该博客文章由AMD视觉和感知计算副总裁Raja Koduri撰写。巧合的是, 与宗教主题保持一致, 在2013年AMD在夏威夷举行的发布会上, 科杜里(Koduri)有一次在坐骑上讲道, 但我离题了。

除了开玩笑, Koduri的团队做得很好。尽管Mantle尚未成为新的行业标准, 但它确实成为Vulkan的基础。最大的不同是Vulkan不仅限于AMD GCN硬件；它可以在来自不同供应商的更多GPU上运行。你可能会看到我要去的地方；拥有一个可以在不同的操作系统和硬件平台上运行的低开销图形API会比拥有一个适用于不同GPU架构, 操作系统等的专有API更好。

这听起来像个双关语, 但是AMD的Mantle实际上是新Vulkan API的核心。

鸣叫

Vulkan API只需占用很大一部分Mantle饼, 并与所有人共享, 而不管操作系统, 硬件, 种族或宗教。

哦, 还有一件事：Mantle最终迫使Microsoft和Khronos最终对DirectX和OpenGL膨胀和效率低下采取了一些措施。正如塔普塔勒(srcminier)的同僚所喜欢的那样, 这是后方的一种温柔, 友善的踢法。

Vulkan与OpenGL相比如何？

显然, 我需要概述Vulkan与OpenGL之间的基本区别。 Khronos给出了一个简单的例子, 显示了使用新API可以消除多少驱动程序膨胀。

Vulkan是适用于所有平台的统一API, 并且还支持更简单的驱动程序。

鸣叫

Vulkan使应用程序更接近金属, 从而消除了对大量内存和错误管理以及大量着色语言源的需求。司机将变得更轻, 更苗条, 更卑鄙。 Vulkan将仅依靠SPIR-V中间语言, 并且由于它具有针对移动, 台式机和控制台市场的统一API, 因此它也应该得到开发人员的更多温柔和关爱。

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

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

• 直接使用Vulkan可获得最大的灵活性和控制力。
• 使用Vulkan库和层可加快开发速度。
• 通过基于新API完全优化的现成游戏引擎使用Vulkan。

第一个选择显然并不适合所有人, 但我怀疑它会成为一些不错的基准测试软件。 Khronos期望第二个选择是”创新的丰富领域”, 因为许多实用程序和层将处于开源状态, 并将简化从OpenGL的过渡。如果发布商拥有一些需要调整和更新的OpenGL标题, 则将使用它们。

最后一种选择也许是最诱人的选择, 因为沉重的负担是由行业重量级人物完成的, 例如Unity, Oxide, 暴雪, Epic, EA, Valve等。

这是一张快速的OpenGL vs. 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 ++的支持的工作正在进行中。未来特定领域的语言, 框架和工具是另一种选择。赫罗诺斯甚至提到开发新的实验语言的可能性。

SPIR-V语言是将绑定Vulkan API中不同平台的粘合剂。

鸣叫

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

SPIR-V应该通过三种方式改善可移植性：

• 共用工具
• 单个ISV的单个工具集
• 简单

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

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

SPIR-V比典型的高级语言更简单, 从而使实现和处理更加容易。

根据Vulkan的实施方式, 可以通过多种方式提高性能：

• 没有更多的编译器前端, 可以脱机完成很多处理
• 优化过程可以更快地解决, 离线执行优化
• 多个源着色器简化为相同的中间语言指令流

Khronos没有指定任何性能数字, 并指出”里程肯定会有所不同”。这完全取决于Vulkan的使用方式。如果要查看详细信息, 请确保查看SPIR-V白皮书。

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

我已经概述了许多功能, 这些功能应该使Vulkan和SPIR-V在开发人员社区中很受欢迎, Khronos也希望能够阐明这一点。使用相同的工具和技能为多个平台开发的前景似乎很吸引人, 尤其是现在各个平台之间的性能差距正在缩小。

当然, 开发用于PC的大型AAA游戏仍将是一个极其复杂且耗时的过程, 涉及大量现金和人力资源, 但是最新的Intel和AMD处理器中采用的移动平台和集成GPU已经提供了很多功能。休闲玩家的GPU性能。此外, 小型, 独立开发商或自由职业者比跨大型休闲游戏开发商更喜欢跨平台休闲游戏。

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

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

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

Vulkan：可行, 但仍在进行中

正如我说的那样, Vulkan仍在进行中, 我们应该在年底之前拥有完整的规格。但是, 到目前为止, 即使使用当前的硬件, 新的API也可以释放很多性能。

到目前为止, 我所见过的Vulkan最好的例子是Imagination Technologies, 它是领先的移动GPU厂商之一。 Imagination Technologies GPU IP与所有其他基于ARM的片上系统设计以及所有低电压Intel x86芯片一起, 用于所有iOS小工具中。

上周, Imagination发表了一篇博客文章, 详细介绍了Vulkan实现的性能提升。它的硬件选择有些不同寻常：Google Nexus Player, 它基于很少使用的带有PowerVR G6430 GPU的英特尔四核处理器。该设备已经过用于PowerVR GPU的最新Vulkan API驱动程序的测试, 而参考运行是在OpenGL ES 3.0上执行的。性能差距令人震惊。

观看此Vulkan API演示：流畅的侏儒vs.断断续续的侏儒

鸣叫

该场景总共包含40万个对象, 这些对象的细节级别不同, 范围从13, 000到300个顶点。广角镜头显示估计有100万个三角形, 植物上有一些alpha, 地精和植物大约有十种不同的纹理。每种对象类型使用不同的着色器, 并且不对gnome进行实例化, 每个绘制调用可以是具有不同材质的完全不同的对象, 但是最终结果将相似。

不过, 还有一个很大的警告：这不是你在现实生活中可以期望的性能提升。 Imagination Technologies团队使用夸张的方案来突出Vulkan的优势, 将其推向极限, 在这种特殊情况下, 该极限有利于Vulkan vs. OpenGL ES。另外, 请记住, 该测试是受GPU约束的, 但这仍然很好地说明了Vulkan的出色CPU使用率。

Vulkan如何减少CPU使用率？

还记得我们之前或更具体地讲, 平铺渲染位的OpenGL vs. Vulkan表吗？大概不是这样, 简而言之：Imagination使用Vulkan将绘制调用成批绘制到图块中并一次渲染图块。根据图块渲染时图块的位置, 它可以进入视图或从视图中消失, 更改其细节级别等等。在OpenGL ES中, 所有绘制调用都是动态的, 它们根据视场中的内容与每一帧一起提交。已经执行的绘图调用无法缓存。

结果, OpenGL ES需要多次进入内核模式才能更改驱动程序的状态并对其进行验证。 Vulkan并非因为它依赖于预先生成的命令(命令缓冲区)来减少CPU开销并消除了在渲染循环期间进行验证或编译的需要。 Imagination团队将重用命令缓冲区的能力描述为”在某些情况下有用”, 并可能在许多游戏和应用程序中”大量使用”。

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

让我们尝试一个类比：如果Vulkan是一台内燃机, 它将存储和重用部分动力, 就像涡轮增压器和中冷器(命令缓冲区)一样, 它能够使用四, 六, 八个甚至十个气缸, 没有效率损失(并行缓冲区生成)。将Vulkan与OpenGL ES进行比较听起来有点像在爷爷的Triumph Trophy上将新的小型涡轮发动机与旧的单缸发动机进行比较。

好吧, 至少爷爷是个合适的摇滚歌手, 而不是mod。

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

Vulkan API的潜在缺点(扰流板警报：没有那么多)

我不是挑剔的。我觉得列出Vulkan API的优缺点也很重要。幸运的是, 除了少数几个小缺点, 还有一个或两个大缺点之外, 没有太多缺点。如果你认为Vulkan是切成薄片的面包以来最好的东西, 并且你渴望在下一个项目中尝试一下, 则可以考虑以下几点：

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

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

Vulkan API的缺点并不多, 但是要花一些时间才能看到它的实际效果。

鸣叫

上市时间是另一个问题, 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系列6 GPU可以支持它, 而系列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和三星设备。基于Qualcomm的设备可能并不那么幸运, 因为Adreno 300系列GPU用于诸如Snapdragon 410, Snapdragon 600, Snapdragon 800和801之类的相对较新的多产设计。 Vulkan变得真正重要。

活到老，学到老

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

大约在同时进行Vulkan优化的驱动程序, 游戏引擎和游戏的同时, 我们将获得新的硬件供你试用, 我并不是说只是对硬件进行了细微的调整。移动SoC的开发由于我现在不愿讨论的许多原因而陷入停滞, 但对于14 / 16nm FinFET节点而言, 更多制造商可以使用它, 并且对于主流硬件(而不是主流硬件)在经济上可行, 因此对于该行业来说, 2016年将是丰收的一年。旗舰芯片。

开发人员将拥有更强大, 更高效的硬件, 新的低开销的图形API将锦上添花。我衷心希望硬件供应商将停止使用显示分辨率作为营销手段, 因为毫无意义的高分辨率对视觉质量无济于事, 但仍然浪费功率。不幸的是, 由于普通消费者无法获得此商品, 并且希望在包装盒上看到更大的数字, 因此我怀疑这种情况不会很快发生。我打算在我即将发表的一篇文章中研究这个奇怪的问题, 因此, 如果你对此感到恼火, 请继续关注并随时在评论部分中发泄。