Update of /cvsroot/mplayer/main/mp3lib In directory mail:/var/tmp.root/cvs-serv19861 Modified Files: decode_MMX.c Log Message: reverting my last change as buggy gcc 3.x fails with it :( Index: decode_MMX.c =================================================================== RCS file: /cvsroot/mplayer/main/mp3lib/decode_MMX.c,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- decode_MMX.c 23 Oct 2003 00:01:23 -0000 1.8 +++ decode_MMX.c 25 Oct 2003 23:13:54 -0000 1.9 @@ -47,10 +47,10 @@ 1060439283, }; +static int temp; // buggy gcc 3.x fails if this is moved into the function :( void synth_1to1_MMX_s(real *bandPtr, int channel, short *samples, short *buffs, int *bo) { -int temp; __asm __volatile( "movl %1,%%ecx\n\t"
Update of /cvsroot/mplayer/main/mp3lib In directory mail:/var/tmp.root/cvs-serv19861
Modified Files: decode_MMX.c Log Message: reverting my last change as buggy gcc 3.x fails with it :( gcc addresses local variables by ebp or esp, and push/pop change esp so it cant work (the correct solution would be to make some free space manually on
Hi On Sunday 26 October 2003 01:14, Alex Beregszaszi wrote: the stack and use that instead) [...]
+static int temp; // buggy gcc 3.x fails if this is moved into the function :( void synth_1to1_MMX_s(real *bandPtr, int channel, short *samples, short *buffs, int *bo) { -int temp;
[...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
Hi,
On Sunday 26 October 2003 01:14, Alex Beregszaszi wrote:
Update of /cvsroot/mplayer/main/mp3lib In directory mail:/var/tmp.root/cvs-serv19861
Modified Files: decode_MMX.c Log Message: reverting my last change as buggy gcc 3.x fails with it :( gcc addresses local variables by ebp or esp, and push/pop change esp so it cant work (the correct solution would be to make some free space manually on the stack and use that instead) Strange is that it worked on 2.95.x
Actually the whole code could be rewritten..it's crappy -- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
Hi,
Hi,
On Sunday 26 October 2003 01:14, Alex Beregszaszi wrote:
Update of /cvsroot/mplayer/main/mp3lib In directory mail:/var/tmp.root/cvs-serv19861
Modified Files: decode_MMX.c Log Message: reverting my last change as buggy gcc 3.x fails with it :( gcc addresses local variables by ebp or esp, and push/pop change esp so it cant work (the correct solution would be to make some free space manually on the stack and use that instead) Strange is that it worked on 2.95.x
Actually the whole code could be rewritten..it's crappy
Actually optims should be ported/redone for ffmp3 and finally rm -rf mp3lib its just broken in many ways, not worth to fix. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
Hi,
Hi,
On Sunday 26 October 2003 01:14, Alex Beregszaszi wrote:
Update of /cvsroot/mplayer/main/mp3lib In directory mail:/var/tmp.root/cvs-serv19861
Modified Files: decode_MMX.c Log Message: reverting my last change as buggy gcc 3.x fails with it :(
gcc addresses local variables by ebp or esp, and push/pop change esp so it cant work (the correct solution would be to make some free space manually on the stack and use that instead)
Strange is that it worked on 2.95.x
Actually the whole code could be rewritten..it's crappy
Actually optims should be ported/redone for ffmp3 and finally rm -rf mp3lib its just broken in many ways, not worth to fix. I'm no mp3lib fan either, but keep in mind that it is still a lot faster on
On Sunday 26 October 2003 01:48, Arpi wrote: older systems (eg. Pentium II. tested that recently).
A'rpi / Astral & ESP-team
-- Best Regards, Atmos ____________________________________________ - MPlayer Developer - http://mplayerhq.hu/ - ____________________________________________
Hi,
reverting my last change as buggy gcc 3.x fails with it :(
gcc addresses local variables by ebp or esp, and push/pop change esp so it cant work (the correct solution would be to make some free space manually on the stack and use that instead)
Strange is that it worked on 2.95.x
Actually the whole code could be rewritten..it's crappy
Actually optims should be ported/redone for ffmp3 and finally rm -rf mp3lib its just broken in many ways, not worth to fix. I'm no mp3lib fan either, but keep in mind that it is still a lot faster on older systems (eg. Pentium II. tested that recently).
It's still a lot faster on any x86 systems, maybe on others too. I was trying to find bottlenecks of ffmp3, and optimize it but failed. The 3 most critical functions of ffmp3: compute_antialias compute_imdct synth_fv they are slow for 2 reasons: - no SIMD optims at all - uses integer (fixedpoint) only, which seems to be slower on intel x86 than float it's like ffmpeg12 vs. libmpeg2 was, but that situation improved a lot thanks to Michael. btw i have a mpegaudiodec.c version with optional float support, but it doesnt work and after 3 days i gave it up to found the 100l. probably the bitstream parsing and dequantization should be done in fixed point, then convert to float, and do antialias + imdct in float, using code from mp3lib. converting the parser+equant to float seems horrible, the code is full of bit shifting tricks and int lookup tables. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
On Mon, Oct 27, 2003 at 10:44:56AM +0100, Arpi wrote:
Hi,
reverting my last change as buggy gcc 3.x fails with it :(
gcc addresses local variables by ebp or esp, and push/pop change esp so it cant work (the correct solution would be to make some free space manually on the stack and use that instead)
Strange is that it worked on 2.95.x
Actually the whole code could be rewritten..it's crappy
Actually optims should be ported/redone for ffmp3 and finally rm -rf mp3lib its just broken in many ways, not worth to fix. I'm no mp3lib fan either, but keep in mind that it is still a lot faster on older systems (eg. Pentium II. tested that recently).
It's still a lot faster on any x86 systems, maybe on others too. I was trying to find bottlenecks of ffmp3, and optimize it but failed. The 3 most critical functions of ffmp3: compute_antialias compute_imdct synth_fv
they are slow for 2 reasons: - no SIMD optims at all - uses integer (fixedpoint) only, which seems to be slower on intel x86 than float
Reason 2 is nonsense. On slower x86 (Pentium, K6, ...), integer is MUCH MUCH faster than float! And slower systems are the only ones where mp3 decoding time matters... Rich
On Mon, Oct 27, 2003 at 10:44:56AM +0100, Arpi wrote:
Hi,
> reverting my last change as buggy gcc 3.x fails with it :(
gcc addresses local variables by ebp or esp, and push/pop change esp so it cant work (the correct solution would be to make some free space manually on the stack and use that instead)
Strange is that it worked on 2.95.x
Actually the whole code could be rewritten..it's crappy
Actually optims should be ported/redone for ffmp3 and finally rm -rf mp3lib its just broken in many ways, not worth to fix.
I'm no mp3lib fan either, but keep in mind that it is still a lot faster on older systems (eg. Pentium II. tested that recently).
It's still a lot faster on any x86 systems, maybe on others too. I was trying to find bottlenecks of ffmp3, and optimize it but failed. The 3 most critical functions of ffmp3: compute_antialias compute_imdct synth_fv
they are slow for 2 reasons: - no SIMD optims at all - uses integer (fixedpoint) only, which seems to be slower on intel x86 than float
Reason 2 is nonsense. On slower x86 (Pentium, K6, ...), integer is MUCH MUCH faster than float! And slower systems are the only ones where mp3 decoding time matters... Anyways, mp3lib even contains handcoded fpu assembler code, so probably that's
On Monday 27 October 2003 21:03, D Richard Felker III wrote: the reason.
Rich
-- Best Regards, Atmos ____________________________________________ - MPlayer Developer - http://mplayerhq.hu/ - ____________________________________________
Hi,
Reason 2 is nonsense. On slower x86 (Pentium, K6, ...), integer is MUCH MUCH faster than float! And slower systems are the only ones where mp3 decoding time matters... Anyways, mp3lib even contains handcoded fpu assembler code, so probably that's the reason. Sadly that code (decode_i586) is buggy and produces distorted output
-- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
On Tuesday 28 October 2003 11:20, Alex Beregszaszi wrote:
Hi,
Reason 2 is nonsense. On slower x86 (Pentium, K6, ...), integer is MUCH MUCH faster than float! And slower systems are the only ones where mp3 decoding time matters...
Anyways, mp3lib even contains handcoded fpu assembler code, so probably that's the reason.
Sadly that code (decode_i586) is buggy and produces distorted output Maybe it was broken by all the merging stuff?
Btw. speed difference of mp3lib float code seems to be caused by better latency of fpu insns compared to integer ones (this is especially true on PIV) - see ffmpeg-devel for more detailed discussion. -- Best Regards, Atmos ____________________________________________ - MPlayer Developer - http://mplayerhq.hu/ - ____________________________________________
Reason 2 is nonsense. On slower x86 (Pentium, K6, ...), integer is MUCH MUCH faster than float! And slower systems are the only ones where mp3 decoding time matters...
Anyways, mp3lib even contains handcoded fpu assembler code, so probably that's the reason.
Sadly that code (decode_i586) is buggy and produces distorted output Maybe it was broken by all the merging stuff? No, I haven't touched that part and it's independent from the other
Hi, parts -- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
participants (6)
-
Alex Beregszaszi -
Alex Beregszaszi -
Arpi -
D Richard Felker III -
Felix Buenemann -
Michael Niedermayer