19b4d9d41e
### Description Updates TensorRT and CANN EPs to use murmurhash3 from core/framework via provider bridge. ### Motivation and Context A failure in a packaging pipeline required us to temporarily duplicate murmurhash3 code for the TensorRT EP. This PR removes the duplicate code. This is what is happening: The original version of this code conditionally included a murmurhash function for TensorRT only (not cuda) in the provider bridge. The packaging pipeline selectively [copies binaries from two separate builds](https://github.com/microsoft/onnxruntime/blob/main/tools/ci_build/github/linux/extract_and_bundle_gpu_package.sh) (a cuda-only build and a tensorrt build) into a single libs directory. These are the files within the resulting libs directory: - onnxruntime.so (copied from tensorrt build, implements murmurhash in provider bridge host) - onnxruntime_providers_shared.so (copied from tensorrt build) - onnxruntime_providers_tensorrt.so (copied from tensorrt build) - onnxruntime_providers_cuda.so (copied from **cuda-only build**, expects a provider host w/o murmurhash) The [squeezenet example](https://github.com/microsoft/onnxruntime-inference-examples/tree/main/c_cxx/squeezenet) crashed when onnxruntime_providers_cuda.so was loaded because the cuda ep tried to call functions from a `ProviderHost` object that did not match what was actually implemented by onnxruntime.so. I've confirmed that we _can_ prevent the crash by modifying the pipeline to use the onnxruntime_providers_cuda.so file from the tensorrt build (instead of the file from the cuda-only build). However, I don't think that is necessarily correct. Instead, I think we should try to make sure that the provider bridge exposes the same interface to any EP libraries that can potentially coexist in the same application (like cuda and tensorrt). Failing that, there's probably something we can do to generate a better error message when an EP detects that the Provider Host implements an unexpected interface. Note that the above applies to the Windows build in the packaging pipeline as well. I used the onnxruntime branch [adrianl/test-trt-cuda-bridge-packaging-pipeline](https://github.com/microsoft/onnxruntime/tree/adrianl/test-trt-cuda-bridge-packaging-pipeline) along with the onnxruntime-inference-examples branch [adrianl/squeezenet_ld_debug](https://github.com/microsoft/onnxruntime-inference-examples/tree/adrianl/squeezenet_ld_debug) to test that copying the onnxruntime_providers_cuda.so file from the tensorrt build gets rid of the crash. |
||
|---|---|---|
| .config | ||
| .devcontainer | ||
| .gdn | ||
| .github | ||
| .pipelines | ||
| .vscode | ||
| cgmanifests | ||
| cmake | ||
| csharp | ||
| dockerfiles | ||
| docs | ||
| include/onnxruntime/core | ||
| java | ||
| js | ||
| objectivec | ||
| onnxruntime | ||
| orttraining | ||
| package/rpm | ||
| samples | ||
| test | ||
| tools | ||
| winml | ||
| .clang-format | ||
| .clang-tidy | ||
| .dockerignore | ||
| .flake8 | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| build.amd64.1411.bat | ||
| build.bat | ||
| build.sh | ||
| CITATION.cff | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| lgtm.yml | ||
| LICENSE | ||
| NuGet.config | ||
| ort.wprp | ||
| ORT_icon_for_light_bg.png | ||
| packages.config | ||
| pyproject.toml | ||
| README.md | ||
| requirements-dev.txt | ||
| requirements-doc.txt | ||
| requirements-training.txt | ||
| requirements.txt.in | ||
| SECURITY.md | ||
| setup.py | ||
| ThirdPartyNotices.txt | ||
| VERSION_NUMBER | ||
ONNX Runtime is a cross-platform inference and training machine-learning accelerator.
ONNX Runtime inference can enable faster customer experiences and lower costs, supporting models from deep learning frameworks such as PyTorch and TensorFlow/Keras as well as classical machine learning libraries such as scikit-learn, LightGBM, XGBoost, etc. ONNX Runtime is compatible with different hardware, drivers, and operating systems, and provides optimal performance by leveraging hardware accelerators where applicable alongside graph optimizations and transforms. Learn more →
ONNX Runtime training can accelerate the model training time on multi-node NVIDIA GPUs for transformer models with a one-line addition for existing PyTorch training scripts. Learn more →
Get Started & Resources
-
General Information: onnxruntime.ai
-
Usage documention and tutorials: onnxruntime.ai/docs
-
YouTube video tutorials: youtube.com/@ONNXRuntime
-
Companion sample repositories:
- ONNX Runtime Inferencing: microsoft/onnxruntime-inference-examples
- ONNX Runtime Training: microsoft/onnxruntime-training-examples
Build Pipeline Status
| System | CPU | GPU | EPs |
|---|---|---|---|
| Windows | |||
| Linux | |||
| Mac | |||
| Android | |||
| iOS | |||
| WebAssembly |
Data/Telemetry
Windows distributions of this project may collect usage data and send it to Microsoft to help improve our products and services. See the privacy statement for more details.
Contributions and Feedback
We welcome contributions! Please see the contribution guidelines.
For feature requests or bug reports, please file a GitHub Issue.
For general discussion or questions, please use GitHub Discussions.
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
License
This project is licensed under the MIT License.