`spirv-std` features for APIs that are not universally available

[nazar-pc]

OTOH, there does exist a SequentiallyConsistent in SPIR-V, so if we wanted to, we could move the error to the new SPIR-T-based validator pass, so you're only going to see if the match ordering {...} doesn't get optimized away.

Originally posted by @eddyb in #399

This is another frustrating part of rust-gpu for me. It exposes all possible permutations of things possible in SPIR-V, even though some of them are only possible in a specific version, some only in OpenCL (is it even a relevant target at this point?), and some are technically valid for Vulkan as such, but not supported by WebGPU/wgpu.

It'd be nice if spirv-std had features flags that hide certain APIs that are specific to Vulkan-only or OpenCL-only or require a specific SPIR-V version (ideally, with Vulkan version aliases).

Some meta feature that only exposes portable features usable with wgpu would be useful as well, but that might be a stretch (though it would be a serious usability improvement).

[eddyb]

To be clear, I was talking about core::sync::atomic types, how they expect SeqCst to be available (as they match on Ordering at runtime), and we don't really control any of that (only how we compile the definitions).

Vulkan doesn't support SequentiallyConsistent, and even OpenCL only does so when CL_DEVICE_ATOMIC_ORDER_SEQ_CST is present in CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES (which is far from universal - though I'm not sure that website is as useful for OpenCL as it is for Vulkan).

The only reason it'd be useful to us that SequentiallyConsistent is in SPIR-V, even if we might not support any targets that do allow it, is if we wanted to delay that error about SeqCst not being supported (and arguably fix #399 in the process), such that passing in other Ordering values into atomic types' methods, won't trigger it.

---

As for the rest of spirv-std, the only subset that feels plausible to quantify is really the WebGPU one (or if you want to go after one of the Vulkan "profiles", but that feels pretty fraught).

The way Khronos has been extending SPIR-V so far, has not resulted in a good split between:

• "shader interface" (worst offenders are several bespoke kinds of pipelines, and of course all the raytracing extensions, with some concepts appearing duplicated/triplicated and overall being much more invasive than necessary)
• "libraries of types and/or operations" (this is most frustrating for anything that does not even interact with any GPU-specific aspects, and could be instinguishable from a function - e.g. OpUDotAccSat - but even "resources with methods" could've been a different level of abstraction than "instruction")
• "fundamental capabilities" (very few fit here, arguably anything with non-trivial controlflow interactions, maybe something like OpTypeUntypedPointerKHR, but it's the rarest category, and yet everything is treated as if it were part of that category, except for...)
• "non-semantic extended instructions" (the notable exception which did get its own level of abstraction, but it's only really useful for debug info and related tools like debugPrintf)

---

Right now we still use -C target-feature for SPIR-V extensions and capabilities, and IIRC the idea there was that spirv-std could use #[cfg(target_feature = "...")] to gate certain APIs (but this never happened? not sure).

More recently, I've been convinced by @Firestar99 that for certain capabilities we can "legalize"/"emulate"/"polyfill"/etc. away (e.g. integer types smaller/larger than 32-bit), it would make much more sense to have a capability-agnostic target, that is later specialized at the very end into one or more variants (without actually having to recompile everything N times).

I'm not sure how that interacts with the "I don't want to even see APIs I couldn't use with the Vulkan/WebGPU/etc. version/subset/etc. I'm targeting" UX desire, but if we stop using -C target-feature, we could potentially offer something more useful via Cargo package features of spirv-std, instead (as long as nothing else wants #[cfg(target_feature = "...")]-like semantics).

[nazar-pc]

That was just a single example that triggered creation of this issue. There are many more I hit over last few months and was quite surprised by.

spirv_std::memory::Semantics, for example, has a lot of variants, some of which also do not make sense for Vulkan. For example, ATOMIC_COUNTER_MEMORY doesn't make sense in Vulkan from my understanding, yet it is there in the list of possible variants, confusing the user.