4
// Contains the list of secondary command buffers to be submitted
std::vector<VkCommandBuffer> secondaryCommandBuffers;

// Inheritance info for the secondary command buffers
VkCommandBufferInheritanceInfo inheritanceInfo = {};
...
inheritanceInfo.renderPass = renderpass;   <-------------
inheritanceInfo.framebuffer = frameBuffer; <-------------
...

VkCommandBufferBeginInfo secondaryCommandBufferBeginInfo = {};
...
commandBufferBeginInfo.pInheritanceInfo = &inheritanceInfo;
...
vkBeginCommandBuffer(secondaryCommandBuffers[i], &secondaryCommandBufferBeginInfo);
vkEndCommandBuffer(secondaryCommandBuffers[i]);


// renderPassBeginInfo for the primary command buffer
VkRenderPassBeginInfo renderPassBeginInfo = {};
...
renderPassBeginInfo.renderPass = renderPass;    <-------------
renderPassBeginInfo.framebuffer = frameBuffer;  <-------------

vkBeginCommandBuffer(primaryCommandBuffer, &cmdBufInfo);
vkCmdBeginRenderPass(primaryCommandBuffer, &renderPassBeginInfo, VK_SUBPASS_CONTENTS_SECONDARY_COMMAND_BUFFERS);
vkCmdExecuteCommands(primaryCommandBuffer, secondaryCommandBuffers.size(), secondaryCommandBuffers.data());
vkEndCommandBuffer(primaryCommandBuffer);

Why do secondary command buffers already set framebuffer and renderpass, and also framebuffer and renderpass for primary command buffer?

Must it be set to the same?

walnut
  • 21,629
  • 4
  • 23
  • 59
Javin Yang
  • 215
  • 3
  • 11

2 Answers2

4

Secondary command buffers which contain rendering commands must execute within a render pass, and wholly within a specific subpass of that render pass (hence VkCommandBufferInheritanceInfo::subpass). This is their purpose.

The framebuffer parameter is optional and may be VK_NULL_HANDLE.

The render pass model essentially requires all aspects of command generation to be able to determine what is going on. How rendering commands get generated depends in many ways on which subpass of which render pass is being used. That's central to the whole mechanism.

The primary/secondary CB distinction allows the structure of a render pass operation to be defined within a primary command buffer (which contains the begin, end, and subpass switching operations), while the actual rendering commands can be built in secondary command buffers on other threads. But in order for those other threads to do their jobs, they have to know about how they're being used. Hence the need for the render pass.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
2

That's an API design question. And any answer by a non-insider would be opinion-based at best.

Most accurate answer (nobody seem to like to hear) is simply: because Vulkan specification requires you to.

At the face of it, secondary command buffer is created way before vkCmdBeginRenderPass. So if the driver might need to know (or there is some advantage in knowing) the render pass environment at vkBeginCommandBuffer of the secondary, then render pass handle must be provided at that point.

As for VkFramebuffer the specification says it is optional, but providing it may yield better performance.

Must it be set to the same?

Appropriate VUs:

If vkCmdExecuteCommands is being called within a render pass instance, the render passes specified in the pBeginInfo::pInheritanceInfo::renderPass members of the vkBeginCommandBuffer commands used to begin recording each element of pCommandBuffers must be compatible with the current render pass.

and

If vkCmdExecuteCommands is being called within a render pass instance, and any element of pCommandBuffers was recorded with VkCommandBufferInheritanceInfo::framebuffer not equal to VK_NULL_HANDLE, that VkFramebuffer must match the VkFramebuffer used in the current render pass instance

krOoze
  • 12,301
  • 1
  • 20
  • 34