A computational program originally designed for NVIDIA CUDA ran directly on an Apple device equipped with an M3 Pro with almost no modifications to the kernel code.
This is an update shared yesterday by X user @Abhinav. More surprisingly, it is not merely a simple demonstration of vector addition, subtraction, multiplication, or division, but rather achieves approximately a 10x speedup in a real 3D fluid simulation task.
Behind this event is a special participant—GPT-5.6 Sol.
The event occurred on the open-source scientific computing platform OpenFPM. Researchers have been doing something many considered "unlikely": enabling high-performance computing programs originally designed for CUDA/HIP GPUs to run across platform boundaries on Apple's native Metal GPU architecture.
Why is this so difficult? For the past decade, the GPU computing landscape has been highly fragmented—NVIDIA has CUDA, AMD has HIP, and Apple has Metal. These ecosystems are like different languages, incompatible with one another. A program written in CUDA typically requires extensive rewriting to run on other platforms.
But this time, instead of developing a new Metal version from scratch, the developers created a conversion pathway: the program is first processed by Clang/HIP, then passed through intermediate layers such as SPIR-V, Vulkan, and MoltenVK, ultimately enabling Apple's Metal GPU to understand and efficiently execute it.
More importantly, they added no Metal-specific particle APIs at all. The application layer retains the original CUDA/HIP-style kernel calls, achieving true hardware transparency.
During this process, GPT-5.6 Sol played a crucial role by assisting in the construction of on-device memory layouts, identifying compatibility issues between MoltenVK and SPIR-V in approximately six hours, and designing appropriate workarounds.
Project link: https://github.com/mosaic-group/openfpm/pull/18
The true test of this work is a complex use case: a 3D SPH dam break simulation. This task requires simultaneously handling multiple intricate modules—including scanning, sorting and rearranging, cell and neighbor list construction, ghost particle exchange, reduction operations, and atomic operations—where any single component failure can lead to performance degradation or physical result inaccuracies.
However, the test results exceeded expectations: on Apple devices equipped with the M3 Pro chip, the task completed in approximately 6 seconds using the Metal GPU, while sequential CPU computation took about 60 seconds. This means that simply switching the computing hardware yielded a roughly 10x speed improvement, with GPU utilization nearing 100% (indicating highly efficient conversion).
More importantly, the speed improvement was not achieved at the expense of accuracy. Developers further examined the simulation results and found that the physical outcomes from the Apple GPU version and the original computation version remained consistent, with key parameters and simulation trajectories showing high similarity. This means that the Apple GPU not only ran the computations but also accurately completed the scientific computing tasks.
Developers further note that particle storage scales linearly with the number of particles N, while workloads such as neighbor search are approximately O(N·k) (where k is the number of neighbors at a fixed density). The currently demonstrated 10x speedup is based on a single-machine backend comparison. In the future, leveraging Apple’s Thunderbolt-supported RDMA technology, dynamic load balancing across multiple machines will be possible, enabling simulations to scale across multiple devices.
Of course, this breakthrough is still far from transforming the entire GPU industry. One of the biggest current limitations of Apple's Metal GPU is its insufficient support for high-precision floating-point calculations, as many professional scientific computing fields rely on double-precision operations. Therefore, NVIDIA's professional GPUs still hold an advantage in supercomputing scenarios such as weather forecasting and aerospace simulations.
However, some have questioned the value of this endeavor. One netizen remarked, “There are so many more suitable systems available—what’s the point of running this small simulation on a Mac?” The implication is that no matter how fast a MacBook’s GPU is, it was never designed for scientific computing, making this effort sound more like a display of technical prowess.
The developer’s response was candid: “The biggest benefit is that it’s fun and makes our workflow smoother.” He explained that the team’s large-scale simulations were already running on clusters, and successfully running them on Apple’s architecture confirmed that the device abstraction layer design works. A more practical reason lies in daily development—before running large simulations, developers always need to debug with smaller ones, but local debugging using a CPU is far too slow; simulation results often run into several gigabytes, making SSH transfers impractical, and remote desktops are cumbersome and inefficient. It’s simply better to run them locally. The most brilliant part? Code that works perfectly on a laptop can be deployed unchanged onto a GPU cluster and automatically scale up.
This exploration also demonstrates that the same CUDA/HIP-style algorithms can run relatively transparently on different hardware backends, such as Apple Silicon. In the future, software developers may no longer be locked into a single GPU ecosystem.
In addition, this demonstrates that AI (GPT-5.6 Sol) is transitioning from assisting with code writing to participating in foundational system design, optimization, and cross-platform engineering debugging.
Apple's GPU bridging the CUDA gap this time may just be the beginning.
Reference link: https://x.com/Abhinavsns/status/2079774018748694696
This article is from the WeChat public account "Machine Heart" (ID: almosthuman2014), authored by Machine Heart.