A piece of CUDA source code is running on Apple GPU.

A computing program originally designed for NVIDIA CUDA can run directly on an Apple device equipped with M3 Pro with almost no modification to its kernel code.

This is a progress announced by X user @Abhinav yesterday. What is more surprising is that it is not a simple demonstration of "vector addition, subtraction, multiplication and division", but achieves an approximately 10x speedup in the real 3D fluid simulation task.

Behind this incident, there is a special participant — GPT-5.6 Sol.

The incident took place on the open-source scientific computing platform OpenFPM. Researchers have been working on something that many people considered "unlikely": enabling high-performance computing programs originally designed for CUDA/HIP GPUs to cross platform barriers and run on Apple's own Metal GPU architecture.

Why is this so difficult? Over the past decade, the GPU computing field has been highly fragmented — NVIDIA has CUDA, AMD has HIP, and Apple has Metal. These ecosystems are like different languages and are incompatible with each other. A program written in CUDA usually requires a lot of rewriting to run on other platforms.

But this time, instead of redeveloping a Metal version, the developer built a conversion channel: the program is first processed by Clang/HIP, then goes through intermediate layers such as SPIR-V, Vulkan, and MoltenVK, so that Apple Metal GPUs can finally understand and execute it efficiently.

More importantly, they did not add any Metal-specific particle APIs at all. The application layer still retains the original CUDA/HIP-style kernel calls, achieving true hardware transparency.

In this process, GPT-5.6 Sol played a key role. It helped complete the construction of the device-side memory layout, discovered compatibility issues in MoltenVK and SPIR-V in about 6 hours, and designed corresponding workarounds.

Project link: https://github.com/mosaic-group/openfpm/pull/18

The real test of this work is a complex test case — 3D SPH dam break simulation. This task needs to process multiple complex modules at the same time, including scanning, sorting and rearrangement, cell and neighbor list construction, ghost particle exchange, reduction operations, and atomic operations. Any problem in any link will lead to performance degradation or deviation of physical results.

But the test results exceeded expectations. On an Apple device equipped with an M3 Pro chip, it takes about 6 seconds to run with a Metal GPU; it takes about 60 seconds to run with sequential CPU computing. That is to say, for the same program, simply changing the computing hardware achieves an approximately 10x speedup, and the GPU utilization rate is close to 100% (indicating a very high conversion efficiency).

More importantly, the speedup does not come at the cost of accuracy. The developer further inspected the simulation results and found that the Apple GPU version and the original computing version finally obtained consistent physical results, with highly close key parameters and simulation trajectories. This means that the Apple GPU not only runs the program, but also truly completes the scientific computing task.

The developer further pointed out that particle storage grows linearly with the number of particles N, while the workload such as neighbor search is roughly O(N・k) (k is the number of neighbors at a fixed density). The 10x speedup demonstrated so far is the result of a single-machine backend comparison. In the future, with the help of RDMA technology supported by Apple Thunderbolt, dynamic load balancing across multiple machines can also be realized, allowing the simulation to scale on multiple devices.

Of course, this breakthrough is still far from changing the entire GPU industry. Currently, one of the biggest limitations of Apple Metal GPUs is the insufficient support for high-precision floating-point computing, while 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 simulation.

However, some people have questioned the significance of this exploration. One netizen said: "There are obviously so many more suitable systems on the market. What is the point of running this small simulation on a Mac?" The implication is that no matter how fast a MacBook's GPU is, it is not designed for scientific computing after all, and this incident sounds more like a show of skills.

The developer's response was quite frank: "The biggest use is that it's fun, and it makes work smoother." He explained that the team's large-scale simulations already run on the cluster, and the fact that this time they can run successfully on the Apple architecture just verifies that the design of the device abstraction layer is valid. A more practical reason lies in daily development — before running a large simulation, you always need to debug with a small simulation first, and local debugging relying on the CPU is really too slow; the simulation results are often several GB in size, which cannot be transferred back via SSH, and remote desktops are cumbersome and difficult to use, so it is better to run directly locally. The most wonderful part is that the code that has been debugged on the laptop can be placed on the GPU cluster as it is, and it will automatically scale up.

This exploration also proves that the same set of 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 tied to a single GPU ecosystem.

In addition, this also shows that AI (GPT-5.6 Sol) is moving from "helping write code" to a new stage of "participating in underlying system design, optimization, and cross-platform engineering debugging".

This time Apple's GPU crossing the CUDA gap may just be the beginning.

Reference link: https://x.com/Abhinavsns/status/2079774018748694696

This article is from the WeChat official account "JI QI ZHI XIN" (ID: almosthuman2014), written by JI QI ZHI XIN, and published with authorization from 36Kr.