RTX 5090 and M4 MacBook Air: Can It Game?

What if you could strap a full desktop GPU to your MacBook Air? Turns out, you can. Just a quick FTC required note: When you buy through my links, I may earn a commission. As much as I hate to admit it, step one in most of my projects now is to ask AI about it. Maybe it ll tell me something I don t know. Fortunately, borderline-impractical is kind of my thing. Ok, so the plan is to plug a big PC gaming GPU, an NVIDIA RTX 5090, into my M4 MacBook Air. To do that, we plug it into a Thunderbolt dock which adapts PCIe to Thunderbolt, and we plug that into a USB-C port. Thunderbolt tunnels PCIe over a USB-C cable, so from the computer s perspective a Thunderbolt device really is a PCIe device, not a USB one. You get 4 PCIe lanes at up to 40Gbps on Thunderbolt 4, with a small performance penalty for the tunneling. USB4 includes the same PCIe tunneling as an optional feature, so some non-Thunderbolt USB4 ports can do this too. You can use this to plug a GPU into a laptop with a compatible port. Thunderbolt from the laptop plugs into the GPU dock. The GPU plugs into the monitor via DisplayPort. Shortly after this was taken, I broke this dock. From the computer s perspective, the device looks more or less like a slightly slower PCIe device, so you can usually use the same drivers you d normally use for those devices. eGPUs work pretty much out of the box on Linux and Windows. It s even possible to use one on a Raspberry Pi (albeit with Oculink, not Thunderbolt). The first hurdle is that macOS does not ship with drivers for NVIDIA or AMD GPUs on Apple Silicon. tinygrad recently released their own macOS eGPU drivers. It s a whole new AI stack with its own open source driver pipeline for NVIDIA and AMD hardware. Sadly, if your main objective is to run AI inference or play games, tinygrad probably isn t the solution you re looking for. This video by YouTuber Alex Ziskind shows that using an eGPU via tinygrad for inference is about 10 times slower than running native Metal inference directly on an M4 Pro without an eGPU. You can only use the tinygrad eGPU driver with the tinygrad stack, not for anything else. It also has very limited support for different AI models. Getting NVIDIA PTX code running on the GPU is one thing. Writing a full general-purpose display driver that works with arbitrary software is a significantly harder problem. So for now, what can you actually do with an eGPU and a Mac? Linux can run on Apple Silicon Macs now. Regrettably, at this time, the Linux kernel does not support Thunderbolt on Apple Silicon (only internal devices and USB3). But You can run Linux in a 64-bit ARM VM on a macOS host. macOS supports Thunderbolt devices. Linux supports NVIDIA GPUs. Let s put the pieces together and pass through the GPU into the Linux VM. At a high level, we re just going to put the GPU in the Linux VM. The VM is the same architecture as the Mac host (arm64), so performance should be comparable. Of course, the devil is in the details. There is no driver for NVIDIA cards on ARM64 Windows. That s why we use Linux. For a quick video demo of the result, take a look: In the rest of the post, I ll go through the long and winding road of getting this to actually work. If you just want to see screenshots and benchmarks, you can probably skip to the benchmark section. Let s look at two things we need working for the VM to talk to the PCI device: PCI BAR (Base Address Registers) - Each PCI device communicates through chunks of memory that the computer can read and write to. There s basically a reserved region of memory on your computer for each device. Those memory regions have to be mirrored into the VM for PCI passthrough to work. DMA (Direct Memory Access) - This is how the device can read and write information directly in/out of your computer s memory. Instead of having the CPU burn cycles copying data from the device, the device can copy the memory automatically. For a GPU, it might be used to copy textures directly from the computer s memory into its own video memory. When QEMU starts a VM, it sets up the guest s memory layout. For normal RAM, this boils down to a call to hvf_set_phys_mem() in QEMU, which uses the Hypervisor.framework method: hv_vm_map(mem, guest_physical_address, size, HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC); Next, we connect to the host PCIDriverKit driver and ask to map the memory from the PCI device into our process. (I m leaving the driver-side code out for now, but it s very similar boilerplate.) // map BAR0 into the current process and set `addr` to the location // where it was mapped mach_vm_address_t addr = 0; mach_vm_size_t size = 0; IOConnectMapMemory64(driverConnection, 0, mach_task_self(), &addr, &size, kIOMapAnywhere); Ok, so then we have addr, which now points to the BAR0 memory that we can access directly in our process. At this point you can just read and write stuff to it, like any other piece of memory. volatile uint32_t *bar0 = (volatile uint3

RTX 5090 and M4 MacBook Air: Can It Game?

Key takeaways

More in computer-science