A Node represents a composable entity for executing certain processing steps. Its interface is described by the following information:

• a set of Ports which are the endpoints for incoming and outgoing data and
• a set of Passes which are executed to perform the desired processing

Each node type offers a custom set of Parameters to configure each instance. Nevertheless a factory function is provided for uniform instantiation.

Port Details

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

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.

Pass Details

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.

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. 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.

Commonly a pass invokes API provided by a DriveWorks module which implements the actual processing logic. A pass is not supposed to spawn its own threads, since that responsibility lies with the scheduler of the application.

Parameter Details

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:

• A JSON value is being looked up from a JSON configuration file based on a string key and the JSON value is converted into the desired compatible C++ type.
• If the C++ type is not compatible with a builtin JSON type (e.g. a custom type like dwContextHandle_t) a special handler for that type determines how the parameter value should be retrieved:
  • The returned value is already uniquely identified by its type so no additional information needs to be looked up from the JSON file. The value might come from a global singleton or some other context.
  • An additional input like an index or identifier is needed to retrieve a specific instance of the requested type. In that case the index / identifier is first looked up from a JSON file based on a string key and that index / identifier is then used to retrieve the actual value from somewhere.
• A mixture of the previous two bullets where the C++ type does have a compatible builtin JSON type but a different handling is desired. To handle two parameters with the same C++ type differently - e.g. one 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.