Repository navigation
CI builds the ONNX EP's NPU leg in no configuration, so a broken ONEBIT_EP_NPU build stays green (#874's class) #917
Description
What
npu/ort/onebit_npu_gemm.cpp (and everything it pulls in: npu_engine_i8ctx_inc.h, q4nx_pack.c) is built by exactly one configuration in the tree: onnx/ep with -DONEBIT_EP_NPU=ON, which needs ONNX Runtime and the private NPU runtime (ONEBIT_NPU_RT_DIR, docs/npu.md). CI has neither, so the leg has never been compiled there in any job, and .github/workflows/ci.yml configures without -DONEBIT_ORT=ON as well.
That is the same hole #898 describes for npu/forward, one directory over — pi-tissues' #912 closes the forward half.
Evidence: it is not hypothetical
#874 (mine, found by a device gate, not by CI): #869 gave I8Ctx::args_fit_elf() a call to q4nx_elf_arg_sizes(), and the leg broke twice while CI stayed green:
| defect | what CI said | what the compiler said |
|---|---|---|
npu_engine_i8ctx_inc.h calls q4nx_elf_arg_sizes() / q4nx_gemv_family() without the declaration npu/forward/include/q4nx_pack.h holds |
build green | error: 'q4nx_elf_arg_sizes' was not declared in this scope |
onnx/ep/CMakeLists.txt's source list omits npu/forward/src/q4nx_pack.c, the file that defines them |
build green | undefined reference to q4nx_elf_arg_sizes (a link error, so an object-only syntax check does not see it either) |
Note the second row: the list that went wrong was a copy that existed only inside an ORT-requiring directory, so nothing outside it could compile the same set.
Why it is not just "turn the flag on"
ONEBIT_EP_NPU=ON needs ONNX Runtime headers (CI installs none) and the runtime sources (npu_rt.cpp, npu_rt_api.cpp — private, not in this repo). So the honest options, cheapest first:
- compile and link the ORT-free half of the leg (
npu/ort/onebit_npu_gemm.cpp+q4nx_pack.c, which is where both onnx EP NPU leg does not compile on main since #869: q4nx_elf_arg_sizes is called without its declaration #874 defects were) from the same source list the EP builds, against a stub of the runtime interface; - install ORT and the runtime in the CI image and build the leg for real (heavier; needs the private runtime available to CI, which is the blocker);
- declare it: a PR touching
npu/ort,npu/forward/engine-srcoronnx/ep's NPU path must show a local-DONEBIT_EP_NPU=ONbuild in its body.
Acceptance
Option 1, done in the PR that closes this: a onebit_ep_npu_linkcheck target built by onebit (so the existing CI build job runs it) that goes red for both #874 defects, with the source list shared via onnx/ep/npu_sources.cmake so it cannot drift from the EP's again.
Activity
bong-water-water-bong commentedon Nov 3, 2026
Verified, and it is one review away already: the acceptance this issue names is PR #918 (open,
MERGEABLE), and the earlier duplicate #915 was closed pointing at it.What I checked at
d326135brather than taking on trust:onnx/ep/CMakeLists.txt:35-61is the only place the leg is built:if(ONEBIT_EP_NPU), and_npu_srcisnpu/ort/onebit_npu_gemm.cpp+npu/forward/src/q4nx_pack.c+ the two private runtime files fromONEBIT_NPU_RT_DIR(:48-55). There is no in-tree configuration that compiles that set without ORT and the private runtime, so CI has never built it — the report's premise is exact.onebit, which the build job already builds (closes #898) #912:_npu_srcpullsnpu_rt.cpp/npu_rt_api.cppfromONEBIT_NPU_RT_DIR, so a CI linkcheck has to supply those symbols itself. ci: compile and link the ONNX EP's NPU leg, so a broken ONEBIT_EP_NPU build goes red #918'sonnx/ep/npu_runtime_ci_stub.cppis that stub,npu_linkcheck.cppis the driver, andonnx/ep/npu_sources.cmakeis the shared list the issue asked for — which is the part that actually prevents the second onnx EP NPU leg does not compile on main since #869: q4nx_elf_arg_sizes is called without its declaration #874 defect (the list that drifted existed only inside an ORT-requiring directory).Labels:
bug+npu. Bucket A, one review away. Note for the record: #912 (merged,ae0ee199) does not cover this — it compilesnpu/forward/src/q4nx_forward.cppand nothing undernpu/ortoronnx/ep, exactly as this issue says.q4nx_pack.c is already in the EP's own list at
:53(that is #874's fix, #878's sibling), so the remaining hole is only that no CI configuration ever links the set. If #918 merges with the linkcheck wired intoonebit, both #874 defects reproduce as hard failures in CI, which is the acceptance — I will close this on that merge commit and re-run the two defects as injections before I do.