command-center/agent/managed-skills/strix-halo-npu-readiness-census/SKILL.md

name, description

name	description
strix-halo-npu-readiness-census	Engine-agnostic census of whether an AMD Strix Halo / Ryzen AI host can run anything on its XDNA2 NPU: driver bind, firmware, device perms, IOMMU, distro XRT, missing AIE compiler, fabric clock, RAM headroom.

Use when asked "can we run <engine/model> on the Strix Halo / Ryzen AI NPU?" for a runtime that is not halogen (halogen has its own gate + vendor catalog: use halogen-npu-feasibility-census for that). This answers only: is the host able, and what is missing.

Why it is usually the wrong door first

XDNA2 executes precompiled AIE partition programs loaded through XRT → amdxdna. There is no generic tensor dispatch: an engine built on ggml/llama.cpp (or any GGUF loader) cannot "enable" the NPU — the port must be a re-export + vendor compile, not a flag. So pair this census with the accelerator the same engine can select by build flag (Vulkan/HIP on the gfx1151 iGPU) before proposing NPU work.

Census (all read-only, over ssh from the operator box)

ssh <host> '
cat /proc/cmdline; ls /sys/kernel/iommu_groups | wc -l      # iommu=pt required; groups==0 => IOMMU off => NPU dead
lsmod | grep -i amdxdna                                      # in-tree driver
sudo dmesg | grep -iE "xdna|npu" | tail                      # "Initialized amdxdna_accel_driver <ver> for 0000:c6:00.1"
lspci -nn | grep -iE "npu|processing"                        # Strix Halo = 1022:17f0
ls /sys/bus/pci/drivers/amdxdna                              # must list the BDF
ls -l /dev/accel                                             # accel0, root:render 660
id -nG <deploy-user> | tr " " "\n" | grep -E "render|video"  # rootless podman needs render, else --device fails at create
find /usr/lib/firmware -iname "*npu*" | head                 # firmware is /usr/lib/firmware/amdnpu/<devid>_<rev>/npu.sbin*.zst — match the PCI rev
dpkg -l | grep -iE "xrt|xdna"; ls /opt/xilinx/xrt/lib 2>&1   # distro libxrt-npu2 = XDNA2 runtime; vendor /opt/xilinx/xrt usually absent
apt-cache policy libxrt2 libxrt-npu2 | grep Candidate
apt-cache search onnxruntime | head                          # distro ONNX RT exists; the Ryzen AI EP does not
python3 -c "import onnxruntime" 2>&1 | tail -1               # absence of the EP + of ryzenai-compile is the real blocker
for c in /sys/class/drm/card*/device; do echo "-- $c"; cat $c/power_dpm_force_performance_level 2>&1; cat $c/pp_dpm_fclk 2>&1 | tr "\n" " "; echo; done
nproc; free -g | head -2                                      # RAM headroom + thread count the engine will pick
'

Reading it

• Driver bound + accel0 + firmware dir + iommu=pt ⇒ kernel side is ready; do not re-litigate "is the NPU disabled". A missing device node is not the modern failure mode.
• auto on pp_dpm_fclk / power_dpm_force_performance_level ⇒ fabric clock unheld. GPU+NPU concurrently with a moving fclk hangs these hosts and corrupts NPU results; any NPU plan must pin the top fclk step (or run in a container holding it) first.
• No ryzenai-compile/ONNX Ryzen AI EP ⇒ nothing on the host can produce a partition program. That is the enablement delta, and it is a toolchain install + a model-specific export/quantize/compile project, not a config change.
• free headroom matters: NPU partitions want a few GB of host RAM each and can log benign Failed to alloc dev bo memory, ret -28 under pressure.

Laws / traps

• Read state only. Never probe or load the NPU beside a live inference service — stop + mask the service first (fleet benching policy); this host class has a precedent of a concurrent GPU/NPU experiment needing a power cycle.
• sudo podman ... finds nothing (per-user rootless storage); run podman as the deploy user.
• /dev/accel/accel0 existing does not mean a context/PASID can be created; with IOMMU off the failure is at context creation, not at the node.