Skip to content

Consider adt_const_params for intrinsics #607

Description

@nazar-pc

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,
) -> I

Will change to something like this:

fn atomic_i_increment<I: Integer, const SCOPE: Scope, const SEMANTICS: Semantics>(
    ptr: &mut I,
) -> I

And usage will be something like this:

atomic_i_increment::<_, { Scope::QueueFamily }, { Semantics::NONE }>(..)

Activity

  1. Firestar99 commented on Jun 6, 2026

    @Firestar99
    Member

    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.

  2. nazar-pc commented on Jun 6, 2026

    @nazar-pc
    ContributorAuthor

    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-std can 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_si128 can 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 requiring adt_const_params.

    I'm just hoping there is a more ergonomic and misuse-resistant API for these.

  3. nazar-pc commented on Aug 4, 2026

    @nazar-pc
    ContributorAuthor

    Turns out this is kind of a duplicate for one of the variants you suggested in #414 already

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions