Repository navigation
Ergonomic easy-to-use builtin arguments with wrapper types #532
Description
I have a prototype that lets you write an entry-point's builtin arguments with newtype wrappers. Would you like to see a completed PR for this?
Example entry-point:
#[spirv(compute(threads(1024)))]
pub fn entry(
// local_invocation_index old:
#[spirv(local_invocation_index)]
local_idx_old: u32,
// New:
local_idx_new: LocalInvocationIndex,
// local_invocation_id old:
#[spirv(local_invocation_index)]
local_id: UVec3,
local_id_new: LocalInvocationId,
) { .. }There's less code to write in the newtyped version, and in my opinion it's easier to write this correctly without looking through rust-gpu book to find both the required type and builtin name. Instead spirv_std could have a module of these builtin wrapper newtypes, and the user could just select the right one without leaving their IDE.
The newtype wrappers for the current prototype are simple to add, here's approximately what could go in spirv_std:
#[spirv(builtin_wrapper("local_invocation_index"))]
#[repr(transparent)]
pub struct LocalInvocationIndex(pub u32);
#[spirv(builtin_wrapper("local_invocation_id"))]
#[repr(transparent)]
pub struct LocalInvocationId(pub UVec3);In rustc_codegen_spirv I currently have a match statement to map from spirv::BuiltIn::_ to the abi type. That could probably be moved into the #[spirv(builtin_wrapper(..)] attribute in spirv_std also, or perhaps inferred from the contents of the newtype?
The current changes for the implementation in rustc_codegen_spirv are only ~75 lines, but before a PR would be ready I'd need to add some more tests, some documentation, and probably better diagnostics. Shall I polish this up for a PR?
Activity
fluffysquirrels commentedon Feb 19, 2026
My implementation is in my fork's branch
builtin-wrapper. Diff.My working example is in a private repo. If we decide to go ahead I can get something working in the examples in this branch.
fluffysquirrels commentedon Feb 19, 2026
I've also just noticed #459, which adds new functions to
spirv_stdto improve ergonomics a different way. It also avoids polluting the entry-point's argument list and non-entry-point functions can call the builtins without passing them down each function call. Neat!If you'd like I can work on that prototype and push it closer to completion instead.
Firestar99 commentedon Feb 19, 2026
I've been kinda distracted from this and been working on other big things, one to hopefully be PRed soon.
I too feel like just having regular getter functions in spirv-std to be more ergonomic. After all, they are just globals in shaders too.
There's actually a second branch:
asm_fn_ptradds the ability to use function pointers in asm blocks, allowing you to write your entry point declarations inasm!blocks for maximum flexibility. This compiletest showcases it nicely. Haven't gotten buffers to work back then, may just revisit it today to see what I can do. The end goal would be to have a proc macro that generates theasm!for you, to make it easy to use,cargo expand-able and extendable by people without looking at the whole compiler. But I'd exclude the built-ins here and move the to free standing functions in spirv-std, which makes both of them kinda independent of each other. I'm just gonna spend the day on this and see how far I can get it.Also feel free to always open up a PR, even for unfinished stuff! We can always have a discussion about how to arrange stuff there and have the diff immediately available for comments. Though, I do feel like #459 is the better approach in this case.
Firestar99 commentedon Feb 19, 2026
Have a look at #534 :D
fluffysquirrels commentedon Feb 19, 2026
I really like the sound of this! Will be great for people that need more custom code and already know some SPIR-V.
OK, I'll close this and take a look at #459 instead. After that I would like to work on more ergonomics stuff.