Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Reinhard Tartler siretart at gmail.com
Sun Feb 16 17:13:26 UTC 2014


Dear ARM porters,

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981
for full context. I've uploaded a patch proposed by Riku that AFAIUI
makes mpg123 really slow on all arm targets, while unbreaking it on
some others.

As one of the maintainers of the mpg123 without familiarity about the
scope of the Debian arm port, I'm rather confused about what's the
best way to proceed here, and would need more input. Can someone more
experienced please advise?

Thanks,
Reinhard


---------- Forwarded message ----------
From: Thomas Orgis <thomas-forum at orgis.org>
Date: Sun, Feb 16, 2014 at 5:46 AM
Subject: Bug#738981: Switch to use generic_fpu for ARM
To: 738981 at bugs.debian.org


Sorry for being late to the party, but I have to say that this is a
rather unfortunate situation now. Not using the assembly-optimized
fixed-point ARM code of the arm_nofpu decoder and resorting to the
generic_fpu one (all plain C) will make mpg123 really slow in
comparison. I'm not sure what hardware we are targeting here ... is it
armel with softfloat? With gcc -mfpu=vfp, generic_fpu might be fine,
although using the neon decoder is still preferred on supporting CPUs.

There is no runtime detection in mpg123 for this and at least for the
decision of fixed or floating point decoding, it likely will never be
as that is a very basic decision on the whole decoder code, not just
some optimization. I can imagine combining generic_fpu and neon builds
with run-time detection, but this still assumes a hardware floating
point unit to make sense. We have arm_nofpu and generic_nofpu for the
cases without one.

Something which is possible right now is to produce one libmpg123.so with
the standard build to please users using slow ARM machines who just
want plain 16 bit playback and produce one libmpg123_float.so for people
using beefy machines and who are using audacious as a media player.

Well ... the least would be to offer builds with usage of vfp if
present (I see hints https://wiki.debian.org/ArmPorts that that's an
option, including runtime linker choice). In any case, ARM's a real
mess in that respect. Very hard to produce a build that is optimal for
that wide range of configurations that debian tries to support.

I could implement a conversion step to floating point with the
arm_nofpu decoder. That would make audacious work (although wasting
precision on machines that have hardware floating point, or even NEON)
and have the benefit of the command-line mpg123 still being fast with
16 bit output. A debian build targeting modern floating-point-capable
hardware would use generic_fpu or better the neon decoder to begin with.

Is there preference to have the faster decoder for debian without
floating point hardware?

_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


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


More information about the pkg-multimedia-maintainers mailing list