Bug#738981: Switch to use generic_fpu for ARM

[Thomas Orgis]

Am Sun, 16 Feb 2014 12:14:46 -0500
schrieb Reinhard Tartler <siretart at gmail.com>: 

> Thomas, in libavcodec, we "solve" (or rather, workaround, depending on
> the PoV) this problem by compiling the libraries multiple times

A sane approach. Runtime code selection in each application can be
stretched beyond the boundary of it being fun quickly.

> ...
> be possible to do something like this for mpg123 as well? This would
> then require to compile
> 
> /usr/lib/arm-linux-gnueabi/libmpg123.so.0
> for different flavors. However, we would need to make sure that
> /usr/bin/mpg123 works with any of them.

That would certainly work and is what I imagined. If this offers
link-time choice of fixed point, vfp or neon, I'd be overly happy for
avoiding headache over making runtime choice inside one build
(which seems rather impractical).

> I'm wondering if this pattern
> wouldn't work for mpg123, but I'm not familiar enough with the
> codebase to say if this would work. Can you please comment?

I don't see am obvious problem. As long as basic ABI fits (also regarding
floating point args), this should work as well as libavcodec. The
mpg123 binary queries the library for things like format support and
decoder engine and one build can work with arm_nofpu or generic_nofpu
(arm-linux-gnueabi), generic_fpu (arm-linux-gnueabi/vfp) and arm_neon
(arm-linux-gnueabi/neon/vfp/). I suppose the gnueabihf variants need an
separate build for the changed ABI of floating point arguments (?).

When setting up the environment to use a specific libmpg123, one should
see an effect in the output of

mpg123 --list-cpu

Just build mpg123 several times, with proper CFLAGS for -march and
friends and matching --with-cpu for configure. You can pick which
mpg123 binary to use, I suggest the most universal one. In the mpg123
binary itself, there is no assembly code affected by the --with-cpu
switch and the performance-relevant bits are in libmpg123. Same for the
other helper applications (mpg123-id3dump, mpg123-strip).

The only issue still present would be that the most basic libmpg123
still misses floating point output format for audacious. But my guess
is that you wouldn't use that player on a system without floating point
hardware. As I said, I can change that, for the sake of completeness
adding a bit of code converting from 16 bit to 32 bit float (and 24 and
32 bit integer) in the output buffer.

The only remaining difference between the libraries would be
performance and accuracy of output. Were you aware of the
--enable-int-quality flag to configure? Yet another set of decoders
being a bit slower but doing better rounding to 16 bit integers;-)

In any case, you might want to check out
mpg123's tests to verify that your various builds
decode properly:

svn co svn://svn.orgis.org/mpg123/test mpg123-test
cd mpg123-test
make # build helper programs (rms computation)
perl compliance.pl /path/to/mpg123

This makes a basic MPEG ISO compliance test, comparing decoder to
reference output (see http://mpg123.org, after scrolling down a bit).

Disclaimer: If anything does not work as I just promised, this is a bug
and will be addressed;-)


Alrighty then,

Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20140216/bd6e56c8/attachment.sig>