Skip to content
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

Merged
merged 36 commits into from
Jul 13, 2021

Conversation

matteosal
Copy link
Contributor

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

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>
@matteosal
Copy link
Contributor Author

@askhade I managed to write the adapters for the deprecated operators (Scatter and Upsample), removing the deprecated node and creating a new one as you suggested. But it required quite a bit of work, as I had to make all adapters return the current node and change how the converter loops through the nodes.

This PR should be fully ready now.

@matteosal
Copy link
Contributor Author

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.

@postrational
Copy link
Contributor

postrational commented Jun 18, 2021

Please add instructions about creating a converter adapter to the docs.
Preferably here:
https://github.com/onnx/onnx/blob/master/docs/AddNewOp.md
Or here:
https://github.com/onnx/onnx/blob/master/docs/Versioning.md#operator-versioning

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>
@matteosal matteosal requested a review from a team as a code owner June 18, 2021 13:03
@matteosal
Copy link
Contributor Author

Please add instructions about creating a converter adapter to the docs.
Preferably here:
https://github.com/onnx/onnx/blob/master/docs/AddNewOp.md
Or here:
https://github.com/onnx/onnx/blob/master/docs/Versioning.md#operator-versioning

Sorry, I forgot about that. Done

@matteosal
Copy link
Contributor Author

Any news on this?

Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
Signed-off-by: Matteo Salvarezza <matteo.salvarezza@gmail.com>
@matteosal
Copy link
Contributor Author

@askhade @postrational @gramalingam another ping on this

@matteosal
Copy link
Contributor Author

@askhade @postrational @gramalingam can we please move this forward? It's been more than 6 months since the original PR

@askhade askhade added this to the 1.10 milestone Jul 12, 2021
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
Copy link
Contributor

@askhade askhade Jul 12, 2021

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

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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:

  1. A new op is introduced but an automatic upgrade test is not added
  2. 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;
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

@matteosal matteosal Jul 13, 2021

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;
Copy link
Contributor

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?

Copy link
Contributor Author

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).

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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>
@gramalingam gramalingam merged commit 39c21b2 into onnx:master Jul 13, 2021
@matteosal matteosal deleted the feature/VersionConverterTests branch April 26, 2023 12:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants