图形专家小组齐聚Khronos巴黎分部交流讨论下一代图形API：Vulkan - 全文

一月底的时候我在巴黎的ISART Digital（视频游戏和3D动画学校）参加了一个座谈讨论会:“新一代图形API座谈会：关于早期的Vulkan”。这次会议是由来自Unity的Christophe Riccio组织和主持的，这次会议的主题是关于Khronos Group新一代图形与计算API：Vulkan。

这次座谈会的嘉宾有来自独立软件供应商（ISV）的,独立硬件供应商（IHV）的,以及不同应用开发平台人员，他们有非常丰富的经验，从现代渲染算法到API实现以及驱动实现：

? Sébastien Lagarde (现任Unity渲染研究总监，以前曾任职于EA Frostbite)
? Julien Ignace (现任Unity R&D渲染程序员，以前曾任职于Quantic Dream)
? Jasper Bekkers (现任OTOY渲染工程师, 以前曾任职于EA Frostbite)
? Cyril Crassin (现任NVIDIA研究科学家)
? Jon Kennedy (现任Intel高级图形软件工程师)
? Adrian Bucur (现任Samsung SERI高级软件工程师)

我们讨论了多个话题，包括Vulkan最适合的开发模式；将Vulkan集成进现有的渲染引擎中有多难；调试工具对Vulkan的影响有多大。在这篇文章中总结了我认为最有意思的讨论点和挑战。

解决OpenGL的一些问题

用了将近两年时间，Khronos的一个工作小组负责设计下一代图形与计算API，致力于解决OpenGL最大的局限性问题，如下：

? 设计一个通用跨平台的API（桌面，控制台，移动和嵌入式平台）
? 紧密贴合现代GPU架构
? 提供一个控制台友好型，低开销，显示的API

专家组成员被问到是否可以从新设计一个API而不使用OpenGL的规范。OpenGL的一些先进性，例如AZDO和GL_KHR_no_error扩展，向我们证实到大量的API相关CPU开销是有可能避免的。设计一个全新的OpenGL并侧重于这些想法会给开发者带来显著的性能提升。

然而这个设计路线可能还是会有一些问题,例如：

? 缓存分配和同步的实现还是不够透明，在某些平台上卡死和缓存重影仍然会发生。
? 状态仍然是全局的。开发者需要清晰的理解每个独立硬件平台的GPU状态是如何设置的，以保证OpenGL的状态能够被有效的配置。
? 高效多线程命令提交仍然很难在OpenGL类似型API中解决。

Vulkan vs OpenGL ES：OpenGL ES不能胜任多线程任务

经过讨论后专家成员认为方向可能有些冒险，但是Vulkan API已经能够满足所有合理帧时间（time frame）的设计目标（尽管有一点点儿延迟）。

Vulkan对于开发者来说究竟有多相关？

大多数独立硬件供应商同意提供一个由开发者控制内存分配，状态设置和调用验证的API会提供更高的运行性能，同时使驱动的跨平台操作更加的可预测，这也会降低维护花销。

独立软件供应商（ISV）却有些怀疑。独立硬件供应商花费了数年时间来优化他们的OpenGL,OpenGL ES和DirectX驱动。要想获得同样的或者更好的性能就会要求独立软件供应商投入大量的资源来设计和优化他们的引擎来兼容这个新的显示API，例如高效的捕获系统状态。

除此之外，现有的中间件将需要继续支持老版本的API很长一段时间。对现在来说，Vulkan将是另一个实现与支持的标准，这将会增加维护渲染引擎代码的整体花销。

正是影响引擎的各种限制因素创造了一个机遇，就是开发更加灵活的中间件。Oxide Games公司开发的Nitrous引擎被作为一个例子进行的讨论，它已经能够兼容这个图形API的前沿技术。对于其他引擎要实现相同的性能还需要很长时间。

ProtoStar是一个使用UE4开发的Vulkan Demo

回到开始的问题这个API与谁最相关。各种引擎肯定会支持它，但是那些不得不支持老版本API的引擎进化得可能就比较慢了。那些最简单调用的工程将会是最早受益。2D渲染引擎多用于桌面显示，例如谷歌的Skia，将会支持这个API来降低功耗。这个API的低开销特性可以让开发者在短期内提升他们设计的系统性能，从而满足设计要求。例如车内手写导航系统对于CPU,GPU和内存限制非常严格。

供应商制定的代码路径是必需的吗？

目前除了扩展功能（总是要求新的代码路径和回调）。不幸的是大多数使用OpenGL和OpenGL ES的跨平台渲染引擎都要求各种各样的代码路径以兼容供应商制定的驱动操作和bugs。专家组成员被问到这些偏差是否将会在Vulkan渲染引擎中继续延续。

随着独立软件供应商不断接入到Vulkan API，很难说有多少代码路径。从理论上讲，不断降低的驱动复杂度会使各种操作变得更加透明，更少的bugs以及更少的因素去实现供应商制定的代码路径。然而专家组成员同意相比OpenGL在Vulkan中对硬件架构的理解和编程更加的重要，例如利用供应商制定的DMA队列优化数据传输。

开发工具会影响Vulkan API的流行吗？

独立软件供应商（ISV）赞同相比API自身因素，开发工具对于API的成功有更大的影响。例如开发者通常会首先采用Sony的平台和API，因为它们拥有工业标准最好的工具（很多人这样认为）。

OpenGL的开发是比较困难的。现在有很多功能模块正在被平台开发者，独立软件供应商，独立硬件供应商和社区所维护，但是这是经历了多年的发展才达到现在这个阶段的。

随着Vulkan的出现，Khronos Group将更多的思考放到工具上而不是以前的标准，例如加载层的设计让开发者能够使用Khronos组织提供的调试工具以及第三方提供的或者自定义的解决方案。不幸的是，类似OpenGL一样Vulkan缺少很多调试操作的规范化实现方式，例如分析和复现调用操作。除非Khronos组织为工具开发组织一个团队与API的开发同步进行，否则这种情况可能不会改变。

自Vulkan正式发布以来，我们看到已经有很多可用的工具，以及更多由Khronos推广者，贡献者和咨询组织成员正在开发的工具。不同平台例如谷歌和Valve将会为它们的操作系统提供跨供应商的工具。社区维护工具例如RenderDoc将会让开发者实现跨各种操作系统和GPU的调试操作。

最后对于工具的讨论，以为观众问到是否GPU的性能能够通过Vulkan API暴露出来。不幸的是这个功能还没有实现，但是未来这个问题可以通过扩展来解决。

这次座谈会得出一个结论就是好的工具对于Vulkan的成功是非常有必要的。现在有各种各样的专用的和社区支持的工具可用，能够让开发者快速找到符合自己需求的调试流程。

Khronos Group也开发了一个高层次应用摘要吗？

在这个API的设计期间，这个组织就考虑开发一个帮助手册让开发者更容易入门Vulkan操作。经过一些考虑后，如果开发一个通用的使用摘要会花费太多的精力，耽误Vulkan API的开发进度。

PowerVR框架为Vulkan开发者提供了中间调用函数

社区提供了各种库，例如PowerVR框架，这让开发者根据需要选择各种通用和不同领域的库。同时Khronos贡献者也已经计划开发这样一个框架，专家组成员同意参考使用摘要会兼容Vulkan API 1.0正式版，同时不会影响Vulkan API的开发进度。

如果你想了解更多就来GDC2016吧

希望这篇文章让大家对硬件与软件供应商关心的问题和API的发展有一个了解。如果你想了解更多关于Vulkan的资讯，以及它是怎样在我们的硬件上工作的。那就赶紧来GDC 2016现场吧（在链接下面评论或者来我们的论坛讨论）。