A Node represents a composable entity for executing certain processing steps. Its interface is described by the following information:
Each node type offers a custom set of Parameters to configure each instance. Nevertheless a factory function is provided for uniform instantiation (see dw::framework::createNode() and dw::framework::NodeConcept::create()).
Each port is identified by a unique name and the C++ data type. Input and output port names are in different namespaces though, meaning that both an input and output port can have the same name. An input port of a node receives data from somewhere, while an output port of a node provides data to somewhere
See dw::framework::NodeConcept::describeInputPorts() and dw::framework::NodeConcept::describeOutputPorts() for details on the API.
A port can be declared as an array port which represents N ports with the same data type. The name of the individual ports of the array are identified with the suffix [0]
, ..., [N-1]
.
By default all ports are considered optional, they might or might not be connected to another endpoint. An input port can have an additional flag that it is required-to-be-connected to a data source in order for the node to be considered to be in a valid state.
Each pass is identified by a unique name. A pass is an undivisible unit of execution and declares a single processor type to be used for that operation. Passes within a node can exchange information through member variables of the node.
See dw::framework::NodeConcept::describePasses() for details on the API.
Commonly a pass invokes API provided by a DriveWorks module which implements the actual processing logic.
Note: a pass is not supposed to spawn its own threads, since that responsibility lies with the scheduler of the application.
By default all passes of a node are executed sequentially but optionally a custom dependency graph between the passes within a node can be specified (see non-sequential passes). By convention each node uses a first pass named SETUP to check for incoming data as well as a last pass named TEARDOWN to send all outgoing data and release buffers.
All parameters are passed to a node through the constructor arguments. There are a few different ways the lookup of a parameter value can happen:
dwContextHandle_t
) a special handler for that type determines how the parameter value should be retrieved:uint32_t
should be read from a JSON configuration file while another uint32_t
should be retrieved from a global singleton - they need to be distinguished by another attribute. That additional attribute is called the semantic type. Commonly an empty struct is used with the name of the struct describing the semantic, e.g. struct ImageWidth
. Beside the C++ type this semantic type acts as a tag dispatch to determine how the value should be retrieved.See dw::framework::NodeConcept::describeParameters() for details on the API.