[FFmpeg-devel] the future of fastmemcpy.h
Tue May 29 14:52:49 CEST 2007
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.
More information about the ffmpeg-devel