进击的 Vulkan 移动开发之 Command Buffer

Vulkan 开发的系列文章：

1. 进击的 Vulkan 移动开发（一）之此生前世

2. 进击的 Vulkan 移动开发（二）之谈谈对渲染流程的理解

3. 进击的 Vulkan 移动开发之 Instance & Device & Queue

此篇文章继续学习 Vulkan 中的组件：Command-Buffer 。

在前面的文章中，咱们已经建立了 Instance、Device、Queue 三个组件，而且知道了 Queue 组件是用来和物理设备沟通的桥梁，而具体的沟经过程就须要 Command-Buffer （命令缓冲区）组件，它是若干命令的集合，咱们向 Queue 提交 Command-Buffer，而后才交由物理设备 GPU 进行处理。

Command-Pool 组件

在建立 Command-Buffer 以前，须要建立 Command-Pool 组件，从 Command-Pool 中去分配 Command-Buffer 。

仍是老套路，咱们须要先建立一个 VkXXXXCreateInfo 的结构体，结构体每一个参数的释义仍是要多看官方的文档。

// 建立 Command-Pool 组件
    VkCommandPool command_pool;
    VkCommandPoolCreateInfo poolCreateInfo = {};
    poolCreateInfo.sType = VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO;
    // 能够看到 Command-Pool 还和 Queue 相关联
    poolCreateInfo.queueFamilyIndex = info.graphics_queue_family_index;
    // 标识命令缓冲区的一些行为
    poolCreateInfo.flags = VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT;
    // 具体建立函数的调用
    vkCreateCommandPool(info.device, &poolCreateInfo, nullptr, &command_pool);
复制代码

有几个参数须要注意：

1. queueFamilyIndex 参数为建立 Queue 时选择的那个 queueFlags 为 VK_QUEUE_GRAPHICS_BIT 的索引，从 Command-Pool 中分配的的 Command-Buffer 必须提交到同一个 Queue 中。
2. flags 有以下的选项，分别指定了 Command-Buffer 的不一样特性：

typedef enum VkCommandPoolCreateFlagBits {
    VK_COMMAND_POOL_CREATE_TRANSIENT_BIT = 0x00000001,
    VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT = 0x00000002,
    VK_COMMAND_POOL_CREATE_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF
} VkCommandPoolCreateFlagBits;
复制代码

• VK_COMMAND_POOL_CREATE_TRANSIENT_BIT

  • 表示该 Command-Buffer 的寿命很短，可能在短期内被重置或释放

• VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT

  • 表示从 Command-Pool 中分配的 Command-Buffer 能够经过 vkResetCommandBuffer 或者 vkBeginCommandBuffer 方法进行重置，若是没有设置该标识位，就不能调用 vkResetCommandBuffer 方法进行重置。

Command-Buffer 组件

接下来就是从 Command-Pool 中分配 Command-Buffer，经过 VkCommandBufferAllocateInfo 函数。

首先须要一个 VkCommandBufferAllocateInfo 结构体表示分配所须要的信息。

typedef struct VkCommandBufferAllocateInfo {
    VkStructureType         sType;
    const void*             pNext;
    VkCommandPool           commandPool;    // 对应上面建立的 command-pool
    VkCommandBufferLevel    level;
    uint32_t                commandBufferCount; // 建立的个数
} VkCommandBufferAllocateInfo;
复制代码

这里有个参数也要注意：

• VkCommandBufferLevel 指定 Command-Buffer 的级别。

有以下级别可使用：

typedef enum VkCommandBufferLevel {
    VK_COMMAND_BUFFER_LEVEL_PRIMARY = 0,
    VK_COMMAND_BUFFER_LEVEL_SECONDARY = 1,
    VK_COMMAND_BUFFER_LEVEL_BEGIN_RANGE = VK_COMMAND_BUFFER_LEVEL_PRIMARY,
    VK_COMMAND_BUFFER_LEVEL_END_RANGE = VK_COMMAND_BUFFER_LEVEL_SECONDARY,
    VK_COMMAND_BUFFER_LEVEL_RANGE_SIZE = (VK_COMMAND_BUFFER_LEVEL_SECONDARY - VK_COMMAND_BUFFER_LEVEL_PRIMARY + 1),
    VK_COMMAND_BUFFER_LEVEL_MAX_ENUM = 0x7FFFFFFF
} VkCommandBufferLevel;
复制代码

通常来讲，使用 VK_COMMAND_BUFFER_LEVEL_PRIMARY 就行了。

具体建立代码以下：

VkCommandBuffer commandBuffer[2];
    VkCommandBufferAllocateInfo command_buffer_allocate_info{};
    command_buffer_allocate_info.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO;
    command_buffer_allocate_info.commandPool = command_pool;
    command_buffer_allocate_info.commandBufferCount = 2;
    command_buffer_allocate_info.level = VK_COMMAND_BUFFER_LEVEL_PRIMARY;
    vkAllocateCommandBuffers(info.device, &command_buffer_allocate_info, commandBuffer);
复制代码

Command-Buffer 的生命周期

建立了 Command-Buffer 以后，来了解一下它的生命周期，以下图：

• Initial 状态

在 Command-Buffer 刚刚建立时，它就是处于初始化的状态。今后状态，能够达到 Recording 状态，另外，若是重置以后，也会回到该状态。

• Recording 状态

调用 vkBeginCommandBuffer 方法从 Initial 状态进入到该状态。一旦进入该状态后，就能够调用 vkCmd* 等系列方法记录命令。

• Executable 状态

调用 vkEndCommandBuffer 方法从 Recording 状态进入到该状态，此状态下，Command-Buffer 能够提交或者重置。

• Pending 状态

把 Command-Buffer 提交到 Queue 以后，就会进入到该状态。此状态下，物理设备可能正在处理记录的命令，所以不要在此时更改 Command-Buffer，当处理结束后，Command-Buffer 可能会回到 Executable 状态或者 Invalid 状态。

• Invalid 状态

一些操做会使得 Command-Buffer 进入到此状态，该状态下，Command-Buffer 只能重置、或者释放。

Command-Buffer 的记录与提交

如今能够尝试着记录一些命令，提交到 Queue 上了，命令记录的调用过程以下图：

在 vkBeginCommandBuffer 和 vkEndCommandBuffer 方法之间能够记录和渲染相关的命令，这里先不考虑中间的过程，直接建立提交。

begin 阶段

VkCommandBufferBeginInfo beginInfo = {};
        beginInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO;
        beginInfo.flags = VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT;
        vkBeginCommandBuffer(commandBuffer[0], &beginInfo);
复制代码

首先，仍是须要建立一个 VkCommandBufferBeginInfo 结构体用来表示 Command-Buffer 开始的信息。

这里要注意的参数是 flags ，表示 Command-Buffer 的用途，

typedef enum VkCommandBufferUsageFlagBits {
    VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT = 0x00000001,
    VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT = 0x00000002,
    VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT = 0x00000004,
    VK_COMMAND_BUFFER_USAGE_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF
} VkCommandBufferUsageFlagBits;
复制代码

• VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT
  • 表示该 Command-Buffer 只使用提交一次，用完以后就会被重置，而且每次提交时都须要从新记录

end 阶段

直接调用 vkEndCommandBuffer 方法就能够结束记录，此时就能够提交了。

vkEndCommandBuffer(commandBuffer[0]);
复制代码

buffer 提交

经过 vkQueueSubmit 方法将 Command-Buffer 提交到 Queue 上。

一样的仍是须要建立一个 VkSubmitInfo 结构体：

typedef struct VkSubmitInfo {
    VkStructureType                sType;
    const void*                    pNext;
    uint32_t                       waitSemaphoreCount;  // 等待的 Semaphore 数量
    const VkSemaphore*             pWaitSemaphores;     // 等待的 Semaphore 数组指针
    const VkPipelineStageFlags*    pWaitDstStageMask;       // 在哪一个阶段进行等待
    uint32_t                       commandBufferCount;  // 提交的 Command-Buffer 数量
    const VkCommandBuffer*         pCommandBuffers;      // 具体的 Command-Buffer 数组指针
    uint32_t                       signalSemaphoreCount;    //执行结束后通知的 Semaphore 数量
    const VkSemaphore*             pSignalSemaphores;       //执行结束后通知的 Semaphore 数组指针
} VkSubmitInfo;
复制代码

它的参数比较多，而且涉及到 Command-Buffer 之间的同步关系了，这里简单说一下，后面再细说这一块。

以下图，Vulkan 中有 Semaphore、Fences、Event、Barrier 四种机制来保证同步。

简单说一下 Semaphore 和 Fence 。

• Semaphore

  • Semaphore 的做用主要是用来向 Queue 中提交 Command-Buffer 时实现同步。好比说某个 Command-Buffer-B 在执行的某个阶段中须要等待另外一个 Command-Buffer-A 执行成功后的结果，同时 Command-Buffer-C 在某阶段又要要等待 Command-Buffer-B 的执行结果，那么就应该使用 Semaphore 机制实现同步；
  • 此时 Command-Buffer-B 提交到 Queue 时就须要两个 VkSemaphor ，一个表示它须要等待的 Semaphore，而且指定在哪一个阶段等待；一个是它执行结束后发出通知的 Semaphore。

• Fence

  • Fence 的做用主要是用来保证物理设备和应用程序之间的同步，好比说向 Queue 中提交了 Command-Buffer 后，具体的执行交由物理设备去完成了，这是一个异步的过程，而应用程序若是要等待执行结束，就要使用 Fence 机制。

Semaphore 和 Fence 有相同之处，可是使用场景却不同，就如图所示。

Semaphore 和 Fence 的建立过程以下，和以往的 Vulkan 建立对象的调用方式没有太大区别：

// 建立 Semaphore
    VkSemaphore imageAcquiredSemaphore;
    VkSemaphoreCreateInfo semaphoreCreateInfo = {};
    semaphoreCreateInfo.sType = VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO;
    vkCreateSemaphore(info.device, &semaphoreCreateInfo, nullptr, &imageAcquiredSemaphore);

    // 建立 Fence
    VkFence drawFence;
    VkFenceCreateInfo fenceCreateInfo = {};
    fenceCreateInfo.sType = VK_STRUCTURE_TYPE_FENCE_CREATE_INFO;
    // 该参数表示 Fence 的状态，若是不设置或者为 0 表示 unsignaled state
    fence_info.flags = 0; 
    vkCreateFence(info.device, &fenceCreateInfo, nullptr, &drawFence);
复制代码

继续回到 VkSubmitInfo 结构体中，若是只是简单的提交 Command-Buffer，那就不须要考虑 Semaphore 这些同步机制了，把相应的参数都设置为 nullptr，或者直接不设置也行，最后提交就行了，代码以下:

// 简单的提交过程
    // 开始记录
    VkCommandBufferBeginInfo beginInfo1 = {};
    beginInfo1.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO;
    beginInfo1.flags = VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT;
    vkBeginCommandBuffer(commandBuffer[0], &beginInfo1);

    // 省略中间的 vkCmdXXXX 系列方法
    // 结束记录
    vkEndCommandBuffer(commandBuffer[0]);

    VkSubmitInfo submitInfo1 = {};
    submitInfo1.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO;
    // pWaitSemaphores 和 pSignalSemaphores 都不设置，只是提交
    submitInfo1.commandBufferCount = 1;
    submitInfo1.pCommandBuffers = &commandBuffer[0];

    // 注意最后的参数 临时设置为 VK_NULL_HANDLE，也能够设置为 Fence 来同步
    vkQueueSubmit(info.queue, 1, &submitInfo1, VK_NULL_HANDLE);
复制代码

以上就完成了 Command-Buffer 提交到 Queue 的过程，省略了 Semaphores 和 Fences 的同步机制，固然也能够把它们加上。

在 vkQueueSubmit 的最后一个参数设置为了 VK_NULL_HANDLE ，这是 Vulkan 中设置为 NULL 的一个方法（实际上是设置了一个整数 0 ），也能够设置了 Fence ，表示咱们要等待该 Command-Buffer 在 Queue 执行结束，虽然说 Command-Buffer 也能够经过 Semaphore 来表示执行结束，但这两种方式的使用场景不同。

回到 Fence 的建立过程，其中有一个 flags 参数表示 Fence 的状态，有以下两种状态：

• signaled state
  • 若是 flags 参数为 VK_FENCE_CREATE_SIGNALED_BIT 则表示建立后处于该状态。
• unsignaled state
  • 默认的状态。

当 vkQueueSubmit 的最后参数传入 Fence 后，就能够经过 Fence 等待该 Command-Buffer 执行结束。

// wait fence to enter the signaled state on the host
// 错误的 waitForFences 使用，由于它并非一个阻塞的方法
// VkResult res = vkWaitForFences(info.device, 1, &fence, VK_TRUE, UINT64_MAX);
    VkResult res;
    do {
        res = vkWaitForFences(info.device, 1, &fence, VK_TRUE, UINT64_MAX);
    } while (res == VK_TIMEOUT);
复制代码

vkWaitForFences 方法会等待 Fence 进入 signaled state 状态，该方法的调用要放在 while 循环中，由于它并非一个阻塞的方法，能够理解成一个状态查询，若是结果不对，返回的是 VK_TIMEOUT，结果知足要求才返回 VK_SUCCESS 。

当 Command-Buffer 执行结束后，传入的 Fence 参数就会从 unsignaled state 进入到 signaled state ，从而触发 vkWaitForFences 调用结束循环，代表执行结束了。

这就是 Fence 的使用，至于 Command-Buffer 之间经过 Semaphore 来同步的示例，详见后续文章。

总结

本篇文章主要讲解了 Command-Buffer 的使用和提交，而且涉及到了 Vulkan 的一些同步机制。

具体和渲染有关的操做，都要在 Command-Buffer 之间记录，结束记录以后提交给 Queue ，让 GPU 去执行具体的操做，固然具体执行是一个异步的过程，须要用到同步机制。

Semaphore 和 Fence 均可以实现同步，但使用场景不一样。

欢迎关注微信公众号：【纸上浅谈】，得到最新文章推送~~~