Interprocess

🚧 Documentation is under development

The Holoscan SDK guide is currently under active development. Some sections may be incomplete or change without notice.

Questions? Contact RidgeRun or email to support@ridgerun.com.

Contents Pin

Overview
Build, Run, and Validate
Core Concepts
- Operators and Graphs
  - Operator Lifecycle
  - Ports, Samples, and Payload Types
  - Temporal Contracts and Input Selection
  - Building Graphs and Queue Policies
  - Fan-Out, Fan-In, Mux, and Demux
  - Execution Planning and Capacity
    - Automatic Partitioning and Plan Inspection
    - Rates, Queue Sizing, and Derived Tensor Capacity
  - Dynamic Graph Behavior
- Tensor Data and Memory
- Interprocess Communication
Application and Operator Development
Operator Reference
- Core Operators
- Holoscan Camera
- Holoscan RidgeRun
Migration from Holoscan 4.x
Examples
- Core
- Holoscan Camera
  - SIPL Frame Saver Example
  - SIPL Stereo Monitor Example
- Holoscan RidgeRun
  - Interprocess External-Endpoint Demo
Benchmark and Use Cases
- Holoscan vs GStreamer
  - Overview
  - Capture and Display
  - Capture and Inference
  - Compare the workloads
  - Implemented Applications
  - Framework Selection
- Interprocess

Application optimization and development

Moving video frames between processes introduces transport and synchronization requirements. RidgeRun can evaluate interprocess video pipelines on your target hardware and help optimize latency and resource usage. Contact RidgeRun.

Executive summary

This benchmark evaluates HoloMQ GPU-frame sharing between two independent Holoscan 5 processes on an NVIDIA Jetson AGX Orin.

The results show that splitting the application into two processes using HoloMQ maintains nearly identical Glass-to-Glass (G2G) latency and comparable resource consumption to running the equivalent pipeline in a single process.

Metric	Interprocess (HoloMQ)	Single Process (V4L2/X11)
Average G2G Latency (ms)	42.75 ± 3.40	42.80 ± 8.00
Average Process CPU (%)	1.60 ± 0.15	2.53 ± 0.01
Average GPU Utilization (%)	37.00 ± 0.81	34.23 ± 0.88
Average Process RSS (MB)	84.24 ± 0.10	92.70 ± 0.02

The Interprocess measurements include both sender and receiver. The single-process reference is the Holoscan 5 V4L2 capture configuration with non-exclusive X11 display from Holoscan vs GStreamer.

Overview

The Interprocess application demonstrates GPU-frame sharing between two independent Holoscan 5 processes using HoloMQ.

The application consists of two components:

Sender: Captures raw Bayer frames through V4L2 USERPTR, converts them to BGRA on the GPU, and publishes them through HoloMQ.
Receiver: Imports the published GPU tensor and displays it through X11DisplayOp.

HoloMQ transfers the allocation handle and tensor metadata without copying the frame payload across the process boundary.

Two additional endpoints coordinate startup and shutdown, allowing the receiver to be launched first and ensuring that both processes terminate cleanly.

Execution context

Parameter	Configuration
Platform	NVIDIA Jetson AGX Orin
Framework	Holoscan 5
Camera	IMX274
Capture Interface	V4L2 USERPTR
Pixel Format	RG10 (RAW10 Bayer)
Resolution	1920 × 1080
Frame Rate	60 FPS target
Sender Processing	`V4L2UserPtrSourceOp` → `RawBayerToBgraOp` → HoloMQ
Receiver Processing	`InterprocessSrcOp` → `X11DisplayOp`
Display	Non-exclusive X11
Benchmark Protocol	Five runs per configuration, 600 frames per run; 20 optical samples for G2G latency

The reference configuration uses the same V4L2 capture, GPU Bayer conversion, and X11 display path, but executes within a single Holoscan process.

Application implementation

Data flow

The application transports camera frames between two independent Holoscan processes.

Sender
------
V4L2 camera (RG10)
  -> V4L2UserPtrSourceOp
  -> RawBayerToBgraOp
  -> HoloMQ exportable CUDA allocation
  -> HoloMQ endpoint "video"

Receiver
--------
HoloMQ endpoint "video"
  -> InterprocessSrcOp
  -> X11DisplayOp

The sender captures camera frames using V4L2 USERPTR buffers mapped for CUDA access. RawBayerToBgraOp performs Bayer conversion and writes the BGRA output directly into an exportable CUDA allocation.

HoloMQ publishes the allocation handle and tensor metadata to the receiver. The frame payload is not copied across the process boundary.

The receiver imports the GPU allocation and forwards the tensor to X11DisplayOp without creating an additional receiver-local frame copy. X11 presentation still requires a device-to-host copy.

Operators

Process	Operator	Description
Sender	`V4L2UserPtrSourceOp`	Captures RG10 frames using CUDA-mapped V4L2 USERPTR buffers.
Sender	`RawBayerToBgraOp`	Converts raw Bayer frames into BGRA directly in GPU memory suitable for HoloMQ export.
Receiver	`InterprocessSrcOp`	Imports the published CUDA tensor, retains the allocation claim, and forwards the tensor without an additional frame copy.
Receiver	`X11DisplayOp`	Copies the BGRA tensor into a host presentation buffer and displays it in an X11 window.

Process coordination

The application uses three HoloMQ endpoints:

Endpoint	Direction	Purpose
`video`	Sender → Receiver	Publishes the GPU-resident BGRA frame tensor.
`receiver_ready`	Receiver → Sender	Signals that the receiver is ready to consume frames.
`sender_done`	Sender → Receiver	Signals the end of transmission so the receiver can stop cleanly.

The receiver is started first. The sender waits for the readiness signal before consuming its frame budget. When transmission finishes, the sender publishes the completion signal, allowing the receiver to exit automatically.

Build and run

Environment setup

The following commands assume that the repository is located at /home/nvidia/holoscan-ridgerun and the Holoscan 5 SDK is installed separately.

Adjust the paths for your local installation.

export S=/home/nvidia/holoscan-ridgerun
export SDK=/opt/nvidia/holoscan
export CUDA_HOME=/usr/local/cuda

export CMAKE_BIN=/path/to/cmake-4/bin
export PATH="$CMAKE_BIN:$CUDA_HOME/bin:$PATH"
export CMAKE_PREFIX_PATH="$SDK/lib"
export HOLOSCAN_LIB_PATH="$SDK/lib"
export LD_LIBRARY_PATH="$SDK/lib:$SDK/lib/ucx:$SDK/lib/gxf_extensions:$CUDA_HOME/targets/sbsa-linux/lib:/usr/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu/tegra${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

export HOLOSCAN_CLI_SEARCH_PATH="$S"
export HOLOSCAN_CLI_ROOT="$S"

cd "$S"

Replace /path/to/cmake-4/bin with the local CMake 4 installation directory.

Build

Build both application modes through HoloHub:

./holohub build interprocess sender \
  --local \
  --language cpp

./holohub build interprocess receiver \
  --local \
  --language cpp

Run

Start the receiver in the first terminal:

cd "$S"

./holohub run interprocess receiver \
  --local \
  --language cpp \
  --no-local-build \
  --run-args="--width 1920 --height 1080 --poll-ms 5"

Then start the sender in a second terminal:

cd "$S"

./holohub run interprocess sender \
  --local \
  --language cpp \
  --no-local-build \
  --run-args="--device /dev/video0 --width 1920 --height 1080 --fps 60 --frame-limit 600"

After 600 frames, the sender publishes the completion signal and exits. The receiver receives that signal and closes automatically.

The --no-local-build flag assumes that the applications have already been compiled.

Benchmark methodology

The application was evaluated using a 1920 × 1080 RG10 camera input at a target rate of 60 FPS.

The benchmark consists of five runs of 600 frames each. Optical G2G latency was measured separately using 20 samples.

Metric	Measurement method
G2G Latency	Optical capture-to-display latency, reported as mean and standard deviation from 20 samples.
CPU Utilization	Combined sender and receiver CPU utilization, normalized against the 12 CPU cores of the platform.
GPU Utilization	System-wide GPU utilization during application execution, including work performed by both sender and receiver.
Process Memory (RSS)	Combined resident memory consumption of the sender and receiver processes.

GPU samples reported as 0% were excluded from the steady-state utilization summary.

Measurements

G2G latency

G2G latency measures the complete camera-to-display path, including HoloMQ transport between the sender and receiver.

The Interprocess application achieved 42.75 ± 3.40 ms, nearly identical to the 42.80 ± 8.00 ms measured with the equivalent single-process V4L2/X11 pipeline.

CPU utilization

CPU utilization includes both sender and receiver processes and is normalized against the total CPU capacity of the platform.

Interprocess averaged 1.60 ± 0.15%, compared with 2.53 ± 0.01% for the single-process configuration.

GPU utilization

GPU utilization represents the combined GPU workload of the sender and receiver, including capture processing, GPU Bayer conversion, HoloMQ-related operations, and X11 presentation.

Interprocess averaged 37.00 ± 0.81%, compared with 34.23 ± 0.88% for the single-process configuration.

Process memory (RSS)

RSS includes the combined resident memory consumption of both sender and receiver processes.

Interprocess averaged 84.24 ± 0.10 MB, compared with 92.70 ± 0.02 MB for the single-process configuration.

Conclusions

The Interprocess benchmark demonstrates that HoloMQ can transport GPU-resident video frames between independent Holoscan 5 processes without introducing a significant increase in end-to-end latency or resource consumption.

Compared with the equivalent single-process V4L2/X11 pipeline, Interprocess maintains nearly identical G2G latency (42.75 ms vs. 42.80 ms), while reporting lower combined CPU utilization and memory consumption, with only a modest increase in GPU utilization.

These results demonstrate that HoloMQ provides an efficient approach to splitting HSDK applications across processes while maintaining performance comparable to a single-process pipeline.

Related benchmarks and documentation

Holoscan vs GStreamer provides the single-process reference configuration and broader framework comparison.
Holoscan RidgeRun Operators contains the available operator documentation.
Performance and Debugging provides additional measurement and investigation guidance.

❯