5.2 命令缓冲记录与队列提交

5.2 命令缓冲记录与队列提交

本节摘要：命令缓冲是 CPU 与 GPU 之间唯一的货运单据：从池里领取、多线程录制、带同步凭证提交、执行完毕按节奏回收。本节讲清命令缓冲的完整生命周期与状态机，交付多线程录制的标准框架，并把提交调用里「等待信号量、发出信号量、完成栅栏」的三件套仪式拆开讲透。

凌晨的性能回放里有个耐人寻味的细节：帧时间毛刺总在提交之后、绘制之前的那段出现。追下去发现，命令录制是主线程现画现录的——GPU 空转着等 CPU 慢慢念工单。本节要立的正是这件事的解法：把「记录」与「执行」彻底解耦，让 CPU 提前批量录、GPU 按序跑。命令缓冲是 Vulkan 执行体系的核心单据，也是多线程渲染的地基。

一、池与缓冲：领取制与两种重置策略

命令缓冲不单独创建，从命令池（VkCommandPool）领取。池有两个关键属性决定使用模式：族编号（缓冲只能提交到该族的队列）与重置标志。重置策略要重点辨析——RESET_COMMAND_BUFFER_BIT 允许逐条缓冲独立重置，灵活但驱动侧管理开销略高；不带该标志时只能整池重置（vkResetCommandPool），适合「每线程一池、每帧整池重置」的批量节奏。工程上后者更常见：回收成本低，且线程与池的绑定天然免锁。

VkCommandPoolCreateInfo pci = {VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO};
pci.flags            = VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT; // 教学用逐条重置
pci.queueFamilyIndex = graphicsFamily;
VkCommandPool pool;
vkCreateCommandPool(device, &pci, NULL, &pool);

VkCommandBufferAllocateInfo ai = {VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO};
ai.commandPool        = pool;
ai.level              = VK_COMMAND_BUFFER_LEVEL_PRIMARY;   // 次级用 SECONDARY
ai.commandBufferCount = maxFramesInFlight;                 // 在途帧各一条
vkAllocateCommandBuffers(device, &ai, cmdBuffers);
​

二、状态机：一条缓冲的五种身份

命令缓冲的生命周期是规范定义的状态机，每个状态允许的操作严格受限：

两条铁律从状态机直接推出。其一，待执行态不可触碰：缓冲正在队列里排队或执行时，重置、重录、销毁全是未定义行为——「何时可以回收」的答案由栅栏给（2.5 节的帧栅栏正是在等这个）。其二，录制是纯本地操作：vkCmd 系列只往缓冲里写指令字节，不碰驱动热路径，这正是多线程录制可行的原因——各写各的缓冲，物理上无共享。

三、提交仪式：三件套的分工

提交是一次带因果声明的委托。vkQueueSubmit 的完整参数里，等待信号量与阶段掩码声明「本批命令从哪个阶段开始要等谁」，发出信号量声明「本批命令完成到哪个阶段后通知谁」，栅栏声明「全部执行完后通知 CPU」：

VkSubmitInfo si = {VK_STRUCTURE_TYPE_SUBMIT_INFO};
si.waitSemaphoreCount   = 1;
si.pWaitSemaphores      = &imageAvailable;            // 等采集完成
si.pWaitDstStageMask    = &colorOutputStage;          // 从颜色输出阶段开始等
si.commandBufferCount   = 1;
si.pCommandBuffers      = &cmd;
si.signalSemaphoreCount = 1;
si.pSignalSemaphores    = &renderFinished;            // 完成后通知呈现

VK_CHECK(vkQueueSubmit(graphicsQueue, 1, &si, frameFence)); // 栅栏通知 CPU
​

三件套各通一侧：等待与发出信号量是 GPU 侧的接力棒（CPU 永远不碰），栅栏是给 CPU 的完成回执。一次提交可以携带多条缓冲（数量上限按 maxCommandBuffers 查询，通常宽松），多条缓冲之间保证按序执行——批内有序、批间无序是提交的基本语义。别把 vkQueueSubmit 当成 vkFlush 那样的「执行一下」：它是异步委托，函数返回时 GPU 多半还没开始跑。

四、多线程录制：次级缓冲的标准框架

命令体系的多线程能力分两层。第一层最朴素：每线程一条主缓冲各自录制、各自提交到同一队列（或不同队列），池按线程分配即免锁。第二层是次级命令缓冲（SECONDARY）：把一个渲染通道内的绘制段落录成「子工单」，主缓冲用 vkCmdExecuteCommands 汇总执行——渲染通道只开关一次，内部段落可并行录制。

// 工作线程：把本帧地表与物件段落录进次级缓冲
VkCommandBufferBeginInfo bi = {VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO};
bi.flags = VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT;  // 声明在通道内
bi.pInheritanceInfo = &inherit;   // 继承主缓冲的通道、帧缓冲、子通道
vkBeginCommandBuffer(secondary[i], &bi);
// ……录制本线程负责的绘制……
vkEndCommandBuffer(secondary[i]);

// 主线程：一次通道内汇总执行（主干示例）
vkCmdBeginRenderPass(cmd, &rbi, VK_SUBPASS_CONTENTS_SECONDARY_COMMAND_BUFFERS);
vkCmdExecuteCommands(cmd, threadCount, secondaries);
vkCmdEndRenderPass(cmd);
​

收益要算清：录制加速的前提是「单线程录制真是瓶颈」。绘制量小、状态少的场景，多线程录制的收益抵不过复杂度；绘制调用数以千计的开放世界场景，这套框架是把 CPU 帧时间压进预算的主力。

五、案例：开放世界场景的录制改造

背景：某开放世界 Demo 每帧约九千条绘制命令，主线程录制加提交占了帧预算的四成，GPU 反而时常空闲等单。

操作：按三层改造。池与缓冲按「在途帧乘工作线程数」布设，每线程独占一池整帧重置；场景按包围盒与材质分桶，静态分桶的命令变化频率低，做「缓存式录制」——桶内容不变时直接复用上一帧的次级缓冲（配合可重入的增量更新）；主缓冲只做骨架（通道开关加汇总执行），分桶次级缓冲由线程池并行重录。提交侧保持单队列，先验证录制端收益再考虑多队列。

结果：录制段 CPU 耗时降为原来的四分之一，主线程只承担骨架汇总；GPU 空转消失，帧率上限抬升。改造最大的一笔成本是「桶的失效追踪」——判定哪些桶必须重录的逻辑成了新的维护点。

解读：这个案例的核心经验是「缓存放在录制层」：命令缓冲是 CPU 产物，天然可缓存、可增量，比任何运行期微优化都直接。而失效追踪的复杂度警告我们：录制的灵活性要用正确的数据结构换，不是徒手循环能扛的。

变式：没有次级缓冲需求的小型应用可以只取第一层（每线程一条主缓冲），复杂度低得多。另一个方向——把不同类工作拆到不同队列并行提交——属于第 6 章多队列模型的领域，录制框架不用改，提交协议要加信号量连线。

六、要点回顾

• 领取制管理：缓冲从池领取，池带族编号与重置策略，「每线程一池、整帧重置」是省心解。
• 状态机即规则：待执行态不可触碰是回收时序的唯一依据，答案由帧栅栏给出。
• 录制本地化：vkCmd 只写指令字节不经驱动，这是多线程录制物理上无共享的原因。
• 提交三件套：等待信号量定起点阶段、发出信号量定完成阶段、栅栏交回执 CPU，批内有序批间无序。
• 缓存式录制：命令缓冲可复用可增量，分桶加失效追踪是把录制成本压到最低的正路。