Repository navigation
Consider adt_const_params for intrinsics #607
Description
Adjacent to #605, I'm wondering whether it'd be acceptable to use adt_const_params for intrinsics like atomics.
Then this signature:
fn atomic_i_increment<I: Integer, const SCOPE: u32, const SEMANTICS: u32>(
ptr: &mut I,
) -> IWill change to something like this:
fn atomic_i_increment<I: Integer, const SCOPE: Scope, const SEMANTICS: Semantics>(
ptr: &mut I,
) -> IAnd usage will be something like this:
atomic_i_increment::<_, { Scope::QueueFamily }, { Semantics::NONE }>(..)
Activity
Firestar99 commentedon Jun 6, 2026
I wish, but requiring nightly-only features breaks building spirv-std on stable, which breaks building it on docs.rs and using it as a dep within your CPU crates that may compile on stable. I'd be fine with having a feature in spirv-std that opts into using some nightly-only feature, but doing so here doesn't really seem possible without hiding the intrinsics completely on non-spirv targets, which will cause a bunch of problems if you plan your CPU crate to depend on your shader crate for type sharing.
nazar-pc commentedon Jun 6, 2026
It would break using it on stable, but it will not break building it on docs.rs since docs.rs is already building things with nightly compiler.
I'm wondering if it even makes sense to expose those intrinsics on non-SPIR-V targets. If such restriction is added (now that it is possible to lint SPIR-V target with Clippy properly directly, etc.),
spirv-stdcan expose or not expose things at compile time.Thus nightly features will be enabled on nightly compiler (that compiling for SPIR-V target will require in the foreseeable future anyway) and they will not be on stable compiler.
Also regular standard library has some really weird things going on with intriniscs on other platforms, I suspect for backwards compatibility. For example,
_mm_aeskeygenassist_si128can be called both as_mm_aeskeygenassist_si128(reg, IMM8)and_mm_aeskeygenassist_si128::<IMM8>(reg)(and IntelliJ Rust plugin seems to be quite confused about it).The source of this seems to be
#[rustc_legacy_const_generics(1)]attribute, so maybe rust-gpu could provide a similar mechanism that achieves both ergonomic end-user behavior and satisfy the needs of knowing the value at compile time. Possibly even with some compiler shenanigans instead of technically requiringadt_const_params.I'm just hoping there is a more ergonomic and misuse-resistant API for these.
nazar-pc commentedon Aug 4, 2026
Turns out this is kind of a duplicate for one of the variants you suggested in #414 already
ScopeandSemanticsnormal arguments rather than const generics #414