-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ONNX] Add ONNX specific FrontEnd classes #6615
[ONNX] Add ONNX specific FrontEnd classes #6615
Conversation
This change implements a subset of FrontEnd API for ONNX: Changes: - move onnx_common, onnx_editor and onnx_import to ngraph/frontend/onnx - introduce new target 'onnx_frontend_ngraph' located in ngraph/frontend/onnx/frontend - new target implements subset of FrontEnd, InputModel and Place interfaces
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rebase to latest master, I see other PR for static protobuf is already merged
ngraph/frontend/onnx/onnx_editor/include/onnx_editor/editor.hpp
Outdated
Show resolved
Hide resolved
ngraph/frontend/onnx/frontend/include/onnx_frontend/input_model.hpp
Outdated
Show resolved
Hide resolved
f066db1
to
15df53a
Compare
return ret; | ||
} | ||
|
||
Place::Ptr InputModelONNX::get_place_by_tensor_name(const std::string& tensor_name) const |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will these methods implement some use case for Model Optimizer conversion? I can't find Place::is_equal
implementation which is mandatory for options like '--input'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be done in separate PR
@@ -121,7 +121,7 @@ else() | |||
endif() | |||
|
|||
ie_dependent_option(NGRAPH_ONNX_IMPORT_ENABLE "Enable ONNX importer" ON "protoc_available" OFF) | |||
ie_dependent_option(NGRAPH_ONNX_EDITOR_ENABLE "Enable ONNX Editor" ON "NGRAPH_ONNX_IMPORT_ENABLE" OFF) | |||
ie_dependent_option(NGRAPH_ONNX_FRONTEND_ENABLE "Enable ONNX FrontEnd" OFF "NGRAPH_ONNX_IMPORT_ENABLE" OFF) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can frontend be enabled by default everywhere when NGRAPH_ONNX_IMPORT_ENABLE is ON? This is to make sure that 'frontend' can be correctly built on all supported platforms
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, don't see a reason how have multiple options about the similar stuff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can frontend be enabled by default everywhere when NGRAPH_ONNX_IMPORT_ENABLE is ON?
That'd make MO to use ONNX frontend by default, which I don't think we want it yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, maybe set name for onnx frontend as something temporary, like "onnx_experimental"? So that it will not conflict with legacy 'onnx' name in MO. I just want to be sure that there are no build issues of onnx frontend on supported platforms
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can frontend be enabled by default everywhere when NGRAPH_ONNX_IMPORT_ENABLE is ON? This is to make sure that 'frontend' can be correctly built on all supported platforms
The feature is currently under development. We have separate PRs for testing against CI with the feature turned ON and we'll merge them after we complete the feature. For now the feature will be turned OFF be defautlt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can we merge changes when we don't know if they are even compilable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We manually enable NGRAPH_ONNX_FRONTEND_ENABLE=ON
in a number of CI environments. We are just not ready to turn it on by default, especially in the context of Model Optimizer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we measure what is the binary size for all ONNX related libraries modified by this PR in comparison to master version?
ngraph/frontend/frontend_manager/include/frontend_manager/frontend.hpp
Outdated
Show resolved
Hide resolved
ngraph/frontend/onnx/frontend/include/onnx_frontend/input_model.hpp
Outdated
Show resolved
Hide resolved
std::int64_t get_opset_version(const ONNX_NAMESPACE::ModelProto& model_proto, | ||
const std::string& domain); | ||
|
||
class Model |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we merge a separate onnx_import directly to ONNX FE and prepare for onnx_import API deprecation having ONNX FE as a replacement that is aligned with other FWs? In this case this Model class as well as others become a kind of internal API inside ONNX FE.
ngraph/frontend/onnx/onnx_import/include/onnx_import/utils/onnx_internal.hpp
Show resolved
Hide resolved
extern "C" FRONTEND_API void* GetFrontEndData() | ||
{ | ||
FrontEndPluginInfo* res = new FrontEndPluginInfo(); | ||
res->m_name = "onnx"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My proposal is to change this name to 'onnx_experimental' so that MO will not try to use it for existing 'onnx' model conversion.
And also it will be possible to enable this by default in CI, and it would be possible to remove 'onnx_reader' from build to verify that ONNX models are converted via frontends path
onnx_frontend branch: |
You can add into onnx CI such test that total size of libs <= NNN |
We will address your idea about package refactoring in a separate PR.
This change implements a subset of FrontEnd API for ONNX: Changes: - move onnx_common, onnx_editor and onnx_import to ngraph/frontend/onnx - introduce new target 'onnx_frontend_ngraph' located in ngraph/frontend/onnx/frontend - new target implements subset of FrontEnd, InputModel and Place interfaces
This change implements a subset of FrontEnd API for ONNX: Changes: - move onnx_common, onnx_editor and onnx_import to ngraph/frontend/onnx - introduce new target 'onnx_frontend_ngraph' located in ngraph/frontend/onnx/frontend - new target implements subset of FrontEnd, InputModel and Place interfaces
This change implements a subset of FrontEnd API for ONNX: Changes: - move onnx_common, onnx_editor and onnx_import to ngraph/frontend/onnx - introduce new target 'onnx_frontend_ngraph' located in ngraph/frontend/onnx/frontend - new target implements subset of FrontEnd, InputModel and Place interfaces
This change implements a subset of FrontEnd API for ONNX:
Changes:
Ticket: 51678