Vulkan on Android 3 — Render Nothing with Lots of Hidden Details Part 4
A render pass we can say is a specification about how rendering resources are organized and it can be viewed as the environment for a particular series of drawing commands.
Framebuffers are counterparts of render passes and they operate in conjunction with each other. They represent a collection of specific memory attachments that a render pass instance uses.
Render Pass
So render pass in detail is a collection of attachments, subpasses, and dependencies between the subpasses, and describes how the attachments are used over the course of the subpasses.
Render passes are usually varied per application and few of them are in common so only the most general operations are included in RenderPass class.
A render pass have one or more subpasses each may with different attachments for the rendering purpose of that subpass, and if multiple subpasses exist, dependencies between them should be specified.
ColorDestinationRenderPass is a render pass with one subpass with one color attachment whose initial layout is VK_IMAGE_LAYOUT_UNDEFINED and VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL when in use and its final layout is VK_IMAGE_LAYOUT_PRESENT_SRC_KHR for presentation.
The content of color attachment at the beginning of the subpass (loadOp) will be cleared with values specified somewhere and be stored(storeOp) at the end of the subpass where it is last used. We have no stencil attachment and hence stencilLoadOp and stencilStoreOp are ignored.
Two subpass dependencies are used, the first one is that memory reads at stage VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT(not actually in this stage but simply a synchronization point) will be visible to write access at stage VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, and the second one is that memory writes in subpass 0 at stage VK_PIPELINE_STAGE_COLOR_ATTACHMENT_-OUTPUT_BIT will be available to memory reads at stage VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT. Here VK_SUBPASS_EXTERNAL means out of subpass which is in host domain.
Framebuffer
The image describes the relationship between swapchain, render pass, and framebuffer. Attachments are not necessary to be color attachments, and not necessarily come from swapchain, neither. The image just depicts what the situation is for our case.
We know from the picture that framebuffers depend on render passes and image views and they are used as values of pAttachment and renderPass of VkFramebufferCreateInfo. We declare move constructors since we have Framebuffers in a vector to construct, and we know vector keeps a dynamically allocated array internally. When push_back causes the amount of Framebuffer excess the capacity of the vector, it will reallocate a bigger memory space to accommodate the elements and assign values of olds ones to new allocated ones with the copy constructor. But using copy constructor is not correct because when old Framebuffer is destroyed the destructor destroys the VkFramebuffer, which corrupts the data of the new allocated Framebuffer. Here’s our move constructor comes into play.
