Repository navigation
Conversation
…memory access faults at runtime
Codecov Report❌ Patch coverage is
❌ Your project check has failed because the head coverage (49.40%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## develop #8571 +/- ##
============================================
- Coverage 70.64% 69.69% -0.95%
============================================
Files 2939 2524 -415
Lines 483952 362315 -121637
Branches 69768 50845 -18923
============================================
- Hits 341874 252515 -89359
+ Misses 118213 91187 -27026
+ Partials 23865 18613 -5252
*This pull request uses carry forward flags. Click here to find out more.
🚀 New features to boost your workflow:
|
✅ All Checks Passed — Ready for Review
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🎉 All checks passed! This PR is ready for review. |
…testing functionality for the internal test suite.
|
It would be very helpful for this PR if there was a check in the fused Bluestein plan creation path which checked whether the assumptions for creating this plan were not met. That way, if the check added in this PR is removed, then something fails at plan generation time, and then we have an indication of where to fix it. |
|
This pull request has been inactive for 25 days and will be marked as stale. If you would like to keep this PR open, please:
This PR will be automatically closed in 5 days if no further activity occurs. |
|
This pull request has been inactive for 25 days and will be marked as stale. If you would like to keep this PR open, please:
This PR will be automatically closed in 5 days if no further activity occurs. |
|
#13020 fixes this issue without adding technical debt. My suggestion is to prefer the former solution. |
|
Cancelling the remaining gfx950 jobs on this run so the TheRock submodule bump PRs can be prioritized on the gfx950 queue. This change does not target gfx950, and gfx950 was the only work still outstanding. Jobs that already finished are unchanged. Re-run failed jobs if you need gfx950 results before merge. |
|
#13020 fixed the issue |
Motivation
JIRA ID : AIFFT-13
Some inner-batched complex 1D FFTs on the Bluestein path were crashing the GPU at runtime with a memory access fault, and returned wrong results once the crash was avoided. The fused Bluestein path assumes the batch is the slowest-moving dimension (batch distance ≥ FFT strides). Inner-batched layouts violate that, the batch is interleaved inside each transform, so the fused path can't represent the padded per-batch convolution distance, and both faults and miscomputes result.
Technical Details
tree_node_bluestein.cpp(DecideBlueType): Detect inner-batched layouts (a batch distance smaller than an FFT stride) and route them to the non-fused multi-kernel Bluestein path instead of the fused path. The non-fused path already handles these layouts correctly, so this fixes both the crash and the numerics.The detection compares each FFT stride against the batch distance, so it also covers inner-batched layouts where the distance is greater than 1 but still smaller than a stride (e.g.
istride=4, idist=2), which a simpleidist==1check would miss.Test Plan
rocfft-test --gtest_filter=manual.vs_fftw -g 1across inner-batched Bluestein cases (prime/large lengths × batch sizes × placements), anistride=4 idist=2case, and non-inner-batched baselines for regressions.Test Result
istride=4/idist=2).Submission Checklist