npu-render Runs the Windows 11 Desktop on an Intel NPU, but Only at 2–3 FPS

The short version is that it works, and it is far too slow to use as your daily desktop. The README's own verdict is that it can take over composition correctly but not yet quickly.

What the project actually is​

npu-render is not a Windows setting, and it doesn't redirect your desktop to "whatever NPU is available." The README describes a purpose-built pipeline for Intel hardware:

• The Desktop Window Manager (DWM) keeps issuing ordinary Direct3D draws.
• The project registers a display adapter whose user-mode driver records those draws into frame batches instead of executing them on the GPU.
• A worker sends the batches to the Intel NPU. They run as hand-written SHAVE rasterization and compositor kernels, delivered through OpenVINO.
• An indirect display driver puts the finished frames on the physical panel.
• A scheduled recovery task restores the normal GPU desktop on request or on any fault.

The README says the NPU driver and firmware treat the work like any other model. The trick is that the project patches its own rasterizer code into the compiled blob of a small OpenVINO operation.

What works​

The README's status line is dated 22 October 2026. It calls the project a research prototype, not a product. It says the prototype renders the real desktop for tens of minutes at a time, including Explorer, the Start menu, Notepad, WPF windows and Edge windows. Output is pixel-exact against a host reference for everything the kernel runs.

Other reported results:

• One trial ran the NPU-rendered desktop for 2,160 seconds. It covered 744 frame batches and 9,363 commands, with zero self-test mismatches.
• The longest clean admission lasted 40 minutes.
• Ordinary processes, including Explorer, Start, Notepad and WinUI apps, are admitted automatically.
• WPF and Edge are composited from their own surfaces and never open the adapter.
• Two rare compositor programs still take slower per-draw routes. One captured program is kept out entirely because its device build miscompiles.

What doesn't work yet​

The 30 Hz target is the headline miss. Tom's Hardware reports actual refresh of roughly 2 to 3 Hz. The README's responsiveness gate is marked "not met":

• 2.5 verified updates per second against a 30 Hz stimulus at 1024×768.
• Median mouse-to-display latency of 94 ms, with a 95th percentile of 1.5 seconds.
• Composition passes that include a blur can take seconds.

Recovery is also incomplete. After a session that opened application windows, the latest probe restored only 7 of 14 window placements and did not restore the foreground window. Sleep and wake are listed as open work.

The "3.4% to 0.6%" GPU figure needs context​

A Reddit post attributed to one of the developers says 3D GPU usage fell from 3.4% to 0.6%. The README confirms those numbers, but they come with qualifications:

• In the GPU-composed baseline, the 3D engine ran at 3.4%, with 2.8% of that inside DWM.
• With NPU composition, the NPU engine sat at a median of 58%. About 1.6 frames per second reached the panel.
• GPU 3D use dropped to 0.6%. Of that, 0.4% was DWM mirroring the NPU's frames to the physical panel.
• The README says DWM's GPU load is small enough that no freed GPU is measurable at this workload. It marks "GPU relief" as not demonstrated.

In other words, composition left the GPU's 3D engine. Nobody has shown that another workload, such as local AI inference, gained anything from it. The Japanese outlet PC Watch also notes that no power measurements are published.

Who can try it, and the risks​

This is not a casual download. The README lists these requirements:

• Windows 11 on a machine with an Intel NPU that OpenVINO's NPU plugin supports.
• Test-signing mode and administrator rights.
• The pinned OpenVINO SDK and WDK headers for the native build.
• A SHAVE toolchain that is not redistributed with the repository.

The authors warn to expect the desktop to switch displays and the compositor to be restarted by the recovery task. If something fails, you may have a few minutes without a usable desktop. They advise running it on a machine you can reach another way. The commands are install --prepare, enable, status and disable.

All measurements come from one Panther Lake laptop. They used NPU driver 5540 and OpenVINO 2026.4.1. Intel's download page lists NPU driver 32.0.100.5540 for Windows 11 23H2, 24H2 and 25H2. Treat the numbers as one data point. They say nothing about AMD or Qualcomm NPUs, or other Intel chips.

Why it matters, and why it doesn't yet​

My own read, and not a claim from the project, is that this is a proof of concept about plumbing, not performance. It shows the Windows compositor path can be intercepted and served by a non-GPU accelerator without apps noticing. That is a neat piece of reverse engineering. It also shows the limits of NPUs: they are built for tensor math, not blur-heavy, low-latency graphics. Per the README, the blur costs tens of microseconds per pixel on a single SHAVE.

The more practical takeaway is on the monitoring side. Windows Task Manager's NPU graph reads the same counter set the project used to prove the NPU did the work. Recent Windows 11 builds also add NPU columns to Task Manager. A June-era ElevenForum post lists builds 26100.8524, 26200.8524 and 28000.2340 for this change. So if an NPU is idle on your machine, you can now at least see why.

For now, keep your GPU on desktop duty. If you want to experiment, use a spare Panther Lake machine, not your work laptop.