Vulkan input attachments and sub passes

Introduction

I have added a new example to my open source C++ Vulkan examples that demonstrates the use of input attachments and subpasses within a single render pass.

Input attachments are image views that can be used for pixel local load operations inside a fragment shader. This basically means that framebuffer attachments written in one subpass can be read from at the exact same pixel (that they have been written) in subsequent subpasses.

Although the limitation of not being able to sample outside of the fixed pixel coordinates rules them out for advanced post processing stuff where you need to sample neighboring pixels, there are still several other applications like G-Buffer composition for a deferred renderer, debug visualizations and even order independent transparency.

The traditional way, without using input attachments would involve multiple passes, where the second pass would consume the attachment image views as e.g. combined images.

On tile-based-renderer, which is pretty much anything on mobile, using input attachments is faster than the traditional multi-pass approach as pixel reads are fetched from tile memory instead of mainframebuffer, so if you target the mobile market it’s always a good idea to use input attachments instead of multiple passes when possible.

Framebuffer setup

In addition to writing to the swap chain (color) image, we also want to fill the images for the input attachments so we add them to the list of views passed as attachments for framebuffer creation:

Subpass setup

In Vulkan a render pass consists of an arbitrary number of subpasses. Subpasses reference framebuffer attachments for reads (and writes), know how they related to other subpasses and can be used to add implicit image layout transitions, so no explicit image memory barriers are required. 

For this example we will be doing two subpasses in our render pass. The first subpass will fill a color and a depth image, the second subpass will read from either one (depending on a user selection) and applies filters to them and writes them to the swap chain color image.

Remember that the framebuffers attachment have been setup as:

These indexes will be referred to in the subpass setup.

The first subpass will write to the images:

We pass the custom color image as the only color attachment (attachment index 1) and the custom depth image (attachment index 2) as the only depth stencil attachment. With this setup, the fragment shader used in this setup can write to the color attachment at location 0, writing to the depth attachment explicitly is not required.

The second subpass will write to the swap chain color image (attachment index 0):

And use the previous color and depth images as input attachments:

Descriptors

For the second subpass, that reads from the color and depth images we need to define descriptors that reference these. This is done with the VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT  descriptor type, the rest is just your standard setup similar to e.g. using combined image samplers.

Descriptor set layout:

Image descriptors:

Note that we don’t pass a sampler, as input attachments are just pixel local  loads and as such aren’t sampled in any way. By reading them you read that exact same value that was previously written at that position.

Descriptor sets:

Pipeline setup

When using multiple subpasses you need to pass the subpass that a certain pipeline is used in at pipeline creation time:

Rendering

When starting a render pass it always starts with the first subpass, which is of then only one used. But we are using multiple sub passes and as such make use of the vkCmdNextSubpass command to the next subpass within the currently active render pass:

This doesn’t look much different than a basic single pass setup. After calling vkCmdNextsubpass, the attachments are transitioned and the information that our write targets from the first subpass will now  be used as input attachments is passed to the command buffer state.

The shaders

One thing that hasn’t been discussed yet is how input attachments are actually read from within a fragment shader. For that, Vulkan introduced a new uniform type and syntax to glsl:

We get a new uniform type called subpassInput  and a layout syntax for specifying the index, set and binding of the input attachment. The later two are the same as for all uniforms and must match the descriptors.

The input_attachment_index simply specifies the attachment index as specified at frame buffer creation time.

Reading from an input attachment is then done by using subpassLoad instead of the texture* functions you’d usually use to sample from an image:

For details on these new Vulkan glsl types and keywords you can refer to the GL_KHR_vulkan_glsl extension.

Closing words

Input attachments and subpasses are something unique to Vulkan and at first it might not seem clear why these should be used instead of a multi pass approach. But if you’re targeting any kind of tile-based renderer, and yes, even desktop GPUs are at least partially tbrs, they are definitely worth a look. If you’re doing something that doesn’t require you to sample outside of the current pixel location these are the perfect tool for getting better performance out of those tbrs.

Going further

While the basic example detailed in here shows how to use input attachments, the use-case is more artificial than real-world related. If you want to see a more practical use-case for input attachments and subpasses you might want to take a look at my subpasses example.

That example uses input attachments and three subpasses for a single pass deferred renderer with forward transparency: