Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RTX 5090 and M4 MacBook Air: Can It Game?

scottjg.com

Post reply on HN
Print view View original

131–140 of 195 posts

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#131

Post by scottjg »

falcor84 wrote: post #13
moralestapia wrote: post #3

Wow, phenomenal project and write-up, thanks for sharing it. "no - not in any practical sense today, and "maybe" only in a very deep, borderline-impractical research sense." This is why humans will always rule over crappy LLMs.

Wait, why? This is exactly what I as a human would have said in this situation. Or if you're referring to how the OP still decided to go ahead, I've seen AIs go ahead on impractical courses of action many times, and surprisingly succeed on some of them.

in fairness to the LLM critics, every time i ran into a minor speed bump in this project, it told me it probably just wasn't possible to get it to work well. the LLM did pretty actively discourage me from trying to get the whole thing working.

that said, since i was willing to ignore that aspect of it, it did accelerate getting the work done by a lot. it seems like it understands system programming really well, and did a good job navigating the qemu codebase. i have ~20 years of systems programming experience so i already knew what had to be done here. it didn't really guide the project much, but it did write a lot of the code.

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#132

Post by monocasa »

m132 wrote: post #50
matthewfcarlson wrote: post #19

I have been bothering the VM team for years for VM GPU pass through. I worked on the Apple Silicon Mac Pro and it would have made way more sense if you could run a linux VM and pass through the GPU that goes inside the case! Sadly, as you can tell, they have not taken me up on my requests. Awesome that other people got it working!

It looks like the pass through part here was implemented using standard DriverKit interfaces, if I'm not mistaken. That is, the PCIe BAR can already be mapped from the user-space, without any extra modifications to macOS. It's just a matter of VMMs, such as QEMU, adopting this interface in addition to Linux VFIO and the like (unless you're talking about Virtualization.framework, which is kind of a VMM of its own). Wh…

Isn't driverkit essentially a separate user space stack compared to regular code? I remember seeing the driverkit specific dyld caches in macos root partition images that included their own copies of everything down to libsystem. Getting driverkit code to run in the same process as normal user code seems like it'd be quite an uphill battle.

Presumably with the right entitlements you can just hit the same (presumably IOKit) syscalls that driverkit does. But that's an extra layer of reverse engineering, and you're not really using driverkit anymore.

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#134

Post by firecall »

runjake wrote: post #111
brcmthrowaway wrote: post #37

Earlier quoted context omitted.

I still believe the lack of NVIDIA GPU support in the Mac Pro will go down as one of the greatest missed opportunities in tech. Anyway, the Mac Pro is dead now. There's only so much sales audio and video professionals can provide.

There was some bad history between Apple and Nvidia. Perhaps with a new generation of leadership at Apple things might change. https://www.reddit.com/r/hardware/comments/1hmgmuf/apples_hi...

Maybe with Tim and Jensen going on holiday together in China, the relationship might be healed somewhat.

Things have moved on since the days where GPUs in Macs were a priority.

But then the AI race has changed things. So who knows - maybe we will one day see official eGPU support from Apple and new drivers from nVidia. Wouldn't put on money on it though....

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#135

Post by scottjg »

m132 wrote: post #130
scottjg wrote: post #83

Earlier quoted context omitted.

two semi interesting things to note around this: 1. Virtualization.framework seems to support some form of GPU passthrough from the host (granted, not eGPU - it's for the integrated GPU). I think the primary use case is having macOS guests get acceleration, while still sharing GPU time with the host. There is also a patch that recently hit QEMU mainline that supports using the "venus server" with virtio-gpu to suppor…

I experimented with booting Arm macOS 14-26 in QEMU a while back, building on the work of Alexander Graf for macOS 12-13, and reverse-engineered substantial parts of Hypervisor.framework, the in-kernel hypervisor, and a bit of Virtualization.framework. Got newer versions of Sequoia to boot past the log in screen, with GPU acceleration too. Unless there's another method I missed, the internal GPU "pass through" of Vir…

thanks!

there also appears to be a generic pci passthrough path. we were discussing it on the qemu-devel list: https://lore.kernel.org/qemu-devel/C35B5E97-73F2-4A60-951B-B...

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#136

Post by m132 »

scottjg wrote: post #135
m132 wrote: post #130

Earlier quoted context omitted.

I experimented with booting Arm macOS 14-26 in QEMU a while back, building on the work of Alexander Graf for macOS 12-13, and reverse-engineered substantial parts of Hypervisor.framework, the in-kernel hypervisor, and a bit of Virtualization.framework. Got newer versions of Sequoia to boot past the log in screen, with GPU acceleration too. Unless there's another method I missed, the internal GPU "pass through" of Vir…

thanks! there also appears to be a generic pci passthrough path. we were discussing it on the qemu-devel list: https://lore.kernel.org/qemu-devel/C35B5E97-73F2-4A60-951B-B...

Oh, thanks for letting me know, and for the upstreaming work too! I might join the party once I find some more time :)

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#138

Post by nothinkjustai »

linkregister wrote: post #49
nothinkjustai wrote: post #22

> 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. It’s these people, not the ones who refuse to use LLMs, who are as they say, “cooked”.

The author of the blog is not cooked; they're raw. Their inventive, multi-chain setup was tuff. Their PCI passthrough and qemu patches were straight fire. Unless you can point to something you've done this impressive, you're just an unc bro.

Fuck you got me there. Unc out

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#139

Post by scottjg »

geerlingguy wrote: post #97

I came into the post thinking it would be running a VM through the slow tinygrad driver... but this is much, much better. It'd be amazing if Apple would provide better support, and allow more than that 1.5 GB window to make this easier. Arm overall has some quirks with PCIe devices, but at least in Linux, it's gotten so much easier since most modern drivers treat arm64 as a first class citizen.

i don't know for sure, but i suspect what makes the tinygrad stuff slow isn't the macos host driver itself. i think they're doing something very similar to what i'm doing, which is just mapping the PCI BARs to userspace, then they have a bunch of python code that drives the GPU.

this is only speculation, but i think the big thing that makes tinygrad slow is that the tinygrad inference engine has not really been optimized much for all these open LLM models. probably most of the work has gone towards optimizing the stack for george's self-driving hardware company. since you can't just run the existing CUDA kernels on their engine, that makes things a lot tougher, engineering-wise.

i am actually curious if my project could share a macos host driver with them. i think it would need some changes, but it seems like there's a lot of overlap

Re: RTX 5090 and M4 MacBook Air: Can It Game?

#140

Post by scottjg »

monocasa wrote: post #132
m132 wrote: post #50

Earlier quoted context omitted.

It looks like the pass through part here was implemented using standard DriverKit interfaces, if I'm not mistaken. That is, the PCIe BAR can already be mapped from the user-space, without any extra modifications to macOS. It's just a matter of VMMs, such as QEMU, adopting this interface in addition to Linux VFIO and the like (unless you're talking about Virtualization.framework, which is kind of a VMM of its own). Wh…

Isn't driverkit essentially a separate user space stack compared to regular code? I remember seeing the driverkit specific dyld caches in macos root partition images that included their own copies of everything down to libsystem. Getting driverkit code to run in the same process as normal user code seems like it'd be quite an uphill battle. Presumably with the right entitlements you can just hit the same (presumably…

it is a separate stack, but that probably doesn't matter much. a user process (in my case, qemu) can communicate with a driverkit driver. the user process can also map memory through the driver, which is how this pci passthrough system works.

i don't think the issues with the project really are specific to driverkit.

Post reply on HN