Update ShaderPanicStrategy::DebugPrintfThenExit documentation for Vulkan SDK changes.

[eddyb]

I noticed a few changes in the Vulkan Validation Layer documentation and ended up with these items:

• multimodule recommendation is no longer necessary (since Vulkan SDK 1.3.275.0):
  • issue: spirv-opt: debugprintf instrumentation reports "Mixed stage shader module not supported" KhronosGroup/SPIRV-Tools#4892
  • PR: printf: Remove stage specific info KhronosGroup/SPIRV-Tools#5495
• DEBUG_PRINTF_TO_STDOUT=1 is now VK_LAYER_PRINTF_TO_STDOUT=1 (since Vulkan SDK 1.3.283.0)
  • old env var still works (just deprecated), but the new one fits in better
  • PR: printf: Add proper vk_layer_settings support KhronosGroup/Vulkan-ValidationLayers#7781
• VK_KHR_shader_non_semantic_info isn't required anymore (since Vulkan SDK 1.4.313.0)
  • we should stop mentioning it, but it's recent and I left it in just in case
  • issue: Turn on VK_KHR_shader_non_semantic_info for users using debug printf KhronosGroup/Vulkan-ValidationLayers#9716
  • PR: printf: No error if non semantic info ext not seen KhronosGroup/Vulkan-ValidationLayers#9718

I'm not sure how happy I am with the result, but it tries the offer both an easy set of env vars
(VK_LOADER_LAYERS_ENABLE=VK_LAYER_KHRONOS_validation VK_LAYER_PRINTF_ONLY_PRESET=1 VK_LAYER_PRINTF_TO_STDOUT=1)
and detailed explanations of all the moving parts, in case that doesn't suffice.

Honestly, we should probably have a separate document, and/or move this to debug_printf!
(and merely refer to it from this setting), since users trying that out would also need this info.

---

As a sneak peek, this is a screenshot of the new docs (click to open its full size):

[eddyb]

@Firestar99 I noticed this in passing, am I right to think this means cargo-gpu cannot make use of this mode? IMO it's invaluable to debugging panics, so we should try to make it easier and more visible (tbf this entire enum is user-facing API on top of ~6 possible strings that get passed to rustc_codegen_spirv via codegen args, but I'm not sure where it would be best placed).

(oh and I would be fine with not exposing UNSOUND_DO_NOT_USE_UndefinedBehaviorViaUnreachable to users at all, I haven't really heard of anyone going for it, so it can stay behind RUSTGPU_CODEGEN_ARGS or w/e instead - then the choices implied by ShaderPanicStrategy get simpler)

[Firestar99]

I think I disabled it since the original cargo-gpu (before my refactors) didn't support it and clap didn't work out of the box, the support for enums with values doesn't seem to cleanly work. But it gets even sillier:

• clap is used to parse args from cmdline, which is disabled
• serde is used to read the [metadata.cargo-gpu] from the crate's Cargo.toml
• if you use cargo-gpu as a library, you just get a spirv-builder you need to configure manually

I agree this is a mess, and we should eventually figure out a unified way to represent these properties. Since I made #347 I thought of two directions to take things:

• encourage the Cargo.toml path, so that tools like cargo gpu clippy could pick up the properties, and make the library path pick those up by default as well
• if we make capabilities and extensions not pre-defined but picked up as they are used, as discussed in "link-time capabilites" on zulip, then there's no need to pre-declare anything per crate. If all settings are link-time settings, then there's no need to declare them in the Cargo.toml for a cargo gpu clippy to pick them up, since it doesn't link anything. And all the linking settings could just be properties of spirv-builder.

[LegNeato]

I think this is probably the first place we need to have a trait for folks to implement or EII or whatever. It should not be this hard to printf from an end-user perspective! But the docs look good.

[LegNeato]

🚀