New Feature: G2CPU V1.7.0 Introduces NVIDIA CUD...

The upcoming release of G2CPU V1.7.0 introduces a major new capability for developers building GPU-accelerated systems: Interprocess Communication (IPC) support for NVIDIA CUDA.

This feature allows separate applications to exchange data efficiently, enabling modular software architectures where one process generates data, another visualizes it, and others perform analysis or logging.

In this tutorial, we will walk through how IPC works in G2CPU, explain the new functions included in V1.7.0, and show how one LabVIEW application can generate a signal while another LabVIEW application displays it in real time.

Although the example uses LabVIEW, the same technology can be extended to environments such as Python, MATLAB, and other CUDA-capable platforms.

What Is IPC and Why Is It Useful?

Interprocess Communication (IPC) allows two or more independent applications to exchange data while running as separate operating-system processes.

The limitations of memory pointers and arrays

Each application has its own private memory space. Even when two programs run on the same computer, they do not automatically have access to each other’s variables, arrays, pointers, or allocated memory blocks. This separation is a fundamental part of modern operating systems and is important for stability and security.

This becomes especially relevant in GPU workflows, where applications often have different responsibilities. One application may acquire data from hardware, another may run CUDA processing, while a third provides the user interface or logging. Although these applications may all need access to the same data stream, they cannot simply pass pointers between one another.

A pointer is only meaningful inside the process that created it. It represents a memory address within that application's own address space. In another process, that same numeric address may refer to something entirely different—or to nothing at all. The same principle applies to array references, buffers, and dynamically allocated memory. If one application allocates an array and sends only the pointer value to another application, the receiving process cannot safely use it.

GPU memory behaves similarly. CUDA buffers, device pointers, and related resources are typically owned by the process that created them. Another application cannot directly interpret or access those memory references without an explicit sharing mechanism.

Without IPC, developers typically work around this limitation using temporary files, TCP/UDP sockets, named pipes, shared host memory, or repeated copies through CPU RAM. While functional, these methods often introduce additional latency, synchronization challenges, data throughput bottlenecks, and unnecessary software complexity.

How IPC overcomes this limitation

IPC solves this by creating a controlled mechanism for one process to expose data and another process to access it safely. Instead of attempting to pass raw pointers or internal references, applications exchange valid handles and structured access paths designed for cross-process communication. Each handle references a memory location on a NVIDIA GPU which applications can transform into a valid memory pointer or G2CPU array within their respective application.

With G2CPU IPC support, developers can build cleaner and faster multi-application systems, where separate programs cooperate efficiently without unsafe memory hacks or expensive copy-based workflows.

How to get started

The new release adds six G2CPU IPC functions that make inter application producer-consumer workflows easy to implement.

1. Creating a Handle to Be Shared

The application that owns or produces the data begins by initializing the IPC subsystem and creating a shareable handle.

The created handle acts as a formal reference to the shared resource. Instead of passing memory addresses between applications—which are invalid outside the originating process—the producer exports a handle that another process can open safely.

This handle becomes the connection point between applications.

The IPC handle is put out as a string, making it easy to transfer it between applications through copy paste, TCP/IP loopback,

For example, a signal generator application may create one handle for waveform data, while another handle could be created for status information or metadata.

2. Using a Shared Handle

A second application can connect to the shared resource by opening the handle created by the producer.

Once opened, the consumer application gains structured access to the shared data channel. Both applications remain independent processes, but they now communicate through the IPC mechanism.

This allows systems such as:

One LabVIEW application generating signals
Another LabVIEW application displaying graphs
A Python analytics process reading the same stream
A MATLAB tool validating results

3. Setting IPC Data

The producer application updates the shared resource using:

This function writes new values into the IPC channel whenever fresh data is available.

A key design point is that typing is strict. The data written into the shared handle must match the type definition expected by that handle. If the handle was created for a specific numeric type or array structure, the producer must write data in exactly that format.

This prevents common cross-process errors such as:

Writing floating-point data into an integer buffer
Sending arrays of incorrect length
Misinterpreting byte layouts
Mixing incompatible numeric precisions

Strict typing ensures that all participating applications interpret the data consistently.

For real-time systems, this is especially important because incorrect typing can silently corrupt measurements or visualizations.

4. Getting IPC Data

The consumer retrieves current values using:

This function reads the shared data in the same strict format defined for the handle.

If the shared channel contains a specific scalar type, vector type, or array structure, the receiving application must request and interpret that exact type. This guarantees consistency between producer and consumer.

For example:

A waveform array written as 32-bit floating point should be read as 32-bit floating point
An integer status flag should be read as integer
A structured numeric buffer should preserve element order and size

Because typing is enforced, developers gain predictable interoperability between LabVIEW, Python, MATLAB, or other environments. Each application knows exactly what data format is expected, reducing debugging time and preventing hidden conversion issues.

Practical Example: LabVIEW Signal Generator to External Executable

A useful demonstration of IPC support is shown in the included video, where two independent applications communicate in real time through G2CPU.

On the left side of the video, a LabVIEW application acts as the producer. It generates a live signal and continuously updates the shared IPC resource with new data.

On the right side of the video, a standalone executable acts as the consumer. It opens the shared handle, reads the incoming signal, and visualizes the data live.

This creates a clean separation of responsibilities. LabVIEW can focus on signal generation, hardware control, or operator interaction, while the executable can focus on visualization, analysis, logging, or custom processing.

What makes this demonstration especially important is that IPC communication is not limited to LabVIEW-to-LabVIEW workflows. A LabVIEW application can exchange data directly with external executables built in C++, Python, or other native environments that support compatible integration.

Rather than forcing all functionality into a single application, developers can now divide systems into dedicated components that communicate efficiently through G2CPU IPC.

Decoupling processing from data acquisition and data storage provides added stability. If the processing application crashes for any reason, the data acquisition and data storage application will keep on running.

The result is a more scalable architecture, easier maintenance, and greater freedom to combine the best tools for each task.

Communicating with External Environments: C++, Python, and MATLAB

One of the most powerful aspects of IPC support in G2CPU V1.7.0 is that communication is not restricted to LabVIEW applications. Any external environment capable of loading native libraries and working with structured memory interfaces can participate in the same workflow.

This means LabVIEW can generate data while another language or runtime consumes it for visualization, analytics, automation, or algorithm development. Instead of choosing one ecosystem for an entire project, developers can combine the strengths of multiple tools.

C++ Integration

C++ is a natural companion for high-performance applications. It offers direct access to native APIs, deterministic memory control, and straightforward CUDA integration.

A common architecture is to use LabVIEW for operator control or hardware I/O while a C++ executable performs intensive processing, rendering, or custom logic.

Typical use cases include:

Real-time GPU compute pipelines
Custom visualization engines
Embedded control systems
Low-latency signal processing

Useful resources:

Python Integration

Python is widely used for scientific computing, automation, AI, and rapid development. IPC allows Python applications to consume live data generated elsewhere and immediately apply advanced processing.

For example, LabVIEW may acquire sensor data while Python performs FFT analysis, machine learning inference, or dashboard visualization.

Popular Python toolkits include:

NumPy for numerical arrays
CuPy for GPU arrays with NumPy-like syntax
Numba for JIT-compiled CUDA kernels
PyCUDA for CUDA interaction
PyTorch for AI pipelines
PyQt / PySide for desktop interfaces
Plotly Dash for web dashboards