A compute program originally written for NVIDIA CUDA ran on an Apple device with an M3 Pro with almost no changes to its kernel code — and not on a toy demo like vector addition, but with roughly a 10x speedup on a real three-dimensional fluid simulation task.

The thing that made this happen is a newly opened "experimental Metal backend" PR for the open-source scientific computing framework OpenFPM. The caveats first:

⚠️ Three boundaries we have to be honest about:

1. This is an open, unmerged PR (GitHub PR #18, author abhinavsns, opened 2026-07-17). As of writing it remains unmerged; it is experimental, and do not take it straight to production.
2. Apple Metal lacks adequate double-precision float support, making it a poor fit for double-precision-dependent HPC workloads like weather prediction and aerospace. That territory remains NVIDIA's professional-GPU home ground.
3. It is currently a single-node backend. Multi-node scaling would rely on Thunderbolt RDMA and belongs to future work.

As for the "GPT-5.6 Sol did it in 6 hours" claim circulating online — that is only the author's own account on X. The GitHub PR itself contains no statement about AI assistance. This article does not treat it as fact, and you should discount similar claims accordingly.

What It Is

OpenFPM is a parallel scientific computing framework for particle and grid methods; official repository mosaic-group/openfpm, project homepage openfpm.mpi-cbg.de.

For the past decade-plus, GPU computing has been highly fragmented — NVIDIA has CUDA, AMD has HIP, Apple has Metal, all mutually incompatible. This PR's core contribution is not "writing yet another Metal version." It builds a translation channel that keeps the original CUDA/HIP-style .cu kernel source unchanged (the "source of truth") while running it transparently on the Apple Silicon GPU underneath.

The Translation Chain

The PR title — "Add transparent Metal GPU support through MoltenVK and SPIR-V while keeping existing .cu files as the source of truth" — lays out the chain precisely:

.cu kernel (CUDA/HIP style)
      │  Clang/HIP compilation
      ▼
   SPIR-V
      │  Vulkan
      ▼
   MoltenVK
      │
      ▼
   Apple Metal GPU

The key point is that the application layer never notices — the developers added no Metal-specific particle APIs; applications still make the same CUDA/HIP-style kernel calls as before, and the hardware differences are absorbed inside the framework. That is genuine "hardware transparency."

Hands-On Benchmark: 3D SPH Dam-Break Simulation

The test case in the PR is a three-dimensional SPH (smoothed-particle hydrodynamics) dam-break simulation complex enough to matter, exercising modules like sweeping, sorting and reordering, cell and neighbor-list construction, ghost particle exchange, reduction operations, and atomic operations.

On an Apple device with an M3 Pro:

A speedup of roughly 10x, achieved purely by switching the compute backend. On closer inspection the developer found the physics results from the Metal and CPU versions stayed consistent — which is crucial for scientific computing; fast but wrong is worthless.

The Complexity Boundary

Particle storage grows linearly with particle count N, and neighbor searches and similar work are roughly O(N·k). The 10x speedup shown is the result of a single-node backend comparison.

The future plan is multi-node dynamic load balancing via RDMA over Apple's Thunderbolt, but no code has landed for that yet — it remains roadmap.

Who It Suits, and Who It Doesn't

Worth an early look:

• Researchers doing scientific computing or physics simulation on a Mac who want to harness the Apple Silicon GPU
• Teams maintaining CUDA/HIP codebases who want to reach macOS without rewriting kernels
• Developers following cross-platform GPU compilation chains (SPIR-V/MoltenVK)

Not a fit for:

• Weather, aerospace, and HPC scenarios that need double-precision floats — Apple Metal cannot carry them
• Anyone needing a stable production environment — this is an unmerged PR and the API is still moving
• Multi-node distributed HPC — currently a single-node backend

How to Try It

Reading the PR beats reading articles about it; the author posted reproduction steps in the PR description:

• PR: https://github.com/mosaic-group/openfpm/pull/18
• The author's X post (with demo video): https://x.com/Abhinavsns/status/2079774018748694696

If you decide to run it, use the PR branch rather than main, and be mentally prepared for experimental code to change at any time. Once it runs, validate physics consistency on a small-scale SPH or particle problem before scaling up — just as the PR author did: confirm the Metal and CPU results agree first, then talk speedups.

Why This Route Matters

If the PR is eventually merged, it is a substantive step forward for Apple Silicon's position in scientific computing: developers keep their existing CUDA/HIP investment from going to waste while gaining the compute of Metal GPUs on a Mac.

But also keep those three boundaries in mind — experimental, single-precision, single-node. Track it as a promising direction, not as a production plan for tomorrow.