M4 맥북 에어에 RTX 5090을 연결한다면?

Table of Contents Never tell me the odds What&rsquo;s a Thunderbolt eGPU? What about tinygrad? The existing Linux driver Engineering PCI Passthrough on macOS PCI device basics Mapping PCI BARs DMA DMA on Apple Silicon apple-dma-pci NVIDIA alignment quirk Coalescing mappings Other performance concerns Scheduling Total store ordering Benchmarks CPU comparison Cyberpunk 2077 720p Low 1080p 4K Takeaways GravityMark Shadow of the Tomb Raider Horizon Zero Dawn Remastered Doom (2016) Can it run Crysis? AI Inference Qwen 3.6 Gemma 4 Can I run this? Get notified Conclusion Follow-on Credits 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. Never tell me the odds # As much as I hate to admit it, step one in most of my projects now is to ask AI about it. Maybe it&rsquo;ll tell me something I don&rsquo;t know. Fortunately, borderline-impractical is kind of my thing. What&rsquo;s a Thunderbolt eGPU? # 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&rsquo;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. From the computer&rsquo;s perspective, the device looks more or less like a slightly slower PCIe device, so you can usually use the same drivers you&rsquo;d normally use for those devices. eGPUs work pretty much out of the box on Linux and Windows. It&rsquo;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. What about tinygrad? # tinygrad recently released their own macOS eGPU drivers . It&rsquo;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&rsquo;t the solution you&rsquo;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? The existing Linux driver # 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&mldr; You can run Linux in a 64-bit ARM VM on a macOS host. macOS supports Thunderbolt devices. Linux supports NVIDIA GPUs. Let&rsquo;s put the pieces together and pass through the GPU into the Linux VM. At a high level, we&rsquo;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&rsquo;s why we use Linux. For a quick video demo of the result, take a look: In the rest of the post, I&rsquo;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 . Engineering PCI Passthrough on macOS # PCI device basics # Let&rsquo;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&rsquo;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&rsquo;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&rsquo;s memory into its own video memory. Mapping PCI BARs # When QEMU starts a VM, it sets up the guest&rsquo;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&rsquo;m leaving the driver-side code out for now, but it&rsquo;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 uint32_t * )addr; printf ( &#34;BAR0[0] = %x \n &#34; , bar0[ 0 ]); // this would output: BAR0[0] = 0x1b2000a1 // which is a device-specific constant that describes my RTX 5090 // // BAR0[0] is the BOOT_0 register. The fields break down as: // arch = 0x1b → GB200 GPU family // impl = 0x2 → GB202 die (RTX 5090) // major_rev = 0xa → stepping A // minor_rev = 0x1 → revision 1 (together: stepping A1) Now we just make sure QEMU calls hvf_set_phys_mem() for our device memory, and we can map that into the guest. When guest code touches that mapping, it talks directly to the GPU with minimal host overhead. This is the best case for performance. At least, in theory. In practice, as soon as the VM touched the PCI BAR memory, the host kernel crashed. If you&rsquo;ve never experienced this before, it&rsquo;s disorienting. Your entire computer will hang, and because the trackpad feedback is controlled by software, suddenly the trackpad will no longer click. The dogs and cats in your neighborhood start howling. Pictures fall off the walls of your house. Eventually your computer will reboot, and you will be presented with this dialog. Ok, so we can&rsquo;t map device memory directly, but we have other tricks up our sleeve. We can trap every access to the memory, exit the guest back into QEMU, and have QEMU forward each read or write to the device. That keeps behavior correct, but it&rsquo;s brutally slow. In many workloads the pain is elsewhere. Most of the performance-sensitive work is DMA, but some paths still care how fast you can push commands through the BAR. I started preparing a bug report for Apple and wrote a small reproduction (well, AI-assisted) to demonstrate the issue: #include <Hypervisor/Hypervisor.h> #include <IOKit/IOMapTypes.h> #include <libkern/OSCacheControl.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #define FAIL(code) do { result->status = (code); goto cleanup; } while (0) #define HV_CHECK(expr, code) do { \ if ((expr) != HV_SUCCESS) FAIL(code); \ } while (0) #define PREFETCHABLE_MASK 0x08 #define SELECTOR_GET_BAR_INFO 10 #define GUEST_CODE_IPA 0x4000ULL #define GUEST_BAR_IPA 0x10000000ULL static const uint32_t prog_read[] = { 0xf9400001 , /* ldr x1, [x0] */ 0xd4000002 , /* hvc #0 */ 0xd4200000