[FFmpeg-devel] [RFC] Cleanse swscale

Luca Barbato lu_zero
Wed Jan 12 16:50:31 CET 2011


On 1/12/11 3:35 PM, Michael Niedermayer wrote:

> if the code becomes 3000+ lines bigger then i dont like the idea

It won't I'm halfway first I need to split then I need
>
> that said, the whole idea of spliting asm into its own directories is bikeshed

No... more below

> if people are fixed on that i wont stop them as long as things dont become
> unreasonable bigger and not slower.

Let me explain in simple term for everybody:

function()
{
#if ARCH
__asm__("gibberish");
stuff
__asm__("gibberish");
#if feature
MACRO
__asm__("gibberish");
#elif feature
MACRO
MACRO
MACRO
#elif variant
#elif ARCH2
inline_function_from_the_outer_space()
#elif ARCH2
__asm__("blah");
#elif ARCH3
MACRO
#else
for ( lines in image )
     do stuff
#endif
#if ARCH
__asm__("barrier sync");
#endif
}

Iterated for all the 20 functions is wrong.

> Adding optimizations for other cpus doesnt need that split as far as i can tell
> one can just add these optims like the x86 optims under #if in the C
> implementations

Sure, we have Alpha code sprinkled and lost.

> That all said, iam quite neutral about this kind of changes, if things improve
> (on technical grounds) iam all in favor, if they worsen iam not. I have no
> problem with either design
> If its worth all the work, is something that you have to decide ...

Sorry to be a bit strong, but the state of swscale is what me drop ANY 
Idea to made the altivec bits on par that time, what made mru give up on 
writing neon and usually make a point for not importing ANY other code 
from mplayer before making it less mad.

What I'd like is to have this mess in a shape that is easy to 
understand, easy to track for people willing to optimize a bit or another.


lu



More information about the ffmpeg-devel mailing list