CODEWITHSUNDEEP
vulkan
董佳斌
董佳斌

Reputation: 161

What is the relationship of RenderPass and Pipeline in Vulkan?

What is the logical relationship between RenderPass and Pipeline in Vulkan?

If you ignore RenderPass, my understanding of the rendering process is first, the vertex data prepared by the application layer, then the texture data can be submitted to the driver, and after that through the various stages of the pipeline, after writing to the Framebuffer, you can complete a rendering.

So what is the responsibility of the RenderPass? Is it an abstraction that provides metadata for rendering each stage (such as Format), or does it have some other role?

Is RenderPass and Pipeline dependent on feelings? For example, each Pipeline belongs to a Subpass. Or a dependency, such as the last output of the Pipeline, is handled by RenderPass. Or is it something else?

Upvotes: 16

Views: 4960

Answers (1)

krOoze
krOoze

Reputation: 13286

At the end of the day Vulkan is a nice modern-ish OO API. All the objects in Vulkan are practically only what parameters they take. Just saying this to ease your learning. You can look at vkCreateX and largely understand what VkX does in Vulkan.

VkPipeline is a GPU context. Think of the GPU as a FPGA (which it isn't, but bear with me). Doing vkCmdBindPipeline would set the GPU to a given gate configuration. But since the GPU is not a FPGA, it sets the GPU to a state where it can execute the shader programs and fixed-function pipeline stages defined by the VkPipeline.

VkRenderPass is a data oriented thing. It is necessitated by tiled architecture GPUs (mobile GPUs). On desktop GPUs it can still fill the role of being an oracle for optimization and\or allow partially-tiled architecture (or any other architecture really that can use this).

Tiled-architecture GPUs need to "load" images\buffers from general-purpose RAM to "on-chip memory". When they are done they "store" their results back to RAM. This loading of attachments is done by smaller "tiles", so the on-chip memory (and therefore shaders) never sees the whole memory at the same time, and so doesn't have random access. It can only access the local parts in the same tile.

VkRenderPass defines what kind of inputs (attachments) will be needed. It defines how they get loaded and stored before and after the render pass instance*, respectively. It also has subpasses. It defines synchronization between them (replaces vkCmdPipelineBarriers). And defines the kind of purpose a given render pass attachment will be filling (e.g. if it is a color buffer, or a depth buffer).

* A Render Pass Instance is the thing created from a Render Pass object (which would conventionally be called "instance" of a class) by vkCmdBeginRenderPass. Yea, not confusing, right.

Upvotes: 12

Related Questions