1bit occlusion shadow...

[Infinisearch]

I was wondering if anyone has any experience with 1bit occlusion shadow maps for shadow casters outside the view frustrum? I was thinking of experimenting but figured I'd post here for opinions first, so any comments, tips or advice? Oh and UAV's in the pixel shader is pretty much my only option right?

edit - I should mention the final goal was to combine them with sparse depth shadow maps.

 

[Infinisearch]

So this idea gets no love then? Or is it stupid and I'm missing something?

 

[sebbbi]

We experimented with UAVs based shadow maps. The reason was to implement our own memory tiling scheme (more freedom compared to hardware tiled resources).

You need to use atomics to write to that UAV, since you potentially will have overdraw and there will be colliding reads & writes to the same pixels. For depth shadow maps use InterlockedMin/InterlockedMax (depending on the depth comparison you want). Your 1 bit maps share the same 32 bit word with 32 pixels, so you need to use atomics even if you do not have any overdraw. InterlockedOr is the right choice. Clear bits to zero before rendering, and use atomic OR to flip bits to one.

Use [earlydepthstencil] attribute in your pixel shader to ensure that the pixel shader is not executed for pixels that fail depth / stencil / triangle test.

 

[sebbbi]

If you know in advance which shadow depth ranges are visible in each screen area (for example at page granularity in sparse shadow mapping), you should use normalized storage scaled to that range (to maximize the storage quality). 16 bit per pixel is enough for most purposes. Clamp values smaller than the near plane to the near plane.

1 bit storage for shadow casters outside the screen is a good idea. You still need a depth buffer for culling, so the shadow rendering doesn't get any faster. If you use a UAV to output the depth shadow map as well, you can combine both to a single pass. Use dynamic branching based on the depth value to selecr the output UAV.

 

[Infinisearch]

We experimented with UAVs based shadow maps. The reason was to implement our own memory tiling scheme (more freedom compared to hardware tiled resources).

Sebbbi first thanks for taking the time, much appreciated. You sure experiment on alot of things, do you enjoy it or find it satisfying?

1 bit storage for shadow casters outside the screen is a good idea. You still need a depth buffer for culling, so the shadow rendering doesn't get any faster. If you use a UAV to output the depth shadow map as well, you can combine both to a single pass. Use dynamic branching based on the depth value to selecr the output UAV.

Thanks for calling it a good idea, but I wish GPU's supported this type of rendering natively (with acceleration structure) then it would be a good. Right now it's more of a curiosity with me. Actually I was going to try three variations:
1. 16bit zbuffer. Use compute shader to post process it to 1bit per pixel.
2. No zbuffer, render to uav, sort into screen space loose tiles and let overdraw have its day but see if the storage and bandwidth saving make up for it.
3. Software rasterization using a compute shader (though I might not pursue this option)

 

[Davros]

shadow casters outside the view frustrum?

Doesn't that mean your rendering shadows that are not visible?

 

[Alexko]

Doesn't that mean your rendering shadows that are not visible?

Shadow casters would be things that cast shadows. So you could have a visible shadow cast by an object that is not visible from this particular point of view.

 

[Davros]

Ahh, i see