Framebuffer-framebuffer compatibility not described

[chrisforbes]

Valid usage for vkCmdExecuteCommands says:

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

Nowhere is it described what it means for a framebuffer to be compatible with another framebuffer. I assume that the intent is that the secondary command buffer's framebuffer, if specified, should compatible with the renderpass used in the current renderpass instance, as per 7.2 ?

CV implements this as requiring the handles be equal, if the secondary command buffer specifies a framebuffer -- which doesn't sound like the right thing.

[krOoze]

vkCmdExecuteCommands:

If vkCmdExecuteCommands is being called within a render pass instance, any given element of pCommandBuffers must have been recorded with the VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT

vkBeginCommandBuffer:

If flags contains VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT, the framebuffer member of pInheritanceInfo must be either VK_NULL_HANDLE, or a valid VkFramebuffer that is compatible with the renderPass member of pInheritanceInfo

and

renderPass is a VkRenderPass object that must be compatible with the one that is bound when the VkCommandBuffer is executed if the command buffer was allocated with the VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT set.

Render pass compatibility:

A framebuffer is compatible with a render pass if it was created using the same render pass or a compatible render pass.

So a little bit convoluted, but I think it's all there. But true, there is no framebuffer to framebuffer compatibility. That seems to be just a shorthand for the restriction chain quoted above...

[oddhack]

@chrisforbes, does @krOoze's response address the issue for you, or do you think spec changes are still needed?

[chrisforbes]

@oddhack I think the spec rule is still iffy. It does appear that it's redundant with the other constraints. If that's the case, can we remove it, or adjust it to be a note? I'm just trying to make sure we end up with validation code that's clearly mappable to spec language, and does exactly the right thing.

[chrisforbes]

@oddhack After thinking about this a bit more, I don't think the interpretation above is correct.

The framebuffer provided as part of BeginCommandBuffer is a hint:

framebuffer refers to the VkFramebuffer object that the VkCommandBuffer will be rendering to if it was allocated with the VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT set. It can be VK_NULL_HANDLE if the framebuffer is not known.

[Note] Note
Specifying the exact framebuffer that the secondary command buffer will be executed with may result in better performance at command buffer execution time.

Compatibility via renderpasses as above is an obvious minimum bar-- but is CmdExecuteCommands trying to require something stronger -- that is, if a framebuffer is provided as a hint, it has to be a /good/ hint? If not, in the case where a framebuffer /is/ provided to BeginCommandBuffer, the implementation needs to record /both/ a general version, and a specialized version taking advantage of the framebuffer information?

[krOoze]

I don't follow. Can you elaborate more?

not correct, how?

require something stronger than what? CmdExecuteCommands() if I am not mistaken, is the only thing that consumes secondary buffers and all of that seems to be its requirements directly or indirectly.

(Of) what is a "general/specialized" version?

[chrisforbes]

@krOoze @oddhack Suppose I record a secondary command buffer, providing a framebuffer. The implementation takes advantage of that to produce better hw commands in some way (looks at the dimensions, looks into the ImageViews, etc).

Suppose I then record CmdExecuteCommands into a primary command buffer, whose current renderpass instance uses a different framebuffer -- compatible with the same renderpass, but different in every other way, such that any specialization done in the secondary command buffer recording would be invalid -- is that intended to be acceptable?

It seems possible that the intent of this valid usage rule is to limit that.

If that's the case, then there needs to be a definition of framebuffer-framebuffer compatibility that guarantees any framebuffer-derived assumptions in the secondary command buffer recording actually hold.

[oddhack]

This should be fixed in the 1.0.16 spec update. The discussion got kinda complex, feel free to reopen/open a new issue if something was missed.