图形专家小组齐聚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渲染引擎中继续延续。