Hello, I’m using vulkan subpasses to implement a deferred shading. First, I would like to ask how relevant is subpasses for desktop applications? I know that for mobile hardware it’s really good. Secondly, I would like some tips on how do I implement other effects that need G-Buffers like SSAO while still using the subpass, since the G-Buffer keeps on memory and can’t be fetched like normal textures, is there a way to turn this limitation ?
You can’t use SSAO within the same subpass that created the depth information. You can’t read arbitrarily from an attachment image, and arbitrary reading is necessary for SSAO to do its job.
You have to create a render pass specifically for SSAO to make this work.
1 Like
what about using vulkan subpasses on desktop, is it really worth on general case?
You cannot render without subpasses, regardless of the platform. You don’t have a choice to not use subpasses.
If you’re asking if you should just have one render pass for every subpass… no. Just do what is reasonable and needed for your rendering to work. Do what you can with as few render passes as possible. If you need to break a render pass to do some effect, OK, but note the word “need”.
1 Like
You can’t use SSAO within the same subpass that created the depth information.
I think you can.
You can’t read arbitrarily from an attachment image
Just make more subpasses.
Depth is 24 bit value.
to make SSAO you need 16 more depth values per pixel
24x16=384 bits
So:
- make framebuffer for depth with 384 bits size to save data.
- render depth once and make 16 subpasses with needed SSAO shift every subpass (reading previous subpass and adding its value to original depth(somehow) and saving result in this subpass)
- on 16 subpas do SSAO base on just single 384 bits value that has all deth values needed for SSAO
How do you plan to do that?
The largest texture formats Vulkan supports have 128 bits per pixel. You’d need one 3x that for what you’re trying to pull off. The closest you might do is a 16x multisample image, but I’m fairly sure you cannot read from any sample other than the one you’re currently computing either.
Since step 1 is not possible, steps 2 and 3 are moot. Even so:
That can’t work either. It would require reading from pixels in the depth buffer other than the one your fragment is meant to write to. Which again, you can’t do. Maybe you can for other samples, but I don’t think so.
it was theoretical solution, obvious that Vulkan 1 not ready for SSAO implementation, we have to wait for Vulkan 2
You can do SSAO in Vulkan. Just not in a single render pass. That’s because tile-based hardware cannot do it in a single render pass.
It’s just the cost of the algorithm.
1 Like
does it makes a big diffence using multiple renderpasses vs using multiple subpasses within one renderpass on desktops?
It’s kind of irrelevant to this context. You can’t do SSAO in a single render pass. And doing SSAO, regardless of the API, already requires a hard dependency between all of the depth rendering and the SSAO rendering computations. So you’re going to have to pay that cost regardless of the structure of the API.
Just use subpasses where you can, and break render passes where you can’t. Don’t overthink it.
1 Like
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.