For years, GigE Vision has been remarkably resilient, regardless of the physical layer speeds beneath it. Whether running at one Gigabit, 2.5 Gigabits, five Gigabits or even 10 Gigabits, the protocol simply worked. But, as imaging applications pushed beyond 10 and towards 25 Gigabits-per-second, cracks began to appear, and addressing them has required a fundamental rethink of how image data moves from camera to application.
Where the standard protocol hits its limits
GigE Vision is fundamentally a UDP-based protocol. This is a deliberate choice that provides lower latency and less overhead relative to TCP-based alternatives. However, because UDP does not guarantee packet delivery, system designers historically had to implement dedicated packet resend mechanisms to ensure complete frames arrived at the host.
GigE Vision was created to provide a standardized method for transmitting image data over Ethernet while ensuring interoperability between cameras, frame grabbers, software, and processing systems from different vendors. Over time, the standard evolved to support increasingly sophisticated machine vision applications (Credit: Pleora)
"As we moved up in speeds, some implementations at 10 Gig were starting to encounter some issues, and at 25 Gig there was just a lot of dropped packets and dropped frames and very high CPU loading," explains James Falconer, Product Manager at Pleora Technologies and Vice Chair of the GigE Vision Technical Committee.
The root cause lies in the data path itself. Image data must travel from the camera to the network interface card (NIC), through the network stack, to the CPU, and finally to the host application.
"There are a lot of different copies," Falconer notes. "And all those copies take CPU utilisation."
Filter drivers helped to alleviate this by eliminating one of those memory transfers, passing a full frame from the NIC essentially direct to the application.
"The filter driver gives you better performance, so you can stream at 10 Gig with some implementations, such as Pleora's eBUS SDK," Falconer says. "But other implementations were continuing to struggle at 10 Gig and future scalability is an issue. So as the GigE Vision Technical Committee, we had to start looking at other ways to address this challenge."
From TCP offloading to RDMA
The committee's first avenue of investigation focused on TCP, which guarantees packet delivery and benefits from offloading capabilities built into many network interface cards. Prototype implementations emerged across both hardware and software, but ultimately failed to deliver the required throughput gains.
Attention then turned to Remote Direct Memory Access (RDMA) over Converged Ethernet, a technology drawn from the InfiniBand specification.
"That seemed to be the best candidate, because you get a direct copy from the camera of the image data to system memory," Falconer explains. "You don't have to worry about all those copies on the host side. The hardware layer, the network interface card, essentially abstracts that, so you get one direct copy of the full frame direct to the application for processing."
This architectural shift forms the foundation for GigE Vision 3.0's new streaming protocol, built on RoCEv2 (RDMA over Converged Ethernet) and designated as the GigE Vision RDMA Streaming Protocol (GVRSP).
Images 1A and 1B, above: Traditional GigE Vision image acquisition typically follows a path across multiple stages, with each stage introduces processing overhead, memory copies, and timing variability. GigE Vision 3.0 changes this workflow using RDMA, allowing image payloads to be transferred directly into memory while bypassing much of the operating system networking infrastructure (Credit: Pleora)
"Because the hardware does all the offloading, and resends are managed by the RoCEv2 layer, there's guaranteed delivery built in," Falconer says. "With GVRSP, there are already implementations streaming at 100 Gigabits per second. You could target up to 200 or 400 Gigabits-per-second, and it's all managed by the hardware layer itself."
Critically, the new protocol required changes only to the data delivery mechanism itself.
"While implementing a new streaming protocol it was critical that we maintained the existing control protocol," Falconer adds. "Only the streaming path changes. There are some other details that have to be added, but it's all managed through the standard control protocol, which is still based on UDP. That's not a critical path though; the streaming path is."
A collaborative push: the Gev-Stream initiative
Realising this new standard required bringing hardware IP and software expertise together, leading to a strategic partnership with imavix engineering. The connection originated within the technical committee itself, where imavix’s CEO Jan Pech was a key proponent of adopting RoCE v2 for GigE Vision.
"Jan launched imavix about a year and a half ago," Falconer says. "Because of our relationship through the technical committee, Pleora and imavix started talking about how our companies could work together. imavix provides an IP core solution, and Pleora is industry-renowned for a very performant, easy-to-use software development kit with unparalleled receive performance."
The resulting Gev-Stream solution combines imavix's IP core with Pleora's eBUS SDK into an integrated, end-to-end package.
"Designers don’t just need transport technology, they need a complete end-to-end solution for high-bandwidth imaging systems," Falconer says. “Too often, the transmit and receive integration becomes a late-stage challenge. By bringing the transport, standards support, and receive software together from the outset, we can significantly reduce development risk and time to market.”
What comes next for hardware and software
On the software front, Pleora is rolling out GigE Vision 3.0 support within its signature eBUS SDK, ensuring high-speed data delivery is paired with the stability expected by vision integrators.
On the hardware side, Pleora is expanding its interface portfolio to support the new standard directly. This includes the development of a dedicated Camera Link to GigE Vision 3.0 converter, the CL-DeCA RoCEv2, enabling 10-Gigabit streaming from legacy frame grabber environments. Additionally, Pleora is embedding this capability directly into hardware modules for camera and imaging system manufacturers.
"Designers are being asked to deliver more imaging performance, but they don't want to become interface experts in the process," Falconer explains. "We’ll be introducing a platform of RoCEv2-enabled embedded video interfaces, with 25 Gig solutions next year followed by 50 and 100 gig variants, that let designers easily integrate next-generation performance.”
The introduction of RoCEv2 creates two complementary deployment models. New camera designs can implement GigE Vision 3.0 and RoCEv2 directly at the source. Existing imaging systems can retain proven camera technologies while introducing GigE Vision 3.0 and RoCEv2 at the transport layer through frame grabber architectures (Credit: Pleora)
For the broader Gev-Stream initiative, the immediate priority is driving industry awareness and expanding hardware compatibility. "Expect more demos, and more promotion," Falconer says. "Together with imavix we’ve been demoing the solution at Automate and showcasing it as VISION Stuttgart."
Looking further ahead, Pleora sees potential for deeper technological convergence between the two companies. "The real value of this collaboration is the potential to strengthen the entire imaging ecosystem," Falconer says. "When hardware, IP, and software are designed to work together from the outset, customers can reduce integration effort and move from concept to deployment faster.”
Ultimately, the arrival of GVRSP marks a pivotal transition for machine vision infrastructure. By handing transport management over to dedicated network hardware, the standard eliminates longstanding CPU bottlenecks and establishes an extensible foundation for next-generation, high-speed inspection systems.
