[Theora-dev] Questions, MMX and co.

[illiminable]

Just as an aside... has anyone compared these new changes with the results
of just telling Visual Studio 2003 to target a P4/Athlon XP w/ SSE2 with
maximum speed/full-program optimisations for example ? Or if anyone has the
Intel Optimising Compiler... its output.

Obviously hand-writing has the potential to do better than just getting the
compiler to do it (and i don't think gcc is all that special at doing this
automatically if it can even do it)... but the advantage being, that it's
pretty much gauranteed to be equivalent to the original... and it will make
scheduling decisions across object boundaries and make these decisions for
the entire source where applciable rather than just the places where someone
has the taken the time to hand-write it.

Cheers,

Zen.


----- Original Message ----- 
From: "David Kuehling" <dvdkhlng at gmx.de>
To: <rodolphe.ortalo at free.fr>
Cc: <theora-dev at xiph.org>
Sent: Thursday, August 26, 2004 4:50 AM
Subject: Re: [Theora-dev] Questions, MMX and co.


> >>>>> "Rodolphe" == Rodolphe Ortalo <rodolphe.ortalo at free.fr> writes:
>
> > 1) Should the C, MMX, MMXEXT, SSE (and possibly later on SSE3 or SSE4)
> > variants of functions be: 1-A) selected at compile time (via #ifdef or
> > compiler flags), like what HoSwiYO did for the decoder, or me last
> > year: one binary version for each; 1-B) all available simultaneously
> > in the library and be selected at run time (thus, probably using the
> > (*funcPointer)(a,b) approach like Wim did in his encoder patch); 1-C)
> > more complex solution (ideas? dllopen()?)
>
> My two cents: if possible always select the variant at run-time.  With
> all the CPU variants currently on the market (MMX, MMXEXT, SSE, SSE2,
> 3DNOW and whatever...) it would be a terrible headache for binary Linux
> distributions to provide properly optimized packages.  Mplayer as an
> example is AFAIK completely run-time CPU detection based.  On the other
> hand, for ATLAS on Debian I can select among 4 different packages, and
> the installation process must make sure that the linker is properly
> configured to make all applications use one of those 4 libraries.
>
> > 2) Which compiler should be supported?
>
> > 3) What is preferred: 3-A) inline assembly, 3-B) (x)mmintrin.h-based
> > MMX functions (Intel compiler, GCC, maybe others)?
>
> Inline assembly is compiler-specific and as far as GCC is concerned had
> always problems with hard-to-trace compiler-bugs occuring on specific
> GCC versions.  (faulty register optimization, internal compiler errors
> etc.)
>
> The way I like most is to put all low-level CPU stuff into separate ASM
> files.  If you use some assembly format (MASM vs AT&T?) that is widely
> supported, you will greately reduce porting problems (and compile-time
> :)
>
> This creates some more problems with the low-level C calling interface
> and with accessing C data types from assembly.  But usually such issues
> can be handled via configure-scripts.  If you need access to C-structs
> from ASM, just use some short C-program to dump the offsets of
> interesting members into some ASM header-file.  The Allegro
> cross-platform gaming library was quite successful with such an
> approach.
>
> > 5) How to *validate* the implementation? It is probably easy to
> > introduce biais in the encoder in the C to MMX transformation
> > process. On the other hand, sometimes output is different and this is
> > normal (psavgb does (A+B+1)/2 which is more precise than
> > (A+B)/2). Maybe we can simply trust experimental work, or rely on a
> > good 4), but then...?
>
> I thought that at least the (I)DCT should be bit-perfectly equal to the
> reference encoder.  Else you will have terrible artifacts if people
> encode movies with large keyframe distances (I already encoded
> Theora-movies with keyframes spaced 512 frames apart).
>
> David
> -- 
> GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
> Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
>
> _______________________________________________
> Theora-dev mailing list
> Theora-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev
>
>