Skip to content

cleanup module structure in spirv_std#540

Open
Firestar99 wants to merge 11 commits intomainfrom
move_mod
Open

cleanup module structure in spirv_std#540
Firestar99 wants to merge 11 commits intomainfrom
move_mod

Conversation

@Firestar99
Copy link
Member

@Firestar99 Firestar99 commented Feb 25, 2026

While working on spirv-std functions to query builtins, I was annoyed that our shader specific intrinsics were a bit all over the place within spirv-std. Particularly annoying was that some intrinsics got their own mod in the root (e.g. debug_printf, sampler etc.), some intrinsics are within arch (e.g. arch::subgroup, arch::mesh_shading), and the raytracing stuff is both in ray_tracing and arch::ray_tracing while mixing the two ray tracing APIs of ray_pipeline and ray_query.

Since that PR will add a lot of new intrinsics for querying (and setting) all the different built-ins, I want to cleanup our module before implementing them all. And as most shader shader types needs their own slightly different built-in declaration, I want to give every single shader type (or extension) a module in the root of the crate.

This leaves arch with only barriers, atomics and some miscellaneous intrinsics, which may be used from any shader. Should we also move barriers and atomics to the root of the crate?

Changes

  • all of these are breaking changes, but should be easy use statement adjustments for most users
  • moved modules
    • spirv_std::arch::primitive -> spirv_std::geometry
    • spirv_std::arch::mesh_shading -> spirv_std::mesh and spirv_std::task
    • spirv_std::arch::subgroup -> spirv_std::subgroup
    • spirv_std::arch::derivative -> spirv_std::fragment
    • spirv_std::arch::demote_to_helper_invocation_ext -> spirv_std::fragment
    • spirv_std::arch::barrier -> spirv_std::barrier
    • spirv_std::arch::atomics -> spirv_std::atomic (Note the missing s to match std::sync::atomic)
    • everything in root spirv_std::arch stays the same, notably IndexUnchecked
  • ray tracing
    • moved to spirv_std::ray_tracing, containing any shared types directly (AccelerationStructure, RayFlags)
    • ray pipeline intrinsics are in spirv_std::ray_tracing::ray_pipeline
      • AccelerationStructure::trace_ray(&self, ...) -> ray_pipeline::trace_ray(AccelerationStructure, ...), since this function is ray pipeline exclusive
    • ray query type is in spirv_std::ray_tracing::ray_query
  • read_clock
    • move from arch::read_clock* to spirv_std::shader_clock::read_clock*
    • make function match glsl more closely by implying Device scope

@Firestar99 Firestar99 force-pushed the move_mod branch 3 times, most recently from d4cfa96 to 4a1f6c9 Compare February 25, 2026 15:45
@Firestar99 Firestar99 marked this pull request as ready for review February 25, 2026 16:13
@LegNeato
Copy link
Collaborator

These are all under arch as that is where they would go once this moved to upstream std, so I think we should at least mirror that? Or do you see spirv_std as being rooted at std::arch::spirv and thus doesn't need arch?

@Firestar99
Copy link
Member Author

Firestar99 commented Feb 26, 2026

I'd say the second, that the entire spirv-std should be at std::arch::spirv.

If you took main's arch and ripped it out, you'd notice that it'll at least also require the mods scalar, vector, scalar_or_vector and the entirety of glam.

By that logic, I should also move out barrier and atomic. The mod arch itself can persist for various dissociated asm!'s it contains in it's root.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants