下一代 3D 图形 API 入门指南

Vulkan 是一种革命性的高性能 3D 图形与计算 API，专为现代 GPU 管线架构而设计，以满足社区日益严苛的需求。该 API 提供了一种全新的方法，用于克服现有传统 API 中的复杂性和不足。Vulkan 是一种显式 API，能够保证可预测的行为，并使你在不产生卡顿或掉帧的情况下获得平滑的渲染帧率。本章将概述 Vulkan API，并介绍它相对于其前身 OpenGL API 所具有的独特特性。我们还将了解 Vulkan 的生态系统，并理解其图形系统。

因此，本章将涵盖以下内容：

• Vulkan 及其演进历程
• Vulkan 与 OpenGL 的对比
• 开始之前需要了解的重要术语
• 学习 Vulkan 的基础知识
• 理解 Vulkan 应用程序
• 入门 Vulkan 编程模型

Vulkan 及其演进历程

自著名的 OpenGL API 诞生以来，至今已将近四分之一个世纪，而它仍在不断演进。从内部实现来看，OpenGL 本质上是一个纯状态机，包含多个以二进制状态（开/关）运行的开关。这些状态用于在驱动程序中构建依赖关系映射，以便管理资源并对其进行最优控制，从而获得最大的性能。

这种状态机以隐式方式自动完成资源管理，但它并不足够智能，无法捕捉应用程序的逻辑，而应用逻辑正是资源管理的核心驱动力。因此，可能会出现一些不可预期的情况，例如在应用程序并未请求的情况下，底层实现发生变化，导致着色器被重新编译。此外，OpenGL API 还可能受到其他因素的影响，例如行为不可预测、多线程扩展性不足、渲染异常等问题。本章后续将通过对比 OpenGL 与 Vulkan API，来帮助理解两者之间的差异。

Vulkan API 由 Khronos 组织于 2016 年发布，其革命性的架构能够充分利用现代图形处理器（GPU），从而构建高性能的图形与计算应用。如果你还不了解 Khronos，它是一个由成员和组织组成的联盟，专注于制定免版税的开放 API 标准。更多信息可参考：https://www.khronos.org。

Vulkan 的最初概念由 AMD 设计和开发，基于其专有的 Mantle API。该 API 通过多款游戏展示了前沿的技术能力，验证了其革命性的设计思路，并满足了行业中所有具有竞争力的需求。随后，AMD 将 Mantle API 开源并捐赠给 Khronos。Khronos 联盟在众多软硬件厂商的协作下，共同推动并发布了 Vulkan。

Vulkan 并不是唯一的下一代 3D 图形 API，它的竞争者还包括微软的 DirectX 12 和苹果的 Metal。然而，DirectX 仅限于 Windows 平台，而 Metal 则仅适用于 Mac（OS X 和 iOS）。相比之下，Vulkan 的优势在于其跨平台特性，几乎支持所有主流操作系统，包括 Windows（XP、Vista、7、8 和 10）、Linux、Tizen、SteamOS 以及 Android。

Vulkan 与 OpenGL 的对比

以下是 Vulkan 相比 OpenGL 具有优势的特性与改进：

• 更低的驱动开销和 CPU 使用率：Vulkan 的设计更贴近底层图形硬件。因此，它为应用程序开发者提供了对主机计算资源的直接控制，从而使 GPU 能以尽可能快的速度进行渲染。这也使软件能够直接访问图形处理器，从而获得更高的性能。
• 多线程可扩展性：OpenGL 的多线程扩展性非常差，很难有效利用线程特性来更好地使用 CPU。相比之下，Vulkan 在设计之初就充分考虑了多线程，允许最终用户以非常透明的方式充分利用其多线程能力，并且不存在隐式的全局状态。不同线程中的任务从创建并提交执行的那一刻起就彼此独立。
• 显式 API：OpenGL 是一种隐式 API，资源管理由驱动程序负责。驱动需要根据应用提供的提示来跟踪和管理资源，这会带来不必要的开销。
  • Vulkan 则是一种显式 API，驱动不再负责跟踪资源及其相互关系，这一任务由应用程序承担。这种清晰的设计方式更加可预测；驱动不会像在 OpenGL 中那样在幕后“翻筋斗”式地管理资源。因此，任务处理流程更加简洁直接，从而实现最佳性能和可预测的行为。
• 预编译的中间着色语言：与 OpenGL 需要以 OpenGL 着色语言（GLSL） 源代码形式提供着色器不同，Vulkan 使用 标准可移植中间语言（SPIR-V）。SPIR-V 是一种用于并行计算和图形处理的标准中间语言。

• 驱动层与应用层：在 OpenGL 中，相比驱动层，应用层要薄得多，因为驱动的自动化机制负责资源管理和状态跟踪。Vulkan 则恰恰相反：它使驱动层更加贴近硬件，并且具有更低的开销，而逻辑、资源和状态的管理责任则交由应用程序来承担。下图展示了这两种 API 中驱动代码与应用代码规模（厚度）的对比。

• 内存控制：Vulkan 能够暴露系统中多种不同的内存类型，并要求应用开发者根据每个资源的预期用途选择合适的内存类型。相比之下，OpenGL 驱动会根据内部启发式算法来决定资源的放置方式，这些算法因厂商而异，可能导致次优的内存放置，或者在驱动后续移动资源时产生意料之外的卡顿。
• 可预测性：与 OpenGL 相比，Vulkan 具有高度的可预测性，在渲染过程中不会引发延迟或卡顿。任务在交给驱动后会立即被提交，而 OpenGL 的任务提交流程并不具备这种即时性，而是受制于驱动的调度器。
• 单一 API：OpenGL 为桌面平台提供了独立的 API（OpenGL），同时还为嵌入式平台提供了另一个 API（OpenGL ES）。Vulkan 的设计更加简洁，只提供一个统一的 API，适用于各种平台。Vulkan 将移动平台视为一等公民，而 OpenGL 并非如此。通常，OpenGL 的实现会首先出现在桌面版本中，随后才移植到 OpenGL ES。
• 直接访问 GPU：Vulkan 通过公开自身的能力和硬件特性，为应用开发者提供了高度的控制权。它暴露了多种可用的物理设备、内存类型、命令缓冲队列以及扩展。这种方式确保了软件层能够更加贴近真实的硬件。
• 错误检查与验证：在使用 OpenGL 时，即使是行为规范、不会在运行时触发错误的应用程序，也仍然需要承担错误检查带来的性能开销。相比之下，Vulkan 将错误检查与验证作为一种可选的附加服务提供，可根据需要随时启用或关闭。这些检查并非强制性的，可以通过启用错误检查层及其他验证层，将其注入到运行时环境中。通过避免不必要的检查，Vulkan 能够减少 CPU 开销。理想情况下，这些错误检查与验证层应在开发阶段开启以支持调试，而在发布阶段关闭以获得最佳性能。
• 支持多种 GPU 硬件：Vulkan 在其实现中将对移动端和桌面端光栅化器的支持作为一体化设计的一部分。它既支持面向嵌入式平台的基于分块（tile-based）或延迟（deferred）的光栅化器，也支持原生的、基于分块的前馈式光栅化器。

开始之前需要了解的重要术语

在深入了解基础细节之前，让我们先看一下一些在 Vulkan 中使用的重要技术术语。随着内容的推进，本书还会介绍更多这样的技术名词。

• 物理设备（Physical device）与设备（Device）：一个系统中可能包含多个支持 Vulkan 的物理硬件设备。物理设备表示一个唯一的硬件设备，而设备则是应用程序中对该物理设备的逻辑表示。
• 队列（Queues）：队列代表执行引擎与应用程序之间的一个接口。一个物理设备始终包含一个或多个队列（例如图形队列、计算队列、DMA/传输队列等）。队列的职责是收集作业（命令缓冲区），并将它们分派到物理设备上进行处理。
• 内存类型（Memory type）：Vulkan 暴露了多种内存类型。从宏观层面来看，主要有两种内存：主机内存（host）和设备内存（device）。在本章的后续内容中，我们将对这些内存类型进行详细介绍。
• 命令（Command）：命令是一条用于执行某种操作的指令。命令大体上可以分为三类：动作（action）、状态设置（set state）以及同步（synchronization）。
• 动作命令（Action commands）：这些命令可用于绘制图元、清除表面、拷贝缓冲区、执行查询/时间戳操作，以及开始/结束子通道（subpass）操作。这类命令能够修改帧缓冲附件，对内存（缓冲区或图像）进行读写，以及向查询池（query pool）写入数据。
• 状态设置命令（Set state commands）：这类命令用于绑定管线（pipeline）、描述符集（descriptor set）和缓冲区；同时也用于设置动态状态以及渲染通道/子通道（render pass / subpass）的状态。
• 同步命令（Synchronization commands）：同步用于满足两个或多个动作命令之间的执行要求，这些命令可能会竞争资源或存在内存依赖关系。同步命令包括设置或等待事件、插入管线屏障（pipeline barrier），以及定义渲染通道/子通道依赖关系。
• 命令缓冲区（Command buffer）：命令缓冲区是一组命令的集合；它用于录制命令并将其提交到队列中执行。

在下一节中，我们将对 Vulkan 进行总体概述，以帮助理解其工作模型和基本原理。同时，我们还将了解命令的语法规则，仅通过观察 API 命令即可对其用法形成初步认识。

学习 Vulkan 的基础知识

本节将介绍 Vulkan 的基础知识，主要包括以下内容：

• Vulkan 的执行模型
• Vulkan 的队列
• 对象模型
• 对象的生命周期与命令语法
• 错误检查与验证

Vulkan 的执行模型

一个支持 Vulkan 的系统能够查询系统并暴露其上可用的物理设备数量。每个物理设备都会公布一个或多个队列。这些队列被划分为不同的队列族（queue family），而每个队列族都具有非常明确、特定的功能。例如，这些功能可能包括图形、计算、数据传输以及稀疏内存管理。队列族中的每个成员可以包含一个或多个相似的队列，使它们彼此兼容。举例来说，某些实现可能在同一个队列上同时支持数据传输和图形操作。

Vulkan 允许应用程序显式地管理内存控制。它会暴露设备上可用的各种堆（heap）类型，而每个堆都属于不同的内存区域。Vulkan 的执行模型相当简单且直观：命令缓冲区被提交到队列中，然后由物理设备按顺序取出并进行处理。

一个 Vulkan 应用程序负责通过录制大量命令到命令缓冲区中，并将这些命令缓冲区提交到队列，从而控制一组支持 Vulkan 的设备。该队列由驱动程序读取，驱动会按照提交的顺序立即执行这些任务。命令缓冲区的构建过程开销较大，因此一旦构建完成，就可以将其缓存起来，并根据需要多次提交到队列中执行。此外，在应用程序中还可以使用多线程并行地同时构建多个命令缓冲区。

下图展示了执行模型的一个简化示意图：

在该模型中，应用程序会录制两个包含多条命令的命令缓冲区。随后，根据任务的性质，这些命令会被提交到一个或多个队列中。队列再将这些命令缓冲区任务提交给设备进行处理。最终，设备处理完成后，要么将结果显示到输出设备上，要么将结果返回给应用程序以供进一步处理。

在 Vulkan 中，应用程序需要负责以下内容：

• 为命令的成功执行准备所有必要的前置条件：
  • 这可能包括准备资源、预编译着色器并将资源绑定到着色器上；指定渲染状态；构建管线；以及发出绘制调用。
• 内存管理
• 同步机制
  • 主机（Host）与设备（Device）之间的同步
  • 设备上不同队列之间的同步
• 资源冲突（Hazard）管理

Vulkan 的队列

队列是 Vulkan 中将命令缓冲区送入设备进行处理的媒介。命令缓冲区中录制了一条或多条命令，并被提交到所需的队列中。设备可能会暴露多个队列，因此，将命令缓冲区提交到正确的队列是应用程序的责任。

命令缓冲区可以被提交到以下类型的队列中：

• 单一队列：
  • 命令缓冲区的提交顺序与执行（或回放）顺序会被保持
  • 命令缓冲区以串行方式执行
• 多队列：
  • 允许命令缓冲区在两个或多个队列中并行执行
  • 除非显式指定，否则命令缓冲区的提交顺序与执行顺序不作任何保证
  • 对此进行同步是应用程序的责任；如果没有进行同步，执行顺序相对于彼此而言可能是完全无序的

Vulkan 提供了多种同步原语，使你能够对执行任务的执行顺序进行相对精细的控制，无论是在单个队列内还是在多个队列之间。具体如下：

• 信号量（Semaphore）：用于跨多个队列的同步，或在单个队列中对命令缓冲区提交操作进行粗粒度的同步。
• 事件（Event）：用于细粒度同步，作用于单个队列，允许在同一个命令缓冲区内部，或提交到同一队列的一系列命令缓冲区之间进行同步。主机（Host）也可以参与基于事件的同步。
• 栅栏（Fence）：用于主机与设备之间的同步。
• 管线屏障（Barrier）：管线屏障是一种插入到命令缓冲区中的指令，用于确保其之前的命令必须先执行完成，之后指定的命令才能开始执行。

对象模型

在应用层面，所有实体（包括设备、队列、命令缓冲区、帧缓冲、管线等）都被称为 Vulkan 对象。在 API 的内部层面，这些 Vulkan 对象通过句柄来标识。句柄分为两种类型：可分派句柄和不可分派句柄。

• 可分派句柄：这是一种指针，指向一个内部的、不透明形态的实体。不透明类型不允许直接访问结构体的字段，字段只能通过 API 例程来访问。每个可分派句柄都有一个关联的可分派类型，用作 API 命令中的参数。示例如下：

VkInstance

VkCommandBuffer

VkPhysicalDevice

VkDevice

VkQueue

• 不可分派句柄：这是 64 位整数类型的句柄，可能直接包含对象信息本身，而不是指向结构体的指针。示例如下：

VkSemaphore	VkFence	VkQueryPool	VkBufferView
VkDeviceMemory	VkBuffer	VkImage	VkPipeline
VkShaderModule	VkSampler	VkRenderPass	VkDescriptorPool
VkDescriptorSetLayout	VkFramebuffer	VkPipelineCache	VkDescriptorSet
VkEvent	VkCommandPool	VkPipelineLayout	VkImageView

对象的生命周期与命令语法

在 Vulkan 中，对象的创建与销毁需要按照应用程序的逻辑显式进行，其生命周期由应用程序自行管理。

Vulkan 对象通过 Create 命令创建，并通过 Destroy 命令销毁：

• Create 语法：对象使用 vkCreate* 命令创建，该命令以 Vk*CreateInfo 结构体作为输入参数。
• Destroy 语法：通过 Create 命令创建的对象，使用 vkDestroy* 命令进行销毁。

对于作为现有对象池（object pool）或堆（heap）一部分创建的对象，则使用 Allocate 命令进行分配，并通过 Free 命令从对象池或堆中释放：

• Allocate 语法：作为对象池一部分创建的对象，使用 vkAllocate* 命令，并以 Vk*AllocateInfo 作为参数输入。
• Free 语法：对象通过 vkFree* 命令释放回对象池或内存。

与具体 Vulkan 实现相关的信息，都可以通过 vkGet* 命令方便地获取。以 vkCmd* 形式命名的 API 用于在命令缓冲区中录制命令。

错误检查与验证

Vulkan 在设计时以性能为核心，通过将错误检查和验证机制设为可选，以实现尽可能高的执行效率。在运行时，错误检查和验证带来的性能开销极低，从而使命令缓冲区的构建与提交过程非常高效。

这些可选能力可以通过 Vulkan 的分层架构来启用。该架构允许在系统运行过程中动态注入各种层（如调试层和验证层），以提供调试与验证支持。

理解 Vulkan 应用程序

本节将概述 Vulkan 应用程序的各个组成部分，这些部分对构建 Vulkan 应用程序至关重要。

下面的框图展示了系统中不同组件模块及其相互间的连接关系：

驱动

一个支持 Vulkan 的系统至少包含一个 CPU 和一个 GPU。独立硬件厂商（IHV）会针对其专用的 GPU 架构，提供符合 Vulkan 规范的驱动程序实现。驱动程序充当应用程序与设备本身之间的接口。它为应用程序提供高层次的功能，使应用能够与设备进行通信。例如，驱动程序会向应用提供系统中可用设备的数量、这些设备所支持的队列及队列能力、可用的内存堆及其相关属性等信息。

应用

应用是指用户编写的程序，目的是使用 Vulkan API 来执行图形或计算任务。应用首先进行硬件和软件的初始化；在此过程中，它会检测驱动程序并加载所有 Vulkan API。显示层通过 Vulkan 的窗口系统集成（WSI）API 进行初始化；WSI 有助于将绘制得到的图像呈现到显示表面上。应用创建资源，并使用描述符将这些资源绑定到着色器阶段。描述符集布局用于将已创建的资源绑定到所创建的底层管线对象（图形管线或计算管线）。最后，应用记录命令缓冲区，并将其提交到队列中进行处理。

WSI

窗口系统集成（Window System Integration，WSI）是 Khronos 提供的一组扩展，用于在不同平台（如 Linux、Windows 和 Android）之间统一显示层的实现方式。

SPIR-V

SPIR-V 为 Vulkan 提供了一种用于描述着色器的预编译二进制格式。针对多种着色器源语言（包括 GLSL 和 HLSL 的不同变体），都提供了相应的编译器，可将其编译生成 SPIR-V。

LunarG SDK

LunarG 提供的 Vulkan SDK 包含多种工具和资源，用于辅助 Vulkan 应用程序的开发。这些工具和资源包括 Vulkan 加载器、验证层、跟踪与回放工具、SPIR-V 工具、Vulkan 运行时安装程序、文档、示例以及演示程序。有关如何开始使用 LunarG SDK 的详细说明，请参见第 3 章《与设备握手》。更多信息可访问：http://lunarg.com/vulkan-sdk

入门 Vulkan 编程模型

让我们详细探讨 Vulkan 的编程模型。这里假设读者是一名完全的初学者，通过本节内容可以理解以下概念：

• Vulkan 的编程模型
• 渲染执行模型（将以伪逐步（pseudo step-by-step）流程进行描述）
• Vulkan 的工作原理

下图展示了 Vulkan 应用程序编程模型的自顶向下视角；我们将对这一流程进行深入讲解，并进一步探讨各个子层级组件及其功能。

硬件初始化

当一个 Vulkan 应用程序启动时，其首要任务是进行硬件初始化。在这一阶段，应用程序通过与加载器进行通信来激活 Vulkan 驱动程序。下图展示了 加载器 及其子组件的框图结构。

加载器：加载器是一段在应用程序启动阶段使用的代码，用于以跨平台、统一的方式在系统中定位 Vulkan 驱动程序。加载器的主要职责包括：

• 定位驱动程序：作为其最主要的职责，加载器知道在当前系统中应当到何处查找 Vulkan 驱动程序，并负责找到正确的驱动并将其加载。
• 平台无关性：Vulkan 的初始化过程在所有平台上都是一致的。这与 OpenGL 不同，在 OpenGL 中，创建上下文需要针对不同环境使用不同的窗口系统 API（如 EGL、GLX 和 WGL）。在 Vulkan 中，平台相关的差异通过扩展机制来体现。
• 可注入层：加载器支持分层架构，并提供在运行时注入各种层的能力。其一大改进在于：在判断应用程序对 API 的使用是否合法时，相关的验证工作不再由驱动程序承担，驱动程序也无需维护为此所需的任何状态。因此，建议在开发阶段根据应用程序的需求启用所选的可注入层，而在部署阶段将其关闭。例如，可注入层可以提供以下功能：
• 跟踪 Vulkan API 命令
• 捕获渲染场景并在之后重新执行
• 提供用于调试的错误检测与验证

Vulkan 应用程序首先与加载器库进行一次握手，并初始化 Vulkan 实现的驱动程序。加载器库以动态方式加载 Vulkan API。加载器还提供了一种机制，可将特定的层自动加载到所有 Vulkan 应用程序中，这种层被称为 隐式启用层（Implicit-Enabled layer）。

在加载器定位到驱动程序并成功与 API 建立链接之后，应用程序需要负责完成以下工作：

• 创建 Vulkan 实例
• 查询物理设备以获取可用的队列
• 查询扩展，并将其保存为函数指针，例如与窗口系统集成（WSI）或特殊功能相关的 API
• 启用用于错误检查、调试或验证流程的可注入层

窗口呈现表面

当加载器成功定位到 Vulkan 实现的驱动程序后，就可以开始使用 Vulkan API 进行绘制了。为此，需要准备一张用于执行绘制操作的图像，并将其呈现到显示窗口中：

构建用于呈现的图像以及创建窗口本身都是高度依赖平台的工作。在 OpenGL 中，窗口系统与渲染过程是紧密耦合的；窗口系统的帧缓冲会在创建上下文/设备时一并生成。与 OpenGL 的这种方式相比，Vulkan 的一个重大区别在于：Vulkan 中的上下文/设备创建完全不需要涉及窗口系统，相关工作通过 窗口系统集成（WSI） 来管理。

WSI 提供了一组跨平台的窗口管理扩展，其特点包括：

• 为大多数平台（如 Windows、Linux、Android 及其他操作系统）提供统一的跨平台实现
• 提供一致的 API 标准，使得创建呈现表面并显示图像变得更加简单，而无需深入了解底层细节

WSI 支持多种窗口系统（如 Wayland、X 和 Windows），同时还通过交换链（swapchain）来管理图像的所有权。

WSI 提供了一种交换链机制；通过这种机制，可以使用多张图像，从而实现当窗口系统正在显示一张图像时，应用程序可以同时准备下一张图像。

下图展示了双重缓冲（double-buffering）的图像交换过程。图中包含两张图像，分别命名为 第一张图像 和 第二张图像。在 WSI 的帮助下，这两张图像在 应用程序 和 显示端 之间进行交换：

WSI 充当了 显示端 与 应用程序 之间的接口。它确保 显示端 和 应用程序 以互斥的方式获取这两张图像。因此，当 应用程序 正在处理 第一张图像 时，WSI 会将 第二张图像 移交给显示端以渲染其内容。一旦 应用程序 完成了对 第一张图像 的绘制，就会将其提交给 WSI，并随即获取 第二张图像 进行处理，反之亦然。

这一步，我们需要进行以下操作：

• 创建一个原生窗口（例如 Windows 操作系统中的 CreateWindow 方法）
• 创建一个附加到该窗口的 WSI 表面
• 创建交换链以便在表面上进行呈现
• 从已创建的交换链中请求绘图图像

资源设置

设置资源意味着将数据存储到内存区域中。这些数据可以是任何类型的，例如顶点属性（如位置、颜色），或者图像类型/名称。当然，这些数据必须已经存在于内存中的某个位置，才能被 Vulkan 访问。

与 OpenGL 不同，OpenGL 通过提示（hints）在幕后管理内存，而 Vulkan 提供了完全的底层访问权限和对内存的控制。Vulkan 会在物理设备上公布各种可用的内存类型，为应用程序显式地管理这些不同类型的内存提供了良好的机会。

内存堆（Memory heaps）可以根据性能分为两种类型：

• 主机本地（Host local）：这是一种较慢的内存类型
• 设备本地（Device local）：这是一种具有高带宽的内存类型，速度更快

内存堆还可以根据其内存类型配置进一步划分：

• 设备本地（Device local）：这种内存物理上附着在物理设备上：
  • 对设备可见
  • 对主机不可见
• 设备本地、主机可见（Device local, host visible）：这种内存同样物理上附着在设备上：
  • 对设备可见
  • 对主机可见
• 主机本地、主机可见（Host local, host visible）：指的是主机的本地内存，但速度比设备本地内存慢：
  • 对设备可见
  • 对主机可见

在 Vulkan 中，资源由应用程序显式地进行管理，应用程序对内存管理拥有完全且独占的控制权。以下是资源管理的流程：

• 资源对象：在资源设置阶段，应用程序需要为资源分配内存；这些资源可以是图像对象（image）或缓冲区对象（buffer）。
• 分配与子分配：当创建资源对象时，它们只关联了逻辑地址，并没有实际的物理内存作为支撑。应用程序需要分配物理内存，并将这些逻辑地址绑定到物理内存上。由于内存分配本身是一个开销较大的操作，子分配是一种高效的内存管理方式：一次性分配一大块物理内存，然后将不同的资源对象放入其中。子分配由应用程序负责。下图展示了从一大块已分配的物理内存中进行子分配的对象示意：

• 稀疏内存：对于非常大的图像对象，Vulkan 完全支持稀疏内存及其所有特性。稀疏内存是一种特殊机制，允许在内存中存储远大于实际物理内存容量的图像资源。该技术会将图像拆分为多个瓦片（tiles），并只加载符合应用逻辑需求的那些瓦片。
• 暂存缓冲区：对象缓冲区和图像缓冲区的数据填充通常通过“暂存”方式完成，即在物理分配时使用两个不同的内存区域。资源的理想内存位置可能对主机不可见，在这种情况下，应用程序必须先在一个对主机可见的暂存缓冲区中填充数据，然后再将其传输到理想的内存位置。
• 异步传输：数据通过异步命令进行传输，可以使用图形队列或 DMA / 传输队列来完成。

因此，在资源设置阶段，你需要执行以下任务：

1. 创建资源对象。
2. 查询合适的内存实例，并创建内存对象，例如缓冲区和图像。
3. 获取分配所需的内存需求。
4. 分配内存空间并将数据存储到其中。
5. 将分配的内存绑定到之前创建的资源对象上。

管线设置

管线是一组按照应用程序逻辑所定义的固定顺序发生的事件。这些事件包括：提供着色器、将着色器绑定到资源，以及管理相关的状态。

描述符集与描述符池

描述符集是资源与着色器之间的接口。它是一种简单的数据结构，用于将着色器与资源信息（如图像或缓冲区）进行绑定。描述符集关联（或绑定）了着色器即将使用的资源内存。描述符集具有以下特性：

• 频繁变化：从本质上来说，描述符集会频繁发生变化；通常包含诸如材质、纹理等属性。
• 描述符池：鉴于描述符集的这种特性，它们通常从描述符池中分配，从而避免引入全局同步开销。
• 多线程可扩展性：这允许多个线程同时更新描述符集。

使用 SPIR-V 的着色器

在 Vulkan 中，指定着色器或计算内核的唯一方式是通过 SPIR-V。其主要特性包括：

• 多种输入来源：存在多种可生成 SPIR-V 的编译器，支持不同的源语言，包括 GLSL 和 HLSL。它们可用于将人类可读的着色器代码转换为 SPIR-V 的中间表示形式。
• 离线编译：着色器 / 计算内核在离线阶段完成编译，并在运行前提前注入到应用程序中。
• glslangValidator：LunarG SDK 提供了 glslangValidator 编译器，可用于将等价的 GLSL 着色器生成 SPIR-V 着色器。
• 多入口点：着色器 / 计算内核在离线阶段完成编译，并在运行前提前注入到应用程序中。

管线管理

物理设备包含一系列硬件设置，用于决定如何解释并绘制所提交的几何体输入数据。这些设置统称为 管线状态（pipeline states）。它们包括光栅化状态、混合状态以及深度/模板状态；同时还包括所提交几何体的图元拓扑类型（点 / 线 / 三角形）以及用于渲染的着色器。管线状态分为两类：动态状态和静态状态。这些管线状态用于创建管线对象（图形管线或计算管线），而管线对象的创建正是一个性能关键路径。因此，我们不希望反复创建管线对象，而是希望一次创建、重复使用。

Vulkan 允许你通过管线对象，并结合 管线缓存对象（Pipeline Cache Object，PCO） 以及 管线布局（pipeline layout） 来控制这些状态：

• 管线对象：管线的创建开销很大，它包括着色器重新编译、资源绑定、Render Pass、帧缓冲管理以及其他相关操作。管线对象的数量可能达到数百甚至上千，因此，每一种不同的状态组合都会被存储为一个独立的管线对象。
• 管线缓存对象：由于管线创建代价高昂，一旦创建完成就可以被缓存。当请求创建新的管线时，驱动程序可以在缓存中查找最接近的匹配，并基于已有管线来创建新的管线。管线缓存是不透明的，其具体的使用细节由驱动程序自行决定，并未在规范中明确规定。如果应用程序希望在多次运行之间复用缓存，则需要自行负责缓存的持久化；同时，在创建管线时提供合适的缓存对象，才能获得潜在的性能收益。
• 管线布局：管线布局描述了将与管线一起使用的描述符集，指明着色器中每个绑定槽位所连接的资源类型。不同的管线对象可以共享同一个管线布局。

在管线管理阶段，主要会发生以下流程：

• 应用程序将着色器编译为 SPIR-V 形式，并在管线的着色器状态中进行指定。
• 描述符用于将资源与着色器连接起来。应用程序从描述符池中分配描述符集，并将输入或输出资源绑定到着色器中的绑定槽位。
• 应用程序创建管线对象，其中包含用于控制硬件设置的静态与动态状态配置。为了获得更好的性能，管线应当从管线缓存池中创建。

命令录制

命令录制是命令缓冲区形成的过程。命令缓冲区从命令池的内存中分配，命令池也可以用于多次分配多个命令缓冲区。命令缓冲区的录制是在应用程序所定义的起始与结束范围内，通过向其中提交一系列命令来完成的。下图展示了一个绘制命令缓冲区的录制过程。可以看到，它由多条按照自上而下顺序录制的命令组成，这些命令共同负责对象的绘制。

绘制过程的主要组成部分如下：

• 作用域（Scope）：作用域定义了命令缓冲区录制的开始与结束。
• 渲染通道（Render Pass）：渲染通道定义了一次可能影响帧缓冲缓存的作业执行过程。它可以包含附件（attachments）、子通道（subpasses）以及这些子通道之间的依赖关系。附件指的是用于执行绘制操作的图像资源。在子通道中，类似附件的图像可以用于多重采样解析。渲染通道还控制在通道开始时如何处理帧缓冲：可以保留其中的上一帧信息，或者使用指定的颜色将其清除。同样，在渲染通道结束时，渲染结果可以被丢弃，也可以被存储下来。
• 管线（Pipeline）：管线对象包含用于控制硬件行为的状态信息，包括静态状态和动态状态。
• 描述符（Descriptor）：描述符用于将资源信息绑定到管线。
• 资源绑定（Bind resource）：指定顶点缓冲区、图像或其他与几何体相关的资源信息。
• 视口（Viewport）：决定在绘制表面上执行图元渲染的区域范围。
• 裁剪区域（Scissor）：定义一个矩形区域，超出该区域的内容将不会被绘制。
• 绘制（Drawing）：绘制命令用于指定几何缓冲区的属性，例如起始索引、元素总数等。

下图展示了一种基于多核、多线程的可扩展命令缓冲区创建模型。该模型能够在多核处理器上实现真正的并行执行。

在该模型中，每个线程都会使用独立的命令缓冲池，由其分配一个或多个命令缓冲区，从而避免对资源锁的竞争。

队列提交

一旦命令缓冲区构建完成，就可以将其提交到队列中进行处理。Vulkan 向应用程序暴露了多种类型的队列，例如图形队列、DMA / 传输队列以及计算队列。提交时所选择的队列类型高度依赖于具体的任务性质。例如，与图形相关的任务必须提交到图形队列；同样地，对于计算操作，计算队列通常是最佳选择。已提交的任务会以异步方式执行。命令缓冲区可以被推送到多个彼此兼容的队列中，从而实现并行执行。应用程序需要自行负责命令缓冲区内部、不同队列之间，甚至主机与设备之间的所有同步工作。

队列提交阶段主要执行以下操作：

• 从交换链中获取用于绘制下一帧的图像
• 部署所需的同步机制，例如信号量和栅栏
• 收集命令缓冲区，并将其提交到相应的设备队列中进行处理
• 请求将已完成绘制的图像呈现到输出设备上

总结

本入门章节将 Vulkan 的复杂性提炼到了一个使初学者也能轻松理解的层次。在本章中，我们了解了 Vulkan 的发展演进，并探究了其背后的历史与贡献者。随后，我们将 Vulkan 与 OpenGL 进行了对比，理解了它在现代计算时代存在的原因和意义。我们还回顾了与该 API 相关的重要技术术语，并给出了简明易懂的定义。Vulkan API 的基础知识部分为其工作模型提供了一个精确且详尽的概览。我们还介绍了 Vulkan 生态系统中的基本构建模块，并了解了它们各自的角色、职责以及相互之间的关联。最后，在本章结尾，我们通过一种易于理解的伪编程模型，对 Vulkan 的工作方式进行了说明。

完成本章后，你应当能够对 Vulkan API 以及其详细的工作模型建立起基本的理解，并熟悉相关的技术术语，从而迈出 Vulkan 编程的第一步。

在下一章中，我们将采用伪代码的方式正式开始 Vulkan 编程实践。我们会构建一个简单示例，在不过多深入细节的前提下，涵盖 Vulkan API 的重要核心概念、基础内容以及关键数据结构，以帮助理解 Vulkan 中图形管线编程的完整流程。