CUDASHM Consumers

Overview

The CUDASHM transport keeps frames in GPU memory end-to-end. The producer pre-allocates a ring of CUDA buffers, exports each via cudaIpcGetMemHandle, and cudaMemcpy2DAsync D2Ds each new frame into the next slot. The consumer attaches by stream name, imports every IPC handle once at attach time, and on each wait_frame gets back a CUDA device pointer that addresses the slot directly. No device-to-host copy happens inside ovstream.

This is the right transport when the consumer is itself running CUDA kernels (simulation, ML pre/post-processing, GPU compositing) and would otherwise have to upload host pixels back to the GPU after a SHM read.

Multiple consumers can attach to one producer concurrently. Consumers can come and go independently of the producer.

[!IMPORTANT] The consumer must run in a separate process from the producer. CUDA forbids cudaIpcOpenMemHandle in the process that called cudaIpcGetMemHandle. Docker containers on the same host are fine (with --ipc=host --gpus all so IPC handles cross the container boundary).

The unified ovstream.Client / ovstream_create_client is backend-agnostic — the transport is chosen by ClientType. This skill covers ClientType.CUDASHM; the same Client also speaks ClientType.SHM (host-resident, see the shm-consumers skill) and ClientType.NATIVE (network, see protocol-selection).

Python: ovstream.Client(ovstream.ClientType.CUDASHM)

The minimal pattern: