Skip to content

Latest commit

 

History

History
37 lines (33 loc) · 2.43 KB

operation_enabling_flow.md

File metadata and controls

37 lines (33 loc) · 2.43 KB
Raw

OpenVINO Operation Enabling Flow

  1. Implement operation "shell" in the src/core/[src|include]/op/:

    • Implement constructor(s)
    • Implement validate_and_infer_types method which should support dynamic input tensor(s) (with partially dynamic shapes). For more information read OpenVINO Shape propagation guide
    • Implement visit_attributes method
    • Implement clone_with_new_inputs method. The generated operation version must be explicitly specified and be equal to the operation version being added
    • In *.hpp file add: 
      OPENVINO_OP("<Operation_name>", "opset_name", <Parent_op> /* Not needed if operation is inherited from ov::Op */);
      If operation is inherited from Operation with BWDCMP_RTTI_DECLARATION please add next declaration to header file: 
      BWDCMP_RTTI_DECLARATION;
    • In *.cpp if operation is inherited from Operation with BWDCMP_RTTI_DECLARATION please add: 
      BWDCMP_RTTI_DEFINITION(op::vX::<Operation>);
    • To support conditional compilation add following for each Operation method in *.cpp file: 
      OV_OP_SCOPE(<operation_version>_<operation_name>_<method_name>);
    • Add shape infer unit-tests to the src/core/tests/type_prop/

  2. Add operation to the dedicated opset file src/core/include/openvino/opsets/opsetX_tbl.hpp

  3. Implement evaluate method for the operation (reference implementation) in the openvino/core/reference/[src|include]/ngraph/runtime/reference/. Reference implementation can be called from Template plugin or from OpenVINO (src/core/src/op/your_operation_name.cpp/hpp). To not increase the binary size of openvino lib it should be placed in Template plugin unless you are directly asked to put it in the OpenVINO core. While adding reference implementation the following points should be considered:

    • The method should avoid using the template parameters if possible. However, for the small operations like activation functions it is acceptable.
    • The method should be instantiated for practical data types only.
    • If the method can be implemented without defining strict data types (for example, data movement operations like Concat or Split) then it should be implemented in a type-agnostic way.

See also