For years, Windows on Arm PCs have been locked out of high-end desktop graphics because Nvidia never shipped a public GeForce driver compiled for Arm processors. That barrier cracked this week when a developer managed to boot Windows 11 on an unsupported Huawei workstation with a desktop RTX 4060, leveraging a driver extracted from Nvidia’s unannounced RTX Spark software stack. The result is raw—performance hovers around 20 to 25 frames per second in games, and the system can’t drive a physical monitor—but it’s the first concrete proof that a powerful discrete GPU can accelerate DirectX 12 and Vulkan workloads on Windows Arm silicon.
The Hack: How a Kunpeng Workstation Got RTX 4060 Gaming
The experiment, first reported by Windows Latest, centered on a Huawei Qingyun W510 desktop powered by the Arm-based Kunpeng 920 processor. That chip, originally designed for Linux servers, was never meant to run Windows, let alone a modern GeForce card. The developer paired it with an RTX 4060 (8GB VRAM) connected over a PCIe 4.0 x8 link—the card’s native bus width—and installed 32GB of DDR4 memory.
Two monumental obstacles stood in the way. First, the machine’s firmware, specifically its ACPI tables, didn’t speak Windows. Microsoft’s OS relies on these tables to understand the hardware layout, power management, and interrupt routing. Without compatible tables, Windows can’t boot. The developer used an open-source patch to rewrite the ACPI data, essentially translating the platform for Windows 11 on Arm. This alone was an unsupported feat that risks boot instability or silent power management failures.
Second, no public Nvidia GeForce driver exists for Arm64 Windows. User-mode x64 apps can be translated by Microsoft’s Prism emulator, but kernel-level graphics drivers must be native. The developer solved this by extracting a native Arm64 Nvidia driver from RTX Spark, Nvidia’s upcoming integrated platform for Arm PCs that pairs custom CPUs with RTX graphics. After installing that driver, Windows recognized the RTX 4060, loaded the driver, and exposed DirectX 12, Vulkan, and hardware acceleration. The driver passed Windows’ security checks, indicating the files retained valid signing—a promising sign for compatibility, though entirely unsupported.
The Immediate Picture: Games Run, but Barely
The graphical victory is a technical one, not a smooth gaming experience. Testing revealed a processor crippled by translation overhead and weak single-core performance. Genshin Impact at 1080p averaged 20 FPS. The Black Myth: Wukong benchmark hovered between 20 and 25 FPS. A Star Wars Reflections demo managed 23–25 FPS. One test failed to enable ray tracing, likely due to a driver compliance issue. These numbers don't reflect the RTX 4060’s capability; in a conventional x86 desktop, the card easily triples those framerates.
The true bottleneck is the Kunpeng 920 CPU. Almost all Windows games are compiled for x86 or x64, forcing Prism to translate instructions in real time. The Kunpeng’s core architecture, optimized for throughput rather than the bursty single-threaded demands of game engines, compounds the problem. The GPU spent much of its time waiting for the processor to feed it commands—classic CPU-bound behavior. Without detailed telemetry on GPU utilization, it’s impossible to know how much of the performance gap comes from translation, from the Kunpeng chip itself, or from driver inefficiencies. But the fact that frames rendered at all on this alien hardware stack is what matters.
The most glaring limitation: no direct monitor output. The RTX 4060 couldn’t send a signal to a physical display because the motherboard lacks proper Windows display drivers, and the firmware modifications didn’t enable display routing. Instead, the developer used Sunshine (host) and Moonlight (client) to stream the desktop and games over a network. That adds compression, latency, and encoding overhead—yet another variable skewing performance numbers. It also means this setup isn’t a traditional PC experience; you’d need a second device just to see what the GPU renders.
What This Means for Everyday Users and Enthusiasts
For the average home user, this hack is a curiosity, not a roadmap. Do not attempt to replicate it on your daily driver. Installing an unsupported driver extracted from a pre-release platform, coupled with firmware patches that could corrupt power management, invites crashes, security holes, and guaranteed zero support from Nvidia or Microsoft. Even if you somehow booted, the unusable frame rates and lack of monitor output make it a non-starter for gaming or creative work.
Enthusiasts and tinkerers, however, have a reason to pay close attention. The experiment demonstrates that Nvidia’s modern GPU driver architecture can initialize a desktop RTX card on an Arm machine without custom silicon. The extracted driver reportedly draws from Nvidia’s unified codebase, meaning it could theoretically support other RTX 20, 30, 40, and 50 series cards. If the community can refine ACPI patches and address the display pipeline, we might see headless GPU nodes for rendering or AI inference on inexpensive Arm workstations.
For developers, this is a concrete signal to start considering native Arm64 builds for GPU-accelerated applications. The presence of DirectX 12 and Vulkan on an Arm host hints that graphics middleware, game engines, and professional tools could eventually target Windows on Arm without sacrificing discrete GPU performance. Microsoft’s Arm64EC technology already allows incremental migration of x64 code to native Arm64, and a fully functional Nvidia driver would remove the last major hardware excuse for sticking to Intel or AMD.
IT administrators and enterprise planners should note the potential for modular Arm desktops. Today’s Windows on Arm devices are almost entirely sealed laptops with integrated graphics. If Nvidia releases a general-purpose GeForce Arm64 driver, businesses could deploy compact Arm workstations with replaceable GPUs for CAD, simulation, or machine learning—areas where CUDA and Tensor cores shine. But that requires official support, validated firmware, and lifecycle guarantees. The hacked driver, however technically adept, cannot serve as a deployment baseline.
The Long Road to a Discrete GPU on Windows Arm
Windows on Arm has spent a decade trying to escape its “appliance” image. When Microsoft launched the Surface Pro X in 2019, the operating system could translate many x86 apps but not x64 ones, and the only graphics option was Qualcomm’s integrated Adreno GPU. Prism, introduced with Windows 11 24H2, finally brought x64 emulation with acceptable performance, and a wave of native Arm apps followed—browsers, Office, Photoshop, Visual Studio. Yet the GPU story remained stagnant.
The core challenge is architectural: a graphics driver is a kernel component that talks directly to hardware. Unlike an application, it cannot be emulated. Nvidia’s Windows driver is a massive, complex piece of software with decades of x86 optimization. Porting it to Arm64 required both engineering effort and a business case. For years, the installed base of Windows Arm PCs was too small to justify that investment.
Nvidia’s RTX Spark, announced in May 2026 in collaboration with MediaTek and Microsoft, finally provided both. The program promises a new class of Arm-based PCs with custom Nvidia-designed processors, full Windows 11 compatibility, and native RTX graphics. Crucially, it includes an Arm64 Nvidia driver stack built from the ground up for this platform. While RTX Spark devices won’t ship until 2027, the driver’s existence is what the Huawei hack exploits.
This isn’t the first time community ingenuity has pushed Windows on Arm forward. Enthusiasts previously booted Windows 10 on Raspberry Pi 4 using unofficial drivers, and various GitHub projects have patched ACPI tables for other unsupported Arm boards. But those efforts generally stopped at basic display output. The RTX 4060 experiment is the first to demonstrate modern gaming APIs with a discrete GPU, and it relies on a driver that—while not public—was built by Nvidia itself for Windows Arm, not reverse-engineered.
Steps You Should Take Now (And Steps to Avoid)
If you’re tempted by the headlines, here are the only sensible actions right now:
- Wait for official RTX Spark devices. Nvidia, MediaTek, and Microsoft have committed to a product lineup that will bring native Arm64 GeForce drivers, validated firmware, and full display support. That’s the path to a reliable Arm gaming or workstation PC.
- Don’t attempt the hack on a production machine. Mismatched ACPI tables can brick a system or cause erratic behavior. The driver is not licensed for redistribution, and future Windows updates could break the configuration permanently. Corporate IT policies would almost certainly flag the modified firmware as a security violation.
- Follow developer channels. If you’re an engineer or creator, keep an eye on Nvidia’s CUDA toolkit for Windows Arm. Official CUDA support would be a far stronger signal than a one-off gaming test. Nvidia hasn’t announced a timeline, but the RTX Spark kernel driver presumably includes compute capabilities that could be exposed later.
- Give feedback to Microsoft and Nvidia. Both companies are gauging interest in modular Arm hardware. If you want to see a general public GeForce Arm64 driver, vocal but realistic community demand can influence product decisions. Don’t spam; participate thoughtfully in official forums and developer programs.
Most importantly, don’t mistake this proof-of-concept for a supported upgrade. The developer behind the experiment disclaimed that the system is suitable only for streaming, not as a daily driver. That’s an honest assessment.
The Future: Why This Hack Matters Beyond Bad Frame Rates
The RTX 4060 on Kunpeng 920 isn’t a product; it’s a weather vane. It shows which way the wind is blowing for Windows on Arm hardware diversity. Nvidia’s driver architecture is more portable than the company’s official support lists imply. That portability, once RTX Spark formalizes it, could rapidly expand the Arm PC ecosystem in three critical directions:
- Modular desktops. Replaceable GPUs are the hallmark of PC gaming and professional computing. If Nvidia opens its Arm64 driver to standard GeForce cards, system builders can offer Arm workstations with the same upgrade freedom as x86 towers. This would put pressure on AMD to release Radeon Arm64 drivers and force Qualcomm to enable PCIe connectivity on future Snapdragon desktop chips.
- Native Arm gaming. The current performance bottleneck is almost entirely the CPU and translation layer, not the GPU. A purpose-built Arm processor with high single-threaded performance—like Nvidia’s rumored RTX Spark chip—paired with native Arm64 games could deliver framerates comparable to x86. The hack proves the graphics stack is ready; the rest is silicon and software maturity.
- CUDA and AI at the edge. For developers working on edge AI, robotics, or scientific computing, a Windows Arm machine with a CUDA-capable GPU is a compelling target. Many Arm-based devices already run Linux with Nvidia Jetson modules. Windows versions would open the door to familiar enterprise tooling, DirectML acceleration, and unified development environments.
The experiment also amplifies the competitive dynamics among chipmakers. Qualcomm’s Snapdragon X Elite has established Arm as a legitimate laptop contender, but its integrated Adreno GPU remains miles behind desktop GeForce and Radeon cards. Nvidia’s entry threatens to make Qualcomm’s premium positioning uncomfortable if customers start demanding discrete graphics. Intel and AMD, meanwhile, must contend with the possibility that GPU brand loyalty—especially around CUDA and DLSS—could entice users to switch CPU architectures entirely.
For now, the hacked RTX 4060 is a brilliant, unsupported anomaly. The real test begins when official RTX Spark PCs land on shelves. Those systems will reveal whether Nvidia intends to keep its Arm64 driver exclusive to its own platform or let the broader Windows ecosystem share in the benefits. Until then, the most important takeaway is that the wall between desktop Nvidia GPUs and Windows on Arm was never a fundamental technological barrier—it was a business decision waiting to be rewritten.