第1章 认识Vulkan：定位、架构与设计哲学

第 1 章 · 认识 Vulkan：定位、架构与设计哲学

章节摘要：本章跟着一条主线走——一个用惯了 OpenGL 的团队，第一次拿到一份 Vulkan 的「办事指南」。我们不急着写代码，先把三件事弄清楚：这套 API 为什么长成这样（起源与哲学）、它的世界里有哪些证件和窗口（术语与对象模型）、它和 OpenGL 及 DirectX 等邻居的边界在哪里（选型对比），最后拆开它的大厅结构（分层架构与扩展机制）。读完本章，你应当能判断自己的项目该不该上 Vulkan，并为第 2 章的第一次真正「递件」做好认知准备。

一条主线

主线从一块新装的独立显卡开始。团队把它插上主板，装好驱动，跑了一个用 OpenGL 写的老 Demo——能转，但帧率抖动得厉害，Profiler 里一半的耗时落在「驱动内部」，无从归因。他们第一次听说 Vulkan 时，得到的评价是两句互相矛盾的话：「快得多」和「烦得多」。本章的任务，就是把这两句话拆开：为什么显式控制能换来快，显式控制又必然带来哪些「烦」。

沿途我们会不断回到这张概念地图。它不是 Vulkan 的对象图（那是下一章的主角），而是本章四个知识块之间的关系：设计哲学决定了对象模型长什么样，对象模型决定了它与旧代 API 的对比结论，分层架构与扩展机制则是哲学在工程结构上的落地。

沿途站点

第一站是 1.1 起源与设计哲学。从 Mantle 捐赠代码到 Vulkan 发布，弄清「把驱动做薄」这个决定从何而来。理解了动机，后面所有的繁琐都会变得有理由。

第二站是 1.2 关键术语与抽象模型。Instance、PhysicalDevice、Device、Queue、CommandBuffer——这些名字背后是严格的所有权层级。本节给出全册都会沿用的「证件与窗口」对照表，后续每一章的新对象都会挂回这张表。

第三站是 1.3 选型对比。Vulkan 不是任何项目的默认答案。本节用同一组渲染需求在 Vulkan、OpenGL、DirectX 12 之间做一次完整的比较，给出该用与不该用的判断标准，并展开一个真实的选型案例。

第四站是 1.4 分层架构与扩展机制。Loader、ICD、Layer 三层各管什么；扩展的命名规则与启用流程；能力查询为什么必须在创建对象之前完成。这一节是第 2 章初始化代码的直接前置。

拐点与结论

本章最重要的认知转折发生在 1.2 到 1.3 之间：当你发现每个 Vulkan 对象都有明确的创建者、明确的参数表、明确的生命周期，你就再也无法用「差不多能跑」来描述一个渲染程序了。结论可以说得很直白——Vulkan 把图形编程从「调用魔法」变成了「办理手续」。手续多，是代价；每一步可查、可验、可复现，是回报。如果你的项目吃不到这份确定性，1.3 节会明确劝你别用 Vulkan，这比任何吹捧都有用。

读完你应该

不带任何资料，向同事讲清楚 Vulkan 与 OpenGL 在责任划分上的差别，并各举一个受益与受损的场景。

画出 Instance 到 Queue 的对象层级，指出哪些对象是查询用的「只读档案」、哪些是执行用的「办事窗口」。

拿到一块新硬件时，列出判断「该不该用 Vulkan」需要收集的证据清单，并说明每项证据来自哪个查询接口。

看到一个形如 VK_KHR_xxx 或 VK_EXT_xxx 的扩展名，说出它的提供方、作用域（实例级还是设备级）以及启用它需要的步骤。

解释验证层为什么不在驱动内部实现，以及这个设计对发布版本意味着什么。

下一章的接力

主线将在第 2 章进入实际办事：领第一张证件（vkCreateInstance）、挑受理网点（物理设备选择）、开办事账户（逻辑设备与队列），一直办到能把图像摆上屏幕（交换链与呈现）。本章的所有概念都会在那里变成带参数的调用，请把 1.2 节的对照表放在手边。

出发前再确认一遍状态：你能不查资料说清 Vulkan 与 OpenGL 的责任分界，能画出对象层级图，能对着一块新硬件列出选型证据清单，能拆解一个扩展名的构成，能解释验证层为何外置。五项齐了，第 2 章的每一段代码都会读得很快；缺哪项，先回对应的站点补齐再动身。