Npunlock runs custom C kernels on Intel Meteor Lake NPUs via a reverse-engineered path

An open-source project called npunlock has surfaced on Hacker News with an unusual claim: developers can write and execute their own C kernels on Intel's neural processing units. Verified on Windows x64 with a Meteor Lake NPU (the NPU3720), it reverse-engineers a capability the hardware supports but Intel's public software stack has never exposed.

The gap npunlock fills

Intel's Core Ultra NPUs contain ACT-SHAVE processors — programmable cores that run software kernels. According to the project's documentation on GitHub, however, Intel's official tooling only accepts graphs assembled from operations its compiler already knows about. There is no supported workflow for supplying a C implementation of an operation.

Npunlock reconstructs that missing route. It compiles user-written C into ACT-SHAVE machine code and splices the result into NPU graphs, while still relying on Intel's own compiler and driver for the surrounding graph and hardware execution. The project demonstrates the approach with a complete FP32 GELU kernel embedded in a Python script, placed into a graph, and validated against a NumPy reference. One curious detail from the README: the underlying MoviTools toolchain makes most conventional libm functions available to kernels — the GELU example calls tanhf directly — without including math.h.

Getting the toolchain

Compiling C for the SHAVE cores requires Intel/Movidius MoviTools, which npunlock neither redistributes nor downloads. Per the README, a package verified to work was located in a legacy Lenovo driver bundle: the MVC_DEPEND payload inside Intel NPU driver 31.0.100.1688. The documentation stresses that users should extract that payload only and must not install or downgrade to the old driver itself.

The full requirement list is Windows x64, a Meteor Lake / NPU3720 device with an installed Intel NPU driver, Python 3.10 or newer, CMake 3.24 or newer with an MSVC toolchain for building from source, and the extracted MoviTools directory. Notably, OpenVINO is not needed as a runtime, Python package, or compiler frontend, although npunlock does emit OpenVINO-format IR for the installed Intel driver.

What works today

Verified functionality includes compiling user C into ACT-SHAVE machine code, running custom kernels inside Intel NPU graphs, static dense FP16 unary and two-input kernels, a verified FP32 unary path, and nonlinear math such as GELU and tanhf. Python, CLI, and native C APIs are all exposed. A breakthrough dated 23 September 2026 lets a single native graph execute independent FP32-unary and FP16-binary custom branches, with an explicit ACT-group preflight step compensating for the compiler's branch reordering.

The boundaries are equally clear. Support is experimental and limited to Windows x64, Meteor Lake / NPU3720, static shapes, compatible ACT carriers, and known tensor layouts. Connected mixed-precision conversion groups are not yet patch-discoverable, so the verified mixed-precision example uses independent branches instead. No other NPU generation has been tested.

Linux and newer NPUs remain open questions

Two hypotheses are flagged as promising but untested. Because the NPU firmware itself executes the custom machine code, a patched NPU3720 graph built on Windows might run on Linux unchanged; compiling SHAVE code on Linux would additionally require a way to load the Windows MoviTools DLLs. Separately, newer Intel NPUs might accept the existing 3720xx SHAVE image, or matching MoviTools components might sit inside older OEM driver packages for those generations. The author asks for hardware validation reports, driver and firmware version records, and output comparisons against a host reference implementation.

The project is Apache 2.0 licensed, with MoviTools and the Intel/Movidius libraries remaining external proprietary dependencies. The author also discloses that AI assisted with scaffolding, repetitive implementation work, documentation, and English editing, while the reverse engineering, experiments, and technical conclusions came from hands-on work.

Why it matters

Intel has shipped NPUs across its Core Ultra line with cores that are genuinely programmable, yet the public stack treats them as fixed-function accelerators reachable only through predefined operations. Npunlock demonstrates that the silicon can do more than the vendor exposes, and it hands researchers a working route to custom operators, precision experiments, and performance exploration on hardware they already own.

It is worth being realistic: an experimental tool, restricted to one NPU generation, one operating system, static shapes, and a compiler extracted from a legacy driver bundle, is not production infrastructure. Its value today is as a proof of capability and a foundation — and as an invitation. If the Linux and newer-NPU hypotheses hold up, custom NPU kernels could become far more broadly accessible than Intel has so far made them.