Back Home

GitHub Repo

Npunlock validates custom C kernels on Intel NPU, runs independent mixed-precision branches in one graph

The project uses Intel’s driver to compile computation graphs, then replaces SHAVE kernels to run custom C code on the NPU. New tests cover independent branches at two precisions, but arbitrary mixed-precision pipelines are not yet supported.

Jacek Halicki · CC BY-SA 4.0 · Image source
zh-Hant

In a progress update published on September 23, the open-source project Npunlock demonstrated independent custom branches—a single-input FP32 branch and a two-input FP16 branch—running within the same native Intel NPU computation graph. The author provided a runnable example and documented that both branches matched host-side reference results. The update expands the ways custom kernels can be combined, but does not yet demonstrate that branches using different precisions can be connected into a working pipeline. [Experiment log](https://github.com/hsfzxjy/npunlock/blob/master/wiki/REVERSE_ENGINEERING.md)

The method first lets the existing Intel driver compile the computation graph: operators recognized by the compiler serve as placeholders for custom nodes, producing tensor layouts, scheduling, data movement, and synchronization structures. A separate workflow uses MoviTools to compile C source code into SHAVE machine code. After checking the calling interface and tensor requirements, the tool replaces the code for the specified operation while preserving the surrounding execution structure. It uses an intermediate representation in OpenVINO format, but does not require the OpenVINO package to be installed at runtime. [Architecture overview](https://github.com/hsfzxjy/npunlock/blob/master/wiki/HOW_NPUNLOCK_WORKS.md)

The mixed-precision example also exposed the effects of compiler reordering: branch order in the native graph differed from the frontend traversal order, causing automatic mapping to refuse to proceed. The author first compiled and inspected the graph, then specified targets by input count and element width to successfully install both kernels. A separate experiment involving a connected precision conversion was rejected by the validator because the input and output byte ranges differed. These negative results define the limits of what is currently reproducible. [Validation details](https://github.com/hsfzxjy/npunlock/blob/master/wiki/REVERSE_ENGINEERING.md)

In a Hacker News discussion, the author described intended uses including adding support for uncommon neural network operators, providing precision-sensitive operations, and fusing multiple small kernels to reduce invocations. These directions have value for on-device inference, but whether fusion improves performance remains an unverified hypothesis. The available material does not provide throughput or power consumption comparisons for complete models. [Author discussion](https://news.ycombinator.com/item?id=49800513)

Deployment constraints are specific: validation is limited to Windows x64 and Meteor Lake’s NPU3720, with support focused on static shapes and known tensor layouts. Linux, newer NPU generations, and arbitrary computation graphs remain untested. The project is licensed under Apache-2.0, but the external MoviTools toolchain is a proprietary dependency that must be extracted separately from an older driver package. The project instructs users to extract only the toolchain, without installing or downgrading to that driver. Engineers should next pin the driver version, compare each kernel’s output against host-side results, and then measure data movement and overall latency, avoiding treating a successfully loaded computation graph as proof of numerical correctness. [Project documentation](https://github.com/hsfzxjy/npunlock)

Sources

  1. hsfzxjy/npunlock
  2. Reverse-engineering breakthroughs
  3. How npunlock works