[FFmpeg-devel] [RFC] Cleanse swscale

[Michael Niedermayer]

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
implementations
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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110112/d74920a8/attachment.pgp>