Introduction

In this post, I want to register the bare minimum requirements necessary to render something to the screen using Vulkan API and talk about Vulkan RenderPass dependencies with SubPass and Framebuffer.
I assume in this post that there are already valid physical and logical devices created that support queue(s) with graphics capabilities.

RenderPass

Render-pass defines a “contract” of attachments. These attachments are shared across the sub-passes, Frame-buffer and also the Fragment shader.
“VkRenderPassCreateInfo” is the structure to be populated to construct a renderpass.

• It takes in an array of attachments, sub-passes and dependencies among those sub passes.
• The attachments are all image-views. No Buffers are allowed!
• The way to interpret the attachments is setup here using “VkAttachmentDescription“. This establishes load and store operations, that defines how to interpret the image data.
• When FinalLayout is specified in the structure, it converts the image to the required layout once the render-pass ends.

The last point above is quite interesting as it allows us to transition image to a different layout automatically and pass it along to another render-pass if we choose to, without performing a manual layout conversion.

Sub-Passes

Each Render pass can have one or more sub-passes. This post is about making sense of how resources are shared, so I’ll ignore everything else.

• Render-pass declares the sub-passes and how they interact with each other.
• If sub-passes use any resources, they must be referenced from the attachments declared in Render-Pass by and unsigned integer index.
• The color attachments defined in the sub-pass form a contract with the outputs of the Fragment shader. The values are written to those attachments after passing through the blending stage.
• A Graphics Pipeline operates on a single sub-pass within the render-pass. Therefore, the attachments defined within the sub-pass form a direct contract with the Fragment Shader.

Frame-Buffer

The Frame buffer is the final piece of puzzle where it all comes together.

• Till this point, we’ve only been kind of talking about the description of attachments. Nowhere have we passed the actual resources that will be consumed!!
• The GPU-Backed image resources are passed to the framebuffer.
• These directly map to the resources defined while creating the render-pass.
• So, if you consider render-pass as a declaration of resource, Framebuffer would be their definitions.
• Framebuffer also declares the render dimensions. This is just a declaration though, the actual dimensions should be defined in VkRenderPassBeginInfo, which the spec dictates to be less than or equal to the dimensions defined by FrameBuffer!!

Conclusion

With a simple Swapchain attachment declared in render pass, passed to sub-pass and defined in Frame-buffer., we could issue the command vkCmdBeginRenderPass with some clear color value and see a solid color on the screen within the render-area defined!!!