Complex shader breaks on NVidia cards, looks like shader compiler issue

[robbertzzz]

Godot version

v4.1.1.stable.official [bd6af8e]

System information

Windows & Linux, multiple versions

Issue description

See repro project and repro steps. It seems like there is a shader compilation issue on NVidia cards.
I have a post-process shader, rendered on a quad, that renders an atmosphere. The shader is using an additive blend mode, but originally used the screen texture that it combined with the atmosphere. When I changed to additive blending, instead of setting ALBEDO to the screen texture where the atmosphere isn't applied I now return black. However, on NVidia cards this completely messes up the look of the atmosphere while on AMD cards there's no issue at all.

This colour has absolutely nothing to do with the glitches we're actually seeing, which makes me think this is a shader compiler issue. I've tried adding a uniform bool for easy swapping between the two versions in an if-statement, but that completely changes the issue. So something with branching code seems to create more problems.

NVidia when returning screen texture and AMD in all cases:

NVidia when returning black:

Steps to reproduce

1. Open the repro project on a machine with an NVidia GPU
2. Move the view around to observe glitching (especially apparent when moving inside the atmosphere like in the above images)
3. Open the shader file
4. Uncomment line 135 - the return statement when no atmosphere is intersected
5. Move the view around and see that there are no glitches anymore

Minimal reproduction project

shader compiler bug.zip

[clayjohn]

This sounds like an NVidia bug and should likely be reported directly to them.

[bitsawer]

I can't repro this on NVIDIA GTX 970, both the uncommented and commented versions looks correct and I can't see any visual glitches with either. There are a few NVIDIA specific issues here, for example #76343, #67150 and some other issues linked to those. Also, when reporting issues with specific devices, it's always a good idea to tell your own device model and maybe driver version.

As a side note, you generally should not use source_color with hint_depth_texture and also prefer textureLod() instead of texture() when reading from some of these special textures, see https://docs.godotengine.org/en/stable/tutorials/shaders/screen-reading_shaders.html#depth-texture I doubt these affect this issue, but who knows.

[robbertzzz]

@clayjohn Any hints on how I can figure out more what's going on before I would attempt reporting a bug to NVidia? Godot uses a proprietary shading language and I don't know which parts are specific to the engine within the rendering pipeline and which parts are specific to the GPU. AFAIK this issue could be happening long before NVidia's code comes into play so some better specifications would help a lot!

Also, when reporting issues with specific devices, it's always a good idea to tell your own device model and maybe driver version.

@bitsawer It's happening across several completely different GPUs, with the common denominator being NVidia. My own NVidia card is a 3060.
The source_color hint with the depth texture is what the engine suggested when upgrading to Godot 4 (where DEPTH_TEXTURE was removed), if that shouldn't be added that's another engine bug. I don't think textureLod would be necessary since this quad is as close to the camera as can be, the only reason the documentation uses it is to force using LOD0.

[darksylinc]

The problem with being exactly 0.0 is that a simple division by 0 could cause an INF or NaN and then be treated differently by HW, then propagated by effects like Glow.

Does the problem go away if using 1.0 / 255.0? What about 1.0 / 65504.0? (65504 = max value in half16 format)

[robbertzzz]

@darksylinc even changing it to 1.0 doesn't change a thing when inside the atmosphere. The problem is that the return value isn't even being used when the issue appears, it seems like some weird optimisation at compile time of branching code that breaks the shader.