Using for-loops in this compute shader crashes the Windows kernel driver

Gaming and Visualization Technologies APIs Vulkan
1

Running the following compute shader triggers a crash in the Windows kernel driver (ie. the screen becomes black, and after a few seconds there’s a message from Windows about the video driver having crashed).

Source code
SPIR-V

Notice that there are three for loops that run only once. Replacing the for loops with simple local variables fixes the problem. Here is a working version:

Source code
Binary

I’m using commit 0c968f9d0ef66dff741032e7bafd10d413f076fb of glslang (which is very recent).
Driver version 368.22
GTX 970
Windows 7 64bits

Should I provide an executable as well?

2

You are likely seeing a TDR Timeout detection and recovery (TDR) - Windows drivers | Microsoft Docs since your shader takes too long to run.

I suggest to increase the local_size to increase the overall performance.

As for the difference between the two shaders, I suspect that the shader compiler wasn’t able to unroll the loop for some reason; we’ll take a look.

3

I don’t think it’s that, for two reasons:

  1. I think the error message is different for a TDR (“there was a crash” vs “device stopped responding”). My system is not in english so I can’t tell you exactly what is written.

  2. Here is a previous version of that same compute shader, and that old version runs fine even though it has at least 64 times more work to do. It has approximately the same for loops as the one that crashes but with respectively 32 and 8 iterations. The old version also uses 1x1x1 for the local size.

I may be wrong though.

4

Your third for loop is:

for (int res_id = 0; i < 1; ++res_id) {

Is it possible that you want to use this for loop instead:

for (int res_id = 0; res_id < 1; ++res_id) {

5

Good catch. With that fix, both shaders compile to the same GPU microcode and as such no TDR due to infinite loop anymore.:)

6

Oh, I feel so stupid now :(

Sorry again for the false alarm.