Vulkan 1.3 动态渲染（Dynamic Rendering）：彻底告别 RenderPass 与 Framebuffer 的历史包袱

在 Vulkan 1.0 发布之初，每一个试图将自研渲染器迁移到 Vulkan 的图形工程师，都会被其极其繁琐且冗长的“样板代码巨兽（Boilerplate Beast）”折磨得身心俱疲。其中最反人类、耦合度最高的设计，莫过于显式的渲染通道对象（VkRenderPass）与帧缓冲区对象（VkFramebuffer）。

在传统 Vulkan 1.0/1.1 规范中，为了将一个简单的网格绘制到一张纹理上，你必须在初始化阶段提前数个文件编写数百行结构体：声明附件描述符（Attachment Descriptions）、配置多通道依赖（Subpass Dependencies）、声明输入输出格式与多采样率，随后还要针对窗口交换链图像的每一个特定视图（ImageView），一一对应创建并管理生命周期脆弱的 VkFramebuffer 单体。一旦玩家拖拽窗口改变了游戏分辨率，所有旧的 Framebuffer 必须全部销毁并在多线程同步锁的严密监控下重新分配。

这种将“渲染目标状态”与“管线执行逻辑”强行死锁的设计，不仅严重违背了现代多通道渲染管线的灵活性需求，更让 Vulkan 的学习与维护成本高不可攀。

Vulkan 1.3 将 VK_KHR_dynamic_rendering 扩展正式吸纳为核心必备规范。**动态渲染（Dynamic Rendering）**的诞生，标志着开发者终于可以彻底把 VkRenderPass 与 VkFramebuffer 扫进图形学的历史垃圾堆。

动态渲染的架构解放拓扑

动态渲染彻底剔除了中间冗余的有状态对象，直接将渲染通道的开启回归至命令流的极简控制：

[ 传统 Vulkan 1.0 架构: 繁重的双重死锁 ]
VkRenderPass ──(强绑定)──> VkFramebuffer ──(强绑定)──> vkCmdBeginRenderPass
(分辨率或格式变更必须全量销毁重建，代码冗长难懂)

[ 现代 Vulkan 1.3 动态渲染架构: 纯命令式极简流转 ]
纹理视图 (VkImageView)
│
▼ (直接填入栈上临时结构体 VkRenderingInfo)
vkCmdBeginRendering(cmd, &renderingInfo)
├── 绑定管线与资源直接绘制 (vkCmdDrawIndexed)
└── vkCmdEndRendering(cmd)
(零对象依赖，零额外内存分配，彻底自由！)

动态渲染 C++20 核心管线构建实现

以下是在 Vulkan 1.3 环境下，利用动态渲染配置并执行一个完整颜色与深度绘制通道的标准范式：

#include <vulkan/vulkan.h>
#include <vector>
#include <iostream>

class DynamicRenderingPipeline {
public:
// 1. 创建图形管线时：只需声明格式链，无需传入 VkRenderPass
static VkPipeline CreatePipeline(
VkDevice device,
VkPipelineLayout layout,
VkShaderModule vertShader,
VkShaderModule fragShader,
VkFormat colorFormat,
VkFormat depthFormat)
{
// 核心：使用 VkPipelineRenderingCreateInfo 替代传统的 renderPass 句柄
VkPipelineRenderingCreateInfo renderingInfo{};
renderingInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_RENDERING_CREATE_INFO;
renderingInfo.colorAttachmentCount = 1;
renderingInfo.pColorAttachmentFormats = &colorFormat;
renderingInfo.depthAttachmentFormat = depthFormat;

VkGraphicsPipelineCreateInfo pipelineInfo{};
pipelineInfo.sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO;
pipelineInfo.pNext = &renderingInfo; // 挂载动态渲染信息链
pipelineInfo.renderPass = VK_NULL_HANDLE; // 彻底置空！
pipelineInfo.layout = layout;

// 其余着色器阶段、光栅化状态、深度状态正常填充…
VkPipeline pipeline = VK_NULL_HANDLE;
vkCreateGraphicsPipelines(device, VK_NULL_HANDLE, 1, &pipelineInfo, nullptr, &pipeline);
return pipeline;
}

// 2. 命令缓冲区录制时：现场即时开启动态渲染
static void RecordPass(
VkCommandBuffer cmd,
VkImageView targetColorView,
VkImageView targetDepthView,
VkExtent2D renderExtent,
VkPipeline pipeline)
{
// 配置颜色附件
VkRenderingAttachmentInfo colorAttachment{};
colorAttachment.sType = VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO;
colorAttachment.imageView = targetColorView;
colorAttachment.imageLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
colorAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
colorAttachment.storeOp = VK_ATTACHMENT_STORE_OP_STORE;
colorAttachment.clearValue.color = {{0.05f, 0.05f, 0.08f, 1.0f}};

// 配置深度附件
VkRenderingAttachmentInfo depthAttachment{};
depthAttachment.sType = VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO;
depthAttachment.imageView = targetDepthView;
depthAttachment.imageLayout = VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL;
depthAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
depthAttachment.storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
depthAttachment.clearValue.depthStencil = {1.0f, 0};

// 组装全局动态渲染配置
VkRenderingInfo renderingInfo{};
renderingInfo.sType = VK_STRUCTURE_TYPE_RENDERING_INFO;
renderingInfo.renderArea.offset = {0, 0};
renderingInfo.renderArea.extent = renderExtent;
renderingInfo.layerCount = 1;
renderingInfo.colorAttachmentCount = 1;
renderingInfo.pColorAttachments = &colorAttachment;
renderingInfo.pDepthAttachment = &depthAttachment;

// 核心指令：一键开启动态通道
vkCmdBeginRendering(cmd, &renderingInfo);

// 正常绑定管线与发起绘制
vkCmdBindPipeline(cmd, VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline);
vkCmdDrawIndexed(cmd, 36, 1, 0, 0, 0);

// 结束动态通道
vkCmdEndRendering(cmd);
}
};

底层硬件开销与驱动等价性解密

许多初次接触动态渲染的工程师常常心存疑虑：抛弃了编译期确定性的 VkRenderPass，底层驱动会不会因此丢失针对 Tile 移动架构（TBDR）的片上优化，从而引发性能下降？

答案是：在现代 Vulkan 1.3 驱动内部，两者的硬件微码完全等价，性能零损失！

现代显卡驱动在执行 vkCmdBeginRendering 时，根据传入的 VkRenderingInfo 参数，在底层直接向硬件命令处理器发射完全相同的 Tile 内存控制指令（如 ARM Mali 的 Tile Load/Store 操作，以及桌面 GPU 的 DCC 压缩初始化）。原本在 VkRenderPass 中极其晦涩的 SubpassDependency，现在被更直观、显式的 Vulkan 管线内存屏障（VkMemoryBarrier2 / vkCmdPipelineBarrier2）所全面取代，使开发者拥有对显存缓存刷新的绝对精确掌控力。

生产级收益复盘

全面重构为动态渲染后，引擎代码库获得了前所未有的工程清爽感：

• 代码体积缩减：剥离了成百上千个 Framebuffer 管理类与 RenderPass 模板代码，渲染框架代码行数直降 40% 以上；
• 无感窗口缩放：玩家在窗口化游戏中随意缩放分辨率时，由于没有任何绑定的 Framebuffer 实体，系统只需重新分配交换链 Image 并创建新的临时 View，窗口重绘耗时从原本几十毫秒的卡顿收敛至微秒级；
• 多通道复用度飙升：同一个阴影 Pass 或几何 Pass 管线，可以自由挂载到不同分辨率的离屏纹理上执行绘制，真正做到了“着色器管线与渲染目标维度的彻底解耦”。

动态渲染是现代低级图形 API 走向务实与成熟的重要里程碑，它剔除了过度工程化的形式主义，让图形编程重新回归于纯粹高效的数据流动之中。