Implement ddx, ddy, fwidth #256
Conversation
| // "must be a scalar or vector of floating-point type. The component width must be 32 bits." | ||
| deriv_impl!(f32); | ||
| // TODO: Fix rustc to support these | ||
| // deriv_impl!(glam::Vec2); | ||
| // deriv_impl!(glam::Vec3); | ||
| // deriv_impl!(glam::Vec4); |
There was a problem hiding this comment.
Just confirmed that these lines (uncommented) stop erroring with rust-lang/rust#79171.
There was a problem hiding this comment.
Think it is a great fit to have this in spirv-std, or at least it is the best place for it now.
Wrt to function names and other such bikeshedding. Think we can just start with this and having the functionality, and then once we've used it a bit evaluate it further and see if we want to rename stuffs.
In general on the CPU I'm in favor of getting compile errors for things that are not implemented, but the general Rust ecosystem philosophy is indeed to have stuff compile and get panics instead. I would probably still lean towards simply not having this available as I really don't want my shaders when running on CPU to be panicking, that type of porting I would want compile errors for and we are in a bit more controlled ecosystem.
But definitely are tradeoffs with IDE/RA also. Could potentially be a Cargo feature flag for the crate also of which behavior to have, probably by default not having the functions available on CPU, but opting in to having them defined but getting panics.
But we'll have to see what works best
Does things relevant to #197 (uh, avoiding the github magic word that closes the issue, since this doesn't deal with all of it)
Now that
asm!is in, we don't even have to touch the compiler to implement this! wow!bikesheddables:
Things that are technically bikesheddables but I feel strongly about: