Vulkan-docs: Why Is it necessary to put VkRenderPass in VkFramebufferCreateInfo?

[ChanLee1123]

I have two issues :

1. I want to know the reason why the parameter Vkrenderpass in VkFramebufferCreateInfo is included.
2. I think Vulkan-Docs should specify why Vulkan need VkRenderPass when creating VkFramebuffer with VkFramebufferCreateInfo.

This issue starts from here.

https://community.khronos.org/t/why-does-vkframebuffer-need-vkrenderpass-when-created/104461

Many other people on the link speculated what they think, but It's just the speculation. And the @krOoze brings some open-source drivers. As the code shows, the driver code does not utilize the VkRenderPass in the vkFramebufferCreateInfowhen creating VkFramebuffer.

The Vulkan spec describes it : renderPass is a render pass defining what render passes the framebuffer will be compatible with. See Render Pass Compatibility for details. So, According to the spec, I feel like that the reason why we put VkRenderPass in the VkFramebufferCreateInfo is to just check the compatibilities between the VkFramebuffer and VkRenderPass in the validation layer zone.

As I already said at the first comment in the link, I think VkRenderPass is not necessary when creating VkFramebuffer. Because checking Compatibility between VkRenderPass and VkFramebuffer also happens on VkCmdBeginRenderPass, I think I need only buffers(VkImageViews) when creating VkFramebuffer. In addition, As the driver code shows, the code does not utilize renderpass at all.

So, I want to know the persuasive reason why VkRenderPass is needed in the VkFramebufferCreateInfo.

[Tobski]

Hi @ChanLee1123 - to 1) the answer is as simple (and somewhat unsatisfying) as information provided render passes is needed by some vendors when constructing a framebuffer. The exact details of this would have to be divulged by individual vendors, rather than by the working group. (FWIW AMD doesn't use this information).

As for 2) we don't document this type of detail in the specification typically, and I don't think we'd be inclined to do so; this would be a significant change in our specification.

However to turn it round a bit, we are actively looking at ways to simplify the render pass API, as we are extremely aware about how complex its interdependencies are.

[krOoze]

FWIW with some testing, NULL render pass works for me for NV, but crashes on Android Adreno.

[chrisforbes]

For a tiler, CreateFramebuffer is the first point where you have everything you need in order to choose your tiling strategy. Structure comes from the renderpass; dimensions and final aliasing situation come from the framebuffer.

[krOoze]

@chrisforbes OK, but should\need you be choosing tiling strategy at createFramebuffer time? What then is vkCmdBeginRenderPass for?

[ratchetfreak]

for applying the chosen tiling strategy.

Computing which tiling strategy is optimal is not necessarily a cheap operation which means it should be precomputed.

One of the design constraints of vulkan is that as much as possible must be precomputed and give client code the opportunity to force that precomputation on its own terms to avoid a "warm up hitch" in the main render code like you'll find in opengl.

[krOoze]

@ratchetfreak Wouldn't you need e.g. VkRenderPassBeginInfo::renderArea for your potentially expensive operation?

[jackohound]

Selecting the optimal tiling strategy and compiling the renderpass/subpasses for the selected tiling strategy can be quite expensive. For some implementations (e.g., Adreno) the first opportunity to perform this work is at createFramebuffer time, where the essential information is available. For Adreno, the supplemental information available at vkCmdBeginRenderpass (e.g. renderArea) is not essential to perform this work.

[krOoze]

Right, it is perhaps the other way around. Looking at the VK_KHR_imageless_framebuffer extension, it is the images that seem to be not needed there. Should have been named vkCreateCompiledRenderPass() or something though...

[ChanLee1123]

So the reason for inserting VkRenderPass into VkFramebufferCreateInfo can be various. The renderpass can be used for validation layer, or precalculated optimization as @ratchetfreak and @jackohound mentioned.

I thought in the spec, the description of the member in Vk###CreateInfo should be like A user can understand what's going on. But It will be very hard to describe all of things, especially under the driver territory in the spec document.

Now I know what's going on about this issue, and I don't know what to do more about this issue. So, I will close this issue. Thanks to all who let me know about this.

[krOoze]

@ChanLee1123 In 1.2 the imagelessFramebuffer is the default, so the renderPass remains the only meaningful parameter to vkCreateFramebuffer now. I think it is safe to assume now the "render pass compilation" is the primary concern of the command. It is only bit weirdly named. And it would be virtually no-op on some drivers. And begs the question why all this was not in vkCreateRenderPass in the first place. Nevertheless the renderPass parameter seem to be exactly the one needed, while the images are actually not.

The renderpass can be used for validation layer

It can, though I think it would not enter the discussion when forming the API. The layers are perfectly able to track state and defer validation to vkCmdBeginRenderPass, if needed, and would not impose restrictions onto the API.

[ChanLee1123]

@krOoze
I checked the imagelessFramebuffer. and I think it just delays passing VkImageView handles into the time to begin renderpass.

I have the same curiosity as you that why the "render pass compilation" is not in the vkCreateRenderPass. I guess there may be driver-things we don't know when the info the driver need is only created when creating framebuffer.

The renderpass can be used for validation layer

The reason why I said this is that I thought

renderPass is a render pass defining what render passes the framebuffer will be compatible with. See Render Pass Compatibility for details.

Render Pass Compatibility in this statement is definitely related to validation layer. But now I feel the compatibility should exist for the driver operation. So I mean as you said I agree with what you said that the validation layer should not be related to forming the API

[krOoze]

I have the same curiosity as you that why the "render pass compilation" is not in the vkCreateRenderPass. I guess there may be driver-things we don't know when the info the driver need is only created when creating framebuffer.

Perhaps if vkCreateRenderPass is somewhat expensive too, then it makes the 1 renderpass -- N framebuffers situation better. Either way this is only an esthetical nitpick now, since it does not cause any additional restrictions onto the Application.