GXF Core concepts

Those are the key GXF terms used in this section:

• Applications are built as compute graphs.

• Entities are nodes of the graph. They are nothing more than a unique identifier.

• Components are parts of an entity and provide their functionality.

• Codelets are special components which allow the execution of custom code. They can be derived by overriding the C++ functions initialize, start, tick, stop, deinitialize, and registerInterface (for defining configuration parameters).

• Connections are edges of the graph, which connect components.

• Scheduler and Scheduling Terms: components that determine how and when the tick() of a Codelet executes. This can be single or multithreaded, support conditional execution, asynchronous scheduling, and other custom behavior.

• Memory Allocator: provides a system for allocating a large contiguous memory pool up-front and then reusing regions as needed. Memory can be pinned to the device (enabling zero-copy between Codelets when messages are not modified) or host, or customized for other potential behavior.

• Receivers, Transmitters, and Message Router: a message passing system between Codelets that supports zero-copy.

• Tensor: the common message type is a tensor. It provides a simple abstraction for numeric data that can be allocated, serialized, sent between Codelets, etc. Tensors can be rank 1 to 7 supporting a variety of common data types like arrays, vectors, matrices, multi-channel images, video, regularly sampled time-series data, and higher dimensional constructs popular with deep learning flows.

• Parameters: configuration variables used by the Codelet. In GXF applications, they are loaded from the application YAML file and are modifiable without recompiling.

There are 2 main elements at the core of Holoscan and GXF designs:

1. How to define and execute application graphs

2. How to define nodes’ functionality

How Holoscan interfaces with GXF on those topics varies as Holoscan evolves, as described below:

Holoscan SDK v0.2

Holoscan SDK was tightly coupled with GXF’s existing interface:

1. GXF application graphs are defined in YAML configuration files. GXE (Graph Execution Engine) is used to execute AI application graphs. Its inputs are the YAML configuration file, and a list of GXF Extensions to load as plugins (manifest yaml file). This design allows entities to be swapped or updated without needing to recompile an application.

2. Components are made available by registering them within an GXF extension, each of which maps to a shared library and header(s).

Those concepts are illustrated in the GXF by example section.

The only additions that Holoscan provided on top of GXF were:

• domain specific reference applications

• new extensions

• CMake configurations for building extensions and applications

Holoscan SDK v0.3

The Holoscan SDK shifted to provide a more developer-friendly interface with C++:

1. GXF application graphs, memory allocation, scheduling, and message routing can be defined using a C++ API, with the ability to read parameters and extensions to load from a YAML configuration file. The backend used is still GXF as Holoscan uses the GXF C API, but this bypasses GXE and the full YAML definition.

2. The C++ Operator class was added to wrap and expose GXF extensions to that new application interface (See dev guide).

Holoscan SDK v0.4

The Holoscan SDK added Python wrapping and native operators to further increase ease of use:

1. The whole C++ API is also wrapped in Python. GXF is still used as the backend.

2. The Operator class supports native operators, i.e. operators that do not require to implement and register a GXF Extension. An important feature is the ability to support messaging between native and GXF operators with the same performance.

In comparison, the latest core concepts of the Holoscan SDK can be found here.