Bug GPU Crash when using lightloop scalarization

The title should be self-explanatory.

When using DXC and enabled SM6.0 wave intrinsics, the Lit Forward+ shaders will crash the GPU in the lightloop.

However, I cannot determine the specific issue, as even though it is possible to embed debug symbols into the shaders with -Zi DXC flag or enabled_d3d11_debug_symbols in shaderlab, the debug tools like PIX For Windows or Nsight Aftermath + Nsight Graphics still cannot access this info and pinpoint the exact instruction or HLSL line that causes this issue. Nsight strictly requires a separate PDB file.

I tried to fork over and compile DXC myself in order to enforce the export of PDB files. However, despite everything seeming correct with the CLI arguments, those still never get exported.

What should I do? Some help is needed. Forward+ seems like a useful feature for our specific case.

Unity version is 2022.2.18. The GPU is RTX 3060 Ti (happens on a separate machine with RTX 3070).

 

Investigating this issue further I've determined that this issue happens due to the lightloop while cycle never breaking when evaluating punctual lights and/or reflection probes. I wrote a simple debugger to indicate which fragments behave this way and enter an infinite loop. However, none of the visible fragments report it being this way.

This leads me to believe that this may be an issue with helper lanes that run for masked fragments on the edges of primitives to provide DDX/DDY functionality. On GameCore (judging by the code) there is actually a check if a current thread in a warp is a helper lane, which early-outs the entire loop. However, for some reason, DXC refuses to compile this intrinsic and gives me an error that it doesn't exist.

Any ideas on this? Isn't WaveIsHelperLane() a first-party feature in SM6.0? I triple-checked to make sure that it only runs in a fragment shader, as it's the only domain where the intrinsic is supported.

 

Bump?

 

Bump?

 

could it be that you posted to the wrong forum? Forward+ is URP specific afaik.

 

HDRP has a Forward+ rendering path as well, in addition to tiled deferred.

 

I guess what was confusing what the "Forward+" terminology, which I've only ever seen in the context of URP.

 

Thank you very much for looking into it.

I was triggering the DXC compilation simply by using #pragma require with a commented out pragma target. Additionally, I needed to forcefully define PLATFORM_SUPPORTS_WAVE_INTRINSICS to run with scalarization, as it was not getting defined when using DXC and requesting wave features. I was using the HDRP sample scene as well.

I will get back later today after investigating further and trying to request an SM6.6 feature to manually enable support for WaveIsHelperLane(). I'll also try running it on an AMD GPU as well (strange that I never even thought of doing that in the first place). I always assumed that it was a 6.6 feature thanks to that page, thank you for clarifying.

 

Requesting an SM6.6 feature simply fails to compile the shader. The FallbackError shader is used instead. There are no compilation errors logged in either the shader inspector or the console. Trying to inspect the shader through the "Compile and show code" button never compiles the shader and litters the memory until Unity crashes (I'm on a 32 gig system).

And indeed, there appears to be no such issue on my AMD Vega 6 embedded GPU. Tested on one more Nvidia device and sure enough, the crash happens there as well.

 

Right, and completely forgot to check Editor.log for additional information. Saw these lines when the shader is being compiled with the request of SM 6.6 features:

WARNING: Shader Unsupported: 'HDRP/Lit' - All subshaders removed

WARNING: Shader Did you use #pragma only_renderers and omit this platform?

WARNING: Shader If subshaders removal was intentional, you may have forgotten turning Fallback off?

Turning off the fallback completely and removing #pragma only_renderers produced this warning message in the shader inspector:

HDRP/Lit shader is not supported on this GPU (none of subshaders/fallbacks are suitable)

This sounds a little strange though, as the device this was compiled on most definitely supports SM 6.6 and on latest drivers to boot

 

Reporting back in.

Using IsHelerpLane() instead completely fixes the issue on the NVidia hardware. It works even when the shader is compiled with SM 6.0 (as noted in the blogpost that the feature can be emulated on previous shader models).

EDIT: this was a false positive. The crash still happens regularly, altough slightly less often.