An OperatorProto represents the immutable specification of the signature and semantics of an operator.
An OperatorProto represents the immutable specification of the signature and semantics of an operator.
Operators are declared as part of an OperatorSet, which also defines the domain name for the set.
Operators are uniquely identified by a three part identifier (domain, op_type, since_version) where *domain* is the domain of an operator set that contains this operator specification.
*op_type* is the name of the operator as referenced by a NodeProto.op_type
*since_version* is the version of the operator set that this operator was initially declared in.
The name of the operator within a domain. This field MUST be present in this version of the IR.
The version of the operator set that first introduced this operator. This value MUST be the same value as the opset_version of the operator set that first published this operator. Subsequent versions of the operator set MUST NOT alter the signature or semantics of the operator once published as STABLE. This field MUST be present in this version of the IR.
This field indicates whether the syntax, semantics, or presence of this operator is in an experimental or stable stage. Once an operator is published as STABLE, it's syntax and semantics MUST NOT change in subsequent versions of the operator set. When an operator is published as EXPERIMENTAL, the syntax and semantics of the operator MAY change across operator set versions. Operators "become" stable by deprecating the experimental version and introducing a new stable operator with the same op_type.
A human-readable documentation for this operator. Markdown is allowed.
An OperatorSetProto represents an immutable set of immutable operator specifications.
An OperatorSetProto represents an immutable set of immutable operator specifications.
The domain of the set (OperatorSetProto.domain) is a reverse-DNS name that disambiguates operator sets defined by independent entities.
The version of the set (opset_version) is a monotonically increasing integer that indicates changes to the membership of the operator set.
Operator sets are uniquely identified by a two part identifier (domain, opset_version)
Like ModelProto, OperatorSetProto is intended as a top-level file/wire format, and thus has the standard format headers in addition to the operator set information.
All OperatorSetProtos start with a distingushed byte sequence to disambiguate protobuf files containing OperatorSets from other content. This field MUST be "ONNXOPSET" This field MUST be present in this version of the IR
All OperatorSetProtos indicate the version of the IR syntax and semantics they adhere to. It is always IR_VERSION. This field MUST be present in this version of the IR
The prerelease component of the SemVer of the IR. This field MAY be absent in this version of the IR
The build metadata component of the SemVer of the IR. This field MAY be absent in this version of the IR
Domain name of the operator set, in reverse DNS form (e.g., com.acme.dnnops).
The version of the set of operators. This is a simple int value that is monotonically increasing as new versions of operator set are published. All operators in this set MUST have version numbers no greater than opset_version.
A human-readable documentation for this set of operators. Markdown is allowed.
The operators specified by this operator set. The (name, version) MUST be unique across all OperatorProtos in operator
The functions specified by this operator set. The (name, version) MUST be unique across all OperatorProtos/FunctionProtos in operator/functions
Operator/function status.
The name of the function, similar usage of op_type in OperatorProto.
The first version of a function set which contains this function. When there's any breaking change for this function, the function set contains the function needs to bump its version, and since_version of the updated function will be changed to the updated function set version.
This field indicates whether the syntax, semantics, or presence of this function is in an experimental or stable stage. Once an function is published as STABLE, its syntax and semantics MUST NOT change in subsequent versions of the operator set. When a function is published as EXPERIMENTAL, the syntax and semantics of the function MAY change across operator set versions. Functions "become" stable by deprecating the experimental version and introducing a new stable function with the same name.
The inputs and outputs of the function.
The attributes of the function.
The nodes in the function.
A human-readable documentation for this function. Markdown is allowed.