Vulkan动态渲染绑定深度附件时首帧冻结，无验证错误

现象 #

• 仅含颜色附件的10+个渲染通道可正常录制并呈现；
• 添加任意深度附件（临时或导入）都会导致首帧冻结；
• 单独硬编码深度图像+vkCmdBeginRendering（不运行渲染图RenderGraph::Execute步骤）可正常工作；
• 仅当渲染图的屏障/录制路径RenderGraph::Execute涉及深度资源时才会出现冻结。

环境 #

• Vulkan 1.3.215，使用动态渲染、synchronization2扩展
• Intel UHD集成显卡，驱动版本0.404.2127，Windows系统，MSVC编译，依赖VMA、GLFW

验证情况 #

已启用验证层和调试消息器，但冻结时无验证输出，日志为缓冲形式，正在通过调试器调用栈确认冻结位置。

相关代码片段 #

深度资源创建及渲染通道代码（main_z_pass.cpp） #

data.depth = builder.CreateImage("MainZBuffer", {  
    .format = VK_FORMAT_D32_SFLOAT_S8_UINT,  
    .usage  = VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT | VK_IMAGE_USAGE_SAMPLED_BIT,  
    .aspect = VK_IMAGE_ASPECT_DEPTH_BIT,  
    .debugName = "MainZBuffer",  
},  
VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL,  
VK_PIPELINE_STAGE_2_EARLY_FRAGMENT_TESTS_BIT,  
VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT);  

// execute lambda  
VkRenderingAttachmentInfo depth{ VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO };  
depth.imageView   = g.GetImageView(data.depth);  
depth.imageLayout = VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL;  
depth.loadOp      = VK_ATTACHMENT_LOAD_OP_CLEAR;  
depth.storeOp     = VK_ATTACHMENT_STORE_OP_STORE;  
depth.clearValue.depthStencil = { 1.0f, 0 };  

VkRenderingInfo info{ VK_STRUCTURE_TYPE_RENDERING_INFO };  
info.renderArea = { {0,0}, ext };  
info.layerCount = 1;  
info.colorAttachmentCount = 1;  
info.pColorAttachments = &color;  
info.pDepthAttachment  = &depth;  

vkCmdBeginRendering(cmd, &info);  
vkCmdEndRendering(cmd);  

渲染图屏障生成代码（RenderGraph::Execute） #

VkImageMemoryBarrier2 vb{ VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER_2 };  
vb.srcStageMask  = b.srcStage;  
vb.dstStageMask  = b.dstStage;  
vb.srcAccessMask = b.srcAccess;  
vb.dstAccessMask = b.dstAccess;  
vb.oldLayout = b.oldLayout;  
vb.newLayout = b.newLayout; // DEPTH_STENCIL_ATTACHMENT_OPTIMAL for the depth image  
vb.image = GetVkImage(b.handle);  
vb.subresourceRange.aspectMask     = GetImageAspect(b.handle); // DEPTH_BIT only  
vb.subresourceRange.levelCount     = VK_REMAINING_MIP_LEVELS;  
vb.subresourceRange.layerCount     = VK_REMAINING_ARRAY_LAYERS;  
// ...  
vkCmdPipelineBarrier2(cmd, &dep);  

核心疑问 #

1. 为何仅在涉及深度附件时，vkCmdBeginRendering/vkCmdPipelineBarrier2会导致程序挂起，仅颜色附件时正常？
2. 图像格式为VK_FORMAT_D32_SFLOAT_S8_UINT（含深度和模板），但仅声明了VK_IMAGE_ASPECT_DEPTH_BIT的aspectMask，同时使用VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL布局，这种不匹配是否是问题所在？
3. 若不是上述原因，正确的排查方式是什么（比如是否为Intel硬件已知驱动问题）？

关于aspectMask与布局的匹配问题 #

这种配置确实存在潜在问题：

• VK_FORMAT_D32_SFLOAT_S8_UINT是深度+模板联合格式，对应的VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL布局要求操作覆盖深度和模板两个aspect。
• 你在屏障中仅指定VK_IMAGE_ASPECT_DEPTH_BIT，但切换到的布局是针对深度+模板的，这会导致驱动无法正确处理资源状态——部分子资源（模板）的状态未被正确同步，可能引发死锁或冻结。

修复建议：

• 创建图像时，将aspect设置为VK_IMAGE_ASPECT_DEPTH_BIT | VK_IMAGE_ASPECT_STENCIL_BIT；
• 屏障的subresourceRange.aspectMask也同步修改为包含深度和模板的联合aspect；
• 若确实不需要模板部分，可改用纯深度格式（如VK_FORMAT_D32_SFLOAT），避免联合格式带来的状态同步问题。

渲染图屏障的潜在问题 #

从现象来看，仅当渲染图执行屏障时才冻结，说明屏障的同步参数可能存在错误：

1. 阶段与访问掩码不匹配：检查屏障的srcStageMask/dstStageMask和srcAccessMask/dstAccessMask是否与深度附件的使用场景匹配。例如，深度附件写入对应的阶段应为VK_PIPELINE_STAGE_2_EARLY_FRAGMENT_TESTS_BIT或VK_PIPELINE_STAGE_2_LATE_FRAGMENT_TESTS_BIT，访问掩码应为VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT；
2. 布局转换不完整：确认深度图像从初始布局到DEPTH_STENCIL_ATTACHMENT_OPTIMAL的转换是否覆盖了所有子资源（mip层、数组层），避免遗漏导致的资源状态不一致；
3. 依赖关系错误：渲染图可能为深度资源生成了错误的依赖链，导致命令流出现死锁（如等待一个永远不会触发的信号）。可以尝试简化渲染图，仅保留深度通道，逐步排查屏障逻辑。

Intel驱动相关排查 #

Intel UHD集成显卡的Vulkan驱动确实存在一些已知的动态渲染和深度附件相关问题：

• 检查驱动版本是否为最新，Intel官方会定期修复Vulkan相关bug；
• 尝试禁用synchronization2扩展，改用传统的vkCmdPipelineBarrier测试，看是否能避免冻结，以此判断是否为扩展兼容性问题；
• 查看Intel官方的Vulkan驱动发布说明，确认是否有类似的深度附件死锁问题记录。

其他排查步骤 #

1. 调试器定位冻结点：通过调试器查看调用栈，确认程序是卡在vkCmdBeginRendering提交后的设备等待，还是卡在命令录制阶段；
2. 简化测试用例：在渲染图中仅保留深度通道，逐步添加其他逻辑，定位具体是哪一步屏障或资源操作导致冻结；
3. 检查图像视图创建：确认深度图像的视图是否正确设置了aspectMask（若使用联合格式，视图应包含深度或模板aspect，但资源本身的状态同步需要覆盖两者）；
4. 启用更详细的验证层日志：尝试将验证层日志设置为实时输出，而非缓冲，看是否在冻结前有未捕获的警告或错误。

内容的提问来源于stack exchange，提问作者Marcus Carter