[FFmpeg-devel] [RFC] Cleanse swscale
Wed Jan 12 15:35:15 CET 2011
On Wed, Jan 12, 2011 at 10:47:50AM +0100, Luca Barbato wrote:
> On 01/12/2011 01:37 AM, Michael Niedermayer wrote:
> > On Tue, Jan 11, 2011 at 10:50:30PM +0100, Luca Barbato wrote:
> >> I started to have yet another look at swscale since soon I might dabble
> >> a bit with neon.
> >> I'd like to move ALL the x86 code in the x86 dir and possibly unify the
> >> init functions so x86 won't be special.
> >> Right now I'm just shuffling the code away and duplicate it (C-only in
> >> libswscale, asm-laced in x86), then I'll untemplateze the C one and
> >> apparently some usual suspect seems interested in convert the x86 asm to
> >> yasm as the latest step of the cleanup. The x86 init code will move away
> >> and possibly will be unified.
> >> So far some early points:
> >> - we have bits of Alpha asm left in rgb2rgb_template.c
> >> - Always set FAST_BGR2YV12 (7bit consts instead of 15bit) puzzles me,
> >> maybe an extended comment might be useful
> > Id add one if i would remember ...
> >> - Non-x86 arches have quite a barrier in order to add effectively
> >> optimizations.
> >> - the functions have sometimes camelCase names sometimes not.
> > changing style of bike colors over the years ...
> Yet you hadn't say anything on the general plan ^^; I already started
> and seems working as should but is _really_ painful to complete.
> Makefile | 7 +-
> ppc/swscale_template.c | 903 ++++++++++++++
> rgb2rgb.c | 163 +---
> rgb2rgb_template.c | 2209 ++---------------------------------
> swscale.c | 10 +-
> swscale_functions.c | 67 ++
> swscale_template.c | 2194 ----------------------------------
> x86/rgb2rgb.c | 150 +++
> x86/rgb2rgb_template.c | 2944
> x86/swscale_template.c | 3043
> 10 files changed, 7223 insertions(+), 4467 deletions(-)
if the code becomes 3000+ lines bigger then i dont like the idea
that said, the whole idea of spliting asm into its own directories is bikeshed
if people are fixed on that i wont stop them as long as things dont become
unreasonable bigger and not slower.
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
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 ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel