[FFmpeg-devel] the future of fastmemcpy.h

[Robin Getz]

On Tue 29 May 2007 06:12, Attila Kinali pondered:
> On Mon, 28 May 2007 21:08:25 -0400
> Robin Getz <rgetz at blackfin.uclinux.org> wrote:
> 
> > Is there a desire to introduce other styles of memcpy?
> > 
> > For example - on some hardware - you can jump into kernel space, start a 
> > memory to memory DMA, return and do computations on other things while the 
> > copy happens in the "background". Think of it as a non-blocking memcpy.
> > 
> > Depending on the overhead of getting to kernel space - this can have 
> > advantages for architectures where the buffer being copies is a small
> > as 1k. 
> 
> This could be very well done, but, it would be very device specific
> and thus would belong into the output device driver and not into
> something generic as a memcpy routine.

Each implementation would be device specific (like a fast_memcpy) - but the 
infrastructure for putting in in place should be common - and there are parts 
of the common code (not the related to output at all) which could take 
advantage of a non-blocking copy.

I thought it could be handled the same way as fast_memcpy, or big_memcpy - if 
defined, and it has a device specific back end, it is used, otherwise, it is 
defined as normal libc memcpy.

-Robin