Npunlock runs custom C kernels on Intel Core Ultra NPUs

What Intel never opened

Intel Core Ultra NPUs (Meteor Lake) carry programmable cores called ACT-SHAVE, but Intel's official software stack only accepts operations composed from a closed set of blocks supported by the graph compiler. There is no public flow for a developer to deliver their own C implementation to run on these cores. That's the gap that npunlock, a project by developer hsfzxjy, reconstructs through reverse engineering: the path from hand-written C code to an executable kernel on the NPU.

According to the repository's README, the project keeps Intel's compiler and driver for the graph and hardware execution around it, but opens a side door just for compatible custom operations. It's not an alternative driver nor a replacement for OpenVINO: npunlock emits IR in OpenVINO format for the normally installed Intel driver, but injects into it a kernel written by the developer themselves.

How the kernel reaches the NPU

The documented flow combines Python, C, and a custom tensor ABI. A full example from the repository implements the GELU activation function in FP32 by embedding the C kernel directly as a string inside the Python script:

import numpy as np
import npunlock as npu

npu.configure(movi_dll_dir=r"C:\path\to\MVC_DEPEND")

gelu_c: bytes = b"""
#define MLIBM_DEFINE_LINK_COMPAT 1
#include <npunlock/npu3720_kernel.h>

void controlled_act(unsigned layerParams) {
    act_abi_invocation invocation;
    ACT_ABI_LOAD_INVOCATION32_OR_RETURN(layerParams, invocation);
    const float *in = ACT_ABI_INPUT_PTR32(const float, invocation, 0u);
    float *out = ACT_ABI_OUTPUT_PTR32(float, invocation, 1u);
    const float SQRT_2_DIV_PI = 0.7978845608028654f;
    for (unsigned i = 0; i < invocation.element_count; ++i) {
        float x = in[i];
        float w = x + 0.044715f * x * x * x;
        w = tanhf(w * SQRT_2_DIV_PI);
        out[i] = 0.5f * x * (1.0f + w);
    }
}
"""

x = npu.input("x", shape=(1, 2048), dtype="f32")
y = npu.custom(x, source=gelu_c, carrier="Abs", _name="y")
program = npu.compile(npu.Graph(inputs=[x], outputs=[y], name="gelu_f32_example"))

The npunlock/npu3720_kernel.h header, included in the project, provides the invocation macros and the NPU3720-specific tensor address helpers. According to the documentation, the tested MoviTools toolchain makes most of the conventional libm functions available to kernels without needing to include , which allows calling tanhf directly inside the C code compiled for the accelerator.

The missing piece: the MoviTools toolchain

This is the trickiest point of the project for anyone in Brazil wanting to reproduce the setup. Compiling the custom C code depends on MoviTools MVC_DEPEND, an Intel/Movidius toolchain that npunlock doesn't redistribute or download automatically. The README indicates that a working copy was found inside a legacy Lenovo driver package (version 31.0.100.1688) and instructs extracting only the MVC_DEPEND payload from that package, with an explicit warning: do not install or downgrade to that driver, just take advantage of the MoviTools bundled inside it. The step-by-step with verification hash and extraction command is documented on the repository's own Getting MoviTools page.

It's a detail that changes the practical complexity of adopting the tool: a pip install isn't enough, you need to hunt down an old driver installer, extract a specific directory from it, and point npunlock to it via an environment variable (NPUNLOCK_MOVITOOLS_DIR) before running any example.

What already runs and what doesn't yet

The author himself lists, in the README, the scope verified as of September 23, 2026:

• compiling user-written C into ACT-SHAVE machine code;
• running custom kernels inside Intel NPU graphs;
• static dense unary and binary kernels in FP16, and a verified unary path in FP32;
• a single graph running independent FP32-unary and FP16-binary branches simultaneously (the "latest breakthrough" dated today in the repository, which required manually handling the branch reordering done by Intel's compiler via an ACT group preflight);
• nonlinear math functions like GELU and tanhf;
• input and output buffers shared between host and NPU, compatible with NumPy;
• Python, command-line, and native C APIs.

On the limitations side, support is experimental and restricted to Windows x64, Meteor Lake / NPU3720 hardware, static shapes, compatible ACT carriers, and known tensor layouts. Connected mixed-conversion groups aren't yet automatically discovered via patching: the verified mixed example uses independent branches, not a conversion chain. No other generation of Intel NPU has been validated so far.

Open call: Linux and newer NPUs

The repository explicitly asks for help from anyone with hardware outside the tested scope. Two hypotheses are described as promising but unvalidated: an NPU3720 graph already compiled on Windows could run on Linux, since it's the NPU firmware that executes the custom machine code (the obstacle would be loading MoviTools' Windows DLLs on Linux); and newer Intel NPUs could execute the same SHAVE 3720xx image, or have an equivalent legacy OEM driver package with compatible MoviTools components. Both routes require validation on real hardware, logging of driver/firmware versions, and comparing output against an oracle running on the host, according to the project's Porting to Linux and newer NPUs guide.

Why this matters for developers in Brazil

Laptops with Intel Core Ultra and NPU are already on the Brazilian market, but until now that unit was reserved for inference workloads that passed through Intel's graph compiler via OpenVINO, with no room for custom logic. npunlock, under the Apache 2.0 license, is an alternative path for anyone who wants to use that dedicated accelerator for operations outside the officially supported catalog, whether in model inference pipelines, signal processing, or any workload that benefits from tailor-made kernels. The author himself makes clear in the README that the reverse-engineering work, the experiments, and the technical conclusions came from hands-on work: "I did use AI while building this project [...] for scaffolding, repetitive implementation work, converting my reverse-engineered results into organized documentation, and fixing my English. The reverse engineering, experiments, debugging, and technical conclusions came from hands-on work."

For anyone wanting to reproduce it, the realistic path today is: a Windows x64 machine with Meteor Lake and NPU3720, Python 3.10 or higher, CMake 3.24+ with MSVC to build from source, and the manual work of extracting MoviTools from a legacy Lenovo driver package without installing it. It's experimental, restricted to a single NPU generation and static tensor shapes, but it's the first publicly documented path to putting compiled C inside the hardware accelerator that, until now, only received ready-made graphs.