-
Notifications
You must be signed in to change notification settings - Fork 1k
[naga]: Add no_std
polyfill for round_ties_even
for f32
and f64
#7585
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
base: trunk
Are you sure you want to change the base?
Conversation
no_std
polyfill for round_ties_even
for f32
and f64
no_std
polyfill for round_ties_even
for f32
and f64
This PR will actually fix |
226490c
to
861d264
Compare
# Check with all features except "std". | ||
cargo clippy --target ${{ matrix.target }} ${{ matrix.extra-flags }} -p wgpu-types --no-default-features --features strict_asserts,fragile-send-sync-non-atomic-wasm,serde,counters | ||
cargo clippy --target ${{ matrix.target }} ${{ matrix.extra-flags }} -p naga --no-default-features --features dot-out,compact |
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 comment isn't correct for naga - I think you should pull them out into their own lines instead of attaching them.
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've just updated the comments to be more broad. I do like the two groups (no features, all compatible features), but I'm happy to split it up (either crate by crate or just each line on it's own)
naga/src/proc/constant_evaluator.rs
Outdated
/// <https://github.com/rust-lang/rust/issues/96710>. | ||
/// | ||
/// [polyfill source]: https://github.com/imeka/ndarray-ndimage/blob/8b14b4d6ecfbc96a8a052f802e342a7049c68d8f/src/lib.rs#L98 | ||
fn round_ties_even<T: num_traits::float::FloatCore>(x: T) -> T { |
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 am really worried about the precision of this. wgsl requires perfect rounding. When it was only used for f16 (using f64 internals) it had a ton of excess precision. But using f64 on f64 I really worry about this.
I think it would be better to take a dep on libm
and call rint
/rintf
which use a slightly different algorithm.
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.
Perfectly reasonable. I was unaware libm
actually offered an option for round_ties_even
(but TBF the libm
documentation leaves a lot to be desired). I've reverted my changes and just switched to libm::rint/f
73bad8d
to
fdca21d
Compare
Update comments around `no_std` CI task
fdca21d
to
f7ed1ba
Compare
Connections
Description
round_ties_even
f16
polyfill forf32
andf64
usingnum_traits::float::FloatCore
, specifically forno_std
supportnaga
to the Checkno_std
CI action now that it is MVP compatibleTesting
Squash or Rebase?
Squash
Checklist
cargo fmt
.RunN/Ataplo format
.cargo clippy --tests
. If applicable, add:--target wasm32-unknown-unknown
cargo xtask test
to run tests.CHANGELOG.md
entry.Notes
f32::round_ties_even
orf64::round_ties_even
, since I don't believe there is substantial value added with such a feature.f16
polyfill. However, there are substantial tests for this exact method in this num-traits PR I opened. This PR would just allow us to continue working onno_std
support while we wait for that PR to be accepted (or not).