[Ffmpeg-devel] [rfc] arch specific dir in libavutil

Michael Niedermayer michaelni
Tue Oct 10 08:25:43 CEST 2006


Hi

On Mon, Oct 09, 2006 at 11:46:01AM -0700, Roman Shaposhnik wrote:
> On Sun, 2006-10-08 at 00:45 +0200, Luca Barbato wrote:
> > > if we have pages of asm code for various cpus then arch specific dirs make
> > > sense for the few lines in avutil it does not and anyway whats your rational
> > > for them?
> > 
> > that w/out nobody would add them for other arches because it would cause
> > bloat:
> > 
> > 5 lines for every major arch and its variant would just grow to pages
> > quickly: think about blackfin, arm variants, ppc/ppc64 variants,
> > x86/x86_64, sparc, mips.
> > 
> > 5 lines is just an oneliner with 2 ifdefs, do it for most of the arches
> > and you have already a monster of over a page.
> 
>   I too, would very much like to see this happen. If for nothing else
> but to make it easier on me to tinker with OpenSPARC T2 optimizations. 
> 
> It seems to me that the architecture proposed by Luca has a very nice 
> benefit of facilitating ports without making the person doing it go over
> 100+ different files to hunt down these one-liners. 

grep asm


> It also helps a lot
> with compiling ffmpeg with different compilers, etc.

all the asm is under #ifdef


> 
>   So, the question is -- would there be a happy medium to which Michael
> would agree ?

iam not against moving asm code into there own files if that can cleanly be
done, choping up functions and having them reassebled by a mix of
preprocessor directives just to seperate the asm is someting i wont agree
to though

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list