Added barrier to panic loop.

[charles-r-earp]

Related to #1048.

On panic!, rustc_codegen_spirv emits a loop {}, but this can be optimized away with spirv-opt due to the AgressiveDCE pass. This PR inserts a memory_barrier inside the loop which prevents it from being removed.

This ensures that shaders that panic, ie from out of bounds accesses, will not silently continue execution but hang the app.

Unfortunately the wgpu compute example errors with UnsupportedInstruction(Function, MemoryBarrier), likely naga does not support barriers.

It does work using create_shader_module_spirv and enabling the features Features::SPIRV_SHADER_PASSTHROUGH | Features::TIMESTAMP_QUERY_INSIDE_PASSES.

Edit:
Replaced with https://github.com/charles-r-earp/rust-gpu/tree/panic-abort.

The idea is for panic! to emit OpKill / OpTerminateInvocation and replace that with a return from the entry point after inlining. Additionally it will use debug_printfln! if available so that it's easier to detect panics while developing.

[eddyb]

Is it safe to say this PR has been obsoleted by the following?

• Lower aborts (incl. panics) to "return from entry-point", instead of infinite loops. #1070
• Add debugPrintf-based panic reporting, controlled via spirv_builder::ShaderPanicStrategy. #1080
• Show panic! messages via debugPrintf, even including some runtime arguments ({u,i,f}32 as {} or {:?}). #1082

[charles-r-earp]

Is it safe to say this PR has been obsoleted by the following?

* [Lower aborts (incl. panics) to "return from entry-point", instead of infinite loops. #1070](https://github.com/EmbarkStudios/rust-gpu/pull/1070)

* [Add `debugPrintf`-based panic reporting, controlled via `spirv_builder::ShaderPanicStrategy`. #1080](https://github.com/EmbarkStudios/rust-gpu/pull/1080)

* [Show `panic!` messages via `debugPrintf`, even including some runtime arguments (`{u,i,f}32` as `{}` or `{:?}`). #1082](https://github.com/EmbarkStudios/rust-gpu/pull/1082)

Yes

[eddyb]

Alright then, closing in that case - thanks for prompting all of this, btw, Rust-GPU panics would've probably stayed in a pretty bad shape for a while longer if not for #1048 and the ensuing discussions.