-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Subgraph extraction in ONNX models #4107
Subgraph extraction in ONNX models #4107
Conversation
The subgraph extraction flow:
|
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.
...
ngraph/frontend/onnx_import/src/editor/detail/subgraph_extraction.cpp
Outdated
Show resolved
Hide resolved
ngraph/frontend/onnx_import/src/editor/detail/subgraph_extraction.cpp
Outdated
Show resolved
Hide resolved
ngraph/frontend/onnx_import/src/editor/detail/subgraph_extraction.cpp
Outdated
Show resolved
Hide resolved
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.
Very readable and well-tested implementation IMO. Great
ngraph/frontend/onnx_import/src/editor/detail/subgraph_extraction.cpp
Outdated
Show resolved
Hide resolved
ngraph/frontend/onnx_import/include/onnx_import/editor/detail/subgraph_extraction.hpp
Show resolved
Hide resolved
const int current_node_idx, | ||
const std::string& input_name) | ||
{ | ||
for (int i = current_node_idx - 1; i >= 0; --i) |
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.
Do we really need to use here the reversed order?
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're iterating over a topological order of nodes. This means that the node producing input to a given node has to be located before. This way we can start looking at the position current_node_idx - 1
and go towards the beginning of the container.
@@ -0,0 +1,120 @@ | |||
ir_version: 3 | |||
producer_name: "tomdol" |
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.
@tomdol Why do we need to have this field?
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 don't, it's optional. I can remove this field but it will require a full run of CI.
{ | ||
} | ||
|
||
const int m_node_idx; |
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 one obtain a valid value for m_node_idx? Briefly looking in the code I see that a valid value is really required but there is no way for user to deduce this index based on some user-visible name without parsing model proto file. Even Netron doesn't give this index.
Can we make it at least optional? In this case it would mean cutting by a tensor name and providing a single input for all the consumers.
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.
Similarily to the comment below - TBD in 47578
/// there are 3 possible valid instances of this struct: | ||
/// InputEdge(5, "in_A") | ||
/// InputEdge(5, "in_B") | ||
/// InputEdge(5, "in_C") |
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.
Assuming that node 5
is an operation and (in_A)
etc. are tensors, this documentation doesn't provide rationale why we are specifying node index, because there is only one consumer for each of the tensors on the schematics. In this case the tensor name should be enough to specify the cutting point.
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.
As discussed offline, this will be addressed in a separate ticket: 47578
@openvinotoolkit/openvino-ngraph-maintainers all feedback addressed. Can we merge it or should we wait for anyone else's review? |
@tomdol I propose to wait for release branch creation. Because the feature freeze happened and we don't want to have this feature in the 2021.3 release. |
Related ticket number: 45414