美国计算机协会(SIGGRAPH)深度探讨Vulkan的一系列文章将陆续发布,本文是开篇之作。我不会透露任何新的信息,只讨论Khronos官方发布的内容。不过,我会阐述所发布内容的深刻含义以及它对交付链的影响——即从我们(IP供应商)到设备供应商和开发商,再到消费者。

将讲述在SIGGRAPH2015年度会议上讨论Khronos BoF系列的内容以及会上其他人所谈论的信息。本周,我将首先讨论,Vulkan针对所有平台设计一个API的意义何在。
一个API意义何在?
Vulkan的覆盖面广,其涵括的大量平台和硬件均有着截然不同的形成因素和功率。Vulkan可以在智能手表或高端工作站上运行,或介于两者之间的任何东西上运行。这些平台有着完全不同的性能和使用案例。
如果API在所有平台上都完全相同,您将无法对其进行区分。那么最终您可能会试图在智能手表上运行Maya——实际上这并没有多大意义。显然,Vulkan不是一个操作系统,所以会有其他方法来区分各个平台,但Vulkan首先需要区分的便是其运行的图形硬件。
所以,在实施上会有什么差异?——它们是什么,且如何保持相同?
一贯性
API编码
Vulkan 启用一个API的主要观点是,您可以在所有目标平台上使用相同的页眉和相同的代码链接到相同的库。有一个路径,即通过API可在屏幕上按你所需画出三角形态,且您可在任何地方使用此路径。没有必要解决预处理器定义在代码中的嵌入深度,比如处理OpenGL和OpenGL ES之间的细微差别。
性能
只要提供相同的编码便可获得相同的性能。大概有一千种方式可在OpenGL上做任何事情,但仅有一、两种方式可在每个供应商的硬件上运转迅速——且随着供应商不同而有所差异。
在Vulkan上,我们则进行了精简,通常只有几种方式可以做任何事情。对于每条保留的路径,已经由Khronos的每个成员仔细筛选,以确保运转顺利。事实上,很多功能的目标是确保快速路径具有一致性——例如通过渲染层加载操作使图像变亮。
所以在大多数情况下,您可以从应用程序中获得良好的性能,且无需对特定硬件进行优化。当然,仍有些供应商可能想让您避免或尽少使用位数——但应该有一个单一的无处不在的快捷路径。虽仍然需要优化特定的供应商,但相比OpenGL已经改善很多。
我将介绍更多Vulkan将发布的有关架构的内容。
差异
性能
有一些功能需要消耗大量的功率,大量占用GPU的面积,且通常不是所有的应用都支持这些功能。但这些不是创建图形应用程序的根本,因此也没必要在所有的平台上使用——还有一组核心的功能可以使用。例如,您不可能在未来看到智能手表上镶嵌着棋盘花纹,况且谁会真正需要那样的手表呢?
将可选择的功能作为Vulkan API的性能标志,这些功能可能会或不会真正实现。为确保功能被使用,在创建设备时便查询或明显启用这些功能,这样您便不会对其错误使用。
限制条件
比实际功能支持更具细粒度的是使用或传递给API的值受到限制。因此,您需要了解可使用的各向异性最大值是多少,或有多少统一的缓冲区可以被着色器等引用。Vulkan可保证所有这些的最小值,因此开发人员可以依靠这些功能支持,同时仍允许供应商提供额外的功能。
扩展
虽然名字不是特别相关,但Vulkan 有一款OpenGL继承版,也是 Khronos的一部分。OpenGL最成功的一个特征是扩展模型。虽然略有瑕疵,但扩展模型在原型新功能设计及展示供应商硬件各种有趣部件方面却非常成功。出于这些原因,Vulkan将公开扩展模型。扩展模型也具有可选功能,因此在初始化时也需显式地启用,以免不可使用。
功能集
现在虽不存在功能集,但我们却有一个想法:将功能打包成集,并分成良好的定义块,以确保功能支持、扩展和各种限制的存在。但您需要寻找设备的功能时,这将成为有用的指南。例如,在CAD / CAM工作中可能需要一个为工作站定义的功能集,包括:为明确指示进行更高限制、机器中资源缺乏的桌面卡——相反可能会有更细的轮廓来表示一个高效的解决方案。任何Khronos定义的功能集旨在设计或购买产品时提供指引——更多功能并不意味着更好!例如,手机中的工作站功能集可能是资源缺乏、接近限制值的设备,且通常是不可取的。
平台供应商还可定义自己的功能集,就像Android的 OpenGL ES 3.1扩展包。如果现有的功能集并不完全符合他们的需求,或者想确保进行特定平台的扩展,供应商的自我定义便可使他们得以区分或为用户提供更一致的体验。
平台支持
Vulka设计成在任何平台上运行,但我们特别期望它出现在Android、Tizen和许多不同偏好的Linux( Ubuntu, Red Hat Enterpise Linux, Steam OS)和Windows桌面版本上 (GPU供应商的默许,而不是Microsoft的保证)。特别是Google曾明确声明,支持Vulkan 在Android上运行,并成为该平台的核心图形API——尽管OpenGL ES不会在一夜之间消失!
平台集成
许多不同的操作系统,每个都有自己独特的窗口、数据输入、视频流和相似物的方式。在EGL上,所有平台集成核心API的一部分——覆盖的部分功能可能被或不被各种平台支持(例如像素图)。
Vulkan API与外部交互的部分是独立的一组扩展,而不是核心API的一部分。初始窗口系统集成扩展相比EGL已大幅减少,定义低水平功能是在屏幕上获取图片的最低需求,且不必去提取不同平台的结构如显示、窗口、上下文等。
因此,你选择的以不同方式支持的每个平台都是不同的,但它却比EGL中定义的要好。详细细节可以在SIGGRAPH 2015同行交流会有关Alon Or-bach的讨论中找到。
小结
Vulkan不限于一个平台子集,其有可能被API广泛采纳。已经有很多平台供应商、开发人员和硬件供应商对此颇感兴趣。这意味着旨在API的应用开发人员通过移动设备和桌面设备将占有大量的市场份额。同样,若建立有关API的开发者生态系统,平台支持可能会因此受益。
Vulkan将对该行业产生重大影响。在接下来的几篇博客中,我将讨论为何它将迅速占领市场,并就为何这么多方对此感兴趣来阐述我的观点。
想了解更多关于Vulkan的资讯,请注册为以下五个即将开展的研讨会:
•一个API适用于所有平台
•移动设备的高效率
•扩展至多个线程
•明确操作和一致的帧时间
•架构:Vulkan API 如何在PowerVR GPU中运作