I've been building PCs for as long as I can remember. My first machine that I put together had an Intel Core i3-2120 and a GTX 560 Ti, essentially serving as a graduation from Lego to, well, expensive Lego. Since then, I've built or upgraded a ton of different systems for both myself and others. Over the past decade or so, the answer to a question relating to buying or building a new computer could be abstracted in the same way nearly every time: something with an x86 chip and a discrete GPU.

What's interesting is that the answer isn't as obvious anymore. My daily driver is an M4 Pro MacBook Pro, and I can count on one hand the number of times I've been unhappy with it. It handles development, writing, browsing, and the general chaos of my workday without ever making a sound. The PC in my office, on the other hand, has one job: gaming. Every other task migrated to the MacBook not because I planned it that way, but because the MacBook is simply faster, quieter, and doesn't heat up my office.

I've already talked about the case for Arm, covering licensing models and software maturity. However, on a personal level, I've tested Arm gaming myself. I've seen what's coming, and I've started to realize that the companies making x86 chips may not be structurally incentivized to compete where consumers actually need them to.

My MacBook already does everything

My PC has become a single-purpose machine

I bought my M1 Pro MacBook a few months after launch, and at the time, there were still rough edges. Some developer tools needed Rosetta 2, Docker was temperamental, and there were some workloads I still had to do on my x86 desktop. The M4 Pro I use now has basically none of those problems. Almost everything I use runs natively, and the few rough edges that existed in the M1 Pro days have mostly disappeared. I haven't heard the fans spin up in months. It's the best computer I've ever owned.

The PC still gets used, but only when I'm playing games like Counter-Strike or Valorant. I boot up the Windows machine, game, and then I'm back on the MacBook. The PC has become a very expensive, very capable console that happens to run Windows.

Plenty of people I know in tech have landed on the same split: MacBook for work, PC for games. It works really well, but it raises a question I think a lot about: if the only thing keeping me on x86 is gaming, what happens when Arm gaming catches up?

I already tested Arm gaming, and it works

Cyberpunk on an AI workstation, through two translation layers

A couple of months ago, I used the Lenovo ThinkStation PGX and tried to play games on it. It's a $3,800 AI workstation running Arm Linux with 6,144 CUDA cores (the same count as an RTX 5070) and 128GB of unified memory. The machine was designed to serve language models, not render frames, so it kind of went against the entire idea behind that chip. As a result, playing games on it felt slightly absurd.

Even getting games running on it took quite a bit of effort, requiring two translation layers. First up was FEX-Emu to translate x86 instructions to AArch64, and then Proton on top of that in order to translate Windows API calls to Linux. That's two layers of overhead on hardware that wasn't intended for gaming. If anything was going to expose the weakness of Arm gaming, this was it.

Cyberpunk 2077 ran at 1440p on max settings at a steady 50 FPS. Counter-Strike 2 averaged 117 FPS. DOOM Eternal sat between 140 and 170 FPS. System power itself was incredibly low, and for context, a desktop RTX 5070 alone has a 250W power limit which is higher than the entire TDP of the ThinkStation. However, even though it seemed the silicon wasn't intended for gaming... the RTX Spark has kinda thrown that assumption out the window.

The RTX Spark platform is built around the same GB10 Grace Blackwell class of silicon, recently announced and shipping this fall, with the same overall shape: a 20-core Arm CPU, a Blackwell GPU with up to 6,144 CUDA cores, and up to 128GB of unified memory. RTX Spark-based machines have a key difference, though: they run Windows on Arm instead, dropping Linux and, by extension, the need for Proton. x86 games may still need CPU translation through Prism unless they're ported, but it's a much cleaner path than Arm Linux running Windows games through FEX and Proton. I got to see RTX Spark gaming firsthand at this year's Computex, and the results check out: graphics workloads, shaders, ray tracing, and DLSS don't care whether the host CPU is x86 or Arm. The GPU runs its own ISA. The CPU handles game logic, physics, draw calls, and driver overhead, and Nvidia and Microsoft have been putting serious work into making sure that side holds up.

Valve, meanwhile, is investing in FEX-Emu for the Steam Frame VR headset. Microsoft also recently added AVX and AVX2 support to its Prism emulator in December, while Nvidia is shipping a full CUDA and RTX stack on Arm. All of this means that Arm gaming isn't a hypothetical anymore, and as someone who ran the benchmarks and has seen the hardware, I feel comfortable saying that there are few remaining questions. Polish, library depth, anti-cheat, and driver maturity are all I'm really wondering about now, not the more existential question of whether Arm gaming is possible at all.

That doesn't mean the gaming problem is solved. Anti-cheat is still a big question mark, as are launchers, overlays, modding tools, and older games. These are all things that have an influence on whether the game you actually play runs or not. That's especially true for someone like me, where Counter-Strike and other competitive games matter more than a curated list of single-player titles. But that's a compatibility and ecosystem problem now, not proof that Arm hardware cannot do the work.

The ISA arguments only take you so far

Arm and x86 are closer under the hood than most people realize

There's been a debate for years about whether Arm is inherently more efficient than x86, and both sides have points. Arm's fixed-width instructions make it easier to build wide front ends, which is one reason Apple and Qualcomm have been able to push very wide client cores. Apple's M4 performance core is reported to have a 10-wide decode front end, while Qualcomm's Oryon is an 8-wide design. x86 can scale too, but it tends to need more elaborate machinery: Intel's Skymont reaches a theoretical 9 instructions per cycle through three 3-wide decode clusters, while AMD's Zen 5 leans heavily on its op cache and a dual-cluster decoder arrangement.

That doesn't mean x86 is doomed; in fact, far from it. There's a tax to decoding that's a very real problem, but modern x86 cores avoid it by caching decoded micro-ops, and Chips and Cheese's Zen 5 testing mostly shows what happens when you deliberately disable one of AMD's key mitigations. Some Arm cores use decoded-instruction or op-cache-like structures too, while others lean harder on very wide decode. Decoding is expensive for everyone. The differences matter, especially in front-end-sensitive workloads like games, but they're not large enough to explain the whole Apple Silicon efficiency story by themselves.

The real argument isn't about the instruction set, but the design heritage. Arm chips grew up in phones, where every tenth of a watt matters and workloads are bursty. Apple's M-series, mostly built from the foundations of its smartphone chips, inherited that DNA. As well, the M1's performance cores had a 192KB L1 instruction cache and a 128KB L1 data cache, which is enormous by laptop standards and keeps the core fed without hitting main memory. Its unified memory architecture also means the CPU, GPU, and accelerators work from the same pool, avoiding the copies and data movement that eat power on traditional PC architectures, and dedicated media engines handle video encode and decode without spinning up general-purpose cores. The M4 Max packs two video encode engines and two ProRes accelerators, but I'm sure you get the point: none of this is about Arm instructions. Apple simply designed a chip for exactly one thing and optimized toward that goal.

However, x86 has one major downside: the chips share DNA with servers, not smartphones. AMD's Zen 5 powers everything from a thin-and-light laptop to a 192-core EPYC, and Intel also builds core families and platform IP for a similar range. Economically, this is incredibly smart: one R&D budget serves multiple markets. However, what this means is that consumer chips inherit design decisions made for data centers.

Take AVX-512, which can be extremely useful in the right workloads. Its existence reflects a throughput-heavy design priority that's easier to justify in servers and workstations, but less justifiable in a thin laptop mostly doing browser tabs, writing, and light development. Chiplet interconnects make it easy to mix compute dies for different server SKUs, but they add idle power and cross-die latency that hurt mobile efficiency. AMD's chiplet-based Dragon Range was brutally fast, but reviews also showed the tradeoff of bringing desktop-class silicon into a laptop: idle and standby behavior could get pretty ugly compared with more mobile-first designs.

That's the real core of the issue: companies building Arm chips are optimizing for the devices consumers actually use. The companies building x86 chips are often optimizing for a much broader and more profitable set of customers, and that's a bigger deal than the decode width arguments that get made.

x86 can be efficient, but the business model fights it

Lunar Lake proved the point, then Intel called it a mistake

Intel showed what was possible last year with Lunar Lake. It was a clean-sheet laptop design that ditched the server baggage, hosting on-package LPDDR5X memory instead of leaving RAM to the wider PC platform, alongside a low-power island, a system-level cache, integrated graphics, and an NPU. It didn't have AVX-512, nor did it have SMT or a chiplet interconnect. It looked more like an Apple SoC than a traditional Intel platform, but it worked. Intel managed to demonstrate just how close x86 could be to Arm.

Then Pat Gelsinger called it a "one-off" on an earnings call. "It's not a good way to run the business," he said. The reason given wasn't a technical one, though. In reality, the biggest problem was that Lunar Lake relied too heavily on TSMC and external memory partners. In other words, on a technical level, Lunar Lake was still a good platform, but it was a more bespoke, tightly integrated design that was harder to square with Intel's normal PC business model. That's a business model where margins, manufacturing strategy, supplier exposure, and platform reuse all matter. Later designs have since moved away from Lunar Lake's on-package memory approach and back toward more conventional PC memory configurations and reusable platform IP.

Intel and AMD can build efficient x86 chips. Lunar Lake proved it. But most of their margin comes from servers, not consumer laptops, and their business model depends on one architecture serving every market. Designing a consumer-first chip that can't amortize across server sales is a harder sell internally than keeping laptops competitive enough while protecting the server business. It's not that x86 is doomed, it's that chasing Apple Silicon on Apple's terms doesn't make financial sense for the companies that build x86.

Lunar Lake's Arm-like approach was the right technical answer and the wrong business one. If the efficiency path requires on-package memory, fixed platform assumptions, and abandoning the reuse of server IP, then the PC industry can't follow it without fundamentally changing what a PC is.

Your next PC might not be x86

Nvidia's RTX Spark could change everything

RTX Spark laptops and desktops are coming later this year from companies like Asus, Dell, HP, Lenovo, Microsoft, and MSI. They pack a 20-core Grace Arm CPU, a Blackwell GPU with 6,144 CUDA cores, up to 128GB of unified memory, and Nvidia's full RTX and CUDA stack, all on an Arm platform running native Windows. Adobe is working to ensure that creator tools like Photoshop and Premiere will run well on the RTX Spark and can even allow for agentic workflows to control those programs. As well, Nvidia is claiming that AAA games will run at 1440p and over 100 FPS. I haven't tested those exact numbers on that exact hardware, but I've tested, more or less, the same chip running through two translation layers. In those tests, I was able to get 50 FPS in Cyberpunk, so the claim doesn't really strike me as unrealistic. It has a clear path to running better, especially where native drivers, DLSS, and fewer translation layers help.

For me, the math has shifted. I already use an Arm machine for everything that isn't gaming, and I've tested Arm gaming on Nvidia's own silicon and it works. The GPU workloads that make up the bulk of modern game rendering are ISA-agnostic, and Nvidia is bringing its entire graphics stack to Arm. The efficiency gap isn't some fundamental law of physics, though, but a consequence of who the chips are designed for.

The companies making Arm chips typically started by optimizing for me, for you, and every other normal consumer out there, while the x86 duopoly is optimizing for data centers. It also cuts both ways: Arm SoCs are used in data centers too, but consumer-focused chips don't scale forever just because you throw more power at them. Past a certain point, you need server-first architectural decisions, and those decisions are different from the ones that make a laptop feel fast, quiet, and efficient.

Five years ago, "my next computer won't be x86" would have sounded absurd, but I don't think it would these days. I'm not totally sure desktop PCs are making the switch to Arm wholesale anytime soon, but it's never been more possible than it is now.