-
Notifications
You must be signed in to change notification settings - Fork 81
refactor derivatives #230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor derivatives #230
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way we can polyfill for f64?
There appear to be valid CI failures.
| use glam::{Vec2, Vec3, Vec3A, Vec4}; | ||
|
|
||
| #[cfg(target_arch = "spirv")] | ||
| macro_rules! cap_deriv_control { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This macro is used elsewhere but impl is commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove it for now, can always undo later if you don't squash.
But interestingly, you can use this to enable a capability from the code itself, and do not need to predeclare it in SpirvBuilder. I want to follow this up a little more, cause I would like to get rid of predeclaring them at all, and you just enable features on the things you use implicitly. Note that using that shader (in Vulkan, unsure about wgpu) requires you to explicitly enable said device feature, so you'd still notice when you accidentally were to use too many features.
Refactoring this would completely remove recompilations due to changed predeclared capabilities, which change absolutely nothing anyway and is a blocker for redistributing build scripts with shaders. And could allow shaders within the same crate to only require the capabilities that the shader actually needs, but this needs more research on how DCE is performed on capabilities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be cool, but commented out it does nothing. So yeah, let's remove and follow-up. I'm a little hesitant that the capabilities code relies on would not be statically known. I think we should take a large hint to how simd is handled in rustc with compile control and runtime checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a commit to just comment it out, now I got one commit that removes it and can be reverted later
|
Forget about polyfiling this for f64 or anything else really. This is a fragment shader only instrinsic for computing derivatives with your neighboring fragments, which are needed in eg. texture operations for mip level selection. |
|
Looks like CI failing:
|
…c3A to be derived disallow f64 as spec expects only 32bit floats
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
Adds a new
trait Derivativethat is implemented forf32,Vec2,Vec3,Vec3AandVec4. Disallows f64 to be derived, spec expects f32 only. Renamed derivatives fromddx()todfdx()to better match glsl'sdFdx().Spec section: https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_derivative_instructions