v1.1.0 — Open NPU Lab

From idle silicon to an open Linux laboratory

This release is a public handoff. It began with a Ryzen 7 PRO 7840U whose XDNA1 NPU was visible under Linux but easy to leave unused. It now gives XDNA1 owners, Strix Point XDNA2 owners, and future-device experimenters a freely reusable path to make small, honest, CPU-checked local-AI building blocks—and to publish successes, failures, and new ideas for the next person.

Anyone may use, copy, modify, fork, publish, redistribute, teach with, or ship the repository's MIT-licensed work commercially. Preserve the license notice; upstream code and model assets retain their own licenses.

New in v1.1.0

• Open NPU Lab: a 15-minute/day/week/research ladder, honest evidence labels, hybrid CPU+iGPU+NPU designs, practical projects, real XDNA1/XDNA2 GIFs, and an explicit invitation to fork the work.
• Primary-source research map: official hardware/kernel/compiler sources plus published XDNA1/XDNA2 LLM work, with each generation, baseline, and evidence type separated.
• Local RAG sidecar: deterministic CPU text features → persistent 256×256 bf16 NPU score matrix → complete CPU oracle and exact top-k gate → optional model endpoint.
• Open experiment intake: the new issue form welcomes hardware passes, compile-only probes, useful failures, latency/energy measurements, and application ideas on any generation.
• Five-language core guides now distinguish this repository's pinned evidence, moving upstream AMD IRON capability, published research, and still-open work.

Final Strix Point evidence

On RyzenAI-npu4, the release candidate rebuilt its toolchain-keyed bf16 VMFB and matched all 65,536 splat outputs exactly. Three semantic RAG queries, each repeated seven times through one persistent context, checked all 65,536 outputs per call, stayed finite, passed a 5% normalized-maximum error gate, and preserved exact CPU top-3 parity. Worst errors were 0.138%, 0.149%, and 0.115%.

The hardware-free suite contains 19 corpus, oracle, endpoint, timeout, secret-handling, and cache-boundary tests. The release commit passed GitHub Actions on both the PR and merged main.

XDNA1 is the reason this remains open

The original Phoenix/7840U hardware results and demos remain first-class evidence and usable source. This release also points to current upstream Phoenix operator coverage and published hybrid LLM research showing that first-generation silicon still has meaningful work to do. It does not pretend that an arbitrary LLM already runs wholly on XDNA1: the exact current-lock full sidecar rerun on XDNA1 is still requested and clearly labelled.

Start with the support matrix, run the read-only check, reproduce one CPU-reference contract, and then change one small piece. An NPU that runs one honest, useful job is no longer decoration.

See the full changelog.

v1.0.0 — Open XDNA1 + XDNA2 Linux NPU toolkit

Changelog

All notable public-release changes are documented here.

1.0.0 - 2026-08-15

Real Strix Point hardware: device detection, i32/bf16 CPU-reference matches,
full persistent-runner validation, and eight-column IRON XRT/HRX execution:

Added

• One open workflow spanning the earlier hardware-verified XDNA1
  (npu1_4col) path and the current-lock-verified Strix Point XDNA2 (npu4)
  path on Linux: detect, build, CPU-reference check, and persistent native/Python
  invocation.
• Real-hardware i32 and bf16 IREE paths, IRON examples, LLM building-block
  checks, ONNX extraction, wake-word, and virtual-camera examples.
• verify-stack.sh as the hardware acceptance contract and hardware-free CI for
  scripts, Python, Markdown links, and repository hygiene.
• Five-language documentation, contribution templates, and public compatibility
  result reporting.

Reproducibility and safety

• Current release toolchain versions are pinned in versions.lock; development
  overrides are explicit rather than silently selecting a new nightly. The exact
  lock and acceptance contract were hardware-revalidated on Strix Point; the
  historical Phoenix result used the same IREE source commit and an earlier
  Peano, so XDNA1 reconfirmation of the exact v1 lock is requested.
• Device selection rejects unverified npu5/npu6 mappings instead of treating all
  XDNA2 hardware as Strix Point.
• Runtime outputs are fully validated, invalid C/Python inputs are rejected, and
  partial initialization is cleaned up.

Known boundaries

• Phoenix XDNA1 has earlier real-hardware evidence, but the exact v1 Peano 22
  lock still awaits XDNA1 reconfirmation. Hawk Point has no separate hardware
  result. The current exact lock is verified on Strix Point npu4; npu5/npu6 are
  not claimed.
• Native bfp16ebs8 CPU-reference checks pass through K=1216 and first fail at
  K=1280 in the documented sweep; this is published as a boundary, not hidden.
• W4A16 front-end compilation works, while full lowering, linking, and NPU
  correctness remain open research work.
• The npu4 camera processing core matched the CPU on all 921,600 output values,
  but the complete XDNA2 GStreamer//dev/video10 loopback and FPS path remains
  unverified on this host; the published camera GIF is the original XDNA1 run.
• Results labelled compile-only, correctness, or performance remain separate.