MCDMA | Metal CUDA Direct Memory Access 🚀
If you have a Spark and an Apple Silicon Mac, MCDMA gives you a direct RDMA path between CUDA memory and Metal-side unified memory over USB-C.
Registered memory, rkeys, one-sided READ/WRITE, two-sided SEND/RECV with credit flow control. Same verbs both ways, no master/slave. The Mac writes straight into CUDA-mapped memory on the Spark, and the Spark writes straight back into Mac memory.
My setup takes it a little further:
Spark 1 ⇄ CX7 ⇄ Spark 2 (prompt processing)
Spark 1 ⇄ USB-C ⇄ Mac Studio (Decode)
Spark 2 ⇄ USB-C ⇄ Mac Studio (Decode)
Two independent MCDMA USBC links, so the Studio isn't stuck behind one cable; both Sparks move data concurrently, and it writes results back into either.
Measured, every byte delivery verified:
• 939 MB/s single link
• 1.80 GB/s Mac → both Sparks, concurrent
• 1.25 GB/s both Sparks → Mac, concurrent
• 24 µs round-trip, 41k msg/s small-message
One Spark + One Mac works. Two is just how I'm using it: DeepSeek prompt processing across the Sparks, decode on the Studio.
Benchmarks, tests, Open Source, and write-up this week.
@NVIDIARTXSpark@NVIDIAAI@NaderLikeLadder@msharmavikram There’s still a lot of performance headroom here. If the currently locked USB4 controller can be allowed to train at full capability, I’d love to test how far we can push this. Please check your DMs.
@nickarner My .claude and .codex directories have grown to 120gb+ of logs images artifacts etc which slows everything. wish they offered an easy solution to archive automation