Update onnxruntime to version 1.26.0, add OpenVINO build flags#1769
Conversation
|
I built the CPU version on my Arch linux. It succeeded (with manual changes for the abseil problem specific for arch, not in general) and now I'm trying to build CUDA. |
|
I am not sure that we need openvino on macos-arm64. It might work, but if it's anything like the dnnl build for macos, it's much slower than coreml that is already supproted, and surely slower than MLX, which we can add as a new preset not unlike openvino. So if ovenvino does not build on that platform, I think we should stick to linux and windows x86_64, and support macos with its own optimized backends. |
…t-for-openvino-y3mnbc Add OpenVINO Execution Provider integration to ONNX Runtime Java preset and sample
|
I have updated the PR so that it references the new OpenVINO preset. I found that ONNX Runtime’s native build.py invokes CMake which calls That is why I added this line I'd like to test the OpenVINOExecutionProviderSample locally, @saudet maybe you could advise - how/when would we push snapshot builds to Sonatype? |
|
The build already gets the OpenVINO binaries from Maven. Use those |
|
I think that we'd need to use the maven dependency plugin to unpack the relevant openvino JAR file in the maven validate goal, is that what you had in mind? When running the cppbuild.sh script (in the maven |
|
If it needs OpenVINOConfig.cmake add it to the Maven artifact, that's what it's for |
|
Anything added to buildResources like this will get extracted in time for the cppbuild.sh script: |
…e/providers/openvino/ov_factory.cc:10:10: fatal error: format: No such file or directory
10 | #include <format>
| ^~~~~~~~
compilation terminated.
|
And we'll need this patch to get the build working for CUDA on Windows: |
…NOExecutionProviderSample confirmed working on linux x86-64 (via WSL)
…e only try load onnxruntime_providers_cuda for CUDA-enabled builds
…envino on platforms that don't build it.
…rged for 1.26.0
This reverts commit 575d140.
…ut macro. CUDA 13 CCCL headers use __out as a parameter name in generated PTX helpers. If Windows/SAL headers are included later while cub.cuh is being parsed, __out can be redefined and expanded away, producing invalid code such as "=r"( [0]). Preloading windows.h lets the existing ORT wrapper undefine __out for the full CUB/CCCL include.
…ut the sources first. revert to full patch reference
…ut the sources first. revert to full patch reference
…runtime-to-version-1.26.0
|
@saudet It seems that the github action that should have deployed this stalled https://github.com/bytedeco/javacpp-presets/actions/runs/26425638965/job/77857915571 |
3 participants
Once the OpenVINO changes are merged, we can declare an optional dependency on the OpenVINO preset (I think).