CODEWITHSUNDEEP
vulkan
tuket
tuket

Reputation: 3941

Trying to understand Vulkan RenderPass compatibility

Quoting the spec:

Framebuffers and graphics pipelines are created based on a specific render pass object.

They must only be used with that render pass object, or one compatible with it.

Two attachment references are compatible if they have matching format and sample count, or are both VK_ATTACHMENT_UNUSED or the pointer that would contain the reference is NULL.

Two arrays of attachment references are compatible if all corresponding pairs of attachments are compatible. If the arrays are of different lengths, attachment references not present in the smaller array are treated as VK_ATTACHMENT_UNUSED.

Two render passes are compatible if their corresponding color, input, resolve, and depth/stencil attachment references are compatible and if they are otherwise identical except for:

• Initial and final image layout in attachment descriptions

• Load and store operations in attachment descriptions

• Image layout in attachment references

As an additional special case, if two render passes have a single subpass, the resolve attachment reference and depth/stencil resolve mode compatibility requirements are ignored.

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

I'm having trouble to understand this part:

Two render passes are compatible if their corresponding color, input, resolve, and depth/stencil attachment references are compatible and if they are otherwise identical except for: ...

RenderPasses don't have attachment references; subpasses do:

typedef struct VkRenderPassCreateInfo {
    VkStructureType sType;
    const void* pNext;
    VkRenderPassCreateFlags flags;
    uint32_t attachmentCount;
    const VkAttachmentDescription* pAttachments;
    uint32_t subpassCount;
    const VkSubpassDescription* pSubpasses;
    uint32_t dependencyCount;
    const VkSubpassDependency* pDependencies;
} VkRenderPassCreateInfo;

typedef struct VkSubpassDescription {
    VkSubpassDescriptionFlags       flags;
    VkPipelineBindPoint             pipelineBindPoint;
    uint32_t                        inputAttachmentCount;
    const VkAttachmentReference*    pInputAttachments;
    uint32_t                        colorAttachmentCount;
    const VkAttachmentReference*    pColorAttachments;
    const VkAttachmentReference*    pResolveAttachments;
    const VkAttachmentReference*    pDepthStencilAttachment;
    uint32_t                        preserveAttachmentCount;
    const uint32_t*                 pPreserveAttachments;
} VkSubpassDescription;

So what is that paragraph referring to the attachment references of the subpasses? What if the two render passes have different number of subpasses? Would that make the render passes incompatible?

IMHO it would make more sense if compatibility was based on the VkAttachmentDescriptions passed to VkRenderPassCreateInfo not on the attachment references of subpasses. Doesn't make sense to me that compatibility of a renderpass with a framebuffer depends on the internal subpasses.

Upvotes: 0

Views: 576

Answers (1)

Nicol Bolas
Nicol Bolas

Reputation: 473302

Subpasses are part of render passes.

What if the two render passes have different number of subpasses?

Then they are not compatible. After all, the quote says, "if they are otherwise identical except for..." and "has a different number of subpasses" is not one of those exceptions.

Doesn't make sense to me that compatibility of a renderpass with a framebuffer depends on the internal subpasses.

That's because this passage is not specifically about compatibility between a render pass and a VkFramebuffer. It also includes compatibility between render passes used by different VkPipeline objects. You can bind a pipeline within a render pass instance that isn't exactly the same one that it was built against. But the pipeline's render pass must be compatible with the current render pass, per the above rules.

Maybe they could have defined a different kind of compatibility here, but it's really unnecessary.

Upvotes: 2

Related Questions