This repository has been archived by the owner on Nov 17, 2023. It is now read-only.
[MXNET-652] Allow for multi-context input to load gluon models from onnx #11637
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Currently, Airbnb is developing applications that use mxnet(particularly
gluon
). We use themxnet.contrib.onnx
package, which supports importing to gluon from ONNX format. As this is an extremely important part of our pipeline, we want to add support to multi-gpu imports, which is currently not supported.This is actually a very simple change, because
_load_init()
already supports, directly, aContext
object or an iterable of them. However, the current implementation forimport_to_gluon
suggests astr
of'CPU'
or'GPU'
. This is not only different from other parts of the mxnet codebase, but also does not allow us to specify which gpu's we want to load the model into. I am aware that this is to comply with ONNX, but the abstraction should be handled at the abstraction layer, not the core utility for importing ONNX to gluon.Checklist
Essentials
Please feel free to remove inapplicable items for your PR.
Changes
Comments
ctx
as an arg for a large portion of the core library. There doesn't seem to be any significant reason for why thecontrib.onnx
code usesstr
instead, rather than it being a minor oversight that passed PR's.