When recording the secondary command buffer with the inheritance of the VkRenderPass but without known VkFramebuffer, the driver crashes. For example, setting the VkCommandBufferInheritanceInfo to: inheritance.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO; inheritance.renderPass = validRenderPass; inheritance.subpass = 0; inheritance.framebuffer = VK_NULL_HANDLE; // not known yet VkFramebuffer object inheritance.flags = VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT; It will result in the crash in the vkCmdDraw() as the driver expects the framebuffer is not NULL. However, the specification says: "framebuffer optionally refers to the VkFramebuffer object that the VkCommandBuffer will be rendering to if it is executed within a render pass instance. It can be VK_NULL_HANDLE if the framebuffer is not known, or if the VkCommandBuffer will not be executed within a render pass instance." Which means, using VK_NULL_HANDLE is absolutely valid from the application point of view and driver should not crash.
Thanks for the bug report! This is a known bug and I'm working on fixing it. Unfortunately, the fix is going to be a bit painful so it may take some time.
I can confirm this bug. If I set inheritance.framebuffer for just one framebuffer in swapchain, I can see the rendered scene for roughly 1/4th of frames for using 4 swapchain framebuffers.
Maybe a bit offtopic: If a vulkan developer supposed to provide separate secondary comamand buffers for each framebuffer, wouldn't it be an overkill to generate 4x as many secondary command buffers(for the whole scene graph)? I don't see how I can avoid the last restrictions (1 node = one command buffer) because each model needs different buffers. Even if one uses one giant Buffor for all vertices and ubos, each model nees different textures -> this means different descriptor sets -> which means different command buffers. Even if you update the same descriptor set, you still may have different pipelines for some models. I would have thought setting inheritance.framebuffer to VK_NULL_HANDLE would be the most usual case, unless it's a fixed demo.
I just landed a major rework of color attachments that fixes this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.