Application panics with naga validation error even if `ShaderFlags::empty()` is used at shader module creation

[francesco-cattoglio]

Description When I call wgpu::Device::create_compute_pipeline() with a compute shader containing the GLSL determinant() function, my application crashes with the following:

[17.799742 ERROR]()(no module): Error compiling the shader "Naga validation: Function { handle: [1], name: \"main\", error: Resolve(TypifyError([40], InvalidSubAccess { ty: [19], indexed: false })) }"
[17.799820 ERROR]()(wgpu_core::device): failed to create compute pipeline: Implementation specific error occurred
wgpu error: Validation Error

Caused by:
    In Device::create_compute_pipeline
      note: label = `Transform`
    not enough memory left

thread 'main' panicked at 'Handling wgpu errors as fatal by default', /Users/francescocattoglio/.cargo/git/checkouts/wgpu-rs-40ea39809c03c5d8/96ca1e4/src/backend/direct.rs:1886:5

even though I created the shader module with the flags: wgpu::ShaderFlags::empty() flags.

Repro steps This is the api trace of the application crashing. Running it under the wgpu player correctly reproduces the crash on my machine. naga_validation_crash.zip

Expected vs observed behavior The program panics, while I would expect naga to simply ignore the validation error.

Platform This only happens under MacOS, metal backend. The same code running on linux, Vulkan backend does not have the same issue. MacOS version 11.2.2, MacBook Pro (13-inch, 2020), wgpu-rs version used is revision 96ca1e41dd4ede12bcb3220712ab5c8c2fd688ad I am using a custom imgui-wgpu-rs https://github.com/francesco-cattoglio/imgui-wgpu-rs/tree/tracking_wgpu_master to make sure that even imgui-wgpu does call create_shader_module() function with the ShaderFlags::empty() flag.

[francesco-cattoglio]

I spent so much time trying to figure out the error that I never realised the shader code that I create is probably invalid GLSL code, because it contains the following line:

mat3 A;
<matrix A initialisation code>
float determinant = determinant(A);

which might be invalid because I am using a function as a variable name. This issue can be closed, or perhaps can be useful for improvements on the error message to the user.

[kvark]

Could you try to confirm if changing the name fixes it?

[francesco-cattoglio]

Yes, if a different name for the variable is used, then the code does not panic and no error gets produced.

[kvark]

hmm, ok. I wonder if SPIR-V was valid to begin with. Do you have access to that SPIR-V produced by shaderc? If you do, we'd want to run spirv-val on it and see if it was valid.

[kvark]

Actually, I see what's going on. SPIRV-Cross has a problem with determinant, hence the actual panic. The failed validation is a red herring here. We'll work on it, and eventually Naga will be able to process these.