<p>Instead of listing specific use cases, I will explain the technical limitations of a render pass structure which would prevent someone from putting all of their rendering within it. The use cases naturally fall out from those limitations.</p>
<p>The most important being this: you cannot arbitrarily access <em>any of the images</em> attached to the render pass throughout the entire render pass. It doesn't matter if a particular subpass doesn't use the image as a render target throughout that subpass; you cannot bind it as a texture/image and read from/write to it in a shader. This covers the entirety of the render pass from start to end.</p>
<p>Now, there are input attachments. These are uses of attachments that allow you to read from them in the shader. However, they aren't textures (though <a href="https://stackoverflow.com/q/43632903/734069">they are descriptors</a>); they have more limitations than textures. The most important limitation being that you can only read from a pixel that corresponds to the current fragment's location (and also, you can only read them from a fragment shader). You can't fetch data arbitrarily from the image. A particular FS invocation can only read the specific pixel that was written previously at this FS invocation's location.</p>
<p>Now, you can do some things within that limitation. You can do programmatic blending, for example. You can do deferred lighting passes, since any particular FS invocation only needs to read gbuffer data from the specific pixel for that invocation's location.</p>
<p>But the main point is this: <em>any effect</em> which requires arbitrarily reading from an image that was rendered to <em>must</em> be in a different render pass from the render pass that rendered that image.</p>

CC BY-SA 4.0
2020-08-10T14:06:47.653Z
Thank you for taking the time to answer even though you disagreed with my question!
FShrike
CC BY-SA 4.0
2020-08-10T14:02:56.263Z
2020-08-10T14:02:56.263Z
Nicol Bolas
<p>From what I understand of Vulkan, we have a render pass with its associated image resources and subpasses, and each subpass accesses those resources and may synchronise with previous subpasses to process the scene. In a 3D scene, we will have some geometry and lighting and shaders etc. we can do depth pass, deferred shading and so on - and that can all be encapsulated in a single render pass, by chaining multiple subpasses and their results together.</p>
<p>Excluding the scenario of tiled rendering, or when we are rendering to multiple final render targets, when would we ever need multiple render passes in a 3d scene? I understand that something like post processing or UI compositing could be implemented in a second render pass, as they need the result from the first 3d pass to present the final image. I am at a loss as to a situation whereby a game engine, let's say, would need multiple render passes, as all of its geometry and lighting and shading etc. can be drawn with the same render pass, and that render pass will contain all the final necessary buffers, like the final image.</p>
<p>Other than using multiple render passes as you might use subpasses (each render pass relying on the previous one in some way and each render pass having only one subpass) - what is the point?</p>
<p>I am very much a beginner to Vulkan and to all of these concepts so please forgive any errors in the question itself or naive notions.</p>

CC BY-SA 4.0
2020-08-09T20:20:32.780Z
"*I understand that something like post processing or UI compositing could be implemented in a second render pass, as they need the result from the first 3d pass to present the final image.*" Didn't you just answer your own question?
Nicol Bolas
CC BY-SA 4.0
2020-08-09T20:21:25.017Z
@NicolBolas I mentioned that in order to exclude such suggestions from potential answers - I am asking for any OTHER use cases
FShrike
CC BY-SA 4.0
2020-08-09T20:22:21.627Z
But why exclude them? It's like asking, "if you ignore all of the reasons to want to go to the store, why would anyone want to go to the store?"
Nicol Bolas
CC BY-SA 4.0
2020-08-09T20:23:16.847Z
@NicolBolas Do you mean to say that those used mentioned in that quote are the only common and reasonable use cases for multiple render passes?
FShrike
CC BY-SA 4.0
2020-08-09T20:24:19.607Z
@NicolBolas because I do not know if they are all the reasons for “going to the store”- which is the exact purpose of my question
FShrike
CC BY-SA 4.0
2020-08-09T20:25:25.143Z
@NicolBolas To be clear, you’re saying that those ARE all the reasons? And that that is your “answer”?
FShrike
CC BY-SA 4.0
2020-08-09T20:25:44.813Z
If you were asking for any use case, that might be a legitimate question for this site. But asking for some comprehensive "every possible use case for X" kind of thing isn't appropriate for Stack Exchange sites. No one person can give you every possible use for anything where the answer isn't obvious. "*And that that is your “answer”?*" If I wanted it to be an answer, I'd have posted it as an answer, not as a comment.
Nicol Bolas
CC BY-SA 4.0
2020-08-09T20:27:58.233Z
@NicolBolas Any use case that I am unaware of would be welcome as an answer - I did not request for a comprehensive list at any point. Do you have such a use case or are you merely questioning my question?
FShrike
CC BY-SA 4.0
2020-08-09T20:28:31.143Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/111600/discussion-between-nicol-bolas-and-idiotic-shrike).
Nicol Bolas
CC BY-SA 4.0
2020-08-09T20:33:17.433Z
@NicolBolas I cannot see a way to do so on the mobile app - apologies if I’m missing an obvious option to do so
FShrike
CC BY-SA 4.0
2020-08-09T20:35:17.623Z
Click the "continue this discussion" link and see where it goes. Or perhaps go to the website through your browser.
Nicol Bolas
<rendering><vulkan>
What are the use cases for multiple render passes?
FShrike
# What are the use cases for multiple render passes?

(Asked by: username_0 on 2020-08-09)

From what I understand of Vulkan, we have a render pass with its associated image resources and subpasses, and each subpass accesses those resources and may synchronise with previous subpasses to process the scene. In a 3D scene, we will have some geometry and lighting and shaders etc. we can do depth pass, deferred shading and so on - and that can all be encapsulated in a single render pass, by chaining multiple subpasses and their results together.

Excluding the scenario of tiled rendering, or when we are rendering to multiple final render targets, when would we ever need multiple render passes in a 3d scene? I understand that something like post processing or UI compositing could be implemented in a second render pass, as they need the result from the first 3d pass to present the final image. I am at a loss as to a situation whereby a game engine, let's say, would need multiple render passes, as all of its geometry and lighting and shading etc. can be drawn with the same render pass, and that render pass will contain all the final necessary buffers, like the final image.

Other than using multiple render passes as you might use subpasses (each render pass relying on the previous one in some way and each render pass having only one subpass) - what is the point?

I am very much a beginner to Vulkan and to all of these concepts so please forgive any errors in the question itself or naive notions.

**Tags:** rendering, vulkan

> **Comments:**
> **username_1**: "*I understand that something like post processing or UI compositing could be implemented in a second render pass, as they need the result from the first 3d pass to present the final image.*" Didn't you just answer your own question?  
> **username_0**: @username_1 I mentioned that in order to exclude such suggestions from potential answers - I am asking for any OTHER use cases  
> **username_1**: But why exclude them? It's like asking, "if you ignore all of the reasons to want to go to the store, why would anyone want to go to the store?"  
> **username_0**: @username_1 Do you mean to say that those used mentioned in that quote are the only common and reasonable use cases for multiple render passes?  
> **username_0**: @username_1 because I do not know if they are all the reasons for “going to the store”- which is the exact purpose of my question  
> **username_0**: @username_1 To be clear, you’re saying that those ARE all the reasons? And that that is your “answer”?  
> **username_1**: If you were asking for any use case, that might be a legitimate question for this site. But asking for some comprehensive "every possible use case for X" kind of thing isn't appropriate for Stack Exchange sites. No one person can give you every possible use for anything where the answer isn't obvious. "*And that that is your “answer”?*" If I wanted it to be an answer, I'd have posted it as an answer, not as a comment.  
> **username_0**: @username_1 Any use case that I am unaware of would be welcome as an answer - I did not request for a comprehensive list at any point. Do you have such a use case or are you merely questioning my question?  
> **username_1**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/111600/discussion-between-username_1-and-idiotic-shrike).  
> **username_0**: @username_1 I cannot see a way to do so on the mobile app - apologies if I’m missing an obvious option to do so  
> **username_1**: Click the "continue this discussion" link and see where it goes. Or perhaps go to the website through your browser.  

---

## 1 answers

### Answer by username_1 on 2020-08-10. Score: 12 | Accepted answer

Instead of listing specific use cases, I will explain the technical limitations of a render pass structure which would prevent someone from putting all of their rendering within it. The use cases naturally fall out from those limitations.

The most important being this: you cannot arbitrarily access *any of the images* attached to the render pass throughout the entire render pass. It doesn't matter if a particular subpass doesn't use the image as a render target throughout that subpass; you cannot bind it as a texture/image and read from/write to it in a shader. This covers the entirety of the render pass from start to end.

Now, there are input attachments. These are uses of attachments that allow you to read from them in the shader. However, they aren't textures (though [they are descriptors](https://stackoverflow.com/q/43632903/734069)); they have more limitations than textures. The most important limitation being that you can only read from a pixel that corresponds to the current fragment's location (and also, you can only read them from a fragment shader). You can't fetch data arbitrarily from the image. A particular FS invocation can only read the specific pixel that was written previously at this FS invocation's location.

Now, you can do some things within that limitation. You can do programmatic blending, for example. You can do deferred lighting passes, since any particular FS invocation only needs to read gbuffer data from the specific pixel for that invocation's location.

But the main point is this: *any effect* which requires arbitrarily reading from an image that was rendered to *must* be in a different render pass from the render pass that rendered that image.

> **Comments:**
> **username_0**: Thank you for taking the time to answer even though you disagreed with my question!  

---

