openvino: Add version 2026.3.1

[luhenry]

• Package: openvino
• Version: 2026.3.1
• Source: https://github.com/openvinotoolkit/openvino
• Docs: https://docs.openvino.ai

Compiles the OpenVINO runtime, its IR/ONNX/TensorFlow/TF-Lite/PyTorch/Paddle frontends and the RISC-V CPU plugin - vendored oneDNN at DNNL_TARGET_ARCH=RV64 plus the RVV JIT emitters built on xbyak_riscv - then the Python API once per interpreter. Upstream publishes no riscv64 wheel.

Mirrors upstream's manylinux_2_28.yml, the recipe behind the published wheels, with the riscv64 cmake options of linux_riscv.yml. The wheel's platform tag, the RVV CPU plugin and the prebuilt riscv64 oneTBB all come from branches upstream already carries.

Differs from upstream

• JS API off - the npm package is out of scope for a wheel
• Distro cmake installed - vendored snappy and xbyak_riscv predate CMake 4's floor
• Tests component off - only the wheels are needed

Testing

• pyopenvino suite narrowed to test_runtime/test_graph/test_transformations - the rest need the template plugin that only the tests component builds

License: Wheel bundles oneTBB (Apache-2.0), fetched by upstream's own riscv64 branch.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://riseproject-dev.github.io/python-wheels/pr-preview/pr-2122/
Built to branch gh-pages at 2026-09-20 01:13 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[luhenry]

First CI run: the wheels build, the wheel can't run — needs a decision before any re-run

Run 35480766550, job 105998045327, 01:12–13:36 UTC (12h24m).

The build is not the problem. Build wheels succeeded after 12h18m and produced all four wheels (cp312/cp313/cp314/cp314t, artifact uploaded, 129 MB). The job then failed 2m12s into Test wheels:

/openvino/riscv64-build-and-test.sh: line 32:    41 Illegal instruction     (core dumped) "${python_exe}" -c '
##[error]Process completed with exit code 132.

Exit 132 = 128+4 = SIGILL. None of the usual suspects apply: no Killed, out of memory, ICE or No space left anywhere; 12h24m against timeout-minutes: 1440 is not a timeout; and the run never reached pytest.

The failing point is exact — in the cp312 smoke check, print(ov.get_version()) printed 2026.3.1-1-759c5a6ab8c and print(core.available_devices) never printed. So it dies inside ov.Core() / device enumeration, i.e. when the CPU plugin is dlopened and constructed. set -e aborted the loop there, so cp313/cp314/cp314t were never tested.

Root cause: the RISC-V CPU plugin requires RVV 1.0, this fleet does not have it

Diagnosed from the uploaded artifact rather than by spending another runner slot. Of the 20 libraries in the wheel, libopenvino_riscv_cpu_plugin.so is the only one whose ELF Tag_RISCV_arch carries vector:

libopenvino_riscv_cpu_plugin.so  rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_…_zve64d1p0_zvl128b1p0
every other library             rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zmmul1p0

It holds 64,554 vector (OP-V) instructions, 34,526 of them vsetvl*, in a contiguous ~10.7 MB region of its 20.6 MB .text — against exactly zero across the other 19 libraries' 52 MB, which is the control showing the scan has no false positives.

Upstream's gate is a runtime probe (cpu_isa_traits.cpp: case gv: return mayiuse(g) && cpu.hasExtension(RISCVExtension::V) && can_compile_rvv100();), and the probe is visible in the binary as the only RVV outside that region: two isolated vsetvli+vmv.v.i pairs at .text+0x10b92 (e8, mf2, ta, ma) and .text+0x10d7a (e64, m1, ta, ma) — can_compile_rvv100() / can_compile_zvfh(), which execute the instruction under a SIGILL handler. mf2 doesn't exist in RVV 0.7.1 and the vsetvli encoding differs between 0.7.1 and 1.0, so on this hardware the probe traps exactly as gotcha 272 documents (HWCAP advertises V; the first RVV-1.0 vsetvli is illegal) — and the process core-dumps instead of the probe returning false.

Static evidence can't separate "the probe's SIGILL recovery fails" from "a static initializer inside one of the RVV-compiled TUs runs at dlopen with no mayiuse in front of it". Both land on the same log line. That question is cheap to settle without rebuilding: the artifact is downloadable until 2026-12-19, so a test-only re-run against the existing wheels (LD_DEBUG=libs, or gdb -batch -ex run -ex bt) answers it in minutes.

Why the triage didn't catch this: upstream's linux_riscv.yml runs its functional tests only under qemu-riscv64 -cpu rv64,v=true,vext_spec=v1.0, and docs/dev/build_riscv64.md's hardware list mixes RVV 0.7.1 (Lichee Pi 4A) with RVV 1.0 (BPI-F3, Orange Pi RV2) boards. "Upstream has a real riscv64 CPU plugin with RVV JIT" turns out to be evidence about an emulator with V forced on, not about baseline hardware.

Second, independent blocker: the bundled oneTBB is a T-Head vendor build

Found the same way. The prebuilt oneTBB that ov_download_tbb() fetches and setup.py bundles is a Xuantie build: Tag_RISCV_arch = rv64i2p0_…_xtheadc2p0, with 906 CUSTOM-0 (opcode 0x0B) instructions in libtbb.so.12 and 892 in libtbbmalloc.so.2 — against zero in the 17 libraries we compile ourselves. The triage confirmed e_machine 243, which was true and not sufficient.

It works here only because the runner fleet is itself T-Head (which also explains gotcha 272's otherwise-odd "HWCAP says V but vsetvli SIGILLs": a T-Head C9xx core means RVV 0.7.1). The wheel would SIGILL on SiFive U74/P550, JH7110 or plain QEMU rv64gc — so even with the RVV problem solved, a green run here would not prove the wheel portable.

Why I have not re-triggered

There is no off switch: src/plugins/intel_cpu/CMakeLists.txt adds the four riscv64/ source dirs and XBYAK_RISCV_V=1 whenever RISCV64, intel_cpu/thirdparty/CMakeLists.txt sets XBYAK_RISCV_V ON and DNNL_TARGET_ARCH=RV64 unconditionally, no option() governs any of it, and -march=rv64gcv appears nowhere in the build (only in clang_tidy.cmake). Unlike zlib-ng's -DWITH_RVV=OFF or libpng's PNG_RISCV_RVV=off, this needs a real patch against a scalar-fallback path upstream's own CI never exercises without v=true.

And an RVV-off build still couldn't ship while the T-Head TBB blob is in the wheel. A shippable wheel needs both an RVV patch and a replacement for the prebuilt TBB (source-built oneTBB, or THREADING=SEQ) — two material divergences from the manylinux_2_28.yml recipe this port exists to mirror, producing a scalar-only OpenVINO with none of the vector acceleration that motivated it, at ~12.5h per validation round.

At this cost that's a call worth making deliberately rather than by pushing a speculative re-run. The options as I see them:

1. Park as disproportionate (my recommendation) — same framing as the paddlepaddle cost discussion.
2. Spend minutes, not hours, first: a test-only run against the existing artifact to get the exact faulting frame, then decide with that in hand.
3. Accept an RVV-1.0-only wheel — which the manylinux_riscv64 tag forbids (gotcha 139), so this is really a non-option unless the wheel is scoped to specific hardware.

No code pushed to this branch; PR left open and draft status untouched. Findings recorded on main as gotchas 448 and 449, with the .queue.yml entry updated.