Conditional discard in standard shadersets

[AnyOldName3]

Modern GPUs are all tiled renderers, and tiled renderers hate conditional discards as they build on early depth testing, which can't be done if a fragment potentially won't do a depth write because it's been discarded. On desktop-class GPUs, a draw with a conditional discard (whether or not it ends up happening) will at the minimum disable the tiled renderer optimisation for that draw call, and for mobile GPUs, it can disable it for every single draw after that point to the same render target. Some drivers are smart enough to generate separate variants when uniforms alone are enough to determine that the discard won't happen, but that's more of a thing in older graphics APIs that don't have tools like specialisation constants to do it explicitly, and don't have explicit pipelines, and even then, couldn't be relied on.

The VSG's built-in shadersets use a discard for alpha testing, and it's only gated off by the materials alpha mask. That's a dynamically-uniform expression, so at least in theory could be used to select a variant pipeline, but it definitely won't work like that everywhere, and there's a good chance it doesn't work like that anywhere.

As an alternative, if the alpha mask were replaced with a define, there may be a framerate improvement of several times in scenes with lots of overdraw and expensive fragment shaders (e.g. soft shadows with lots of samples). This would mean more pipeline switches, but in theory, some drivers are doing this implicitly anyway, and the presence of discards is expensive enough that it can be worth many pipeline switches to avoid a few of them.

[timoore]

I don't know which desktop GPUs use tiled rendering, but I totally agree that the conditional discard disables the early-Z optimization and I think it's worth a pipeline switch to avoid that. Another possibility is clamping the alpha value to 0 and blending.

[AnyOldName3]

Everything from Nvidia since Maxwell, and everything from AMD since Vega.

Using blending as a stand-in for alpha testing is a worthwhile approach under certain circumstances, but when you need the depth write to be conditional, it's not viable as only colour is blended. It can be much more expensive to split up your draw calls to a fine enough degree that you can submit them in depth order (either as separate draw calls after sorting CPU-side or via an indirect multidraw with sorting in a compute shader) and end up with correct output than to have part of a frame use alpha testing, and even when the speed's comparable, this doesn't let the depth buffer be used for effects like post-process ambient occlusion.

[robertosfield]

Relying upon alpha testing used to be standard thing in vis-sim, it used to help with performance avoiding the blending & writing to the colour and depth buffer. You can also get different visual results if you are writing an fragment that is alpha blending out so that it still writes to the depth buffer but can't be seen, but then prevents subsequent fragments at further depths being visible when they should be.

I understand the motivation for optionally disabling it, In OpenGL you have to explicitly enable the alpha test so perhaps something similar would be natural to do with the VSG's ShaderSet's with the fragment discard code path only compiled in when something like VSG_ALPHA_TEST #define is set. This way converting from old OSG scene graphs that relied upon alpha test still have a natural replacement.

@AnyOldName3 have you do some performance benchmarks to access the difference?

[AnyOldName3]

If depth writes are disabled (as it's the conditional depth write that's the problem) it can still help performance to discard a zero-alpha fragment rather than have the blending hardware do a framebuffer readback and write back identical data, and most applications have depth writes disabled for most of the things they use blending for, so that works out fine.

It's everything else, which is mostly opaque and has depth writes enabled that has performance problems.

I don't have benchmark data specific to the VSG, but the basic idea behind a tiled renderer is that when it's working to its full extent, all fragment shader invocations are deferred until all draws have been submitted, and then only one needs executing for each pixel as only one fragment wins the depth test. When they're not working at all, every fragment that lands within the view frustum needs its fragment shader to be executed, even if it's behind something else, even if that thing was submitted in an earlier draw call, so that should give you an idea of the potential impact. You probably won't hit the absolute worst case unless it's a particularly ill-conceived GPU architecture or there are other shader variants that alter gl_FragDepth, as a discard can't change the depth the rasteriser emits, so wouldn't make a fragment that failed the early depth test succeed. However, things likely will get as bad as on a traditional GPU, where you can only skip a fragment shader invocation if an earlier fragment already wrote a nearer depth, even if a later fragment will write a nearer depth.

In a contrived scene with draws submitted from furthest to nearest with an expensive fragment shader but cheap vertex shader and minimal state changes, you could make the difference arbitrarily large.

[robertosfield]

I'll take a real-world benchmark test over more words about a theoretical significant performance difference any day.

Lets quantify what we are talking about then make decisions about default code paths in shaders.

[AnyOldName3]

.\vsgshadow.exe -c --sm 4 -n 3 --fps -t --pcf 10 --large -p .\saved_animation_large.vsgt (with that camera path being designed to encourage overdraw) gives identical performance for me whether or not I comment out the discard. That wasn't what I expected, even on a desktop-class GPU. I also tried drawing a glTF file with the same volume filled with a grid of loads of cubes (2.5 million vertices) as that would happen as a single draw call instead of many separate ones, and make any overhead more clear. With that setup, I was getting around 15.6 FPS with the discard left in, and 16.1 FPS with it removed. This was reliable between runs, but is only a 3% difference, so still pretty minor.

The fact that there is a difference, but wasn't with a different scene, suggests that this is down to early depth testing being different rather than just the shader being easier to optimise without the branch. Maybe, as modern desktop GPUs are more of a hybrid than a full-on tiled implementation, this could be explained by unshaded triangles being flushed between draw calls. Anyway, it's hardly a world-changing difference.

I still suspect that a mobile-class GPU would show a bigger difference, but I don't have one in a device that's convenient to build things for, so won't be investigating that.