Repository navigation
Ergonomic easy-to-use builtin arguments with wrapper types #532
Description
Activity
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.
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.
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.
Reacted by Alex HelfetHave a look at #534 :D
Reacted by Alex HelfetThe end goal would be to have a proc macro that generates the
asm!for you, to make it easy to use,cargo expand-able and extendable by people without looking at the whole compiler.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.
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:
There's less code to write in the
newtyped version, and in my opinion it's easier to write this correctly without looking throughrust-gpubook to find both the required type and builtin name. Insteadspirv_stdcould have a module of these builtin wrappernewtypes, and the user could just select the right one without leaving their IDE.The
newtypewrappers for the current prototype are simple to add, here's approximately what could go inspirv_std:In
rustc_codegen_spirvI currently have a match statement to map fromspirv::BuiltIn::_to the abi type. That could probably be moved into the#[spirv(builtin_wrapper(..)]attribute inspirv_stdalso, or perhaps inferred from the contents of the newtype?The current changes for the implementation in
rustc_codegen_spirvare 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?