Re: [RFC] Global video buffers pool

[Marek Szyprowski <m.szyprowski@samsung.com>]

Hello Laurent,

We have been developing quite simmilar solution for Samsung SoCs multimedia 
drivers that the one mentioned in this RFC.

Our solution bases on the global buffer manager that provides buffers 
(contiguous in physical memory) to user applications. Then the application can 
pass the buffers (as input or output) to different multimedia device drivers. 
Please note that our solution is aimed at UMA systems, where all multimedia 
devices can access system memory directly.

We decided not to use any special buffer identifiers. In our solution 
applications must mmap the buffer (even if they don't plan to read/write it 
directly) and pass the buffer user pointer to the multimedia driver.

To get access to specified buffer we prepared a special layer that checks if 
the passed user pointer points to the buffer that is continuous in physical 
memory, locks properly the buffer memory and returns the buffer physical 
address. More details on this solution can be found here: 
http://thread.gmane.org/gmane.linux.ports.arm.kernel/56879

Using the user pointer access type gave us the possibility to directly 
transfer multimedia data to frame buffer memory and to create an SYSV SHMem 
area from it (by some additional hacks in kernel mm). This gave us the real 
power esspecially in hardware acceleration of XServer - with XSHM extensions 
we were able to blit frames directly from user application's buffer to the 
frame buffer memory.

Our multimedia devices do not use V4L framework currently, but moving towards 
V4L2 is possible.

Now let's get back to the RFC thesis.

The idea behind the global memory pool is really good and especially required 
in embedded-like systems. One of the important features of the buffer manager 
is cache coherency control. User, who allocated a buffer can request the 
buffer should be mapped as cacheable area or not, depending on the aimed use 
case. Queueing non-cacheable buffers is faster of course (no cache flush is 
required), but CPU read access is much slower (note the write-combining here).

A global memory pool should also reduce system memory requirements, however it 
should be kept in mind that some use cases might cause memory fragmentation 
issues. A pluginable memory management should also be considered. With some 
standard allocating methods like all buffers of the same size, first fit, best 
fit, etc in the buffer manager most of the typical usecases can be covered. 
Also some statistics on buffer allocation/deallocation and usage can be easily 
gathered with buffer manager.

However one should consider whether introducing new v4l2 buffer access method 
(V4L2_MEMORY_POOL) is really required. One of the key features of the 
introduced pool buffer identifiers is the much quicker buffer locking, as no 
per-page locking needs to be done. However a simmilar effect can be achieved 
with USERPTR access method. User application can allocate the buffer from the 
buffer manager (global pool), mmap it and pass it to the driver with USERPTR 
method. The driver can quite easily check if the passed user pointer is a 
pointer to the buffer from the pool and then lock it quickly with the simmilar 
method we used in our drivers for SoCs multimedia hardware.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center