-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
New version converter tests #3344
New version converter tests #3344
Conversation
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
@askhade I managed to write the adapters for the deprecated operators ( This PR should be fully ready now. |
I have encountered another issue with the version converter: #3529 It would be nice to discuss a solution for that while this PR is under review, so that a fix could be hopefully added here. |
Please add instructions about creating a converter adapter to the docs. |
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Sorry, I forgot about that. Done |
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Any news on this? |
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
@askhade @postrational @gramalingam another ping on this |
@askhade @postrational @gramalingam can we please move this forward? It's been more than 6 months since the original PR |
docs/AddNewOp.md
Outdated
@@ -49,10 +49,11 @@ Once the criteria of proposing new operator/function has been satisfied, you wil | |||
1. The testing examples will be extracted to the doc. | |||
2. We also generate binary data for it. | |||
3. Example: https://github.com/onnx/onnx/blob/master/onnx/backend/test/case/node/abs.py | |||
5. Update the documentation and generate the test data. | |||
5. Add at least one automatic upgrade test for your operator in https://github.com/onnx/onnx/blob/master/onnx/test/automatic_upgrade_test.py |
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.
Is this step required for new operator?
In case of op updates, what happens if automatic upgrade is not possible?
Can you add more clarification in the doc
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.
I see some details are present in Versioning.md... can you add them here as well as people generally use this doc to understand all the steps involved
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.
Is this step required for new operator?
Yes because the new tests check that all operators are tested at least once (test_ops_tested
)
In case of op updates, what happens if automatic upgrade is not possible?
What do you mean by this? As long as the old op's functionality is a subset of the new one's, upgrade is always possible. Maybe the only case in which this got violated is batch_normalization_13_14.h
which I added in this PR (opset 14 disabled outputs 4 and 5). Currently the automatic upgrade tests are not testing this upgrade path (they are FAR from testing all the possible upgrade paths from all possible settings for all ops anyways). In the future we can extend these new tests to also add upgrade paths which are expected to fail at some step.
Can you add more clarification in the doc
I see some details are present in Versioning.md... can you add them here as well as people generally use this doc to understand all the steps involved
Versioning.md says to add an adapter whenever a change is made (and don't add a test because the automatic tests will test the adapter), while this is about adding a test whenever a new op is introduced (and don't add an adapter because there's nothing to adapt), so I don't see much overlap. But I have added more information about the basic idea of the new tests.
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.
thanks for the clarification.
How are we enforcing\gating PRs on these tests... Will these tests run as part of python test suite and fail if someone did not add a test for new op?
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.
thanks for the clarification.
How are we enforcing\gating PRs on these tests... Will these tests run as part of python test suite and fail if someone did not add a test for new op?
Yes. The CI will fail in these 2 cases:
- A new op is introduced but an automatic upgrade test is not added
- An op is changed but an upgrade adapter is not added
@@ -26,7 +26,7 @@ class Adapter { | |||
target_version_(target_version) { | |||
} | |||
|
|||
virtual void adapt(std::shared_ptr<Graph> /*graph*/, Node* node) const = 0; | |||
virtual Node* adapt(std::shared_ptr<Graph> /*graph*/, Node* node) const = 0; |
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.
does this create a new Node and returns it? Can you add comments for this mtd
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.
I had to make this change because in case of deprecated operators we have to destroy the current node and replace it with another one. Since the new node is referenced via its pointer even after adapt
is called, adapt
has to return the pointer. But 99% of the time (when the node is preserved and only its attributes/inputs/outputs are changed) the returned pointer is the same as the argument.
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.
you have graph and mutable Node* can you not create a new node and point Node* to this new node?
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.
Yes but why bother to create a new node, copy all the attributes/inputs/outputs of the old node to the new one and destroying the old node in all adapters when we can almost always modify the old node in place? That's how the adapters have always worked up to just before this PR. I have added the possibility of returning a different node only to deal with deprecated operators. I have added a comment to clarify this
adapt_argmax_argmin_12_11(node); | ||
return node; |
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.
I dont understand the point of this change.... input Node* node is not const, it is mutable then why return the same node?
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.
See the other reply. All adapters return the same node except adapters for deprecated operators (upsample_9_10.h, scatter_10_11.h).
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.
what is the difficulty in changing say Upsample Node to Resize Node in place? I remember you mentioned it was not possible... cant remember what is the exact reason
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.
I just couldn't find a way to do it. Which doesn't mean it can't be done, but kind_
is private in the definition of Node
and it didn't seem designed to be changed to me. If that's possible I'll revert this change and modify the nodes in place for the deprecated ops.
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.
So, I guess it is a matter of changing kind_ to be non-constant, and adding a method to SetKind in a Node?
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 seems likely that they didn't anticipate a need to change the operation. But generalizing it to allow it seems reasonable, but I understand your concern whether it might cause some unanticipated problem.
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.
Looking at the (existing) code it is not clear to me what NodeKind is exactly meant for... It is not exactly similar to op_type since it includes popular attribute names and such... and while it includes most of the ops it does not include all... will need to check the usage of Kind through out version converter and optimizer code to understand whether we should add a setter for kind_.
I am OK with the current change now. There are some fundamental changes that need to happen to version converter (updates post IRv3 .i.e allow initializers not included as inputs) soon and we can reconsider this when we take up that task.
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.
I am fine with using the current API to play it safe.
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
A subset of this PR which was split in two parts as requested: #3243
This part contains the new version converter tests
The other part containing the adapters is: #3343