Add atomic memory orderings for Metal

[VEZY]

Note: I used Codex with GPT-5.5 High to implement this feature (both on Metal.jl and here). The original issue for context is linked to building a TLAS on GPU with RayCore.jl (JuliaGeometry/Raycore.jl#19). The PR on Metal is here: JuliaGPU/Metal.jl#870. Please wait for this PR to be merged before merging this one.

Summary

This updates AtomixMetalExt so atomic operations on Metal arrays preserve the memory ordering requested through Atomix/UnsafeAtomics.

The extension previously dispatched to Metal atomic operations without forwarding the requested ordering. That makes relaxed counter-style atomics work, but it prevents acquire/release synchronization patterns from being represented correctly on Metal.

Changes:

• Map Atomix/UnsafeAtomics orderings to Metal memory orders:
  • unordered / monotonic -> relaxed
  • acquire -> acquire
  • release -> release
  • acq_rel / acquire_release -> acq_rel
  • seq_cst / sequentially_consistent -> seq_cst
• Pass the mapped ordering through modify!.
• Pass success and failure orderings through replace!.
• Implement Metal-backed get and set! using ordered Metal load/store operations.
• Preserve relaxed Metal atomics for unordered/monotonic requests.
• Add Metal extension tests covering get/set and ordering propagation.

Why

Atomix exposes memory ordering as part of its atomic API, and downstream GPU code relies on those orderings for synchronization-sensitive algorithms. In particular, algorithms that publish ordinary device-memory writes through an atomic operation need acquire/release or stronger semantics to make the writes visible to another workitem. This was my case when building a TLAS on GPU for performing all hits computations with a ray tracing algorithm (using RayCore).

Forwarding the requested ordering to Metal fixes those synchronization cases while keeping unordered/monotonic atomics mapped to relaxed Metal operations for fast counters and reductions.

Validation

• Atomix Metal extension tests passed against a patched local Metal checkout (available here: Add ordered atomics JuliaGPU/Metal.jl#870).
• Downstream RayCore.jl TLAS/BLAS Metal repro passed with Atomix orderings wired through to Metal.
• ArchimedLight (my package) derived static TLAS comparison passed: CPU-built/adapted and direct Metal-built TLAS match for nodes, instances, all BLAS buffers, descriptors, and root AABB.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.35%. Comparing base (e60c518) to head (7605e9b).
⚠️ Report is 22 commits behind head on main.

Files with missing lines	Patch %	Lines
ext/AtomixMetalExt.jl	0.00%	24 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main      #79       +/-   ##
===========================================
- Coverage   92.95%   50.35%   -42.61%     
===========================================
  Files           6       10        +4     
  Lines         142      282      +140     
===========================================
+ Hits          132      142       +10     
- Misses         10      140      +130     

Flag	Coverage Δ
Pkg.test	50.35% <0.00%> (-42.61%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vchuravy]

@copilot resolve the merge conflicts in this pull request

[christiangnrd]

Suggested change

	Metal = "1.10.3"
	Metal = "1.10.1"

[maleadt]

I'm going to close this in favour of a more general fix: With JuliaGPU/Metal.jl#977, Metal.jl emits plain LLVM atomics that GPUCompiler lowers to AIR, so orderings are honoured on every supported macOS version, with fences before Metal 4.1. Atomix's generic UnsafeAtomics path then works on Metal as-is, so I'll remove AtomixMetalExt instead of forwarding orderings through it. Your publish pattern should just work once that's released.

[VEZY]

Thanks @maleadt, good to have a better solution!