Vulkan: Workaround Adreno discard bug

[unknownbrackets]

Like #11192, but applied to regular fragment shaders too. However, I did some more testing: it still works with depth_unchanged (ExecutionModeDepthUnchanged) specified. I think that should prevent any performance impact over and above already using discard.

I updated stencil to match, although it shouldn't matter since it doesn't use depth. Just for consistency.

At first, I planned to do this for Adreno only, but I found a MESA bug that was exactly the same. Now I'm expecting other mobile drivers did the wrong thing too. We can easily restrict it gl_extensions.bugs if we discover performance impact.

On the topic of bad drivers, the spec says (emphasis mine):

Vulkan - 25.4
The depth bounds test, stencil test, depth test, and occlusion query sample counting are performed before fragment shading if and only if early fragment tests are enabled by the fragment shader (see Early Fragment Tests).

I realize this probably only specifies apparent behavior, but I figured it can't hurt to assert early_fragment_tests since we're detecting the opposite anyway.

-[Unknown]

[hrydgard]

Wow, that's an interesting find that the bug is so widespread.

Hopefully those shader compilers won't ever decide that gl_FragDepth = gl_FragCoord.z is a noop and take it out before the other checks they do :)

[unknownbrackets]

Hopefully, but at least with Vulkan we control the compiler... it will output ExecutionModeDepthReplacing in addition to ExecutionModeDepthUnchanged, afaiu.

-[Unknown]

[unknownbrackets]

Oh, and just to clarify: it seems the MESA bug is fixed now, it just existed in a previous version. Still, it suggests it's a common mistake indeed.

-[Unknown]

[hrydgard]

Oh, good that the decision of the execution mode is encoded in the SPIR-V. Because technically we of course only control the frontend, after SPIR-V there'll always be another compiler or two before the code hits the shader execution units of the GPU :)