[FFmpeg-devel] the future of fastmemcpy.h
Tue May 29 03:08:25 CEST 2007
On Tue 22 May 2007 16:56, Michael Niedermayer pondered:
> On Tue, May 22, 2007 at 10:17:34PM +0200, Reimar Doeffinger wrote:
> > On Tue, May 22, 2007 at 09:53:59PM +0200, Alex Beregszaszi wrote:
> > > > Ronald brought up the subject of the fastmemcpy.h #includes that
> > > > we continue to have in a few source files. fastmemcpy.h is part of
> > > > MPlayer and not FFmpeg. Is the #include just old cruft or worth
> > > > keeping?
> > > >
> > >
> > > I thought today about moving fastmemcpy into libavutil.
> > Please don't without proper performance testing, it stops gcc from
> > replacing constant-size memcpys by an inlined builtin, causing both
> > valgrind problems and at least for lzo massive slowdown.
> introduce a big_memcpy() and leave memcpy() as is ...
> and yes it should be benchmarked
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.
More information about the ffmpeg-devel