+ notes: '12 Linux/macOS/Windows wheels upstream (abi: cp310-cp314t, build tag 22476), no sdist at all; no riscv64 on PyPI or pypi.riseproject.dev. Feasible and NOT a gotcha-214/ortools scope stop: OpenVINO has first-class upstream riscv64 support, so the only open question was build scale. Upstream carries a dedicated .github/workflows/linux_riscv.yml (per-PR plus 00:00 Wed/Sat, 150-min budget, 16-core x86 cross-build with ccache) that builds the CPU plugin for riscv64 and runs ov_cpu_func_tests under `qemu-riscv64 -cpu rv64,v=true,vext_spec=v1.0`, and docs/dev/build_riscv64.md documents the build (validated on Lichee Pi 4A/RVV 0.7.1, Banana Pi BPI-F3 and Orange Pi RV2/RVV 1.0) including `-DENABLE_PYTHON=ON -DENABLE_WHEEL=ON`. The CPU plugin carries real riscv64 code rather than a generic C++ fallback: src/plugins/intel_cpu/CMakeLists.txt links the xbyak_riscv submodule with XBYAK_RISCV_V=1 for RVV JIT, compiles src/{emitters/plugin,emitters/snippets,nodes/kernels,nodes/executors}/riscv64/*, renames the plugin openvino_riscv_cpu_plugin, and excludes mlas/kleidiai/ACL/libxsmm (X86_64/AARCH64-gated); intel_cpu/thirdparty/CMakeLists.txt sets DNNL_TARGET_ARCH=RV64 for the vendored oneDNN, so none of oneDNN''s x64 JIT tree is built. GPU/NPU need no flag work - features.cmake gates ENABLE_INTEL_GPU on "X86_64 OR AARCH64" and ENABLE_INTEL_NPU on "X86_64". Two upstream riscv64 branches make the wheel recipe work unchanged, and both were verified rather than assumed: (1) src/bindings/python/wheel/CMakeLists.txt''s _ov_platform_arch() has a RISCV64 -> riscv64 case and derives the tag from the build glibc, so the build emits manylinux_2_39_riscv64 itself and needs no auditwheel retag (contrast build-onnxruntime.yml, whose setup.py allow-list has no riscv64 entry); (2) cmake/dependencies.cmake''s ov_download_tbb() has a RISCV64 branch fetching oneapi-tbb-2022.3.0-lin-riscv-release.tgz from storage.openvinotoolkit.org - downloaded it and confirmed genuine riscv64 oneTBB (ELF e_machine 243) needing only GLIBC<=2.33, so the default TBB_ADAPTIVE threading resolves and setup.py bundles TBB exactly as in the published x86_64/aarch64 wheels. Deliberately did NOT copy linux_riscv.yml''s -DTHREADING=OMP: that predates the riscv TBB archive, and OMP would link the image''s libgomp into the wheel, forcing a gpl_sources job and diverging from the wheel recipe for no gain (ov_download_tbbbind_2_5 has no riscv64 entry but only warns and returns). Scale is proportionate: with GPU (996 files) and NPU (176) off, the compiled set is ~2400 of openvino''s own .cpp plus oneDNN RV64, protobuf, onnx, flatbuffers, snappy, pugixml and zlib - comparable to onnxruntime, which this repo already publishes for riscv64 (cp312-cp314t), and far under torch 2.13/2.14+cpu and libclang''s ~10h LLVM build, both of which this runner pool has already absorbed. build-openvino.yml mirrors manylinux_2_28.yml (the recipe behind the PyPI wheels): one C++ build, then a per-interpreter cmake over src/bindings/python with -DOpenVINODeveloperPackage_DIR pointing at that build dir and ENABLE_GIL_PYTHON_API=OFF for cp314t, podman-driving quay.io/pypa/manylinux_2_39_riscv64 like build-onnxruntime.yml (single job, no python matrix, so the interpreter-independent C++ world is compiled once). Deviations: -DENABLE_JS=OFF (the npm addon is out of scope and would FetchContent node headers), tests component off, and `dnf install -y cmake` because the image ships CMake 4.4.3 while vendored snappy (cmake_minimum_required 3.1) and xbyak_riscv (2.6...3.0.2) sit below CMake 4''s hard 3.5 floor - confirmed in-image that dnf yields cmake 3.31.8 on Rocky 10 riscv64, above openvino''s own 3.26 requirement, which is also why upstream''s manylinux job calls /usr/bin/cmake. Local rehearsal per gotcha 15/9, run inside the real manylinux_2_39_riscv64 image under QEMU (a full build is impractical there, a configure is not): BOTH halves configure clean with the workflow''s exact flags - the base build ends "Configuring done (135.6s) / Generating done", exit 0, with CMakeCache showing DNNL_TARGET_ARCH=RV64, ENABLE_INTEL_CPU=ON, XBYAK_RISCV_V=ON, ENABLE_INTEL_GPU/NPU=OFF, THREADING=TBB_ADAPTIVE and TBBROOT=temp/Linux_riscv64/tbb (the prebuilt riscv TBB actually downloaded and resolved); the per-interpreter `cmake -S src/bindings/python -DOpenVINODeveloperPackage_DIR=/build` then also exits 0 against a base configured with ENABLE_PYTHON=OFF, which is the one combination upstream never runs itself (its riscv CI uses ENABLE_PYTHON=OFF without the developer package; its wheel CI uses the developer package with python on) and therefore the riskiest part of the design. The generated build files name the wheel exactly: openvino-2026.3.1-1-cp312-cp312-manylinux_2_39_riscv64.whl, i.e. correct version and tag, with PEP 427 build tag 1 because ov_commit_number() counts first-parent commits in actions/checkout''s shallow clone (upstream''s own releases carry 22476); build-tagged filenames are already precedented and published here by cmeel-boost and shiboken6, and update_doc.py reads the version from METADATA rather than the filename. Runtime deps resolve: numpy has riscv64 wheels, openvino-telemetry is py3-none-any, and pillow (needed by one test) is on the registry for cp312-cp314t. Testing mirrors upstream''s job_python_api_tests.yml (pytest over src/bindings/python/tests) narrowed to test_runtime/test_graph/test_transformations with -m ''not template_extension'', since the template plugin/extension only ships in the tests component this build does not produce, plus a real CPU inference check (relu over a 1x4 f32 tensor) and the .so proof on openvino._pyopenvino. No patches needed. PR #2122 open, CI not yet observed - the first real run is the remaining evidence; expect a long build and watch for (a) OOM on the 15GB runner from `--parallel $(nproc)` (cap it if the intel_cpu tail dies), (b) pytest failures from tests that assume the tests component. Candidate gotcha once green (not filed yet, per the skill''s after-green rule): do not copy an arch-specific upstream CI workflow''s build options blindly - check whether the project''s *wheel* recipe already has a branch for the arch, since the CI workflow may predate it (openvino''s riscv CI forces OMP threading while its dependency downloader already ships a riscv64 TBB).'
0 commit comments