Add ARM64X implementation libs, to be forwarded to by the ARM64X lib.
From Ben Niu:
For system dlls that are built outside of windows repo and ingested through vpacks or binary check-ins, we always start by trying to port them to ARM64X. However, due to immature support for ARM64X build from Visual Studio 2019, it could be quite uphill to port dlls to ARM64X.
When that happens, we have an alternative without porting the dll to ARM64X. The alternative solution is, we build an ARM64X pure forwarder from windows repo, for example, onnxruntime.dll. That forwarder does nothing but forwards all the ARM64 API calls to a native ARM64 onnxruntime_arm64.dll, and all the x64 APIs to native x64 onnxruntime_amd64.dll. Please see here for an example: 29ae6ca516
At load time, applications still loads the ARM64X forwarder onnxruntime.dll. In an ARM64 process, that forwarder dll will further load the native ARM64 onnxruntime_arm64.dll; otherwise, the x64 onnxruntime_amd64.dll will be loaded, both the ARM64 and x64 dlls are happy.
The onnxruntime_arm64.dll and onnxruntime_amd64.dll are essentially aliases of their native counterparts, but we cannot directly rename existing native dlls in windows build. The reason is about PDB binplacing. If you simply rename a dll, the PDB name embedded in the dll is still unchanged. So you can imagine that if we just rename the native dlls in ARM64 windows build, there will be two renamed native dlls, onnxruntime_arm64.dll and onnxruntime_amd64.dll, sharing the same PDB name onnxruntime.pdb. When binplacing happens (basically moving dll and pdb from os\obj to os\bin), one PDB will overwrite the other. As a result, we either lose the PDB for the ARM64 dll, or the x64 dll.
That’s why we are asking to change the build pipeline to execute the link commands two extra times to produce onnxruntime_arm64/amd64.dll with different pdb names. You don’t need to do the compilation twice, but just the link. See here for an example: https://microsoft.visualstudio.com/DefaultCollection/Xbox/_git/Xbox.ShaderCompiler.WinTools/pullrequest/5291717
Related work items: #31925159
* update benchmark for transformers 4.* and ORT 1.7
* Fix gpt2 onnx conversion for transformers 4.3.*. Add a check of transformer version >= 3.1.
* remove code related to openmp
* update pretrain model list: keep representitive models only
Add providers for CoreML, ROCM, NNAPI, ArmNN
Adding the structs for OrtCUDAProviderOptions and OrtOpenVINOProviderOptions
Updating NNAPI flags.
Adding the new CoreML flag.
Adding hooks to the build system to tell Java about the new providers.
* remove tests to speed up CI
* add back _into_data_parallelism tests to see how long the CI test takes
* remove unnecessary save calls
* add back data_parallelism_full_precision_bart_path
* add data_parallelism_full_precision_path
* remove data parallelism tests
Co-authored-by: Jingyan Wang <jingywa@OrtTrainingDev3.af05slrtruoetgaxwwjv5nsq5e.px.internal.cloudapp.net>
* If unit tests are manually excluded via `--cmake_extra_defines onnxruntime_BUILD_UNIT_TESTS=OFF` (e.g. testing changes to binary size where you want to keep the build time as quick as possible) it should still be possible to create the python bindings.
Update CMakeLists.txt to decouple the inclusion of onnxruntime_python.cmake from unit tests being enabled.
Update onnxruntime_python.cmake so it works when unit tests are disabled. Also skip copying of test py files when unit tests are disabled.
* Add robust dependency check for Python package
* Add version_info.py to .gitignore
* Fix Linux build
* Fix Windows CPU build
* Fix Windows 32-bit build
* Minor tweak
* Generate version_info.py earlier in onnxruntime_python.cmake
* Print a user-friendly message if cuDNN is not found in
* Relax version requirements for CUDA 11 - only the major version has to match
* Fix PATH environment variable to include CUDA 11 in 'Python packaging pipeline' (Windows/GPU)
* Fix the build with cuDNN 7
ONNX Runtime 1.7 will the last release that will publish MCR
container images for ONNX Runtime with OpenVINO EP. From ONNX
Runtime 1.8 onwards, this will be discontinued. Users are advised
to switch to using PyPi packages or build their own containers
using dockerfiles.
* Fixes OpenVINO-EP windows build
Openvino EP build is broken on windows. The issue
is wchar_t is UTF-16 on windows while on other platforms
such as Linux and MacOS, wchar_t is UTF-32.
so wide Unicode string has to be converted to an UTF8 string
for sure on windows.
This commit fixes this issue.