Operator Information Definition
Principles
The operator information library, one of the deliverables for operator development, mainly describes the implementation specifications of operators in the Ascend AI Processor, including the input and output dtype, format, and input shape supported by operators. During network running, FE performs basic verification based on the operator information in the operator information library (including information such as dtype and format), and finds the corresponding operator implementation file based on the information, and builds the implementation file to to generate the operator binary file.
Configuration Description
You need to configure the operator information library file to register the operator implementation information in the Ascend AI Processor to the operator information library file.
Path of the operator information library file: /tbe/op_info_cfg/ai_core/<soc_version>/xx.ini under the custom operator project directory
For details about the configuration rules, see Table 8-1.
Information |
Required or Optional |
Description |
[OpType] |
Required |
Operator type, which defines the start of operator information and is the same as the value of OpType in REG_OP(OpType) in Operator Prototype Definition. |
input0.name |
Required |
Name of input0, which must be the same as that in the Operator Prototype Definition. If input0.paramType is set to dynamic, set input0.name to x. The name of x must be the same as that in Operator Prototype Definition. When the graph is running, x0, x1, x2, and so on are automatically generated based on the number of inputs. The inputs are numbered starting at 0 in ascending order. |
input0.paramType |
Required |
Type of the input0.
Defaults to required. |
input0.dtype |
Optional |
Data types supported by input0. If multiple data types are supported, separate them with commas (,). The options are as follows: float16, float, int8, int16, int32, uint8, uint16, uint32, bool, and more Notes:
|
input0.format |
Optional |
Format of the input0.
Note:
|
input0.reshapeType |
Optional |
Dimension padding method for input0. If the input data format of the operator is NC1HWC0, but the operator input on the original network is not 4D input, you need to set this parameter to pad the non-4D shape on the original network to 4D shape according to the following rules:
If this parameter is not set and the operator input format must be NC1HWC0:
|
input0.shape |
Optional |
Shapes supported by input0.
|
input1.name |
Optional |
If the operator has multiple input tensors, add the configurations of input1.xx and input2.xx by referring to the parameter configuration of input0.xx. The inputs are numbered starting at 0 in ascending order. Name of the input tensor, which must be the same as that in the operator prototype definition. |
...... |
Optional |
Configuration for other input parameters of input1. Configure other inputs (input1, input2, input3, ...) of the operator by referring to input0, if any. |
attr.list |
Optional |
List of operator attributes required for operator implementation. Separate multiple attributes by commas (,). The attribute sequence must be consistent with the operator declaration. The list is used by FE to obtain the corresponding attributes from OpDesc. Example: stride,padding Note: This parameter needs to be configured if related attributes are required in the operator implementation. Otherwise, build fails. |
attr_key.type |
Optional |
Type of an attribute. attr is a fixed prefix, and key corresponds to a specific parameter. For example: attr_stride.type=int indicates that the type attribute of the stride parameter is of the int type and the method of obtaining the operator attribute from OpDesc is GetInt. This field must correspond to the attributes in attr.list. The number of attributes in attr.list and the number of attr_key.type records to be configured must be the same.
|
attr_key.value |
Optional |
Attribute value. all indicates that all attribute values are supported. Separate multiple values by commas (,). Example: 1,3,5 This field is optional and does not affect compilation. It is used for verification during TBE precompilation. |
attr_key.paramType |
Optional |
Whether a parameter is required in OpDesc. For example, in two different scenarios of quantization and non-quantization, some parameters of the convolution operator may exist or may not exist. The value can be:
Defaults to required. |
attr_key.defaultValue |
Optional |
If attr_key.paramType is set to optional and the parameter value fails to be obtained from OpDesc, the default value of this parameter is used. Note: This parameter is invalid when attr_key.paramType is set to required. When attr_key.paramType is optional, if the value fails to be obtained from OpDesc and the defaultValue is not defined, a failure message is returned. |
output0.name |
Required |
Name of output0. If output0.paramType is set to dynamic, set output0.name to y. The name of y must be the same as that in Operator Prototype Definition. When the graph is running, y0, y1, y2, and so on are automatically generated based on the number of inputs. The outputs are numbered starting at 0 in ascending order. |
output0.paramType |
Optional |
Type of output0.
Defaults to required. |
output0.dtype |
Optional |
Data type of output0. Note:
|
output0.format |
Optional |
Format of output0.
Note:
|
output0.shape |
Optional |
Shape supports by the first output (output0)
|
output1.name |
Optional |
If the operator has multiple output tensors, add the configurations of output1.xx by referring to the parameter configuration of output0.xx. The sequence numbers increase from output1 and output2, respectively. |
opFile.value |
Optional |
Name of the operator implementation file. FE searches for the operator implementation file based on the file name. If this parameter is not specified, uppercase letters in the name are converted into underscores (_) based on the OpType field to match the operator implementation file name. For details about the mapping rule, see 1. |
opInterface.value |
Optional |
Operator implementation API name. FE calls the operator based on the API name. If this parameter is not specified, uppercase letters in the name are converted into underscores (_) based on the OpType field to match the operator API name. For details about the mapping rule, see 1. |
op.pattern |
Optional |
Defines whether an operator belongs to the broadcast, reduce, or formatAgnostic class.
|
dynamicFormat.flag |
Optional |
Defaults to false. If this parameter is set to true, the input and output dtype and format configured for the operator are ignored. The op_select_format Function API in the operator implementation file is called to obtain the input and output dtype and format supported by the operator. |
precision_reduce.flag |
Optional |
Controls the operator precision mode during ATC model conversion or network commissioning. This parameter is valid only when precision_mode is set to allow_mix_precision.
|
heavyOp |
Optional |
If set to true, heavy format inheritance happens to the operator to reduce the insertion of the format conversion operator and improve the network running efficiency. This parameter is mainly used for Cube operators. According to the inheritance logic, if the input or output format of an operator is one of the following heavy formats: NC1HWC0, C1HWNCoC0, FRACTAL_Z, FRACTAL_NZ, NDC1HWC0, FRACTAL_Z_3D, FRACTAL_Z_3D_TRANSPOSE recursively search for the connected operator of the input or output, and infer the format of the found operator to the selected heavy format. Stop format inference in the following cases:
Defaults to false. |
After the custom operator information library file is compiled and deployed, the operator definition information is stored in the operator information library of the corresponding version of the Ascend AI Processor. The default storage directory is opp/op_impl/custom/ai_core/tbe/config/<soc_version>/aic-<soc_version>-ops-info.json.
op_select_format Function
If dynamicFormat.flag is set to true, you do not need to configure the dtype and format supported by the operator input and output in the operator information library file. Instead, you need to implement the op_select_format function in the operator implementation file (*.py) to infer the dtype and format supported by the operator input and output.
The op_select_format function is defined as follows:
def op_select_format(input, output, attr, kernel_name="xx"):
The input parameters of the op_select_format function are consistent with those of the operator interface (that is, the input, output, attributes, and kernel_name of the operator). The output parameters are a character string containing the lists of formats and data types supported by the input and output of the current operator in the following format:
{ "input0": { "name": "x", "dtype": "float16,float16,int8,int8", "format": "NC1HWC0_C04,NC1HWC0,NC1HWC0_C04,NC1HWC0" }, "input1": { "name": "y", "dtype": "float16,float16,int8,int8", "format": "FRACTAL_Z_C04,FRACTAL_Z,FRACTAL_Z_C04,FRACTAL_Z" }, "output0": { "name": "z", "dtype": "float16,float16,int32,int32", "format": "NC1HWC0,NC1HWC0,NC1HWC0,NC1HWC0" } }
For details about the implementation sample, see (Optional) op_select_format Function Implementation.