How to: 20-Camera GigE Vision RDMA Streaming to the GPU: PTP Sync, eTrigger, CUDA Debayering

BayerRG8 sends 1 byte for each pixel and RGB8 sends 3. With BayerRG8 the maximum camera frame rate increases from 29.16 fps to 87.33 fps, because the 10GigE link is the limit and not the sensor. The GPU then does the debayering. The Option 2 reference system operates 20 cameras at 87 fps with BayerRG8.

Use RGB8 if 28 fps is sufficient and you want the camera’s colour processing without GPU debayering code. Use BayerRG8 if you need more than 28 fps, more network margin, or less buffer memory.

The reference system uses a CUDA kernel with the Malvar-He-Cutler 5 x 5 filter. The kernel reads the image buffer directly on both host options.

For DGX Spark, keep the VLAN and physical cable connections shown above, but select the active Linux interfaces according to the table below.

The built-in ConnectX-7 connects to the GB10 through two PCIe Gen5 x4 links. Each physical network port appears as two Linux interfaces, one for each PCIe link. Use enp1s0f0np0 for VLAN 10 and enP2p1s0f1np1 for VLAN 20 so the two camera groups use different PCIe links.

Why Option 2 uses both PCIe links

At 4096 × 3000 resolution, 20 cameras generate approximately 21 GB/s of image data when streaming RGB8 at 28.8 fps or BayerRG8 at 87 fps. This exceeds the theoretical bandwidth of one PCIe Gen5 x4 link, approximately 15.75 GB/s per direction before protocol overhead. DGX Spark therefore uses one camera VLAN on each PCIe link.

The discrete workstation’s ConnectX-5 uses a single PCIe Gen4 x16 connection with approximately 31.5 GB/s of theoretical bandwidth per direction before protocol overhead. Both network ports share this wider connection, so Option 1 does not require the additional PCIe-link selection used on DGX Spark. Both options still use one physical network port per camera VLAN.

Apply the commands for your selected host option. For Option 2, disable both unused interfaces, assign the host IP addresses to the two active interfaces, and set their MTU to 9000.

Verify that both active interfaces show mtu 9000 and are administratively UP. The two unused interfaces must remain administratively DOWN to prevent duplicate camera discovery. These commands apply to the current session; configure the same settings persistently so they are retained after reboot.

The lead time must be longer than the time for the command to get to the last receiver, which includes the relay. Start with a conservative lead time that exceeds the worst-case command delivery time to all receivers, including the relay to the second VLAN. Allow additional margin for delivery-time variation and differences between camera clocks. Reduce the lead time gradually while comparing the image timestamps from all receivers for each pulse. At each step, send 20 pulses and compare the timestamps of the image captured by each receiver for the same pulse. When the difference increases suddenly, the lead time is too short.  A lead time that is too short does not cause missing images. This creates a larger timestamp difference because GenICam standards require devices to execute scheduled action commands unconditionally.

Read the required buffer size from the camera’s PayloadSize node and allocate each buffer accordingly:

• Option 1: Discrete GPU: Allocate GPU memory using cudaMalloc.
• Option 2: DGX Spark: Allocate mapped, pinned host memory using cudaHostAlloc with cudaHostAllocMapped.

Pass the allocated buffers to StartStream as user-supplied buffers using UserSuppliedBuffer. Images retrieved through GetImage reference data in these buffers without an additional image-data copy.

Enable PTP on all cameras and wait for PTP lock before sending a trigger pulse.

Configure the sender camera:

Choose a lead time that allows the scheduled action command to reach all receivers, including those on the second VLAN, before its execution time.

Configure the receiver cameras:

When streaming BayerRG8, perform Bayer-to-RGB conversion on the GPU. The demo uses a custom CUDA kernel implementing Malvar-He-Cutler demosaicing, a 5 × 5 linear filter that combines bilinear interpolation with gradient correction. The kernel reads the acquisition buffer directly and writes the converted output into an OpenGL texture, avoiding an intermediate image copy.

As an alternative to implementing a custom debayering kernel, NVIDIA NPP provides nppiCFAToRGB_8u_C1C3R for Bayer-to-RGB conversion. Integration with the application’s output buffers and OpenGL display remains a separate step.