@stonedFractals @Apple Here is the PR for people interested in the code: https://github.com/mosaic-group/openfpm/pull/18
Abhinavsns ports CUDA kernels to Apple Metal using GPT 5.6
A dam-break fluid simulation benchmark validated the port.
561.6K14785084.9K
Original post unavailable.
Sentiment
Many users praised the project that lets CUDA kernels run on Apple Metal GPUs via GPT assistance, calling the LLM-based approach brilliant and a big deal.
Pos
100.0%
Neg
0.0%
19 comments with sentiment.
Cluster Engagement
Digg Deeper
No Digg Deeper questions have been answered for this story yet.
Posts from X
Most Activity
Most Activity
BOOKMARKS7
RETWEETS147
We got CUDA kernels running on @Apple Metal GPUs! 🍎⚡️ Thanks to GPT 5.6 Sol, our existing CUDA/HIP-style simulation kernels in OpenFPM now directly execute on Apple Silicon GPUs. Here is how we got there, and what the first real Dam break benchmark says. 🧵
REPLIES2
@Apple I feel this is more than a Metal demo. Existing CUDA/HIP-style algorithms stay hardware-transparent while Apple Silicon becomes another backend target. Real particle simulation. Same launch sites. Matching numerics. A 10× measured speedup. 🚀
@Apple The benchmark used the same source and workload on an M3 Pro chip: Metal/GPU: ~6 seconds. Sequential/CPU: ~60 seconds 10× solver speedup end-to-end. As a bonus, GPU utilization remained at 100% indicating efficient translation. The caveat: metal only supports float precision.
@Apple A vector-add/multiply demo is easy. The real test was optimized 3D SPH dam-break example: scans, sorting/reordering, cell and neighbor lists, ghost exchange, reductions, and atomics working together in one simulation. No Metal-specific particle API was added.
@Apple Speed is irrelevant if the translation changes the physics. Both backends reached the same final simulation time and reported the same final maximum viscosity. Intermediate traces also followed closely.
How should it scale? Particle storage scales O(N). Cell/neighbor work is roughly O(N·k), with k the neighbor count at fixed density. The 10× result is a single computer backend comparison! Since apple now supports RDMA over thunderbolt, it would be fun to see dynamic load balancing in action as openfpm redistributes spatial work across multiple computers and how the scaling would hold up.
@michaeljanich @Apple Yes, but CUDA is here to stay and we are very curious about hardware agnostic HPC code.
@Abhinavsns @Apple Using LLM to write CUDA kernel for non Nvidia hardware is so brilliant. I feel @AMD and @intel should also work on making cuda drivers working on their gpus
@Abhinavsns @Apple very nice. How many tokens did it take?
@TheSocialNick @Apple Planning to write some notes around it soon. I would recommend checking out the commit and asking claude to compile and run the examples. There is also doxygen in the library https://github.com/mosaic-group/openfpm/pull/18
@Abhinavsns @Apple thats a lot of juice out of the $20 plan lol
@Abhinavsns @ljupc0 @Apple 他的效率如何與MLX比較？ 這是未來可以更有效率的接上NVIDIA GPU嗎？
@Abhinavsns @Apple Now THIS is a big deal.
@Abhinavsns @Apple That would be great for AI. Always have trouble to remove CUDA and add MPS.
@Abhinavsns @Apple @Abhinavsns Where can i learn more about the technique.
Load more posts
The idea sounds unreasonable: take the same .cu file and send it through Clang/HIP → SPIR-V → Vulkan/MoltenVK → Metal. Sol ultra took ~6 hours to build the memory layout in the devices backend, and found bugs in MoltenVK/SpirV and then built workarounds for the bugs. The build embeds and registers the SPIR-V automatically. The application keeps its existing kernel calls.