【Intel技术不愧是大牛，分析vulkan这么到位!】

关于作者

我成为软件开发人员已有超过 9 年的时间。我最感兴趣的领域是图形编程，大部分工作主要涉及 3D 图形。我在 OpenGL* 和着色语言（主要是 GLSL 和 Cg）方面拥有丰富的经验。三年来我还一直致力于开发 Unity* 软件。我也曾有机会投身于涉及头盔式显示器（比如 Oculus Rift*）或类似 CAVE 系统的 VR 项目。

最近，我正与英特尔的团队成员一起准备验证工具，为被称为 Vulkan 的新兴 API 提供显卡驱动程序支持。图形编程接口及其使用方法对我来说非常新鲜。在了解这些内容的时候我突然想到，我可以同时准备有关使用 Vulkan 编写应用的教程。我可以像那些了解 OpenGL 并希望“迁移”至其后续产品的人一样，分享我的想法和经验。

关于 Vulkan

Vulkan 被视作是 OpenGL 的后续产品。它是一种多平台 API，可支持开发人员准备游戏、CAD 工具、性能基准测试等高性能图形应用。它可在不同的操作系统（比如 Windows*、Linux* 或 Android*）上使用。 Vulkan 由科纳斯组织创建和维护。 Vulkan 与 OpenGL 之间还有其他相似之处，包括图形管道阶段、OpenGL 着色器（一定程度上），或命名。

但也存在许多差异，但这进一步验证了新 API 的必要性。 20 多年来，OpenGL 一直处于不断变化之中。自 90 年代以来，计算机行业发生了巨大的变化，尤其是显卡架构领域。 OpenGL 库非常适用，但仅依靠添加新功能以匹配新显卡功能并不能解决一切问题。有时需要完全重新设计。因此创建出了 Vulkan。

Vulkan 基于 Mantle* — 第一个全新的低级别图形 API。 Mantle 由 AMD 开发而成，专为 Radeon 卡架构而设计。尽管是第一个公开发布的 API，但使用 Mantle 的游戏和基准测试均显著提升了性能。后来陆续发布了其他低级别 API，比如 Microsoft 的 DirectX* 12、Apple 的 Metal*，以及现在的 Vulkan。

传统图形 API 和全新低级别 API 之间有何区别？ OpenGL 等高级别 API 使用起来非常简单。开发人员只需声明操作内容和操作方式，剩下的都由驱动程序来完成。驱动程序检查开发人员是否正确使用 API 调用、是否传递了正确的参数，以及是否充分准备了状态。如果出现问题，将提供反馈。为实现其易用性，许多任务必须由驱动程序在“后台”执行。

在低级别 API 中，开发人员需要负责完成大部分任务。他们需要符合严格的编程和使用规则，还必须编写大量代码。但这种做法是合理的。开发人员知道他们的操作内容和希望实现的目的。但驱动程序不知道，因此使用传统 API 时，驱动程序必须完成更多工作，以便程序正常运行。采用 Vulkan 等 API 可避免这些额外的工作。因此 DirectX 12、Metal 或 Vulkan 也被称为精简驱动程序/精简 API。大部分时候它们仅将用户请求传输至硬件，仅提供硬件的精简抽象层。为显著提升性能，驱动程序几乎不执行任何操作。

低级别 API 要求应用完成更多工作。但这种工作是不可避免的，必须要有人去完成。因此由开发人员去完成更加合理，因为他们知道如何将工作分成独立的线程，图像何时成为渲染对象（颜色附件）或用作纹理/采样器等等。开发人员知道管道处于何种状态，或哪些顶点属性变化的更频繁。这样有助于提高显卡硬件的使用效率。最重要的原因是它行之有效。我们能够观察到显著的性能提升。

但“能够”一词非常重要。它要求完成其他工作，但同时也是一种合适的方法。在有一些场景中，我们将观察到，OpenGL 和 Vulkan 之间在性能方面没有任何差别。如果不需要多线程化，或应用不是 CPU 密集型（渲染的场景不太复杂），使用 OpenGL 即可，而且使用 Vulkan 不会实现性能提升（但可能会降低功耗，这对移动设备至关重要）。但如果我们想最大限度地发挥图形硬件的功能，Vulkan 将是最佳选择。

主要显卡引擎迟早会支持部分（如果不是所有）新的低级别 API。如果希望使用 Vulkan 或其他 API，无需从头进行编写。但通常最好对“深层”信息有所了解，因此我准备这一教程。

源代码说明

我是 Windows 开发人员如果有选择，我选择编写面向 Windows 的应用。因为我在其他操作系统方面没有任何经验。但 Vulkan 是多平台 API，而且我希望展示它可用于不同的操作系统。因此我们准备了一个示例项目，可在 Windows 和 Linux 上编译和执行。

关于本教程的源代码，请访问：

https://github.com/GameTechDev/IntroductionToVulkan

我曾尝试编写尽可能简单的代码示例，而且代码中不会掺杂不必要的“#ifdefs”。但有时不可避免（比如在窗口创建和管理过程中），因此我们决定将代码分成几个小部分：

Tutorial 文件，是这里最重要的一部分。与 Vulkan 相关的所有代码都可放置在该文件中。每节课都放在一个标头/源配对中。
OperatingSystem 标头和源文件，包含依赖于操作系统的代码部分，比如窗口创建、消息处理和渲染循环。这些文件包含面向 Linux 和 Windows 的代码，不过我试着尽可能地保持统一。
main.cpp 文件，每节课的起点。由于它使用自定义 Window 类，因此不包含任何特定于操作系统的代码。
VulkanCommon 标头/源文件，包含面向从教程 3 之后各教程的基本课程。该类基本上重复教程 1 和 2 — 创建 Vulkan 实例和渲染图像和其他所需的资源，以在屏幕上显示图像。我提取了这一准备代码，因此其他章节的代码可以仅专注于所介绍的主题。
工具，包含其他实用程序函数和类，比如读取二进制文件内容的函数，或用于自动破坏对象的包装程序类。

每个章节的代码都放置在单独的文件夹中。有时可包含其他数据目录，其中放置了用于某特定章节的资源，比如着色器或纹理。数据文件夹应拷贝至包含可执行文件的相同目录。默认情况下可执行文件将编译成构建文件夹。

没错。编译和构建文件夹。由于示例项目可在 Windows 和 Linux 上轻松维护，因此我决定使用 CMakeLists.txt 文件和 CMake 工具。 Windows 上有一个 build.bat 文件，可创建 Visual Studio* 解决方案 — （默认情况下）Microsoft Visual Studio 2013 需要编译 Windows 上的代码。我在 Linux 上提供了一个 build.sh 脚本，可使用 make 编译代码，但使用 Qt 等工具也可轻松打开 CMakeLists.txt。当然还需要 CMake。

生成解决方案与项目文件，而且可执行文件将编译至构建文件夹。该文件夹也是默认的工作目录，因此数据文件夹应拷贝至该目录，以便课程正常运行。执行过程中如果出现问题，cmd/terminal 中将“打印”其他信息。如果出现问题，将通过命令行/终端运行课程，或检查控制台/终端窗口，以查看是否显示了消息。

我希望这些说明能够帮助大家了解并跟上 Vulkan 教程的节奏。现在我们来重点学习 Vulkan！