This document provides a detailed description of the MXNet-TensorRT runtime integration feature. This document covers advanced techniques, contains a roadmap reflecting the current state of the feature and future directions, and also contains up-to-date benchmarks. If you'd like a quick overview of the feature with a tutorial describing a simple use-case please refer to this MXNet hosted tutorial. For more information you may also visit the original design proposal page.
Table of Contents
Why is TensorRT integration useful?
...
https://jira.apache.org/jira/browse/MXNET-1085
Conditional Checkout and Compilation of Dependencies
TensorRT integration required us to add a number of third party code sub-repositories to the project. This is not ideal for users who would like to checkout and build MXNet without using the TensorRT feature. In the future we should migrate the feature to be CMake only, and checkout the project at pre-compilation time to avoid forcing all users to checkout these subrepos. We can also model these dependencies using CMake such that they're automatically built and linked against when required, which would make building from scratch easier for those that do want to use TensorRT integration.
Make use of Cached TRT Engines
Similar to the cudnn auto-tuning feature we've received requests from users that we cache TensorRT engine compilations so that we avoid the delay of building the engine each time we start the process.
Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key MXNET-1152
Increased Operator (/Layer) Coverage
...
Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key MXNET-1086
Decouple NNVM to ONNX from NNVM to TensorRT in MXNet
Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key MXNET-1252
The current nnvm_to_onnx classes are tightly coupled to TensorRT. We could extract all of the TensorRT specific functionality and have a proper separation between nnvm_to_onnx and onnx_to_tensorrt. When structuring nnvm_to_onnx we should make use of object hierarchy to convert to specific opsets of onnx to help us maintain compatibility with different toolsets. We should create a base class that performs generic onnx conversions. We should then specialized objects that inherit from the base onnx class and take care of the differences between opsets. We should also create unit tests on a per-op basis to make sure we're introducing regressions.
Currently supported operators:
Operator Name | Operator Description | Status |
---|---|---|
Convolution | Complete | |
BatchNorm | Complete | |
elemwise_add | Complete | |
elemwise_sub | Complete | |
elemwise_mul | Complete | |
rsqrt | Complete | |
Pad | Complete | |
mean | Complete | |
FullyConnected | Complete | |
Flatten | Complete | |
SoftmaxOutput | Complete | |
Activation | relu, tanh, sigmoid | Complete |
Operators to be added:
Operator Name | Operator Description | Status |
---|---|---|
Deconvolution Op | Required for several Computer Vision models. | In Progress |
elemwise_div | Required for some Wavenet implementations. | In Progress |
Benchmarks
TensorRT is still an experimental feature, so benchmarks are likely to improve over time. As of Oct 11, 2018 we've measured the following improvements which have all been run with FP32 weighted networks.
Model Name | Relative TensorRT Speedup | Hardware |
---|---|---|
cifar_resnet20_v2 | 1.21x | Titan V |
cifar_resnext29_16x64d | 1.26x | Titan V |
Resnet 18 | 1.8x | Titan V |
Resnet 18 | 1.54x | Jetson TX1 |
Resnet 50 | 1.76x | Titan V |
Resnet 101 | 1.99x | Titan V |
Alexnet | 1.4x | Titan V |
Related articles
https://mxnet.incubator.apache.org/tutorials/tensorrt/inference_with_trt.html
...