You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/AddNewOp.md
+7-2Lines changed: 7 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@
14
14
15
15
# Proposing and submitting a new operator or function to ONNX <aname="new_operator_or_function"></a>
16
16
17
-
Operators are the basic building blocks that define ONNX model. With a rich set of operators, ONNX can describe most DNN and ML models from various frameworks. Functions allow for composing complex operators from more primitive operators. The ONNX specification includes a core set of operators that enable many models. It is a non-goal to add all possible operators, however more operators are added as needed to cover evolving needs.
17
+
Operators are the basic building blocks used to define ONNX models. With a rich set of operators, ONNX can describe most DNN and ML models from various frameworks. Functions enable expressing complex operators in terms of more primitive operators. The ONNX specification includes a core set of operators that enable many models. It is a non-goal to add all possible operators, however more operators are added as needed to cover evolving needs.
18
18
19
19
In this document, we describe the process of accepting a new proposed operator and how to properly submit a new operator as part of ONNX standard. The goal is to improve on what we currently have based on our experience, learning and feedbacks we gathered from the community.
20
20
@@ -26,14 +26,19 @@ In this document, we describe the process of accepting a new proposed operator a
26
26
27
27
## Step 1: Proposing a new operator/function <aname="step1_new_operator_or_function"></a>
28
28
In order to propose a new operator/function, the following is needed:
29
-
1. If the operator can be composed by other ONNX operators, then it should be a function and not an operator (we have a function in ONNX : MeanVarianceNormalization).
29
+
1. If the operator can be expressed in terms of other ONNX operators, then it should be a function and not an operator (we have a function in ONNX : MeanVarianceNormalization).
30
30
2. If the operators can be split to new primitives, propose those primitives instead and make the operator a function.
31
31
3. Based on a model. This will help us understand the usage and that it solves an actual problem. For the case of the model being private or IP and can't be shared, the operator doesn't belong to the standard and should be implemented as custom OP.
32
32
4. The operator needs to be implemented by at-least one (well-known) framework. This help us to understand the actual behavior of the operator and its usage.
33
33
5. Operator signature and behavior:
34
34
1. If the operator is available in numpy, prefer numpy semantics.
35
35
2. If the operator is available in more than one frameworks, make sure that your design is general and cover those frameworks.
36
36
6. Prefer attributes over inputs.
37
+
7. The operator should not be made more complex than is required by the use-cases. However, the operator
38
+
should be made as general as possible, as long as it does not make the implementation more complex.
39
+
This requires carefully balancing generality and complexity. For example, generalizing from 3-D tensors to
40
+
N-D tensors is straight-forward (implementation-wise) for some operators, but complex for other operators.
41
+
The choice in such cases will be made based on the complexity of such a generalization.
Once the criteria of proposing new operator/function has been satisfied, you will need to submit a PR for the new operator/function. Here the expectation of what the PR should include. The reviewer is expected to verify the completeness of the PR before signoff.
0 commit comments