Video buffer pools [LWN.net]

The Video4Linux2 API has a well-developed interface for sharing video buffers between user space and the kernel. It is not without its problems, though. Simple video acquisition devices transfer large amounts of data (video frames) but cannot do scatter/gather I/O, forcing the allocation of large, physically-contiguous buffers. Queueing buffers for frame transfers can be a significant source of latency, especially when user-space buffers need to be locked into memory or when the architecture requires significant cache invalidation operations. It would also be nice to be able to pass buffers directly between video devices and related devices, such as hardware codecs, but the current API does not support that well.

In response to these problems, Laurent Pinchart has proposed a new subsystem implementing a global video buffer pool. These buffers would be allocated early in the system's lifetime, working around the unreliability of large contiguous allocations. Cache invalidation operations could be done ahead of time, eliminating a significant source of capture-time latency. Passing buffers between devices would be explicitly supported. The proposal is in an early stage, and Laurent would like comments from interested developers.

(Log in to post comments)

Video buffer pools

Posted Nov 14, 2009 21:01 UTC (Sat) by vleo (guest, #32027) [Link]

I've used hack with top memory allocation since kernel 2.0 times for LML33 original driver (not V4L compatible one). That certainly was source of complications in the hardware/driver install process for the end users.

Zoran 36060/67 JPEG codec chipset supports scatter/gather for coded JPEG data transfers, but interestingly enough - not for raw video transfers, that must go to biggish memory buffer.

Patches for this kind of support have been around for over 10 years, but still that is not seen in the kernel.org kernels.

Is that good or bad? From the perfectionist POV it is good. I will not ever design hardware that does not support S/G... well, not in the final release :-) it's easier to implement just a big buffer, w/o need to bother with s/g, especially in the initial VHDL coding phase.

So, maybe these big buffers should be supported after all in the kernel at large, not only under V4L I hope.