Vulkan API架构及详述
一、API架构
下图是Vulkan中主要的组件以及它们之间的关系：
1.1 Device
Device很好理解，一个Device就代表着一个你系统中的物理GPU。它的功能除了让你可以选择用来渲染（或者计算）的GPU以外，主要功能就是为你提供其他GPU上的资源，例如所有要用到显存的资源，以及接下来会提到的Queue和Synchronization等组件。
1.2 Pipeline
第二个主要的组件，比Device复杂很多，就是Pipeline。一个Pipeline包含了传统API中大部分的状态和设定。只不过Pipeline是需要事先创建好的，这样所有的状态组合的验证和编译都可以在初始化的时候完成，运行时不会再因为这些操作有任何性能上的浪费。但正是因为这一点，如果你不同的Pass需要不同的状态，你需要预先创造多个不同的Pipeline。然而我们不能把所有渲染需要的信息全都prebake进pipeline中，一个Pipeline应该是可以通过绑定不同的资源而复用的。接下来介绍的几个组件就可以被动态的绑定给任何Pipeline。
1.3 Buffer
接下来是Buffer。Buffer是所有我们所熟悉的Vertex Buffer, Index Buffer, Uniform Buffer等等的统称。而且一个Buffer的用途非常多样。在Vulkan中需要特别注意Buffer是从什么类型的内存中分配的，有的类型CPU可以访问，有的则不行。有的类型会在CPU上被缓存。现在这些内存的类型是重要的功能属性，不再只是对驱动的一个提示了。
1.4 Image
Image在Vulkan中代表所有具有像素结构的数组，可以用于表示纹理，Render Target等等。和其他组件一样，Image也需要在创建的时候指定使用它的模式，例如Vulkan里有参数指定Image的内存Layout，可以是Linear，也可以是Tiled Linear便于纹理Filter。如果把一个Linear layout的Image当做纹理使用，在某些平台上可能导致严重的性能损失。类似传统的API，纹理本身并不直接绑定给Pipeline。需要读取和使用Image则要依赖于ImageView。
1.5 Binding Resources
讲了几种不同类型的内存， 但是内存是从什么地方分配的呢？在Vulkan中，所有内存都分配与一个指定的Heap。一个Device也许支持几种不同类型的Heap，有些也许可以分配Mappable的内存，有些不行。具体的类型取决于程序运行的平台。值得注意的是，Vulkan Heap分配的内存和最终的Vulkan组件例如Buffer和Image直接可以不，也不应该是一对一的映射。一段内存可以分配成数段，并且分配给不同的资源使用。某种程度上这样的资源复用也是Vulkan基本的设计哲学之一。
上面提到，Buffer和Image可以动态的绑定给任意Pipeline。而具体绑定的规则就是由Descriptor指定。和其他组件一样，Descriptor Set也需要在被创建的时候，就由App指定它的固定的Layout，以减少渲染时候的计算量。Descriptor Set Layout可以指定绑定在指定Descriptor Set上的所有资源的种类和数量，以及在Shader中访问它们的索引。App可以定义多个不同的Descriptor Set Layout，所以如何为你的程序或者引擎设计Descriptor Set的Layout将是优化的重要一环。当然，程序也可以拥有多个指定Layout的Descriptor Set。因为Descriptor Set是预先创建并且无法更改的，所以改变一个绑定的资源需要重新创建整个Descriptor Set，但改变一个资源的Offset可以非常快速的在绑定Descriptor Set的时候完成。一会我会讨论如何利用这一点来实现高效的资源更新。
1.6 Command Buffer
介绍了那么多组件，都是渲染需要的数据。那么Command Buffer就是渲染本身所需要的行为。在Vulkan里，没有任何API允许你直接的，立即的像GPU发出任何命令。所有的命令，包括渲染的Draw Call，计算的调用，甚至内存的操作例如资源的拷贝，都需要通过App自己创建的Command Buffer。Vulkan对于Command Buffer有特有的Flag，让程序制定这些Command只会被调用一次（例如某些资源的初始化），亦或者应该被缓存从而重复调用多次（例如渲染循环中的某个Pass）。另一个值得注意的是，为了让驱动能更加简易的优化这些Command的调用，没有任何渲染状态会在Command Buffer之间继承下来。每一个Command Buffer都需要显式的绑定它所需要的所有渲染状态，Shader，和Descriptor Set等等。这和传统API中，只要你不改某个状态，某个状态就一直不会变，这一点很不一样。
1.7 Command Buffer Pool
Command Buffer Pool是一个需要注意的多线程相关的组件。它是Command Buffer的父亲组件，负责分配Command Buffer。Command Buffer相关的操作会对其对应的Command Buffer Pool里造成一定的工作，例如内存分配和释放等等。因为多个线程会并行的进行Command Buffer相关的操作，这个时候如果所有的Command Buffer都来自同一个Command Buffer Pool的话，这时Command Buffer Pool内的操作一定要在线程间被同步。所以这里建议每个线程都有自己的Command Buffer Pool，这样每个线程才可以任意的做任何Command Buffer相关的操作。
Command Buffer Pool的另一个性质就是支持非常高效的重置。一旦重置，所有由当前Pool分配的Command Buffer都会被清零，并且不会有任何内存管理上的碎片。所以程序只要为每一个帧和线程的组合分配一个Command Buffer Pool，就可以利用这一点，在更新Round Robin中的Command Buffer时非常快速的将需要的Buffer清零。
1.8 Descriptor Pool
另一个类似Command Buffer Pool的组件，就是Descriptor Pool。所有Descriptor Set都由Descriptor Pool分配，Descriptor Set操作会导致对应的Descriptor Pool工作而且需要线程间同步，并且Descriptor Pool也支持非常高效的将所有由当前Pool分配的Descriptor Set一次性清零。所以程序应该为每个线程分配一个Descriptor Pool，可以根据Descriptor Set的更新频率，创建不同的Descriptor Pool，例如每帧、每场景等等。
1.9 Queue
最后一个关键组件， Queue，是Vulkan中唯一给GPU递交任务的渠道。Vulkan将Queue设计成了完全透明的对象，所以在驱动里没有任何其他的隐藏Queue，也不会有任何的Synchronization发生。在Vulkan中，给GPU递交任务不再依赖于任何所谓的绑定在单一线程上的Context，Queue的API极其简单，你向它递交任务（Command Buffer），然后如果有需要的话，你可以等待当前Queue中的任务完成。这些Synchronization操作是由Vulkan提供的各种同步组件完成的。例如Samaphore可以让你同步Queue内部的任务，程序无法干预。Fence和Event则可以让程序知道某个Queue中指定的任务已经完成。所有这些组件组合起来，使得基于Command Buffer和Queue递交任务的Vulkan非常易于编写多线程程序。后文会简单讨论一些常见的多线程模式。最后，和前面提到的一样，Queue不光接收图形渲染的调用，也接受计算调用和内存操作。
二、相关API简述
2.1 设备初始化
2.1.1 Instance --> GPU --> Device
Instance表示具体的Vulkan应用。在一个应用程序中可以创建多个实例，这些实例之间相互独立，互不干扰。
当调用API创建Vulkan实例的时候，Vulkan SDK内部会经由驱动装载器（loader）查找可用的GPU设备。
创建Vulkan实例需要两个输入信息：
- 应用程序的信息
- 内存分配回调函数
Vulkan通过用户输入的内存分配器来分配内存。
创建好Instance，就可以用Instance枚举所有可用的Vulkan GPU设备。
有了GPU设备，就可以获取具体GPU的信息。如果系统中安装了多个GPU设备，就可用GPU信息比较GPU设备之间的兼容性等。
找到了合适的GPU后，就可以通过GPU创建设备示例。
2.2、绘制
2.2.1 Queues
有了设备，就可以创建命令队列。命令队列是与设备绑定的，不能跨设备使用。
队列封装了图形、计算、直接内存访问功能，独立调度、异步等调度操作。
2.2.2 Command Buffer
有了设备，就可以创建命令缓冲。命令缓冲是绘制命令的批次集合。
用户可创建任意多的命令缓冲，支持在多线程中创建。
Command占用的内存是通过Command Buffer内存池动态分配，不需要指定内存池的大小。
2.2.3 Command
在命令缓冲区中可以创建多个命令。多个命令完成批次即命令缓冲后，可以重复利用。
这里有点像OpenGL里面的NameList。
Command Buffer的操作使用pipeline barrier区分。barrier可以等待和触发事件。
注：
- 这里可以看出Command被包装在Command Buffer中，当把Command
Buffer提交给Queue中后，Queue中执行的是Command Buffer中的Command。 - Command Buffer和Queue的类别需要匹配，否则不能正确执行，但一个Command
Buffer并不会跟任何Queue有联系。也就意味着，一个Command Buffer可以被提交给多个Queue，只要他们的类别匹配。
2.2.4 Shaders
使用设备创建Shader。
同样支持多线程。
2.2.5 Pipeline
渲染管线同样需要设备创建。
渲染管线状态包括：Shaders，混合、深度、剔除、模版状态等。
另外Vulkan提供了API保存和加载渲染管线的状态。
2.2.6 Descriptors
Vulkan资源都用descriptor表示, descriptor分成descriptor set，descriptor set从descriptor pool分配。
每个descriptor set都有个layout布局，布局是在pipeline创建的时候确定的。layout在descriptor set 和pipeline之间共享，并且必须匹配。
pipeline可以切换使用相同layout的descriptor set。
多个不同layout的set可以组成链在一个pipeline中使用。
2.2.7 Render Pass
Render Pass表示一帧的某个阶段，包含了绘制过程中的很多信息，包括：
- Layout和framebuffer attachment的类型
-Render Pass在开始和结束的时候该做什么
-Render Pass影响framebuffer的区域-分块渲染和延迟渲染需要的信息
2.2.8 Drawing
Draws位于Render Pass内，在Command Buffer的上下文中执行。支持多种绘制类型：基于索引的和非索引的，直接的和间接的等
3.1、多线程支持
3.1.1 同步
使用事件同步任务，可以设置、重置、查询和等待事件。
Command Buffer执行完成后可以触发事件
3.1.2 任务队列
任务在设备所属的队列中执行，准备好的Command buffer送到队列中执行。
队列保留内存，驱动不负责管理内存，同样由程序管理。
队列可以触发事件，等待信号量。
4.1、呈现
4.1.1 Presentation
展现就是如何在屏幕上显示图片。
可显示的资源使用与framebuffer绑定的“图片”展现，由与平台相关的模块创建，即所谓的窗口系统接口WSI。
WSI用了列举系统的显示设备和视频模式，全屏，控制显示垂直同步等。
Presenta跟命令缓冲一起进入队列。
5.1、资源创建和释放
资源包括CPU资源和GPU资源。
CPU资源通过vkCreate创建，GPU资源由vkAllocMemory创建，由vkBindObjectMemory与CPU对象绑定。
应用程序负责Vulkan对象的析构，需要保证顺序。Vuilkan资源没有引用计数机制，都需要显式释放。
转载：https://blog.csdn.net/qq_35312463/article/details/105923904