Vulkan统一所有平台的API

本文是系列博客文章中的第一篇，旨在更深入地探讨在“2015计算机图形图像特别兴趣小组（SIGGRAPH）”大会上披露的有关Vulkan的信息。我不是要透露任何新信息，新信息我会留待Khronos官方发布！我要做的是，解释已经发布的信息的含义，以及说明具备这些含义的信息对从上到下的整个产品交付链中每一方的影响，从我们这样拥有知识产权（IP）的厂商到设备厂商和开发商直至消费者都在这个链条上。

在这个系列的博客文章中，会谈到我在2015 SIGGRAPH大会的Khronos BoF上谈过的每一点，还会触及其他人也许已经谈论过的信息。“Vulkan是为所有平台而设计的统一的API”这句话意味着什么？本周我将从这个话题谈起。

统一的API意味着什么？

Vulkan能够用在多种不同的使用场景和功耗大不相同的平台和硬件上。Vulkan可以在从智能手表上到高端工作站之间的所有设备上运行。这些平台功能完全不同，因此我们有足够的理由断定，设计这些平台时，所考虑的用途也是不同的。

如果跨所有这些平台使用的Vulkan完全相同，应用开发人员就不用区分平台了，那么最终的态势会演变成，人们试图在智能手表上运行Maya，这就没有太大意义了。显然，Vulkan不是操作系统，所以人们可能会说，还可以通过其他途径来应对平台不同的问题，不过，Vulkan仍然需要以某种方式区分运行它的图形硬件。

因此Vulkan在实际使用时会有不同，那么有哪些不同点？又有哪些相同点？

一致之处

API的编码

Vulkan之所以称为统一API，其要点是，应用程序可以链接到同一个库，在所有目标平台上，标题和代码都相同。在Vulkan中有一条通路，通过这条通路，能够以开发人员所希望的方式在显示屏上画三角形，开发人员可以随处使用这条通路。例如，无需为了应对OpenGL和OpenGL ES之间的细微差别，而处理深深嵌入应用程序代码之中的前处理器定义。

性能

编程时，我们希望保持代码的一致性和连贯性；同样，我们还应该保证性能的连贯性一致性。用OpenGL做任何事情都有大约上千种方式*，但是只有一种或两种方式在每个厂商的硬件上速度都很快，而究竟哪种方式速度快，硬件厂商不同，答案也不同。

使用Vulkan时，可能的方式大大减少，做任何事情都只有为数不多的几种方式。每个Khronos成员公司都仔细研究了每一条可能的编码方式，以确保这些方式对这些成员公司的产品有效，而且更重要的是，这些方式能够很好地发挥作用。事实上，就大多数功能而言，目标都是确保这一高效的方式对每一方都是相同的，例如，通过渲染通道（Render Pass）加载操作实现清除。

因此，在大多数情况下，不必求助于特定于硬件的优化，就可以得到非常好的应用性能。毫无疑问，仍然有一些特性，可能是有些厂商希望避免使用或慎用的，但是应该有一个高效的方式适用于所有地方。特定于厂商的优化仍然是有意义的，但是不像使用OpenGL时意义那么大。

在后续有关“积极架构（Architecture Positive）”的博客文章中，我会进一步谈到Vulkan是怎样做到这一点的。

区别

功能

某些功能消耗大量功耗、占用大量GPU芯片面积，或者由于其他原因而不能将这些功能作为通用功能提供。没有这类功能，也未必不能开发出良好的图形应用，这类功能并非必不可少，因此未必所有平台都要提供，我们仍然可以依靠一套核心功能。例如，在最近的将来，不可能在智能手表上看到tessellation功能，再说，实际上谁需要在智能手表上使用这种功能呢**?

在Vulkan API中，这些可选功能是作为功能标记获取的，每个标记占一个数据位，实际使用Vulkan时，这些功能可能有，也可能没有。在设备创建时，这类功能每一种都必须查询，如果需要使用，都必须明确启动，这样才不会误用。

限制

相比实际支持哪些功能而言，需要更细致地考虑的是，对可以传递给API的数值的限制。这么做是为了让开发人员知道，可以在多大程度上利用各向异性，或者一个着色器可以引用多少uniform缓冲区？Vulkan会保证所有这些数值的最小值，以便开发人员可以得到一致的支持，同时Vulkan仍然允许厂商展现额外的功能。

扩展

尽管Vulkan这个名字与OpenGL不是特别相关，但是Vulkan与OpenGL确实有继承关系，而且在Khronos开展的工作中，占据了很大一部分。OpenGL最成功的功能之一是扩展模型。扩展功能尽管有一些缺点，但是在形成新功能原型以及在揭示不同厂商硬件亮点方面却非常成功。完全出于同样的原因，Vulkan将公开扩展功能。就像可选功能一样，在设备创建初期，扩展功能就必须明确启动，这样扩展功能才不会被误用。

功能集

尽管目前还不存在功能集，但是我们一直致力于实现将各套功能打包成定义完备的功能块这一理念，以确保提供功能支持、扩展功能和各种不同的数值限制。当我们想为设备寻找功能集时，这一理念将起到有用的指导作用。例如，可能有一个功能集是为面向CAD/CAM任务的工作站定义的，这套功能可能包括较多的数值限制，以表明工作站中有极其庞大、耗费大量资源的桌面显卡，反过来，也有可能有数值限制较少的情况，这表明解决方案能效很高，钱花得很划算。Khronos定义的任何功能集都打算用来指导产品设计或采购——更多功能并不意味着更好！例如，在手机中提供一套工作站功能可能意味着，手机耗电量非常大，会很快接近允许温度的极限，这种情况通常是不希望出现的！

平台厂商在一定范围内可以定义自己的功能集，如同面向OpenGL ES 3.1的安卓扩展包一样。这样，平台厂商就可以实现产品差异化，或者在现有功能集不能很好满足需求的情况下，用自己定义的功能集提供更加一致的用户体验，再或者厂商希望确保有一些特定于平台的扩展功能可供选择。

平台支持

Vulkan设计为可在任何平台上运行，但是我们特别希望Vulkan出现在安卓（Android™）、Tizen™、很多不同版本的Linux®（Ubuntu®、红帽（Red Hat®）、Enterprise Linux®、Steam® OS等）和台式机版Windows®（需要得到GPU厂商的允许而不是微软的承诺）上。尤其是，谷歌已经明确声明，安卓支持Vulkan，而且Vulkan已经板上钉钉地成为安卓平台的核心图形API，尽管OpenGL ES不会一夜之间消失！

平台集成

目前已有很多不同操作系统，每种操作系统都有自己独特的开窗、数据输入、视频流传送等方式。在EGL接口中，实际上所有平台集成功能都是核心API的组成部分，涵盖了各种不同的平台也许支持、也许不支持的功能组件（例如Pixmaps）。

Vulkan API中与外部世界互动的部分是自含式的，作为一套扩展功能而不是核心API组成部分提供。与EGL相比，初始Window系统集成的扩展功能大大减少了，仅定义了在显示屏上得到图像所需的最小限度的低级功能，而没有过于努力地抽取显示、视窗、背景等不同的平台构成部分。

因此，在我们选择以各种不同的方式支持的每一种平台上，功能集成都是不同的，但是与使用EGL相比，使用Vulkan时功能集成的定义依然完备得多。如需大量了解这方面的详细信息，可以查阅Alon Or-bach在2015 SIGGRAPH BoF上的讲话。

结论

Vulkan由于未被限定为平台的子集，因此有可能成为得到广泛采用的API。平台厂商、应用软件开发商和硬件厂商已经对Vulkan表现出极大的兴趣。这意味着，准备采用这个API的应用软件开发商有可能跨移动和桌面设备获得很大的市场份额。同样，随着Vulkan影响力的逐渐扩大，围绕这个API会建立一个庞大的生态系统，而支持Vulkan的平台也有可能从这个生态系统受益。

Vulkan将对行业产生重大影响，在接下来的几篇博客文章中，我将详细探讨Vulkan为什么如此重要，并深入探究为什么业界各方都对Vulkan有浓厚兴趣。

作者：Tobias Hector，2015年10月19日，发布在Multimedia、PowerVR Developers和PowerVR Graphics页面

转自：http://www.52vr.com/article-608-1.html