Using Render Passes and Sub-passes

In Vulkan, a render pass represents a collection of frame buffer attachments, sub-passes, and dependencies between the sub-passes. It also describes how the attachments are used over the course of the sub-passes such as with load and store operations. Render passes group together rendering commands that are all targeted at the same frame buffer into well-defined tasks – they represent the structure of the frame.

Render passes operate in conjunction with frame buffer objects. Frame buffers represent a collection of specific memory attachments that a render pass instance uses.

It is advisable that applications use as few render passes as possible, because changing render targets is a fundamentally expensive operation.

Sub-passes

In Vulkan, a sub-pass represents a phase of rendering that reads and writes a subset of the attachments in a render pass. Rendering commands are recorded into a particular sub-pass of a render pass instance.

Readable attachments are known as input attachments and contain the result of an earlier sub-pass at the same pixel location. An important property of input attachments is that they guarantee that each fragment shader only accesses data produced by shader invocations at the same pixel location.

On PowerVR hardware, make use of sub-passes and sub-pass dependencies wherever appropriate, because the driver will aim to collapse them whenever possible. The sub-pass (attachments) will stay entirely in pixel local storage (on-chip memory) and will never be written out to system memory, significantly reducing transfers to system memory. This makes it a very efficient method for implementing a deferred lighting pipeline.

Load and store ops

Vulkan provides explicit control over load and store operations on frame buffer attachments.

On PowerVR hardware, the most optimal settings are defined below:

• Load operation – should be set to either VK_ATTACHMENT_LOAD_OP_DONT_CARE or VK_ATTACHMENT_LOAD_OP_CLEAR wherever possible. This is preferred over using the function vkCmdClearAttachment. The graphics driver will be informed that it does not need to load the buffers data from system memory, saving enormous amounts of bandwidth.

• Store operation – should be set to VK_ATTACHMENT_STORE_OP_DONT_CARE, unless the attachment is required for later use, as in preserve the data.

Note

There is a rare situation where the graphics core enters smart parameter mode (SPM) which occurs when the parameter buffer overflows, causing the driver to perform a partial render. In this case, a load/store operation will be performed to preserve the contents of the attachments. This operation must be carried out, so that the state may be restored when rendering resumes.

Transient attachments

Vulkan render pass objects may also contain transient attachments. This type of attachment can be read and written by one or more sub-passes, but is ultimately discarded at the end of the pass. Therefore, the data is never written out to main memory, saving valuable memory bandwidth.

Older PowerVR graphics drivers do not take advantage of Vulkan transient attachments. It is still advised that an application makes use of this feature in Vulkan, as devices with newer drivers will fully support this feature.

Optimal number of attachments

On PowerVR hardware, it is recommended to have fewer than eight input and output frame buffer attachments across an entire render pass.

Attachment order

On PowerVR hardware, the order of input attachments will not adversely affect performance. The driver will re-order the attachments as required, producing the optimal order for the graphics core when the render pass is compiled.