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上的讲话。