Fix DecoupledLookback with a device-scope memory fence - #116
Conversation
Replace the raw UnsafeAtomics.fence(acquire/release) in the DecoupledLookback lookback with an overridable `_decoupled_fence()` (generic no-op fallback). A plain fence is not device-scope and fails to select on recent NVPTX, so cross-block publish/consume was not coherent: correct on high-occupancy GPUs but racy where blocks run in waves. Each GPU backend supplies a native device fence via `@device_override` in its package extension. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Override `_decoupled_fence()` with a native device-scope fence per backend: CUDA threadfence; AMDGPU agent-scope seq_cst fence; oneAPI and OpenCL/POCL a SPIR-V device-scope atomic_work_item_fence; Metal an atomic_thread_fence over device memory at device scope (Metal 3.2+). Each extension is a single override so it lifts cleanly into KernelAbstractions if a portable fence lands there. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a small-tile (block_size 16-64, one item per thread) non-uniform scan loop in both directions, run for every algorithm. It maximises the number of inter-block publish/consume handoffs so DecoupledLookback exercises the device fence on many blocks; a fence that is not device scoped drops whole-block carries and fails here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@christiangnrd @maleadt Please give it a look :) |
There was a problem hiding this comment.
A few minor things.
Any reason you didn't push to #98?
Wanted to keep commit history clean. |
b703309 to
5cf3169
Compare
|
That broke CUDA… I’ll look into why in a bit |
CUDA was already broken this just surfaced the error. Your CUDA extension wasn't being loaded since we test with CUDACore not the full CUDA package. The device fence being called was the default noop, but when it was changed to a function definition with no methods, the bug was uncovered. I've fixed it to extend CUDACore instead of CUDA. Unfortunately this removes support for CUDA v5. I think it would be possible to keep support for it in but it would be very convoluted so I wouldn't bother unless someone explicitly asks. |
|
Ok this looks good to me. @maleadt any final thoughts? |
3 participants
No description provided.