onnxruntime/docs/execution_providers
Du Li 095d55bf54
Cherry picking for Rel-1.6 (#6006)
* Update onnx (#5720)

* update onnx

* update docker image for testing
(cherry picked from commit 705d093167)

* cherry pick PR 5720

* C#: Add CreateFromMemory to FixedBufferOnnxValue to allow bind user buffers and pass custom binary compatible types (#5886)

Add CreateFromMemory to FixedBufferOnnxValue so users can bind their own custom binary compatible buffers to feed/fetch data.
(cherry picked from commit c2d610066a)

* [Java] Initial Apple Silicon support (#5891)

* Rearranging checks in onnxruntime_mlas.cmake to pickup Apple Silicon.

On an M1 Macbook Pro clang reports:

$ clang -dumpmachine
arm64-apple-darwin20.1.0

So the regex check needs to look for "arm64" first, as otherwise it
matches 32-bit ARM and you get NEON compilation failures.

* Adding Java side library loading support for Apple Silicon (and other aarch64 architectures).

* Adding Qgemm fix from @tracysh

* Fixes the java packaging on Windows.

* Missed a check in the java platform detector.
(cherry picked from commit 8b83c51a35)

* Add OpenVINO EP shared lib to Py Wheel (#5920)

* Add OpenVINO EP shared lib to Py Wheel

Include the libonnxruntime_providers_openvino.so/.dll to the wheel

* Follow libs.extend pattern as other EPs
(cherry picked from commit 40926867c3)

* Make NNAPI EP reject nodes with no-shape inputs (#5927)

(cherry picked from commit 87368655e2)

* Sahar/fix documentation shared lib (#5926)

* Update OpenVINO-ExecutionProvider.Md

update openvino-executionprovider.md for shared library

* Update Build.md

updated --build_shared_lib flag for building openvino shared provider lib

* Update Dockerfile.openvino

building for shared library with the new changes for openvino shared lib

* Revert "Update Build.md"

This reverts commit c9cf5fee76be7fdc10cadf07259f1d4ed5b45b93.

* Revert "Update Dockerfile.openvino "

This reverts commit e1624e4f93a4cfb425b6f21d7fb71b299a146740.

* Update OpenVINO-ExecutionProvider.md

fix documentation to the shared library

Co-authored-by: sfatimar <sahar.fatima@intel/com>
(cherry picked from commit 8168c91978)

* Update dockerfiles (#5929)

1. Remove conda from the images. Because conda contains a file named /opt/miniconda/lib/libcrypto.so.1.0.0 which can't pass our security scan. Also, it will be easier for us to manage the third party usage registrations.
2. Remove openssh from the images. Because the official openssh package provided by Ubuntu can't pass our security scan.
3. Reduce the image size to 1/3 by using stages. Also, because it contains less packages, it will be less often needed to update.
4. Put the LICENSE-IMAGE.txt file in right place. It is missed in current images. You can see it was added to a temp folder "/code" but it got deleted afterwards.
5. Update the CPU docker image's base image to Ubuntu 18.04. The GPU one is already 18.04. It's better to keep them the same.
6. Remove the build arg ONNXRUNTIME_REPO/ONNXRUNTIME_BRANCH. Instead, the new one always uses the local source. I feel it can reduce confusion.
(cherry picked from commit 1dbabb2362)

* Add Longformer Attention Cuda Op(#5932)

Limitation: Global tokens must be at the beginning of sequence.
(cherry picked from commit 31a6be3d67)

* Bug fix for MaskRCNN and FasterRCNN (#5935)

Signed-off-by: MaajidKhan <n.maajidkhan@gmail.com>
(cherry picked from commit e39e82b43a)

* Fix publishing pipelines. (#5942)

Fix publishing pipelines.
(cherry picked from commit c4b55d29fe)

* Fix Python Linux GPU package name (#5943)

Fix Python Linux GPU package name. I accidentally added "noopenmp" to it.

(cherry picked from commit 5fdd9f0fd2)

* Update BUILD.md with shared provider information (#5944)

* Update build instructions to include information about shared providers

(cherry picked from commit 27513d1fd7)

* [OpenVINO]Fix memory leak in `IsDebugEnabled()` under Windows (#5948)

* w

* w

Co-authored-by: modav <modav@microsoft.com>
(cherry picked from commit e207589631)

* Add support for Python 3.8+ on Windows when CUDA is enabled (#5956)

(cherry picked from commit 015fbb3dbb)

* Support the cross compiling for Apple Silicon (#5974)

* support macos_arm64 cross compiling

* update the build docs

* update as commented.

* Update BUILD.md
(cherry picked from commit 2ec211ea7b)

* Update docker files to put 'unattended-upgrades' in a right place(#5983)

(cherry picked from commit 3323fb6082)

* Enable the xcode build for Apple Silicon (arm64 MacOS) (#5924)

* fix the build script for macos/xcode

* add the version check

* correct the osx-arch configuration

* typo
(cherry picked from commit 1852ade75d)

* Add python 3.9 support (#5874)

1. Add python 3.9 support(except Linux ARM)
2. Add Windows GPU python 3.8 to our packaging pipeline.

* Revert some pipeline changes in #5874

Co-authored-by: Ashwini Khade <askhade@microsoft.com>
Co-authored-by: Du Li <duli@OrtTrainingDev0.af05slrtruoetgaxwwjv5nsq5e.px.internal.cloudapp.net>
Co-authored-by: Dmitri Smirnov <yuslepukhin@users.noreply.github.com>
Co-authored-by: Adam Pocock <craigacp@gmail.com>
Co-authored-by: S. Manohar Karlapalem <manohar.karlapalem@intel.com>
Co-authored-by: Guoyu Wang <62914304+gwang-msft@users.noreply.github.com>
Co-authored-by: sfatimar <64512376+sfatimar@users.noreply.github.com>
Co-authored-by: Changming Sun <chasun@microsoft.com>
Co-authored-by: Tianlei Wu <tlwu@microsoft.com>
Co-authored-by: Maajid khan <n.maajidkhan@gmail.com>
Co-authored-by: Ryan Hill <38674843+RyanUnderhill@users.noreply.github.com>
Co-authored-by: Moshe David <mosdav165@gmail.com>
Co-authored-by: Ivan Stojiljkovic <17503404+ivanst0@users.noreply.github.com>
Co-authored-by: Wenbing Li <10278425+wenbingl@users.noreply.github.com>
2020-12-02 13:45:20 -08:00
..
images Updated docs: Execution Provider overview (#5328) 2020-10-06 15:01:25 -07:00
ACL-ExecutionProvider.md Updating EP docs with Onnxruntime API calls (#5503) 2020-10-19 12:21:21 -07:00
ArmNN-ExecutionProvider.md Updating EP docs with Onnxruntime API calls (#5503) 2020-10-19 12:21:21 -07:00
DirectML-ExecutionProvider.md Switch to unified DirectML 1.4.0 redistributable (#5794) 2020-11-17 13:42:23 -08:00
DNNL-ExecutionProvider.md Updating EP docs with Onnxruntime API calls (#5503) 2020-10-19 12:21:21 -07:00
MIGraphX-ExecutionProvider.md Updating EP docs with Onnxruntime API calls (#5503) 2020-10-19 12:21:21 -07:00
MKL-DNN-Subgraphs.md Renaming MKL-DNN as DNNL (#2515) 2019-12-03 07:34:23 -08:00
NNAPI-ExecutionProvider.md Updating EP docs with Onnxruntime API calls (#5503) 2020-10-19 12:21:21 -07:00
Nuphar-ExecutionProvider.md Updating EP docs with Onnxruntime API calls (#5503) 2020-10-19 12:21:21 -07:00
OpenVINO-ExecutionProvider.md Cherry picking for Rel-1.6 (#6006) 2020-12-02 13:45:20 -08:00
README.md Updated docs: Execution Provider overview (#5328) 2020-10-06 15:01:25 -07:00
RKNPU-ExecutionProvider.md Updating EP docs with Onnxruntime API calls (#5503) 2020-10-19 12:21:21 -07:00
TensorRT-ExecutionProvider.md Use flatbuffers for INT8 calibration table (de)serialization in TensorRT EP (#5873) 2020-11-19 21:41:12 -08:00
Vitis-AI-ExecutionProvider.md [Vitis-AI EP] Fix to enable multi-output subgraphs inside Vitis-AI EP + edit docs (#4171) 2020-06-13 04:56:07 -07:00

Introduction

ONNX Runtime is capable of working with different HW acceleration libraries to execute the ONNX models on the hardware platform. ONNX Runtime supports an extensible framework, called Execution Providers (EP), to integrate with the HW specific libraries. This interface enables flexibility for the AP application developer to deploy their ONNX models in different environments in the cloud and the edge and optimize the execution by taking advantage of the compute capabilities of the platform.

Executing ONNX models across different HW environments

ONNX Runtime works with the execution provider(s) using the GetCapability() interface to allocate specific nodes or sub-graphs for execution by the EP library in supported hardware. The EP libraries that are preinstalled in the execution environment processes and executes the ONNX sub-graph on the hardware. This architecture abstracts out the details of the hardware specific libraries that are essential to optimizing the execution of deep neural networks across hardware platforms like CPU, GPU, FPGA or specialized NPUs.

ONNX Runtime GetCapability()

ONNX Runtime supports many different execution providers today. Some of the EPs are in GA and used in live service. Many are in released in preview to enable developers to develop and customize their application using the different options.

Adding an Execution Provider

Developers of specialized HW acceleration solutions can integrate with ONNX Runtime to execute ONNX models on their stack. To create an EP to interface with ONNX Runtime you must first identify a unique name for the EP. Follow the steps outlined here to integrate your code in the repo.

Building ONNX Runtime package with EPs

The ONNX Runtime package can be built with any combination of the EPs along with the default CPU execution provider. Note that if multiple EPs are combined into the same ONNX Runtime package then all the dependent libraries must be present in the execution environment. The steps for producing the ONNX Runtime package with different EPs is documented here.

APIs for Execution Provider

The same ONNX Runtime API is used across all EPs. This provides the consistent interface for applications to run with different HW acceleration platforms. The APIs to set EP options are available across Python, C/C++/C#, Java and node.js. Note we are updating our API support to get parity across all language binding and will update specifics here.

`get_providers`: Return list of registered execution providers.
`get_provider_options`: Return the registered execution providers' configurations.
`set_providers`: Register the given list of execution providers. The underlying session is re-created. 
    The list of providers is ordered by Priority. For example ['CUDAExecutionProvider', 'CPUExecutionProvider']
    means execute a node using CUDAExecutionProvider if capable, otherwise execute using CPUExecutionProvider.

Using Execution Providers

import onnxruntime as rt

#define the priority order for the execution providers
# prefer CUDA Execution Provider over CPU Execution Provider
EP_list = ['CUDAExecutionProvider', 'CPUExecutionProvider']

# initialize the model.onnx
sess = rt.InferenceSession("model.onnx", providers=EP_list)

# get the outputs metadata as a list of :class:`onnxruntime.NodeArg`
output_name = sess.get_outputs()[0].name

# get the inputs metadata as a list of :class:`onnxruntime.NodeArg`
input_name = sess.get_inputs()[0].name

# inference run using image_data as the input to the model 
detections = sess.run([output_name], {input_name: image_data})[0]

print("Output shape:", detections.shape)

# Process the image to mark the inference points 
image = post.image_postprocess(original_image, input_size, detections)
image = Image.fromarray(image)
image.save("kite-with-objects.jpg")

# Update EP priority to only CPUExecutionProvider
sess.set_providers('CPUExecutionProvider')

cpu_detection = sess.run(...)