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

121–130 of 195 posts

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

#121

Post by aviinuo »

Melatonic wrote: post #114
ademeure wrote: post #58

Earlier quoted context omitted.

Apple GPUs didn’t have tensor cores until the M5 (aka “a neural accelerator in each core”) and in the article’s charts that a M5 Pro significantly beats a M4 Max (while in other workloads it would be much smaller since Pro is ~1/2 Max). EDIT: since Aurornis beat me by 3 minutes, I’ll add another interesting tidbit instead :) NVIDIA tensor cores on consumer GPUs are massively less powerful per SM core than on their da…

Does that include stuff like the Pro Blackwell 6000? Or are the tensor cores as good per SM comparably? They perform quite well on many tests

Pro Blackwell 6000 is just a 5090 with more VRAM. It does not have the tcgen05 (5th gen tensor core) instructions despite the "5th gen tensor core) branding and thus do not support any optimized Blackwell (sm100) kernels.

Every Blackwell card other than the (G)B100, (G)B200, (G)B300 and Jetson Thor, use the Ampere tensor core instruction (mma.sync) but with fp4/6/8 added on. Beyond that the DGX Spark (which is advertised as having the same architecture as B200) has especially weak (not tcgen05) tensor cores that have a very narrow operating window and low utilization.

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

#123

Post by hacker_mar »

bigyabai wrote: post #99
lowbloodsugar wrote: post #85

Earlier quoted context omitted.

Just built a workstation with an older Threadripper Pro. It has 128 PCIE lanes, for 7 16-lane PCIE slots. An egpu has 4. I have one GPU, at x16, and I can add more. Most people don't need that, but most people don't need an eGPU either. The number of gamers who would switch to Macbook+eGPU is negligible. It's just not compelling. For LLMs, hanging a 5090 off the thunderbolt port makes prompt processing fast, but I wi…

> The number of gamers who would switch to Macbook+eGPU is negligible. It's just not compelling. This. eGPUs fade in and out of relevance every few years, and even back in the Intel Macbook days there were people advocating for eGPU gaming with Bootcamp. It was a terrible solution, there is every reason to avoid macOS with a dGPU when you have something like Linux or even Windows as an alternative.

[dead]

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

#124

Post by [deleted] »

arjie wrote: post #74

Wait, this is incredible. I have a spare 5090 lying around and run a claw-like on my M4 Mini. Just plugging it into some sort of 3D print frame for stability and plugging it into the TB port might get me a pretty viable tool for local inference. Would need something neat to ensure the power etc. is well fed. The problem is `max-num-seqs` and `max-model-len` fight each other, and unless you're in the pure single-clien…

[deleted]

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

#126

Post by SilentM68 »

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!

In your view why have they refused to implement a "Linux VM and pass through the GPU that goes inside the case?"

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

#127

Post by codebje »

mikae1 wrote: post #104
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…

>> This project requires a special entitlement from Apple. I’ve requested it, and heard they may be open to granting it, but I have not yet heard back, and I’m told that the wait time could be months. > I have been bothering the VM team for years for VM GPU pass through. Good luck. I'm sure they're keen on giving people access to this so that people can spend their money on NVIDIA GPUs instead of buying more expensiv…

There isn't a more expensive Mac option to buy if what you're after is a gaming GPU. It's more likely that the VM team sees this as a very low benefit ticket to pursue given the tiny segment of Mac gamers hoping to improve their options with a Linux VM for gaming.

(Meanwhile, I'm recompiling Wine to see if I can patch it to address an issue that was hotfixed in Proton two weeks ago but isn't in a CrossOver build yet, so yeah, there's maybe some arguments to be made here that I'd be a potential beneficiary. If I weren't too cheap to spring for an eGPU in today's market, anyway.)

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

#128

Post by m132 »

mikae1 wrote: post #104
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…

>> This project requires a special entitlement from Apple. I’ve requested it, and heard they may be open to granting it, but I have not yet heard back, and I’m told that the wait time could be months. > I have been bothering the VM team for years for VM GPU pass through. Good luck. I'm sure they're keen on giving people access to this so that people can spend their money on NVIDIA GPUs instead of buying more expensiv…

The entitlement in question is the standard `com.apple.developer.driverkit.transport.pci` [0], required for anything that touches the PCIe bus [1]. Apple is generally restrictive with how much third-party applications can do on machines with SIP/"full security", so I'm not exactly surprised. It's not an Apple-private entitlement, however.

The VFIO-style driver made by the author of this also appears generic enough to support all kinds of PCIe, not just GPUs. Apple might find a way to weasel out of this ("hey, this is for hardware companies and you don't seem to be affiliated with one", "your driver requests too broad access", etc.) if there really is a conflict of interest, but so far, there's a chance it will just get rubber-stamped.

I can see them rejecting it for legitimate reasons, though, at least as far as "legitimate" with Apple goes. This driver is essentially a thin layer over PCIDriverKit, exposing all functionality that's supposed to be behind the entitlement to arbitrary applications, in similar fashion to WinRing0. They probably didn't come up with all this bureaucracy only to sign something like that in the end. We'll see what happens.

[0] https://github.com/scottjg/qemu-vfio-apple/blob/84ecdcf5db6b...

[1] https://developer.apple.com/documentation/pcidriverkit/creat...

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

#130

Post by m132 »

scottjg wrote: post #83
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!

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 Virtualization.framework you're thinking of might actually just be paravirualization, at least that's what the name suggests. It's implemented in the public ParavirtualizedGraphics framework [0], albeit for PG on Arm macOS, the relevant interfaces are private [1]. I haven't looked that deep into it per se, but, fixing the bugs around it, I've run into a few clues suggesting that it's just a command stream + shared memory being passed around. It also uses its own generic driver on the guest side.

Great job, by the way! Love how authors of pieces like this casually come here to comment :)

[0] https://developer.apple.com/documentation/paravirtualizedgra...

[1] https://github.com/qemu/qemu/blob/edcc429e9e41a8e0e415dcdab6...

Post reply on HN