Why does VkFramebuffer need VkRenderPass when created?

My question is the title. It’s about the Vulkan API itself.

After some of studies on Vulkan, I’ve recognized that VkFramebuffer is a collection of Color/Depth_stencil Buffers (VkImage -> VkImageView -> VkFrameBuffer).

and I’ve recognized that VkRenderPass is a collection of various operations on one framebuffer.
When you create VkRenderPass, you don’t need the VkImage, VkImageView, VkFrameBuffer.
However, at the time, you have to know the organization(color/depth buffer, subpass strategy, and so on) of a Vkframebuffer which you will use with the VkRenderpass.

After I scrutinize VkFramebuffer/RenderPass like above,
I think that the VkRenderPass Variable of VkFramebufferCreateInfo is not proper.

Even if the VkRenderPass must have a relationship with VkFramebuffer, I think when creating VkFramebuffer, I don’t need VkRenderPass. Because VkFrameBuffer just need Buffers, not operations on them (I mean VkRenderpass has operations on framebuffer).

Maybe, when calling VkCreateFramebuffer(), I guess that validation layer may check the compatibility between framebuffer and renderpass. And definitely, I’ve checked that validation layer must check the compatibility between framebuffer and renderpass when recording command buffer with vkCmdBeginRenderPass.

So, I have guesses why VkRenderPass is in the VkFramebufferCreateInfo:

  1. Checking Compatibility
  2. Just limiting the wrong use of VkFramebuffer with VkRenderPass

I wonder why we have to put the VkRenderPass when creating VkFramebuffer even if i don’t need it.

  1. Because the specification requires you to.
  2. Same reason Pipeline creation requires it.

There’s no “The Design and Evolution of Vulkan”; only the authors could answer you.

1 Like

No, the VkFramebuffer has a relationship with the VkRenderPass, not the other way around.

But it doesn’t. It needs to know how those images are going to get used by the render pass.

If it didn’t know, if all it did was just store an ordered sequence of images, then every time you did vkCmdBeginRenderPass, the system would have to look at the render pass and the framebuffer and work out exactly where those images need to go relative to each other. By creating the framebuffer relative to a render pass, any processing for that step only gets done once. Thus, a VkFramebuffer can be nothing more than a container of GPU instructions to be copied directly into the queue, without any thought by the CPU at vkCmdBeginRenderPass time.

How much processing this represents is implementation-defined. But there’s no reason not to do as much of it outside of the main rendering loop as possible.

If they wanted to do things your way, there wouldn’t be a VkFramebuffer object at all. You would just pass a list of images directly to the vkCmdBeginRenderPass function, which would be indexed the way the render pass indexes its attachments.

1 Like

Okay. your reddit link helps me a little. Thank you

Thanks to your detailed-explanation, I’m persuaded a little to understand why VkRenderPass is there. So, According to your description, The reason why VkRenderpass is needed in creating VkFramebuffer is that some of pre-processing will take place in creating VkFramebuffer. So, Vulkan doesn’t need to process additional tasks for beginning a renderpass instance with a framebuffer. and it makes the benefits of performance in the structure of main loop recording commands on a command buffer.

Yeap. That’s what I always thought. I know the Metal API of Apple does not have a framebuffer object. it has only a renderpass object. So, I often compared two APIs, and the harder construction of Vulkan API made me have a curiosity on this topic. Thanks!

It does not, in the sense that it is full of pointless speculation. But I figured you might want to see it, as it is dup of this question.

Anyway, there are some open-source drivers.

(doesn’t seem to use render pass)

(also doesn’t seem to use it)

(also doesn’t seem to use it)

(also doesn’t seem to use it)

Soo, our question boils down to IF some (obscure) driver would use it, what would it use it for. Which I find pointless speculation, because spec requires you to provide the parameter anyway. Maybe some obscure driver has so HW notion of framebuffer that requires to know upfront what subpases it will be used in? Dunno…

Since this is somewhat restricting requirement, I don’t think it would harm to simply ask the authors. Besides wide community will not be able to answer this with anything but speculation about what driver might or might not do (I hope we can leave this OpenGL-style culture where not necessary). I did ask such type of question e.g. here: Vulkan-Docs#574. And I think you will get similar mundane answer (one of the IHVs simply felt they needed rpass at that point, while other do not need it), but it will at least be an authoritative answer.


I appreciate you for bringing lots of driver source code. I can refer to it since now! thank you. After seeing your reference code, It becomes clearer that VkFramebufferCreateInfo does not need VkRenderPass. I will ask this question on the authors of Vulkan API. Thank you.

and I’ve looked over your activities on Vulkan-Docs github. it inspired me to ask such questions which i have on this topic. you give me another outlet for asking the details of API.

Anyway, I think it’s quite challenging for me to make a formal issue according to the spec and other test cases. But I will try to challenge it.


^ That’s a stretch. Most of them want it to make sense HWically, while being modern C. Also, the draw calls are actually influenced by Render Target (aka Render Pass Instance), which is a Framebuffer + Render Pass, and it is created by vkCmdBeginRenderPass.
Bit of a pointless speculation. May or may not be. We will never know, unless they release Design and Principles of Vulkan book. And knowing does not really help us any, because we need to provide the Render Pass either way.

So did you end up making an Issue? Could you link it here?

Finally, I did it. I wish I did it correctly.
Thank you, @krOoze.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.