Post

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

To collect the lists, I first count how many pixels each draw and shader want, then allocate space in a big buffer for each shader, then allocate space for each draw within the chunk allocated for their shader. Then repeat the same logic but writing the pixels to the buffer with the right offset.

Tried writing them once unsorted then sorting, but like I imagined, is just too expensive. I do believe you could make something like this work if you tiled the whole resolve and kept the working set of in local memory though. You need enough tiles/work in flight to feed a big GPU though.

The resolve is dispatched per-shader, not per-draw, so it's still a very manageable amount of dispatch indirect calls. As in, a single one for all your variations of standard, anisotropic, whatever... so there isn't a ton of concerns about empty dispatch indirect arguments.

Because the list is not only sorted per-shader but also per-draw, most of the waves will just see one draw! To take advantage of this, I scalarize based on the draw index, so all of the draw-related data can be uniform and stay in scalar registers. With a noticeable win in occupancy too 😊

This can include a lot of data like per-draw transforms, tinting, material stuff, and notoriously also including the bindless texture indices. Nice not to need any of that NonUniformResourceIndex uglyness.

There's only a few waves per-frame that see two or more draws when resolving, which are the only cases where the waves aren't fully utilized. This is as good as it can be anyway, if those waves weren't going to shade another draw, they would have been inactive in a "wave-perfect" resolve anyway.

I *really* like the flexibility of this approach while keeping the resolve waves full. With this you can do software VRS easily, both spatially and temporally, which is super cool! You can just write any logic to decide how the visibility buffer values map to a sample to resolve.

Plus you also can select variations of the shaders to further optimize! If a pixel is not seeing any local lights, you can dispatch a version of the resolve shader that has all the local light code compiled out. Or if a pixel is fully in shadow from directional light, nuke all that code too, etc...

And because this approach ends up compacting the list of pixels per-draw, it responds really well to scenes with heavy dithering into the visibility buffer. Some of the other tile-based approaches I tried struggled with this, since they'd need to dispatch multiple resolve tiles per tile on-screen.

Paying my respects with a video rendering 10% of the pixels each frame (hacking this in just now so turning all denoising and TAA off, no reprojection of "empty" pixels either 😜). (Prepare for the bsky video butchering though)

Oh! Also worth mentioning. In this sort of system you'll see a lot of contention when writing to shared counters. It's a good idea to minimize this by doing the global write once per wave or group. A neat trick is to also scalarize on the shader/draw for when a wave sees different values there 🙃

If you need the correct index per-thread, as you do when you're going to write the samples to the buffer, there's some more wave-ops involved, since you also need to calculate the local offset for each thread on the wave. WaveReadLaneFirst/WavePrefixCountBits sorts you out, here is how it'd look:

The first active thread of the wave does the atomic and retrieves the global offset for the wave, WaveReadLaneFirst then broadcasts it. The local offset within the wave comes from WavePrefixCountBits, since it's just the count of how many threads with a lower index are also writing one element.