Repository navigation
Far-field hard edges on HIP rest on a square root whose rounding isn't guaranteed, and the fuzz isn't in the tree #504
Description
What happens
The far-field pass promises that a hard aperture edge decides exactly as numpy_ref decides. That rests on each product and sum rounding on its own, and on a correctly rounded square root.
#497 fixes the first part on HIP: Clang fused the operations there, and on an AMD Instinct MI325X 16 of 588 exact edge decisions disagreed with the reference. The second part is observed, not guaranteed. __dsqrt_rn is __builtin_sqrt on HIP, and I found nothing in its documentation that promises correct rounding. With the fix, 0 of 1,938 decisions disagreed on that card, and 0 of 591 on an NVIDIA H200. far_field.hpp says this in a comment.
The fuzz that found the bug was a throwaway script, so nothing in the tree would catch this coming back.
Why it matters
A wrong decision moves a sample across a hard edge between backends, which breaks the exact hard-mask contract without raising anything. A new ROCm release could change it.
To do
- Add the exact-edge fuzz to the
gpu-marked tests besidetests/backends/test_native_far_field.py: columns placed on a shape's edge, compared with the reference's decisions. It belongs with the device tests, not CI, until CI builds no CUDA or HIP target, so device builds break unnoticed #151 gives CI a device lane. - Find out what AMD's device library promises for double-precision
sqrt, and state it in the comment and indocs/dev/accuracy.md.
Done when
The fuzz runs in the device tests and fails on the base of #497, and the comment states a documented guarantee or says plainly that there's none.
Activity
Check a replaced input on threads, and fuzz columns on a shape's hard…
jtravs commentedon Nov 5, 2026
The first item is in #520:
test_columns_on_a_shape_s_edge_decide_on_a_device_as_the_reference_decidesintests/backends/test_native_far_field.py, 40 seeds across a circle's, a half-plane's and an ellipse's hard edge, 5 columns each, with the exact edge and a float either side. The same fuzz runs on CPU with 4 seeds, so CI holds it too.8cd170e2. The other 3 were one bad seed in the test, not a decision: it drew only bins the load masks. That's fixed, and each target must now give both answers. It hasn't been rerun on that card.SOLPROP_NATIVE_FAR_FIELD_HIP_STRICTemptied, to show the fuzz fails without Far-field aperture shapes, a custom absorbed_power channel, and the boundary items #497's fix, which this issue asks.By a separate estimate at double-extended precision, a fused sum would flip about half of the half-plane's exact decisions, so the fuzz should find it.
The second item, what AMD's device library promises for
sqrt, I haven't looked into, so this stays open.