Vulkan多线程渲染：从命令缓冲录制到同步机制的设计实践-平芜编程栈

把绘制和提交拆开想清楚之后，Vulkan多线程其实没有传说中的那么玄乎。这个主题我接触了很久，一开始也被各种同步对象绕得晕头转向，后来把一个最小渲染器改成多线程录制，才真正明白Vulkan为什么被叫做“显式API”。这篇文章不聊营销话术，只讲实际设计、踩坑记录和可以复用的思路，适合已经写过Vulkan单线程渲染、想进一步提升CPU侧性能的开发者。

1. 重新理解Vulkan的线程模型

1.1 为什么Vulkan天生适合多线程

很多人把Vulkan多线程和一个线程画一帧等同起来，这个理解是片面的。Vulkan多线程的核心不在于“有多少个物理提交线程”，而在于命令录制、资源状态管理这些CPU工作可以被并行化。

Vulkan在API设计之初就明确考虑了主机端多线程。比如vkBeginCommandBuffer、vkCmdDraw、vkCmdPipelineBarrier这类高频函数，并没有隐式全局锁。只要你对不同对象进行操作，这些调用可以同时发生在多个线程中，而不会互相踩踏。这和OpenGL那种“整个上下文就是一个大状态机”的模型有本质区别。

更准确地说，Vulkan把“线程安全”的边界显式暴露给了开发者。规范里会标注某个对象、某个命令是否需要“外部同步”。你需要遵守的不是“避免多线程”，而是“什么对象能被同时访问”。一旦理清边界，很多看似麻烦的同步其实都可以通过架构设计规避掉。

这也是为什么现代渲染引擎几乎都选择Vulkan或类似API来做多线程架构：CPU核心越来越多，GPU负载固定的情况下，只有把CPU侧利用起来，才能减少每一帧的空闲时间，提升整体吞吐。

1.2 从OpenGL到Vulkan的工作方式转变

用OpenGL写多线程渲染是一件很痛苦的事。要么把整个上下文锁住，线程全部排队；要么搞多个共享上下文，还得处理资源同步、对象共享的兼容性问题。核心原因是OpenGL把“渲染状态”隐藏在了驱动内部，你根本不知道下一秒驱动会不会偷偷修改某个内部结构。

Vulkan换了个思路：它把**命令缓冲（Command Buffer）**变成了一等公民。你可以把录制命令当成“买菜切菜備料”，把GPU执行当成“厨师炒菜”。每个工作线程在独立的“备菜区”工作，最后提交给“炒锅”的只是一个已经处理好的半成品。

这带来两个直接好处：

录制命令缓冲时完全不占用GPU执行时间，CPU可以提前把很多帧的命令准备好。
多个线程可以同时录制不同的命令缓冲，只要它们操作的对象互不冲突。

用生活化的类比说，OpenGL像是一个只有一套厨具的小餐馆，人多反而帮倒忙；Vulkan则像一个分好工的后厨，每个厨师手里有自己的一套刀和砧板。

1.3 线程安全的边界在哪里

我最初踩坑，就是以为Vulkan所有对象都可以随便跨线程访问。实际上规范把很多对象标为“必须由应用外部同步”。几个关键结论：

同一个VkDevice的大多数调用是线程安全的，但有例外。
同一个VkQueue上的提交（如vkQueueSubmit、vkQueuePresentKHR）需要外部同步，不能多线程同时调用。
同一个VkCommandPool不是线程安全的，所以标准做法是每个工作线程自己创建一个命令池。
同一个VkCommandBuffer不能被多个线程同时录制，但多个线程完全可以录制多个不同的命令缓冲。

我见过有同事尝试用一个全局命令池、多个线程同时分配命令缓冲，结果运行几帧后偶尔报错。原因就是命令池本身需要外部同步，线程间互相干扰了。

所以“外部同步”可以这样理解：虽然Vulkan不会替你做锁，但它把规则写清楚了，你只需要避免在同一个对象上直接并发操作。比如你会给每个线程单独的命令池，单独的命令缓冲，单独的资源描述符池，这样一来，大多数录制路径你不需要临时去抢锁，性能自然就上去了。

2. 多线程渲染器的设计与思路拆解

2.1 核心架构：帧循环与任务拆分

多线程渲染器的典型架构并不是“多个线程各自独立渲染一整个场景”，而是把一帧的绘制工作拆成多个独立片段，并行去录制。

为什么不能简单地为每帧安排一个线程？因为一帧内部有大量依赖。后一个pass需要前一个pass的输出，前一个pass如果还在录制，后一个pass根本不知道资源状态。虽然可以用两个线程分别录两个primary command buffer，然后让它们在GPU上顺序执行，但这里仍受限：如果你只有一个render pass，就无法把同一个render pass的命令从多个primary command buffer拼起来。

所以最常见的拆分粒度是：

主线程负责全局逻辑、剔除、排序、更新uniform缓冲。
工作线程负责录制VkSecondaryCommandBuffer（二级命令缓冲），每个线程拿到一批物体或一个划分区域。
主线程最终录制一个primary command buffer，在render pass内执行这些secondary command buffer。

这个模型的好处是，所有工作线程只写命令缓冲，不接触GPU资源状态，也不需要直接提交队列。主线程承担的提交工作非常轻，不会成为瓶颈。

那么“任务拆分”怎么确定？参考我在模拟项目X中的做法：

如果场景是大量静态物体，按空间分块。
如果是角色渲染，按骨骼网格体分批次。
如果是后处理链，可以把部分计算任务丢给异步计算队列。

核心思路是：任务之间不共享可变资源，或者共享的部分经过只读设计。只要满足这个前提，并行录制就是安全的。

2.2 命令缓冲是怎么分发给工作线程的

实际分发命令缓冲时，很多新手会问：为什么用secondary command buffer而不是主线程提前分配多个primary command buffer？

先说区别。VkPrimaryCommandBuffer可以独立提交到队列，但一个render pass实例只能在单个primary command buffer内开启。如果你有三个primary buffer都在同一个render pass里绘制，它们不能直接按顺序“拼接”到同一个render pass中。你只能在每个primary buffer里重复begin/end render pass，这往往不是你想要的，因为render pass的load/clear行为会导致多次清屏，或者效率降低。

而VkSecondaryCommandBuffer天生就是为了嵌入另一个primary command buffer而设计的。它可以在render pass内部执行，继承当前render pass的渲染状态。这就允许你先让五个线程各自录制五个secondary buffer，然后在primary buffer中通过vkCmdExecuteCommands一次性执行。

分发的步骤大致是这样：

创建线程池，每个线程一个VkCommandPool。
从每个线程对应的pool中分配一个或几个secondary command buffer。
工作线程收到一批绘制项后，使用如下参数开始录制：

VkCommandBufferInheritanceInfo inheritanceInfo{}; inheritanceInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO; inheritanceInfo.renderPass = renderPass; inheritanceInfo.subpass = 0; inheritanceInfo.framebuffer = framebuffer; inheritanceInfo.occlusionQueryEnable = VK_FALSE; VkCommandBufferBeginInfo beginInfo{}; beginInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO; beginInfo.flags = VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT; beginInfo.pInheritanceInfo = &inheritanceInfo; vkBeginCommandBuffer(secondaryCmd, &beginInfo); // 绑定管线、描述符、顶点缓冲，调用 vkCmdDraw 等 vkEndCommandBuffer(secondaryCmd);

注意，VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT表明这是一个继续render pass的二级命令缓冲。如果在render pass以外执行，或没有指定正确的renderPass，就会触发校验层错误。

2.3 队列族与提交模型的正确理解

Vulkan把GPU执行工作分成多个“队列族”：图形队列、计算队列、传输队列等。同一个队列族下可以申请多个队列对象。

多线程是不是意味着必须创建多条队列？这个不一定。

录制命令缓冲在CPU侧执行，提交命令时才会把工作交给GPU。如果你的所有图形绘制都要按顺序渲染，那么即使你创建了多条图形队列，最终的绘制结果也必须按场景依赖顺序来。盲目往多条队列提交，结果可能是GPU并行执行了不应该并行的pass，导致渲染结果错乱。

我的建议是：

如果没有明显的异步计算需求，先使用一条图形队列，所有CPU线程录制的命令最终都提交到这一条队列上。提交本身是一个很轻的操作，一条队列足够。
如果有大量粒子计算、遮挡剔除、预计算光照，可以额外创建一条计算队列，通过semaphore与图形队列同步。
如果需要在传输纹理数据的同时渲染，可以加一条传输队列，让上传与渲染并行。

这里要特别小心：同一队列上的所有提交需要外部同步。即便你允许任意线程随时调用vkQueueSubmit，实际提交时还是要用一个mutex保护队列对象，否则Vulkan会报错。所以更常见的设计是“多线程录制，单线程提交”，避免在提交点竞争。

提到队列所有权，如果资源被多个队列使用，你需要处理“队列族所有权转移”。这部分很容易被忽略，尤其是从传输队列把staging buffer内容拷到本地图像、再转发给图形队列时，需要插入barrier或semaphore。

3. 关键同步机制：Fence、Semaphore与Barrier

3.1 Fence和Semaphore的区别与使用场景

多线程渲染真正难的是同步。Vulkan里最常见的三个同步对象：VkFence、VkSemaphore、VkPipelineStageFlags配合的barrier。

先说fence和semaphore：

VkFence用于GPU到CPU的同步，CPU可以主动等待它。比如vkWaitForFences会阻塞当前线程，直到GPU执行完提交的所有命令。
VkSemaphore用于GPU内部的同步，CPU一般不能等待semaphore。它负责描述“提交A完成了某个signal操作后，提交B才能开始某个wait操作”。

在多线程渲染中，fence最常见的应用是保证一帧的命令缓冲可以被安全重置和复用。你用一个fence标记“这一帧的GPU工作已经全部执行完”，然后CPU才能重新录制包含该帧引用的命令缓冲。

这里我总结一个实践原则：

不要把“全局一帧一个fence”当作万金油。如果要支持多帧在flight（比如CPU已经录好了第N+2帧，GPU还在执行N帧），你需要给每个帧缓冲槽或swapchain image索引一套独立的fence和semaphore。

3.2 Pipeline Barrier在并行录制中的作用

很多人第一次接触barrier时，以为它是CPU线程之间的锁。其实是两回事。

vkCmdPipelineBarrier会被录制进命令缓冲，然后在GPU执行到那里时强制保证某种内存可见性和执行顺序。它影响的是GPU内部的stage执行顺序，不是为了保护CPU数据。

多线程录制时，每个工作线程都会在自己的secondary command buffer中插入barrier吗？这里有个很关键的坑：

同一个资源的状态转换只能由“拥有该次转换”的命令缓冲来插入barrier，所有线程必须遵守同一个资源状态计划。

如果线程A在它的secondary buffer里把一张纹理从VK_IMAGE_LAYOUT_UNDEFINED转到VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL，线程B又在另一个secondary buffer里同时对同一张纹理做同样的转换，就会形成一种“状态冲突”。因为GPU执行时，B可能先转换，A后转换，导致A读到的内容不是预期内容。

所以多线程录制的设计要点是：

全局统一的资源状态表，由主线程或资源系统提前规划好barrier放置点。
二级命令缓冲里默认资源都处于“只读”状态，尽量避免在二级命令缓冲里做layout transition。
如果需要写入渲染目标，通常该写入是一个独立pass，放在单独的primary command buffer，或专门安排一个secondary buffer负责。

我在实际操作中也会遇到必须在一个巨大的render pass内对部分资源做动态写读的情况。这种时候尽量把资源拆成不同阵列，让每个线程只碰自己的那一部分，避免跨线程共享同一个image layer。

3.3 简单的同步示例

一个典型的帧提交同步流程如下：

// 等待该帧的命令缓冲可以复用 vkWaitForFences(device, 1, &frameFence[pendingFrame], VK_TRUE, UINT64_MAX); // 获取交换链图像 vkAcquireNextImageKHR(device, swapchain, UINT64_MAX, imageAvailableSemaphore[pendingFrame], VK_NULL_HANDLE, &imageIndex); // 提交 VkPipelineStageFlags waitStage = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT; VkSubmitInfo submitInfo{}; submitInfo.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO; submitInfo.waitSemaphoreCount = 1; submitInfo.pWaitSemaphores = &imageAvailableSemaphore[pendingFrame]; submitInfo.pWaitDstStageMask = &waitStage; submitInfo.commandBufferCount = 1; submitInfo.pCommandBuffers = &primaryCommandBuffers[imageIndex]; submitInfo.signalSemaphoreCount = 1; submitInfo.pSignalSemaphores = &renderFinishedSemaphore[pendingFrame]; // 提交前重置fence，此时可以保证上一帧已执行完 vkResetFences(device, 1, &frameFence[pendingFrame]); vkQueueSubmit(graphicsQueue, 1, &submitInfo, frameFence[pendingFrame]); // 呈现 VkPresentInfoKHR presentInfo{}; presentInfo.sType = VK_STRUCTURE_TYPE_PRESENT_INFO_KHR; presentInfo.waitSemaphoreCount = 1; presentInfo.pWaitSemaphores = &renderFinishedSemaphore[pendingFrame]; presentInfo.swapchainCount = 1; presentInfo.pSwapchains = &swapchain; presentInfo.pImageIndices = &imageIndex; vkQueuePresentKHR(graphicsQueue, &presentInfo);

注意，vkAcquireNextImageKHR本身的调用不能与提交并发，通常会放在同一个主线程的帧逻辑里。如果你的线程池也想参与帧循环，我建议把提交逻辑单独封装成一个RenderThread方法，由唯一的渲染线程调用，而不是让所有工作线程直接调用提交函数。

4. 实操：构建一个最小多线程绘制系统

4.1 资源准备与每个线程的上下文

下面从一个最小的demo出发，展示如何把单线程命令录制改成多线程。

先定义线程上下文：

struct WorkerContext { VkCommandPool commandPool; std::vector<VkCommandBuffer> secondaryBuffers; // 记录该线程负责的物体索引范围 uint32_t objectStart; uint32_t objectCount; };

每个线程创建自己的命令池，而不是共享一个全局池：

VkCommandPoolCreateInfo poolInfo{}; poolInfo.sType = VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO; poolInfo.flags = VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT; poolInfo.queueFamilyIndex = graphicsQueueFamily; for (auto& worker : workerContexts) { vkCreateCommandPool(device, &poolInfo, nullptr, &worker.commandPool); // 为每个workder分配一个secondary command buffer VkCommandBufferAllocateInfo allocInfo{}; allocInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO; allocInfo.commandPool = worker.commandPool; allocInfo.level = VK_COMMAND_BUFFER_LEVEL_SECONDARY; allocInfo.commandBufferCount = 1; vkAllocateCommandBuffers(device, &allocInfo, &worker.secondaryBuffers[0]); }

这里VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT允许在录制后重置单个命令缓冲。如果希望每帧都重置，这个flag是必要的。

另外，每个线程还需要一个VkDescriptorPool或至少一个线程安全的描述符分配方式。vkAllocateDescriptorSets本身由vulkan实现内部管理吗？规范中VkDescriptorPool不是线程安全的，所以要么每个线程一个描述符池，要么在主线程预先分配所有descriptor sets。推荐前一种，因为录制时绑定descriptor set的操作也需要读这些数据结构。

4.2 多线程录制命令缓冲的实现

工作线程的录制入口大概是：

void workerThread(uint32_t workerId) { auto& ctx = workerContexts[workerId]; VkCommandBufferInheritanceInfo inheritanceInfo{}; inheritanceInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO; inheritanceInfo.renderPass = renderPass; inheritanceInfo.subpass = 0; inheritanceInfo.framebuffer = currentFramebuffer; VkCommandBufferBeginInfo beginInfo{}; beginInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO; beginInfo.flags = VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT; beginInfo.pInheritanceInfo = &inheritanceInfo; vkBeginCommandBuffer(ctx.secondaryBuffers[0], &beginInfo); // 该线程需要绑定绘制管线，但注意一次绑定对整条命令缓冲都有效 vkCmdBindPipeline(ctx.secondaryBuffers[0], VK_PIPELINE_BIND_POINT_GRAPHICS, graphicsPipeline); for (uint32_t i = ctx.objectStart; i < ctx.objectStart + ctx.objectCount; ++i) { VkDeviceSize offset = objectMeshes[i].vertexOffset; vkCmdBindVertexBuffers(ctx.secondaryBuffers[0], 0, 1, &vertexBuffer, &offset); vkCmdBindDescriptorSets(ctx.secondaryBuffers[0], VK_PIPELINE_BIND_POINT_GRAPHICS, pipelineLayout, 0, 1, &objectDescriptorSets[i], 0, nullptr); vkCmdDraw(ctx.secondaryBuffers[0], objectMeshes[i].vertexCount, 1, objectMeshes[i].firstVertex, 0); } vkEndCommandBuffer(ctx.secondaryBuffers[0]); }

这里有几点要特别提防：

二级命令缓冲里绑定render pass范围内的状态时，不能包含vkCmdClearAttachments之外的全屏load操作，因为render pass已经在primary中开启。
如果你需要每个物体使用不同的pipeline或render pass，可以在每条命令缓冲里切换pipeline，但切换频率越高，性能越差。
尽量避免在二级命令缓冲中设置vkCmdSetViewport等动态状态，除非你把它们放到了继承的render pass之外，否则不同线程需要完全一致。

4.3 提交与帧同步的实现

所有工作线程录制完成后，主线程组装primary command buffer：

vkBeginCommandBuffer(primaryCmd, &primaryBeginInfo); VkRenderPassBeginInfo rpBegin{}; rpBegin.sType = VK_STRUCTURE_TYPE_RENDER_PASS_BEGIN_INFO; rpBegin.renderPass = renderPass; rpBegin.framebuffer = framebuffer; rpBegin.renderArea = {0, 0, width, height}; VkClearValue clearValues[2] = {}; clearValues[0].color = {{0.1f, 0.1f, 0.1f, 1.0f}}; clearValues[1].depthStencil = {1.0f, 0}; rpBegin.clearValueCount = 2; rpBegin.pClearValues = clearValues; vkCmdBeginRenderPass(primaryCmd, &rpBegin, VK_SUBPASS_CONTENTS_SECONDARY_COMMAND_BUFFERS); // 执行所有worker录制的二级命令缓冲 for (auto& worker : workerContexts) { vkCmdExecuteCommands(primaryCmd, 1, &worker.secondaryBuffers[0]); } vkCmdEndRenderPass(primaryCmd); vkEndCommandBuffer(primaryCmd);

注意vkCmdBeginRenderPass的第三个参数。因为primary命令缓冲内会执行secondary命令缓冲，必须传VK_SUBPASS_CONTENTS_SECONDARY_COMMAND_BUFFERS。

提交阶段仍然走第3小节的流程。这里推荐为每个swapchain image保留一组独立的primary命令缓冲，这样你可以提前录制下一帧，而GPU还在执行上一帧。但如果采用“录制完成后立即提交”的同步模型，就没有这个概念了。

4.4 RenderPass与Swapchain绑定注意点

很多人问我：二级命令缓冲里的renderPass和framebuffer到底该怎么填？

如果二级命令缓冲是在render pass之外执行的，renderPass为VK_NULL_HANDLE即可；如果它要在render pass内继续执行，必须设置为同一个VkRenderPass句柄，并且subpass要与primary命令缓冲当前所在的subpass一致。

关于framebuffer，规范说它是“可选的”，因为一些驱动不一定需要。但我建议你传入当前framebuffer。在部分实现上，缺少framebuffer可能会导致继承信息不完整，后续viewport变换等状态无法正确继承。

另外，如果使用多个swapchain image，不同帧的framebuffer不同。所以每个worker在每帧开始前需要确保自己拿到的currentFramebuffer是最新的。这也是为什么我通常把currentFramebuffer和imageIndex保存在一个帧状态结构体里，而不是用全局变量。

5. 常见问题与排查技巧实录

5.1 校验层报错：同步验证怎么解读

Vulkan校验层（Khronos Validation Layer）是多线程开发的好帮手。但很多人看见报错就懵，尤其是一长串中文英文混在一起的提示。

我建议按三个关键字定位：

SYNCHRONIZATION：同步问题，比如在同一个命令缓冲还没执行完时重新录制。
MEMORY：内存或资源生命周期问题，比如vertex buffer被释放后还在使用。
THREADING：线程安全冲突，最常见的是有多个线程同时使用了同一个命令池、命令缓冲或描述符池。

比如你看到这样的报错：

Validation Error: [ VUID-vkQueueSubmit-pCommandBuffers-00071 ] Object 0: handle = ... Object 1: handle = ... The submitted command buffer is expected to be in the executable state, but is in the initial state.

这说明你提交了一个还没录制完成的命令缓冲，或者命令缓冲在上一次执行尚未结束时就被重置了。解决办法通常是把等待fence的代码放在正确的帧索引上，并确认每个命令缓冲的生命周期跨越完整的一轮录制到执行。

5.2 渲染结果随机闪烁或花屏

随机花屏是多线程渲染最容易出现的问题，原因是CPU在GPU还在读取数据时覆盖了数据。

举个例子：你在onUpdate里往一个动态uniform缓冲写入新的矩阵，但上一帧GPU可能还在用这个缓冲。如果是单线程渲染，你可能会隐式地在绘制前等待fence，从而规避；多线程后，你为了不阻塞CPU，提前录制了下一帧，结果覆盖了GPU还没读完的数据。

解决思路：

使用多帧缓冲（multi frames in flight），为每个在flight的帧准备独立的uniform buffer和descriptor set。
命令缓冲也建议按帧缓冲区槽位分别录制。
如果你只有一份资源，至少在录制下一帧前调用vkWaitForFences等待上一帧完成。

我实际踩过的一个坑是：只给vertex data做了双缓冲，但忘记给index buffer做双缓冲，导致偶尔出现一部分三角形错位。排查时图像不是完全损坏，而是某些帧的索引数据被新帧覆盖，表现就是“同一模型在不同帧之间跳变”。

5.3 性能并未提升，反而更慢

多线程不是万金油。我在模拟项目X中做过对比，当场景只有1000个draw call时，多线程录制甚至比单线程还慢。原因很简单：

创建线程池本身有开销。
拆分任务也需要在CPU侧排序和分发，这一部分也要时间。
如果每个线程录制的命令缓冲太少，线程同步和任务调度的开销会超过并行录制的收益。

所以你需要先测量。用性能分析工具抓一帧的CPU耗时，看看命令录制占据了多大比例。如果整个录制只有2ms，而你有16个线程，理论最大省耗也只有2ms，但任务分配、fence等待可能吃掉2ms以上。

这种情况下，更好的做法是：

合并粗粒度任务：让每个线程一次处理更大范围的draw call，而不是把每个对象当作一个task。
使用稳定的线程池，避免每帧创建销毁std::thread。
命令池不要临时创建，要复用。

5.4 多线程扩展建议

如果已经跑通了基础版多线程录制，下一步可以根据项目的实际瓶颈做扩展：

使用异步计算队列处理粒子更新、遮挡剔除、IBL卷积等计算密集型工作，让图形队列与计算队列并行。
使用多队列提交时，记得为每个队列准备独立的同步原语，并在队列间传递semaphore。
如果场景大、物体多，可以引入VK_KHR_descriptor_indexing，实现bindless descriptor，减少每个线程绑定descriptor带来的调用次数。

我自己实际体验是：多线程录制阶段，最值钱的一步不是“让GPU执行并行”，而是把CPU侧的录制耗时从帧关键路径里摘出去。只要你的二级命令缓冲录得足够快，最终提交到GPU前CPU几乎是空闲的，你再把CPU资源投入到更复杂的场景逻辑、物理烘焙、动态生成任务里，整个引擎的吞吐能力就会明显上一个台阶。