Windows build

[hardWorker254]

Name and Version

.

Operating systems

Windows

Which llama.cpp modules do you know to be affected?

No response

Command line

Problem description & steps to reproduce

How do I build this fork on Windows? I know how to do it for Linux, but I can't find XRT for Windows. Should I install RyzenAI Software or something similar?
I have Ryzen 7 pro 8845HS(Hawk Point)

First Bad Commit

No response

Relevant log output

No response

[hardWorker254]

I installed RyzenAI + llvm_aie, mlir-aie, but there is an issue in ggml/src/ggml-xdna/CMakeLists.txt. It searches for headers and libraries only for Linux, but not for Windows.
@Soket1

[Soket1]

You're right, and it's two separate bugs in ggml/src/ggml-xdna/CMakeLists.txt:

find_path(XRT_INCLUDE_DIR
    NAMES xrt/xrt_device.h
    HINTS /opt/xilinx/xrt/include $ENV{XILINX_XRT}/include)

find_library(XRT_CORE_LIB
    NAMES xrt_core                      # <-- Windows has no xrt_core
    HINTS /opt/xilinx/xrt/lib $ENV{XILINX_XRT}/lib)

1. The HINTS only cover Linux layouts.
2. NAMES xrt_core is wrong on Windows — the import library there is xrt_coreutil.lib. So even with XILINX_XRT set correctly, find_library still fails.

Until I fix this properly, pass both explicitly:

cmake -B build -DGGML_XDNA=ON ^
  -DXRT_INCLUDE_DIR="C:/path/to/xrt_sdk/xrt/include" ^
  -DXRT_CORE_LIB="C:/path/to/xrt_sdk/xrt/lib/xrt_coreutil.lib"
cmake --build build --config Release -j

That's exactly what my own build resolves to (from CMakeCache.txt), so it does work.

---

However — and I'd rather say this before you sink more time in:

Ryzen 7 PRO 8845HS (Hawk Point) is XDNA 1 (AIE2). This fork's decode path is built for XDNA 2 / AIE2P (Strix Point / Ryzen AI 300). That isn't a driver or build detail, it's the ISA the kernels are compiled against:

• IRON-windows/iron/operators/decode_layer_f3best/design.py:22 — decode_layer_f3best targets npu2 (AIE2P); device_type 'npu' (NPU1) unsupported
• ggml/src/ggml-xdna/ggml-xdna.cpp:4841 additionally hard-guards the fused layer to one geometry: E=2048, hidden=8192, head_dim=64, kv_heads=8, q_heads=32 — i.e. Llama-3.2-1B Q4_0 and nothing else

So on Hawk Point the build can succeed and every NPU op will still fall back to CPU — silently, because a missing kernel bundle is a fallback rather than a hard error.

If you want to confirm what's actually landing on the NPU:

python ggml/src/ggml-xdna/tools/correctness_test.py --list
python ggml/src/ggml-xdna/tools/correctness_test.py --bench --bench-only "f3best"

If the NPU rows aren't clearly beating the CPU row, nothing is running on the NPU.

I'll fix the CMake lookup (proper Windows hints + xrt_coreutil) since that's a genuine bug regardless of hardware — thanks for pinning it down. The XDNA 1 support question is a much bigger piece of work and I can't promise it.

[Soket1]

Correction to my previous comment — I misread the CMake block.

I claimed NAMES xrt_core was a second bug. It isn't. There are two find_library calls, and the one that matters looks for xrt_coreutil:

find_library(XRT_CORE_LIB     NAMES xrt_core     ...)   # unused, dead variable
find_library(XRT_COREUTIL_LIB NAMES xrt_coreutil ...)   # this is the one

and only the second is checked and linked (if (XRT_INCLUDE_DIR AND XRT_COREUTIL_LIB) → target_link_libraries(... ${XRT_COREUTIL_LIB} ...)). So xrt_core failing to resolve on Windows is harmless — sorry for the noise.

The real bug is just the one you reported: the HINTS are Linux-only. That's it, and it's enough to break the configure step on a clean Windows tree.

Why it never showed up on my machine: my CMakeCache.txt already has XRT_INCLUDE_DIR / XRT_COREUTIL_LIB set explicitly from a -D on the first configure, and CMake skips find_library entirely once a cache entry exists. So I've been building around the bug without seeing it. Your report is the first clean-tree Windows configure.

The workaround in my previous comment still stands (pass both with -D), and the fix is now just adding Windows hints.

[Soket1]

Circling back with an actual answer to your original question — where to get XRT for Windows — plus the fixes your report triggered.

The XRT Windows SDK

No, Ryzen AI Software does not give you it. I verified that on my own machine: the 1.7.1 installer creates C:\Program Files\RyzenAI\xrt\ empty, and there is no xclbinutil.exe, xrt-smi.exe, xrt_device.h or xrt_coreutil.lib anywhere under Program Files. So you weren't missing something obvious — it genuinely isn't there.

It's published by AMD as a release asset of XRT itself:

https://github.com/Xilinx/XRT/releases/download/2.21.75/xrt_windows_sdk.zip

Unpack it anywhere. The directory you point CMake at is the inner ...\xrt_sdk\xrt — that's the one holding include\, lib\ and xclbinutil.exe.

For what it's worth, this is identified rather than assumed: xclbinutil --version reports build hash 4eb1f439 dated 2026-02-03, that commit exists in the public Xilinx/XRT tree at the same instant, and my local copy matches the release asset byte for byte (SHA256 CCC244C2...5295, 70,834,080 bytes). License is Apache 2.0.

Also: github.com/amd/xdna-driver has no releases at all, so don't spend time looking there.

⚠️ One trap that will cost you an hour

XILINX_XRT is a configure-time variable. If you leave it set in your environment afterwards, XRT itself reads it to locate xrt_core.dll — which lives in the NPU driver package, not the SDK — and the kernel compile then dies with exit 1 and no output whatsoever. Not a stack trace, not a message. Unset it after cmake.

compile.py therefore uses its own XDNA_XRT_SDK_DIR for its lookup and never touches XILINX_XRT.

Fixed since your report

• CMake lookup (a1fd5ed0e) — Windows/standard install hints added, so XILINX_XRT (or XRT_ROOT, or a normal C:\Xilinx\XRT install) is found without any -D. The failure message now names the variable, the exact directory to point it at, and the runtime trap above. The dead xrt_core find_library is gone — it resolved to NOTFOUND even on a working install and reads exactly like the reason a Windows configure failed, which is how I misled you in my first reply.
• compile.py (33f1c1683) — it had four absolute paths pinned to my machine, each behind os.path.exists(), so on anyone else's box they were skipped silently and the failure surfaced somewhere unrelated. One of them was already dead on my own machine. Now: the driver directory is globbed, the SDK resolved from env/PATH/standard roots, and a missing xclbinutil fails loudly listing every path tried.
• Prebuilt kernels are in the repo (e042862cf) — the whole set is ~1 MB, including the fused decode layer that was previously missing, so a clone needs no AIE toolchain for the supported model. npu_kernels_win_8col/README.md maps each file to the tensor it serves.
• Docs rewritten (8855a5394, aa13e8407) — the old ones pointed at a different fork, at amd/IRON (which lacks ~70 operators this backend dispatches), and quoted numbers from a much older state. There's also a run-npu.ps1 now, because the fast path needs fifteen environment variables and -fa off, and a forgotten one doesn't error — it silently gives you the slow path.

Measured on Ryzen AI 9 365, Llama-3.2-1B Q4_0: decode 10.6 → 29.0 t/s. Prompt processing goes the other way, 191.6 → 100.3 — worth knowing before you optimise for the wrong workload.

Your hardware — honest status

Ryzen 7 PRO 8845HS is Hawk Point, XDNA 1 (AIE2), 4 columns. The fused decode layer is compiled for AIE2P and refuses NPU1 outright:

IRON-windows/iron/operators/decode_layer_f3best/design.py:22
    raise ValueError("decode_layer_f3best targets npu2 (AIE2P); device_type 'npu' (NPU1) unsupported")

and the backend additionally hard-guards it to one geometry (ggml-xdna.cpp:4841): Llama-3.2-1B, E=2048, hidden=8192, head_dim=64, kv=8, q=32.

I did fix one thing in your favour (e511dda7c): compile.py used to hardcode "8 columns" on Windows. Every caller uses that as a guard — compile for the requested width, refuse if the device is narrower — so hardcoding 8 didn't build wider kernels, it switched the guard off. On your 4-column part a request for 8 columns would have sailed through and failed later as an unexplained load error. Real detection now runs on Windows too, so it fails at the right place with the right message.

That makes XDNA 1 fail comprehensibly. It does not make it work, and I'm not going to claim otherwise: I have no Hawk Point hardware, so nothing here has ever run on one. What I genuinely don't know is how far the per-op GEMV path gets on 4 columns — it's shape-parametric and might well compile, but it is untested, and the prebuilt kernels in the repo are 8-column artifacts that won't apply to you.

If you do try it, python ggml/src/ggml-xdna/tools/correctness_test.py --list and the --bench runs will tell you what's actually reaching the NPU, and I'd be glad to hear what happens either way — it's the only way this gets tested.