[PATCH] Altivec split-radix FFT
1.6x faster than altivec radix-2 as measured by fft-test on a G4. 2.0x as measured by gprof. I failed to get oprofile or POWERPC_PERF to measure anything. This is my first time writing ppc asm, so any optimization hints are appreciated. I used raw asm rather than intrinsics because gcc adds a ginormous overhead to each function call. Is there anything I need to do to make it work on ppc64, if it doesn't already? --Loren Merritt
Hello, On Mon, Aug 24, 2009 at 6:09 AM, Loren Merritt<lorenm at u.washington.edu> wrote:
1.6x faster than altivec radix-2 as measured by fft-test on a G4. 2.0x as measured by gprof.
Outstanding!
I failed to get oprofile or POWERPC_PERF to measure anything.
Don't use that, it doesn't work.
This is my first time writing ppc asm, so any optimization hints are appreciated.
I'll try to do my best.
I used raw asm rather than intrinsics because gcc adds a ginormous overhead to each function call. Is there anything I need to do to make it work on ppc64, if it doesn't already?
I'll look into this. I think all you need to do is avoid refering to the general purpose registers' name explicitely. You patch doesn't apply cleanly here: patch -p1 --dry-run < ../fft_altivec.diff patching file libavcodec/Makefile Hunk #1 FAILED at 523. 1 out of 1 hunk FAILED -- saving rejects to file libavcodec/Makefile.rej patching file libavcodec/fft.c Hunk #1 FAILED at 110. 1 out of 1 hunk FAILED -- saving rejects to file libavcodec/fft.c.rej patching file libavcodec/ppc/fft_altivec.c Hunk #1 FAILED at 1. Hunk #2 FAILED at 22. Hunk #3 FAILED at 30. 3 out of 3 hunks FAILED -- saving rejects to file libavcodec/ppc/fft_altivec.c.rej patching file libavcodec/ppc/fft_altivec_s.S patching file libavcodec/ppc/types_altivec.h Hunk #1 FAILED at 30. 1 out of 1 hunk FAILED -- saving rejects to file libavcodec/ppc/types_altivec.h.rej patch -p1 --dry-run < ../cleanup.diff patching file libavcodec/dsputil.h Hunk #1 FAILED at 691. 1 out of 1 hunk FAILED -- saving rejects to file libavcodec/dsputil.h.rej patching file libavcodec/fft.c Hunk #1 FAILED at 60. Hunk #2 FAILED at 68. Hunk #3 FAILED at 107. 3 out of 3 hunks FAILED -- saving rejects to file libavcodec/fft.c.rej Did I miss something? Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Mike Ditka - "If God had wanted man to play soccer, he wouldn't have given us arms." - http://www.brainyquote.com/quotes/authors/m/mike_ditka.html
Guillaume POIRIER <poirierg at gmail.com> writes:
Hello,
On Mon, Aug 24, 2009 at 6:09 AM, Loren Merritt<lorenm at u.washington.edu> wrote:
1.6x faster than altivec radix-2 as measured by fft-test on a G4. 2.0x as measured by gprof.
Don't use gprof. It adds huge overhead making it unreliable.
Outstanding!
I failed to get oprofile
What did you try? You should be able to use "sudo opcontrol" on my PPC machine.
or POWERPC_PERF to measure anything.
Don't use that, it doesn't work.
Then we should either fix it or remove it. Keeping it broken serves nobody. -- M?ns Rullg?rd mans at mansr.com
Fixed oprofile thanks to M?ns. Now measures 1.85x FFT speedup, on the sizes vorbis uses. On Mon, 24 Aug 2009, Guillaume POIRIER wrote:
I used raw asm rather than intrinsics because gcc adds a ginormous overhead to each function call. Is there anything I need to do to make it work on ppc64, if it doesn't already?
I'll look into this. I think all you need to do is avoid refering to the general purpose registers' name explicitely.
You mean using registers' number instead? That's the only thing gas supports.
You patch doesn't apply cleanly here: patch -p1 --dry-run < ../fft_altivec.diff [...] Did I miss something?
That command works for me, on top of svn-r19689. --Loren Merritt
Hi, On Mon, Aug 24, 2009 at 1:43 PM, Loren Merritt<lorenm at u.washington.edu> wrote:
Fixed oprofile thanks to M?ns. Now measures 1.85x FFT speedup, on the sizes vorbis uses.
On Mon, 24 Aug 2009, Guillaume POIRIER wrote:
I used raw asm rather than intrinsics because gcc adds a ginormous overhead to each function call. Is there anything I need to do to make it work on ppc64, if it doesn't already?
I'll look into this. I think all you need to do is avoid refering to the general purpose registers' name explicitely.
You mean using registers' number instead? That's the only thing gas supports.
I have no idea what I'm talking about ;-) Your ASM looks OK at first look, but there's smth wrong about it that doesn't make it PPC64-compatible: Starting program: /home/guillaume/ffmpeg-svn/libavcodec/fft-test FFT 512 test Checking... Program received signal SIGSEGV, Segmentation fault. 0x1001115800000000 in ?? () (gdb) up #1 0x00000000100107d0 in .ff_fft_calc_altivec () (gdb) disassemble $pc-32 $pc+32 Dump of assembler code from 0x100107b0 to 0x100107f0: 0x00000000100107b0 <.ff_fft_calc_altivec+524>: ld r9,-31728(r2) 0x00000000100107b4 <.ff_fft_calc_altivec+528>: rldicr r0,r0,3,60 0x00000000100107b8 <.ff_fft_calc_altivec+532>: add r9,r9,r0 0x00000000100107bc <.ff_fft_calc_altivec+536>: ld r11,0(r9) 0x00000000100107c0 <.ff_fft_calc_altivec+540>: mtctr r11 0x00000000100107c4 <.ff_fft_calc_altivec+544>: stw r2,-4(r1) 0x00000000100107c8 <.ff_fft_calc_altivec+548>: li r2,16 0x00000000100107cc <.ff_fft_calc_altivec+552>: bctrl 0x00000000100107d0 <.ff_fft_calc_altivec+556>: lwz r2,-4(r1) 0x00000000100107d4 <.ff_fft_calc_altivec+560>: ld r9,608(r31) 0x00000000100107d8 <.ff_fft_calc_altivec+564>: lwz r0,0(r9) 0x00000000100107dc <.ff_fft_calc_altivec+568>: extsw r0,r0 0x00000000100107e0 <.ff_fft_calc_altivec+572>: cmpwi cr7,r0,4 0x00000000100107e4 <.ff_fft_calc_altivec+576>: bgt- cr7,0x10010810 <.ff_fft_calc_altivec+620> 0x00000000100107e8 <.ff_fft_calc_altivec+580>: ld r11,616(r31) 0x00000000100107ec <.ff_fft_calc_altivec+584>: ld r9,608(r31) End of assembler dump. (gdb) print $r2 $1 = 16 (gdb) print $r1 $2 = 17359809783712 I need to look into this. I've never ported code to PPC64, so now's a good time to start...
You patch doesn't apply cleanly here: patch -p1 --dry-run < ../fft_altivec.diff [...] Did I miss something?
That command works for me, on top of svn-r19689.
The problem was that my version of "patch" was confused by the CR/LF line endings. Fixed locally. Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Ogden Nash - "The trouble with a kitten is that when it grows up, it's always a cat." - http://www.brainyquote.com/quotes/authors/o/ogden_nash.html
Hey, On Wed, Aug 26, 2009 at 12:07 AM, Guillaume POIRIER<poirierg at gmail.com> wrote:
Your ASM looks OK at first look, but there's smth wrong about it that doesn't make it PPC64-compatible:
Starting program: /home/guillaume/ffmpeg-svn/libavcodec/fft-test FFT 512 test Checking...
Program received signal SIGSEGV, Segmentation fault. 0x1001115800000000 in ?? () (gdb) up #1 ?0x00000000100107d0 in .ff_fft_calc_altivec () (gdb) disassemble $pc-32 $pc+32 Dump of assembler code from 0x100107b0 to 0x100107f0: 0x00000000100107b0 <.ff_fft_calc_altivec+524>: ?ld ? ? ?r9,-31728(r2) 0x00000000100107b4 <.ff_fft_calc_altivec+528>: ?rldicr ?r0,r0,3,60 0x00000000100107b8 <.ff_fft_calc_altivec+532>: ?add ? ? r9,r9,r0 0x00000000100107bc <.ff_fft_calc_altivec+536>: ?ld ? ? ?r11,0(r9) 0x00000000100107c0 <.ff_fft_calc_altivec+540>: ?mtctr ? r11 0x00000000100107c4 <.ff_fft_calc_altivec+544>: ?stw ? ? r2,-4(r1) 0x00000000100107c8 <.ff_fft_calc_altivec+548>: ?li ? ? ?r2,16 0x00000000100107cc <.ff_fft_calc_altivec+552>: ?bctrl 0x00000000100107d0 <.ff_fft_calc_altivec+556>: ?lwz ? ? r2,-4(r1) 0x00000000100107d4 <.ff_fft_calc_altivec+560>: ?ld ? ? ?r9,608(r31) 0x00000000100107d8 <.ff_fft_calc_altivec+564>: ?lwz ? ? r0,0(r9) 0x00000000100107dc <.ff_fft_calc_altivec+568>: ?extsw ? r0,r0 0x00000000100107e0 <.ff_fft_calc_altivec+572>: ?cmpwi ? cr7,r0,4 0x00000000100107e4 <.ff_fft_calc_altivec+576>: ?bgt- ? ?cr7,0x10010810 <.ff_fft_calc_altivec+620> 0x00000000100107e8 <.ff_fft_calc_altivec+580>: ?ld ? ? ?r11,616(r31) 0x00000000100107ec <.ff_fft_calc_altivec+584>: ?ld ? ? ?r9,608(r31) End of assembler dump. (gdb) print $r2 $1 = 16 (gdb) print $r1 $2 = 17359809783712
I need to look into this. I've never ported code to PPC64, so now's a good time to start...
There's really little information about inline asm PPC64 programming. So far, it looks like PPC64 is exactly the same thing as PPC32, except that it allows 64-bits pointers. The previous error I reported was on Linux/PPC64, where your code was compiling/assembling OK, but not running. I tried fix that problem on my local OSXLepoard/PPC, and in fact, your code doesn't assemble with that toolchain. That can't be good. This is the relevant part of your code (from ff_fft_calc_altivec() function) : + "mtctr %0 \n" + "stw 2,-4(1) \n" + "li 2,16 \n" + "bctrl \n" + "lwz 2,-4(1) \n" // ABI docs say r2 is general purpose and caller-saved, but gcc doesn't save it and crashes Which translates into: L214: mtctr r11 L215: stw 2,-4(1) L216: li 2,16 L217: bctrl L218: lwz 2,-4(1) The error message is: libavcodec/ppc/fft_altivec.S:215:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:216:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:218:Parameter syntax error (parameter 1) I honestly don't understand what's wrong with what you wrote. OSX toolchain doesn't like that code neither for PPC32 nor PPC64 target. I guess I have many more things to learn about that in the following days... Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Charles de Gaulle - "The better I get to know men, the more I find myself loving dogs." - http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html
Guillaume POIRIER <poirierg at gmail.com> writes:
Hey,
On Wed, Aug 26, 2009 at 12:07 AM, Guillaume POIRIER<poirierg at gmail.com> wrote: There's really little information about inline asm PPC64 programming.
I've found gcc source code to be the best documentation for inline asm.
So far, it looks like PPC64 is exactly the same thing as PPC32, except that it allows 64-bits pointers.
Registers are 64-bit instead of 32-bit which makes a hell of a difference if you use the full width.
The previous error I reported was on Linux/PPC64, where your code was compiling/assembling OK, but not running. I tried fix that problem on my local OSXLepoard/PPC, and in fact, your code doesn't assemble with that toolchain. That can't be good.
This is the relevant part of your code (from ff_fft_calc_altivec() function):
+ "mtctr %0 \n" + "stw 2,-4(1) \n" + "li 2,16 \n" + "bctrl \n" + "lwz 2,-4(1) \n" // ABI docs say r2 is general purpose and caller-saved, but gcc doesn't save it and crashes
Which ABI doc was that? Mine says r2 is "reserved for system use and should not be changed by application code". Be that as it may, I assume you meant stwu to push the value of r2 and lwz/addi to restore it. Even with that change, it would fail on ppc64 since you'd be preserving only half the register. Furthermore, the ABI mandates a 16-byte-aligned stack at all times, but you could probably get away without that if you never call any compiled code.
Which translates into: L214: mtctr r11 L215: stw 2,-4(1) L216: li 2,16 L217: bctrl L218: lwz 2,-4(1)
The error message is: libavcodec/ppc/fft_altivec.S:215:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:216:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:218:Parameter syntax error (parameter 1)
I honestly don't understand what's wrong with what you wrote. OSX toolchain doesn't like that code neither for PPC32 nor PPC64 target.
That's probably the assembler throwing a fit over the reserved r2 register. You could cheat it by writing the instructions with .word directives instead. -- M?ns Rullg?rd mans at mansr.com
On Aug 26, 2009, at 5:28 PM, M?ns Rullg?rd wrote:
Guillaume POIRIER <poirierg at gmail.com> writes:
Hey,
The previous error I reported was on Linux/PPC64, where your code was compiling/assembling OK, but not running. I tried fix that problem on my local OSXLepoard/PPC, and in fact, your code doesn't assemble with that toolchain. That can't be good.
This is the relevant part of your code (from ff_fft_calc_altivec() function):
+ "mtctr %0 \n" + "stw 2,-4(1) \n" + "li 2,16 \n" + "bctrl \n" + "lwz 2,-4(1) \n" // ABI docs say r2 is general purpose and caller-saved, but gcc doesn't save it and crashes
Which ABI doc was that? Mine says r2 is "reserved for system use and should not be changed by application code". Be that as it may, I assume you meant stwu to push the value of r2 and lwz/addi to restore it. Even with that change, it would fail on ppc64 since you'd be preserving only half the register. Furthermore, the ABI mandates a 16-byte-aligned stack at all times, but you could probably get away without that if you never call any compiled code.
On OS X at least it's general purpose. http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelA...
Which translates into: L214: mtctr r11 L215: stw 2,-4(1) L216: li 2,16 L217: bctrl L218: lwz 2,-4(1)
The error message is: libavcodec/ppc/fft_altivec.S:215:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:216:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:218:Parameter syntax error (parameter 1)
I honestly don't understand what's wrong with what you wrote. OSX toolchain doesn't like that code neither for PPC32 nor PPC64 target.
That's probably the assembler throwing a fit over the reserved r2 register. You could cheat it by writing the instructions with .word directives instead.
Apple's gas only accepts register names, not numbers for asm. So it would be stw r2, -4(r1) etc. Apple's gas also doesn't support the macro syntax used in the .S, doesn't support .ifb, and uses .const_data instead of .rodata.
David Conrad <lessen42 at gmail.com> writes:
On Aug 26, 2009, at 5:28 PM, M?ns Rullg?rd wrote:
Guillaume POIRIER <poirierg at gmail.com> writes:
Hey,
The previous error I reported was on Linux/PPC64, where your code was compiling/assembling OK, but not running. I tried fix that problem on my local OSXLepoard/PPC, and in fact, your code doesn't assemble with that toolchain. That can't be good.
This is the relevant part of your code (from ff_fft_calc_altivec() function):
+ "mtctr %0 \n" + "stw 2,-4(1) \n" + "li 2,16 \n" + "bctrl \n" + "lwz 2,-4(1) \n" // ABI docs say r2 is general purpose and caller-saved, but gcc doesn't save it and crashes
Which ABI doc was that? Mine says r2 is "reserved for system use and should not be changed by application code". Be that as it may, I assume you meant stwu to push the value of r2 and lwz/addi to restore it. Even with that change, it would fail on ppc64 since you'd be preserving only half the register. Furthermore, the ABI mandates a 16-byte-aligned stack at all times, but you could probably get away without that if you never call any compiled code.
On OS X at least it's general purpose. http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelA...
I was reading the PPC ELF spec. I guess they're different.
Which translates into: L214: mtctr r11 L215: stw 2,-4(1) L216: li 2,16 L217: bctrl L218: lwz 2,-4(1)
The error message is: libavcodec/ppc/fft_altivec.S:215:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:216:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec.S:218:Parameter syntax error (parameter 1)
I honestly don't understand what's wrong with what you wrote. OSX toolchain doesn't like that code neither for PPC32 nor PPC64 target.
That's probably the assembler throwing a fit over the reserved r2 register. You could cheat it by writing the instructions with .word directives instead.
Apple's gas only accepts register names, not numbers for asm. So it would be stw r2, -4(r1) etc.
And gnu gas only supports numbers. For extra fun, objdump uses r names. -- M?ns Rullg?rd mans at mansr.com
On Wed, 26 Aug 2009, M?ns Rullg?rd wrote:
+ "mtctr %0 \n" + "stw 2,-4(1) \n" + "li 2,16 \n" + "bctrl \n" + "lwz 2,-4(1) \n" // ABI docs say r2 is general purpose and caller-saved, but gcc doesn't save it and crashes
I assume you meant stwu to push the value of r2 and lwz/addi to restore it. Even with that change, it would fail on ppc64 since you'd be preserving only half the register. Furthermore, the ABI mandates a 16-byte-aligned stack at all times, but you could probably get away without that if you never call any compiled code.
I meant to store it in the redzone. My asm also never touches the stack pointer, and store their return addresses at fixed locations in the redzone. --Loren Merritt
Loren Merritt <lorenm at u.washington.edu> writes:
On Wed, 26 Aug 2009, M?ns Rullg?rd wrote:
+ "mtctr %0 \n" + "stw 2,-4(1) \n" + "li 2,16 \n" + "bctrl \n" + "lwz 2,-4(1) \n" // ABI docs say r2 is general purpose and caller-saved, but gcc doesn't save it and crashes
I assume you meant stwu to push the value of r2 and lwz/addi to restore it. Even with that change, it would fail on ppc64 since you'd be preserving only half the register. Furthermore, the ABI mandates a 16-byte-aligned stack at all times, but you could probably get away without that if you never call any compiled code.
I meant to store it in the redzone. My asm also never touches the stack pointer, and store their return addresses at fixed locations in the redzone.
What redzone? There isn't one on PPC. -- M?ns Rullg?rd mans at mansr.com
On Thu, 27 Aug 2009, M?ns Rullg?rd wrote:
Loren Merritt <lorenm at u.washington.edu> writes:
I meant to store it in the redzone. My asm also never touches the stack pointer, and store their return addresses at fixed locations in the redzone.
What redzone? There isn't one on PPC.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelA... But I underestimated the number of different ABIs involved. Anyway, already fixed in my 2nd patch. --Loren Merritt
Loren Merritt <lorenm at u.washington.edu> writes:
On Thu, 27 Aug 2009, M?ns Rullg?rd wrote:
Loren Merritt <lorenm at u.washington.edu> writes:
I meant to store it in the redzone. My asm also never touches the stack pointer, and store their return addresses at fixed locations in the redzone.
What redzone? There isn't one on PPC.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelA... But I underestimated the number of different ABIs involved.
Which ones have you found so far? -- M?ns Rullg?rd mans at mansr.com
Now with MDCT, and tested on PPC64. --Loren Merritt
Hello, On Thu, Aug 27, 2009 at 2:44 PM, Loren Merritt<lorenm at u.washington.edu> wrote:
Now with MDCT, and tested on PPC64.
It indeed now works on Linux/PPC64 and Linux/PPC32, but still not on OSX/PPC*. Do you think that gas' .macro functionalities could allow to make your ASM portable across both Linux and OSX, defining each register Rx as either rx on OSX, and x on all the other platforms that use FSF tools? Cheers, Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a day." - http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html
On Fri, Aug 28, 2009 at 10:02:35AM +0200, Guillaume POIRIER wrote:
On Thu, Aug 27, 2009 at 2:44 PM, Loren Merritt<lorenm at u.washington.edu> wrote:
Now with MDCT, and tested on PPC64.
It indeed now works on Linux/PPC64 and Linux/PPC32, but still not on OSX/PPC*.
Do you think that gas' .macro functionalities could allow to make your ASM portable across both Linux and OSX, defining each register Rx as either rx on OSX, and x on all the other platforms that use FSF tools?
It is preprocessed anyway, you can just define REG_1... REG_n in a header and in include that in both C and asm files.
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
On Fri, Aug 28, 2009 at 10:02:35AM +0200, Guillaume POIRIER wrote:
On Thu, Aug 27, 2009 at 2:44 PM, Loren Merritt<lorenm at u.washington.edu> wrote:
Now with MDCT, and tested on PPC64.
It indeed now works on Linux/PPC64 and Linux/PPC32, but still not on OSX/PPC*.
Do you think that gas' .macro functionalities could allow to make your ASM portable across both Linux and OSX, defining each register Rx as either rx on OSX, and x on all the other platforms that use FSF tools?
It is preprocessed anyway, you can just define REG_1... REG_n in a header and in include that in both C and asm files.
I'd just #define r1 1 etc for the cases that prefer numbers over names. -- M?ns Rullg?rd mans at mansr.com
On Fri, 28 Aug 2009, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
On Fri, Aug 28, 2009 at 10:02:35AM +0200, Guillaume POIRIER wrote:
It indeed now works on Linux/PPC64 and Linux/PPC32, but still not on OSX/PPC*.
Do you think that gas' .macro functionalities could allow to make your ASM portable across both Linux and OSX, defining each register Rx as either rx on OSX, and x on all the other platforms that use FSF tools?
It is preprocessed anyway, you can just define REG_1... REG_n in a header and in include that in both C and asm files.
I'd just #define r1 1 etc for the cases that prefer numbers over names.
Avoided .ifb. Fixed register names (untested). The manually unrolled list is ugly, but I can't find a gas equivalent to yasm's ability to expand macros in macro names. Are the other configure checks for ppc asm broken? Some use register names and some don't, and I don't think this is what they're supposed to be detecting. When the first reg of an address is being a literal zero rather than a register, should it be named? Didn't change .rodata. Is there some version-dependent define for that? Or same/another configure check? --Loren Merritt
On Fri, Aug 28, 2009 at 04:48:08PM +0000, Loren Merritt wrote:
--- a/configure +++ b/configure @@ -2107,6 +2108,7 @@ elif enabled mips; then
+ check_asm named_regs '"add r0, r0, r0"' check_asm dcbzl '"dcbzl 0, 1"' check_asm ppc4xx '"maclhw r10, r11, r12"' check_asm xform_asm '"lwzx 0, %y0" :: "Z"(*(int*)0)'
nit: alphabetical order
--- a/libavcodec/ppc/fft_altivec.c +++ b/libavcodec/ppc/fft_altivec.c @@ -30,106 +30,66 @@ +static void swizzle(vec_f *z, int n) +{ + int i; + n >>= 1; + for(i=0; i<n; i+=2) {
for (i = 0; i < n; i += 2) { I have a PPC, so let me know if you need some testing on my PowerBook G4. Diego
Loren Merritt <lorenm at u.washington.edu> writes:
On Fri, 28 Aug 2009, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
On Fri, Aug 28, 2009 at 10:02:35AM +0200, Guillaume POIRIER wrote:
It indeed now works on Linux/PPC64 and Linux/PPC32, but still not on OSX/PPC*.
Do you think that gas' .macro functionalities could allow to make your ASM portable across both Linux and OSX, defining each register Rx as either rx on OSX, and x on all the other platforms that use FSF tools?
It is preprocessed anyway, you can just define REG_1... REG_n in a header and in include that in both C and asm files.
I'd just #define r1 1 etc for the cases that prefer numbers over names.
Avoided .ifb.
Fixed register names (untested). The manually unrolled list is ugly, but I can't find a gas equivalent to yasm's ability to expand macros in macro names.
Can you elaborate on that?
Are the other configure checks for ppc asm broken? Some use register names and some don't, and I don't think this is what they're supposed to be detecting. When the first reg of an address is being a literal zero rather than a register, should it be named?
I suggest writing literal zeros as a digit zero (0) if the assembler accepts this.
Didn't change .rodata. Is there some version-dependent define for that? Or same/another configure check?
What is the problem with .rodata again? -- M?ns Rullg?rd mans at mansr.com
On Tue, 15 Sep 2009, M?ns Rullg?rd wrote:
Loren Merritt <lorenm at u.washington.edu> writes:
Fixed register names (untested). The manually unrolled list is ugly, but I can't find a gas equivalent to yasm's ability to expand macros in macro names.
Can you elaborate on that?
gas: DEFINE_REG 0 DEFINE_REG 1 DEFINE_REG 2 DEFINE_REG 3 DEFINE_REG 4 DEFINE_REG 5 DEFINE_REG 6 DEFINE_REG 7 DEFINE_REG 8 DEFINE_REG 9 DEFINE_REG 10 DEFINE_REG 11 DEFINE_REG 12 DEFINE_REG 13 DEFINE_REG 14 DEFINE_REG 15 DEFINE_REG 16 DEFINE_REG 17 DEFINE_REG 18 DEFINE_REG 19 DEFINE_REG 20 DEFINE_REG 21 DEFINE_REG 22 DEFINE_REG 23 DEFINE_REG 24 DEFINE_REG 25 DEFINE_REG 26 DEFINE_REG 27 DEFINE_REG 28 DEFINE_REG 29 DEFINE_REG 30 DEFINE_REG 31 yasm: %assign i 0 %rep 32 DEFINE_REG i %assign i i+1 %endrep
Didn't change .rodata. Is there some version-dependent define for that? Or same/another configure check?
What is the problem with .rodata again?
Apple calls it .const_data instead. Remaining problems that I don't know how to solve: The only macro syntax that gas supports is named args. The only macro syntax that Apple as supports is numbered args. So a polyglot can't use macros at all. And Guillame said that Apple as doesn't have a string concatenation operator. Can we just not support Apple? That would make it all simple. --Loren Merritt
Loren Merritt <lorenm at u.washington.edu> writes:
On Tue, 15 Sep 2009, M?ns Rullg?rd wrote:
Loren Merritt <lorenm at u.washington.edu> writes:
Fixed register names (untested). The manually unrolled list is ugly, but I can't find a gas equivalent to yasm's ability to expand macros in macro names.
Can you elaborate on that?
gas: DEFINE_REG 0 DEFINE_REG 1 [...]
yasm: %assign i 0 %rep 32 DEFINE_REG i %assign i i+1 %endrep
I can't think of a way to do that with gas.
Didn't change .rodata. Is there some version-dependent define for that? Or same/another configure check?
What is the problem with .rodata again?
Apple calls it .const_data instead.
That would be easily solved with an ifdef or two.
Remaining problems that I don't know how to solve: The only macro syntax that gas supports is named args. The only macro syntax that Apple as supports is numbered args. So a polyglot can't use macros at all.
So it's the same mess as on ARM.
And Guillame said that Apple as doesn't have a string concatenation operator.
Can we just not support Apple? That would make it all simple.
I won't complain. If there's anyone left running macos on ppc, they can use David's script to convert the syntax. -- M?ns Rullg?rd mans at mansr.com
Hi, On Thu, Aug 27, 2009 at 2:44 PM, Loren Merritt <lorenm at u.washington.edu>wrote:
Now with MDCT, and tested on PPC64.
I can confirm it works as expected with FSF toolchain, but still fails with Apple toolchain. I fixed locally the fact that Apple toolchain doesn't supported named parameters, but only supports numbered parameters ($0 to $9). The problem I can't seem to be able to fix is the string concat problem (i.e. generating symbol names based on the macro's parameters): gcc-4.2 -arch ppc64 -DHAVE_AV_CONFIG_H -I. -I"/Users/gpoirier/Prgm/ffmpeg-git" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -mcpu=970 -mpowerpc-gfxopt -mpowerpc64 -mdynamic-no-pic -MMD -MF libavcodec/ppc/fft_altivec_s.d -MT libavcodec/ppc/fft_altivec_s.o -c -o libavcodec/ppc/fft_altivec_s.o libavcodec/ppc/fft_altivec_s.S libavcodec/ppc/fft_altivec_s.S:323:Invalid mnemonic 'fft_pass\()_altivec:' libavcodec/ppc/fft_altivec_s.S:323:Invalid mnemonic 'fft32\()_altivec:' libavcodec/ppc/fft_altivec_s.S:323:Parameter syntax error (parameter 1) libavcodec/ppc/fft_altivec_s.S:323:Rest of line ignored. 1st junk character valued 92 (\). libavcodec/ppc/fft_altivec_s.S:323:Missing ')' assumed I found the part of GAS' doc that refers to it: http://sourceware.org/binutils/docs-2.19/as/Macro.html#MacroBut it looks like Apple's GAS doesn't support that syntax: http://developer.apple.com/mac/library/documentation/DeveloperTools/Referenc... I'll try with spaces as FSF's doc suggests it instead of \() (but Apple doesn't suggests anything). Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Mike Ditka <http://www.brainyquote.com/quotes/authors/m/mike_ditka.html> - "If God had wanted man to play soccer, he wouldn't have given us arms."
On Mon, 31 Aug 2009, Guillaume POIRIER wrote:
[more differences between apple and fsf]
Wow, I never thought I'd see a polyglot in production code. Are you sure we can't, like, stick with one language? --Loren Merritt
Now without Apple workarounds. --Loren Merritt
Hello, Loren Merritt a ?crit :
Now without Apple workarounds.
As far as I'm concerned, I'm OK with the idea of not supporting Apple's GAS, however, I'd like to have PPC/OSX users being able to use an optimized split-radix FFT, using the earlier version of your patch that used AlitVec C intrinsics. Ok, this means code duplication, but isn't it better than letting OSX users only use the C version of the split-radix FFT? Guillaume
On Fri, Sep 18, 2009 at 04:30:55PM +0200, Guillaume Poirier wrote:
Hello,
Loren Merritt a ?crit :
Now without Apple workarounds.
As far as I'm concerned, I'm OK with the idea of not supporting Apple's GAS, however, I'd like to have PPC/OSX users being able to use an optimized split-radix FFT, using the earlier version of your patch that used AlitVec C intrinsics.
Ok, this means code duplication, but isn't it better than letting OSX users only use the C version of the split-radix FFT?
cant osx users just install a working toolchain? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
Hi, On Fri, Sep 18, 2009 at 12:10 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
cant osx users just install a working toolchain?
It's legacy; all current OSX ship for x86. Ronald
Michael Niedermayer <michaelni at gmx.at> writes:
On Fri, Sep 18, 2009 at 04:30:55PM +0200, Guillaume Poirier wrote:
Hello,
Loren Merritt a ?crit :
Now without Apple workarounds.
As far as I'm concerned, I'm OK with the idea of not supporting Apple's GAS, however, I'd like to have PPC/OSX users being able to use an optimized split-radix FFT, using the earlier version of your patch that used AlitVec C intrinsics.
Ok, this means code duplication, but isn't it better than letting OSX users only use the C version of the split-radix FFT?
cant osx users just install a working toolchain?
No, because there isn't one. However, I doubt there are many people still running macos on PPC. -- M?ns Rullg?rd mans at mansr.com
On Fri, Sep 18, 2009 at 05:25:45PM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
On Fri, Sep 18, 2009 at 04:30:55PM +0200, Guillaume Poirier wrote:
Hello,
Loren Merritt a ?crit :
Now without Apple workarounds.
As far as I'm concerned, I'm OK with the idea of not supporting Apple's GAS, however, I'd like to have PPC/OSX users being able to use an optimized split-radix FFT, using the earlier version of your patch that used AlitVec C intrinsics.
Ok, this means code duplication, but isn't it better than letting OSX users only use the C version of the split-radix FFT?
cant osx users just install a working toolchain?
No, because there isn't one. However, I doubt there are many people still running macos on PPC.
I don't think so. I, for one, still do. Of course PPC is on its way to become a fringe platform, but there are many usable machines out there. Diego
On Fri, Sep 18, 2009 at 05:25:45PM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
On Fri, Sep 18, 2009 at 04:30:55PM +0200, Guillaume Poirier wrote:
Hello,
Loren Merritt a ?crit :
Now without Apple workarounds.
As far as I'm concerned, I'm OK with the idea of not supporting Apple's GAS, however, I'd like to have PPC/OSX users being able to use an optimized split-radix FFT, using the earlier version of your patch that used AlitVec C intrinsics.
Ok, this means code duplication, but isn't it better than letting OSX users only use the C version of the split-radix FFT?
cant osx users just install a working toolchain?
No, because there isn't one. However, I doubt there are many people still running macos on PPC.
For example, I do and intend in near future. Also don't forget purists that care about some features missing on some platform (like nobody cared about NEON port of FFT).
-- M?ns Rullg?rd mans at mansr.com
Kostya <kostya.shishkov at gmail.com> writes:
On Fri, Sep 18, 2009 at 05:25:45PM +0100, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
On Fri, Sep 18, 2009 at 04:30:55PM +0200, Guillaume Poirier wrote:
Hello,
Loren Merritt a ?crit :
Now without Apple workarounds.
As far as I'm concerned, I'm OK with the idea of not supporting Apple's GAS, however, I'd like to have PPC/OSX users being able to use an optimized split-radix FFT, using the earlier version of your patch that used AlitVec C intrinsics.
Ok, this means code duplication, but isn't it better than letting OSX users only use the C version of the split-radix FFT?
cant osx users just install a working toolchain?
No, because there isn't one. However, I doubt there are many people still running macos on PPC.
For example, I do and intend in near future.
Do they still release PPC versions? -- M?ns Rullg?rd mans at mansr.com
On Fri, Sep 18, 2009 at 02:10:57PM +0000, Loren Merritt wrote:
Now without Apple workarounds.
--- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -527,11 +527,13 @@ ALTIVEC-OBJS-$(CONFIG_VC1_DECODER) += ppc/vc1dsp_altivec.o ALTIVEC-OBJS-$(CONFIG_VP3_DECODER) += ppc/vp3dsp_altivec.o ALTIVEC-OBJS-$(CONFIG_VP5_DECODER) += ppc/vp3dsp_altivec.o ALTIVEC-OBJS-$(CONFIG_VP6_DECODER) += ppc/vp3dsp_altivec.o +ALTIVEC-OBJS-FFT-$(HAVE_FSF_GAS) += ppc/fft_altivec.o \ + ppc/fft_altivec_s.o \
Please place these lines above the other ALTIVEC-OBJS- lines, like this: ALTIVEC-OBJS-FFT-$(HAVE_FSF_GAS) += ppc/fft_altivec.o \ ppc/fft_altivec_s.o \ ALTIVEC-OBJS-$(CONFIG_FFT) += $(ALTIVEC-OBJS-FFT-yes) ALTIVEC-OBJS-$(CONFIG_H264_DECODER) += ppc/h264_altivec.o ALTIVEC-OBJS-$(CONFIG_VC1_DECODER) += ppc/vc1dsp_altivec.o ALTIVEC-OBJS-$(CONFIG_VP3_DECODER) += ppc/vp3dsp_altivec.o ALTIVEC-OBJS-$(CONFIG_VP5_DECODER) += ppc/vp3dsp_altivec.o ALTIVEC-OBJS-$(CONFIG_VP6_DECODER) += ppc/vp3dsp_altivec.o Diego
Loren Merritt <lorenm at u.washington.edu> writes:
Now without Apple workarounds.
--Loren Merritt
From 100bf86add9537c20f4db2c5d2eeb2880c9c705e Mon Sep 17 00:00:00 2001 From: Loren Merritt <pengvado at akuvian.org> Date: Sat, 22 Aug 2009 11:22:09 +0100 Subject: [PATCH 1/3] altivec split-radix FFT 1.8x faster than altivec radix-2 on a G4 8% faster vorbis decoding
--- configure | 2 + libavcodec/Makefile | 4 +- libavcodec/fft.c | 2 +- libavcodec/ppc/asm.S | 59 ++++++++ libavcodec/ppc/fft_altivec.c | 152 +++++++------------- libavcodec/ppc/fft_altivec_s.S | 322 ++++++++++++++++++++++++++++++++++++++++ libavcodec/ppc/types_altivec.h | 1 + 7 files changed, 440 insertions(+), 102 deletions(-) create mode 100644 libavcodec/ppc/asm.S create mode 100644 libavcodec/ppc/fft_altivec_s.S
diff --git a/configure b/configure index 6aa6177..fdb6ade 100755 --- a/configure +++ b/configure @@ -933,6 +933,7 @@ HAVE_LIST=" fast_cmov fast_unaligned fork + fsf_gas gethrtime GetProcessTimes getrusage @@ -2108,6 +2109,7 @@ elif enabled mips; then elif enabled ppc; then
check_asm dcbzl '"dcbzl 0, 1"' + check_asm fsf_gas '"add 0, 0, 0"' check_asm ppc4xx '"maclhw r10, r11, r12"' check_asm xform_asm '"lwzx 0, %y0" :: "Z"(*(int*)0)'
This is the syntax the IBM PPC documentation uses, so branding it fsf seems a bit wrong.
diff --git a/libavcodec/fft.c b/libavcodec/fft.c index c827139..52bc73a 100644 --- a/libavcodec/fft.c +++ b/libavcodec/fft.c @@ -89,7 +89,7 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int inverse) s->split_radix = 1;
if (ARCH_ARM) ff_fft_init_arm(s); - if (HAVE_ALTIVEC) ff_fft_init_altivec(s); + if (HAVE_ALTIVEC && HAVE_FSF_GAS) ff_fft_init_altivec(s); if (HAVE_MMX) ff_fft_init_mmx(s);
if (s->split_radix) {
I'd rather hide this condition inside ff_fft_init_altivec().
diff --git a/libavcodec/ppc/fft_altivec.c b/libavcodec/ppc/fft_altivec.c index 83b2b7f..235f205 100644 --- a/libavcodec/ppc/fft_altivec.c +++ b/libavcodec/ppc/fft_altivec.c [...] +extern FFTSample ff_cos_16[];
Isn't this declared in some header file? If not, it should be.
+// pointers to functions. but unlike function pointers on some PPC ABIs, these aren't function descriptors.
What does that mean? Not saying it's wrong, I just don't understand it.
From fc014fba0a5c39e47d2cb651856d1b1e83c4edf9 Mon Sep 17 00:00:00 2001 From: Loren Merritt <pengvado at akuvian.org> Date: Wed, 26 Aug 2009 09:44:32 +0100 Subject: [PATCH 2/3] remove vestiges of radix-2 FFT
--- libavcodec/dsputil.h | 3 - libavcodec/fft.c | 83 +++--------------------------------------------------- libavcodec/ppc/fft_altivec.c | 1 3 files changed, 5 insertions(+), 82 deletions(-)
diff --git a/libavcodec/dsputil.h b/libavcodec/dsputil.h index d100d5f..901f8a7 100644 --- a/libavcodec/dsputil.h +++ b/libavcodec/dsputil.h @@ -675,15 +675,12 @@ typedef struct FFTContext { int nbits; int inverse; uint16_t *revtab; - FFTComplex *exptab; - FFTComplex *exptab1; /* only used by SSE code */
I need to update the offsets in the NEON code for this, so don't commit without telling me first.
diff --git a/libavcodec/fft.c b/libavcodec/fft.c index 52bc73a..a7c7b96 100644 --- a/libavcodec/fft.c +++ b/libavcodec/fft.c @@ -60,39 +60,30 @@ static int split_radix_permutation(int i, int n, int inverse)
av_cold int ff_fft_init(FFTContext *s, int nbits, int inverse) { - int i, j, m, n; - float alpha, c1, s1, s2; - int av_unused has_vectors; + int i, j, n;
if (nbits < 2 || nbits > 16) goto fail; s->nbits = nbits; n = 1 << nbits;
- s->tmp_buf = NULL; - s->exptab = av_malloc((n / 2) * sizeof(FFTComplex)); - if (!s->exptab) - goto fail; s->revtab = av_malloc(n * sizeof(uint16_t)); if (!s->revtab) goto fail; + s->tmp_buf = av_malloc(n * sizeof(FFTComplex)); + if (!s->tmp_buf) + goto fail; s->inverse = inverse;
- s2 = inverse ? 1.0 : -1.0; - s->fft_permute = ff_fft_permute_c; s->fft_calc = ff_fft_calc_c; s->imdct_calc = ff_imdct_calc_c; s->imdct_half = ff_imdct_half_c; - s->mdct_calc = ff_mdct_calc_c;
I think that line should stay.
- s->exptab1 = NULL; - s->split_radix = 1;
if (ARCH_ARM) ff_fft_init_arm(s); if (HAVE_ALTIVEC && HAVE_FSF_GAS) ff_fft_init_altivec(s); if (HAVE_MMX) ff_fft_init_mmx(s);
diff --git a/libavcodec/ppc/fft_altivec.c b/libavcodec/ppc/fft_altivec.c index 235f205..9f01992 100644 --- a/libavcodec/ppc/fft_altivec.c +++ b/libavcodec/ppc/fft_altivec.c @@ -89,5 +89,4 @@ void ff_fft_calc_altivec(FFTContext *s, FFTComplex *z) av_cold void ff_fft_init_altivec(FFTContext *s) { s->fft_calc = ff_fft_calc_altivec; - s->split_radix = 1; }
From e2e5f93792d62becaa666723ce26f81472e2eddc Mon Sep 17 00:00:00 2001 From: Loren Merritt <pengvado at akuvian.org> Date: Wed, 26 Aug 2009 10:08:06 +0100 Subject: [PATCH 3/3] altivec imdct 1.8x faster than C iMDCT (excluding the FFT part) on a G4 10% faster vorbis decoding
--- libavcodec/ppc/fft_altivec.c | 113 ++++++++++++++++++++++++++++++++++++++++- 1 files changed, 110 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ppc/fft_altivec.c b/libavcodec/ppc/fft_altivec.c index 9f01992..0d4ced3 100644 --- a/libavcodec/ppc/fft_altivec.c +++ b/libavcodec/ppc/fft_altivec.c @@ -49,7 +49,7 @@ static void swizzle(vec_f *z, int n) } }
-void ff_fft_calc_altivec(FFTContext *s, FFTComplex *z) +static av_always_inline void fft_dispatch(FFTContext *s, FFTComplex *z, int do_swizzle) { register vec_f v14 __asm__("v14") = {0,0,0,0}; register vec_f v15 __asm__("v15") = *(const vec_f*)ff_cos_16; @@ -75,18 +75,125 @@ void ff_fft_calc_altivec(FFTContext *s, FFTComplex *z) "subi 1,1,%1 \n" "bctrl \n" "addi 1,1,%1 \n" - ::"r"(ff_fft_dispatch_altivec[1][s->nbits-2]), "i"(12*sizeof(void*)), + ::"r"(ff_fft_dispatch_altivec[do_swizzle][s->nbits-2]), "i"(12*sizeof(void*)), "r"(zarg), "r"(cos_tabs), "v"(v14),"v"(v15),"v"(v16),"v"(v17),"v"(v18),"v"(v19),"v"(v20),"v"(v21), "v"(v22),"v"(v23),"v"(v24),"v"(v25),"v"(v26),"v"(v27),"v"(v28),"v"(v29) : "lr","ctr","r0","r4","r5","r6","r7","r8","r9","r10","r11", "v0","v1","v2","v3","v4","v5","v6","v7","v8","v9","v10","v11","v12","v13" ); - if (s->nbits <= 4) + if (do_swizzle && s->nbits <= 4) swizzle((vec_f*)z, 1<<s->nbits); }
+static void ff_fft_calc_altivec(FFTContext *s, FFTComplex *z) +{ + fft_dispatch(s, z, 1); +} + +static void ff_imdct_half_altivec(MDCTContext *s, FFTSample *output, const FFTSample *input) +{ + int j, k; + int n = 1 << s->nbits; + int n4 = n >> 2; + int n8 = n >> 3; + int n32 = n >> 5; + const uint16_t *revtabj = s->fft.revtab; + const uint16_t *revtabk = s->fft.revtab+n4; + const vec_f *tcos = (const vec_f*)(s->tcos+n8); + const vec_f *tsin = (const vec_f*)(s->tsin+n8); + const vec_f *pin = (const vec_f*)(input+n4); + vec_f *pout = (vec_f*)(output+n4);
Why the intrinsics here? -- M?ns Rullg?rd mans at mansr.com
On Fri, 18 Sep 2009, M?ns Rullg?rd wrote:
On Fri, 18 Sep 2009, Loren Merritt wrote:
Now without Apple workarounds.
diff --git a/configure b/configure index 6aa6177..fdb6ade 100755 --- a/configure +++ b/configure @@ -933,6 +933,7 @@ HAVE_LIST=" fast_cmov fast_unaligned fork + fsf_gas gethrtime GetProcessTimes getrusage @@ -2108,6 +2109,7 @@ elif enabled mips; then elif enabled ppc; then
check_asm dcbzl '"dcbzl 0, 1"' + check_asm fsf_gas '"add 0, 0, 0"' check_asm ppc4xx '"maclhw r10, r11, r12"' check_asm xform_asm '"lwzx 0, %y0" :: "Z"(*(int*)0)'
This is the syntax the IBM PPC documentation uses, so branding it fsf seems a bit wrong.
changed.
diff --git a/libavcodec/fft.c b/libavcodec/fft.c index c827139..52bc73a 100644 --- a/libavcodec/fft.c +++ b/libavcodec/fft.c @@ -89,7 +89,7 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int inverse) s->split_radix = 1;
if (ARCH_ARM) ff_fft_init_arm(s); - if (HAVE_ALTIVEC) ff_fft_init_altivec(s); + if (HAVE_ALTIVEC && HAVE_FSF_GAS) ff_fft_init_altivec(s); if (HAVE_MMX) ff_fft_init_mmx(s);
if (s->split_radix) {
I'd rather hide this condition inside ff_fft_init_altivec().
changed.
diff --git a/libavcodec/ppc/fft_altivec.c b/libavcodec/ppc/fft_altivec.c index 83b2b7f..235f205 100644 --- a/libavcodec/ppc/fft_altivec.c +++ b/libavcodec/ppc/fft_altivec.c [...] +extern FFTSample ff_cos_16[];
Isn't this declared in some header file? If not, it should be.
+// pointers to functions. but unlike function pointers on some PPC ABIs, these aren't function descriptors.
What does that mean? Not saying it's wrong, I just don't understand it.
<malc> ff_fft_dispatch_altivec[s->nbits-2] forces gcc to assume it's TOC and lead to funny results such as the one guys on the ML have mentioned. <malc> the table should be declared as one just containing plain pointers (void * for instance) so that the compiler wont try to be smart about it. <pengvado> function points are different from normal pointers on ppc? <malc> on AIX PPC32 and PPC64 (any ABI) those point to function descriptor. <malc> which is basically a pair of function address and a TOC corresponding to said function. <malc> same is true for IA64 i think.
s->fft_permute = ff_fft_permute_c; s->fft_calc = ff_fft_calc_c; s->imdct_calc = ff_imdct_calc_c; s->imdct_half = ff_imdct_half_c; - s->mdct_calc = ff_mdct_calc_c;
I think that line should stay.
changed.
+static void ff_imdct_half_altivec(MDCTContext *s, FFTSample *output, const FFTSample *input) +{ + int j, k; + int n = 1 << s->nbits; + int n4 = n >> 2; + int n8 = n >> 3; + int n32 = n >> 5; + const uint16_t *revtabj = s->fft.revtab; + const uint16_t *revtabk = s->fft.revtab+n4; + const vec_f *tcos = (const vec_f*)(s->tcos+n8); + const vec_f *tsin = (const vec_f*)(s->tsin+n8); + const vec_f *pin = (const vec_f*)(input+n4); + vec_f *pout = (vec_f*)(output+n4);
Why the intrinsics here?
Because gcc doesn't screw it up. I tried an asm version, but it's 100 lines longer and not at all faster. --Loren Merritt
Hello, On Mon, Oct 12, 2009 at 2:47 PM, Loren Merritt <lorenm at u.washington.edu>wrote:
On Tue, 29 Sep 2009, Loren Merritt wrote:
changed.
ping
I'm fine with it. Too bad it won't speed-up the FFT on OSX, but at the very least it doesn't break compilation on that OS. People who want split-radix FFT on OSX can either use Conrad's script or use FSF's SDK. Guillaume -- "I am the Jesus Christ of politics. I sacrifice myself for everyone." -- Silvio Berlusconi
Guillaume POIRIER <poirierg at gmail.com> writes:
Hello,
On Mon, Oct 12, 2009 at 2:47 PM, Loren Merritt <lorenm at u.washington.edu>wrote:
On Tue, 29 Sep 2009, Loren Merritt wrote:
changed.
ping
I'm fine with it. Too bad it won't speed-up the FFT on OSX, but at the very least it doesn't break compilation on that OS.
People who want split-radix FFT on OSX can either use Conrad's script or use FSF's SDK.
Will this FFT be enabled automatically if David's script is used? -- M?ns Rullg?rd mans at mansr.com
Hello, 2009/10/12 M?ns Rullg?rd <mans at mansr.com>
Guillaume POIRIER <poirierg at gmail.com> writes:
Hello,
On Mon, Oct 12, 2009 at 2:47 PM, Loren Merritt <lorenm at u.washington.edu wrote:
On Tue, 29 Sep 2009, Loren Merritt wrote:
changed.
ping
I'm fine with it. Too bad it won't speed-up the FFT on OSX, but at the very least it doesn't break compilation on that OS.
People who want split-radix FFT on OSX can either use Conrad's script or use FSF's SDK.
Will this FFT be enabled automatically if David's script is used?
Nope. Actually, I never managed to make that script work for me, even though I passed the configure options that David advised me to pass: ./configure --cpu=g5 --enable-gpl --cc="gcc-4.2" --as="/Users/gpoirier/Prgm/ffmpeg-git/gas-preprocessor.pl gcc-4.2" compilation ends as follows: gcc-4.2 -DHAVE_AV_CONFIG_H -I. -I"/Users/gpoirier/Prgm/ffmpeg-git" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -mcpu=970 -mpowerpc-gfxopt -mpowerpc64 -std=c99 -mdynamic-no-pic -fomit-frame-pointer -maltivec -mabi=altivec -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wundef -O3 -fno-math-errno -fno-tree-vectorize -MMD -MF libavcodec/ppc/fft_altivec.d -MT libavcodec/ppc/fft_altivec.o -c -o libavcodec/ppc/fft_altivec.o libavcodec/ppc/fft_altivec.c /var/folders/OK/OK9VWpWfFU0cYq0AxFLacE+++TI/-Tmp-//ccYt2viD.s:576:Parameter syntax error (parameter 1) /var/folders/OK/OK9VWpWfFU0cYq0AxFLacE+++TI/-Tmp-//ccYt2viD.s:577:Parameter syntax error (parameter 1) /var/folders/OK/OK9VWpWfFU0cYq0AxFLacE+++TI/-Tmp-//ccYt2viD.s:579:Parameter syntax error (parameter 1) /var/folders/OK/OK9VWpWfFU0cYq0AxFLacE+++TI/-Tmp-//ccYt2viD.s:1077:Parameter syntax error (parameter 1) /var/folders/OK/OK9VWpWfFU0cYq0AxFLacE+++TI/-Tmp-//ccYt2viD.s:1078:Parameter syntax error (parameter 1) /var/folders/OK/OK9VWpWfFU0cYq0AxFLacE+++TI/-Tmp-//ccYt2viD.s:1080:Parameter syntax error (parameter 1) Maybe I don't have the latest version of his script? Guillaume
On Mon, 12 Oct 2009, M?ns Rullg?rd wrote:
Guillaume POIRIER <poirierg at gmail.com> writes:
I'm fine with it. Too bad it won't speed-up the FFT on OSX, but at the very least it doesn't break compilation on that OS.
People who want split-radix FFT on OSX can either use Conrad's script or use FSF's SDK.
Will this FFT be enabled automatically if David's script is used?
configure just checks whether it can assemble ibm syntax. If you replace `as`, that should be enough. --Loren Merritt
On Oct 19, 2009, at 4:51 PM, Loren Merritt wrote:
On Mon, 12 Oct 2009, M?ns Rullg?rd wrote:
Guillaume POIRIER <poirierg at gmail.com> writes:
I'm fine with it. Too bad it won't speed-up the FFT on OSX, but at the very least it doesn't break compilation on that OS.
People who want split-radix FFT on OSX can either use Conrad's script or use FSF's SDK.
Will this FFT be enabled automatically if David's script is used?
configure just checks whether it can assemble ibm syntax. If you replace `as`, that should be enough.
Not quite; check_asm uses inline asm, and my script doesn't transform register numbers to names (since that would be a lot of work vs. ~40 additional lines in ffmpeg.) Anyway, I added support for inline asm to my script, but there still needs to be a check for fsf vs. apple gas in addition to ibm syntax vs. named regs. The attached patch on top of your patches compiles for me; I'm currently running make test. ibm_gas should probably be ibm_syntax I guess, and I copied the X() macros from arm/asm.S, I don't know a good place for them to not duplicate them.
On Tue, 20 Oct 2009, David Conrad wrote:
ibm_gas should probably be ibm_syntax I guess, and I copied the X() macros from arm/asm.S, I don't know a good place for them to not duplicate them.
arm/*.S uses X() only for referring to external symbols from asm. Symbols defined in the asm are mangled by "function", which is more like yasm's "cglobal". ff_fft_dispatch_altivec isn't a function, but cglobal works either way. --Loren Merritt
Loren Merritt <lorenm at u.washington.edu> writes:
On Tue, 20 Oct 2009, David Conrad wrote:
ibm_gas should probably be ibm_syntax I guess, and I copied the X() macros from arm/asm.S, I don't know a good place for them to not duplicate them.
arm/*.S uses X() only for referring to external symbols from asm. Symbols defined in the asm are mangled by "function", which is more like yasm's "cglobal". ff_fft_dispatch_altivec isn't a function, but cglobal works either way.
For functions defined in arm/*.S, both mangled and non-mangled names are defined. Only the mangled one is exported though. I suppose something similar could be done for PPC should that simplify anything. -- M?ns Rullg?rd mans at mansr.com
participants (10)
-
diego＠biurrun.de -
gpoirier＠mplayerhq.hu -
kostya.shishkov＠gmail.com -
lessen42＠gmail.com -
lorenm＠u.washington.edu -
mans＠mansr.com -
michaelni＠gmx.at -
poirierg＠gmail.com -
Reimar.Doeffinger＠gmx.de -
rsbultje＠gmail.com