21 Jan
2005
21 Jan
'05
9:14 p.m.
Hi all,
The denormal problem with freeverb/ardour on P-4's is killing me.
Since CMT plugin development seems to be a little stagnant, I decided
to take it into my own hands a bit, but I might need a little help from
a kind someone out there. Is there anyone who can give me a tip on
proper syntax for changing the denormals.h file in freeverb (assuming
this is where the problem lies)?
Details:
On this list and/or posts elsewhere I found that the denormals.h file
for freeverb doesn't work too well with some newer gcc compilers; one
recommendation was to exchange the first statement below with the second
definition:
#define undenormalise(sample) if(((*(unsigned
int*)&sample)&0x7f800000)==0) sample=0.0f
static inline float
undenormalise(volatile float s)
{
s += 9.8607615E-32f;
return s - 9.8607615E-32f;
}
I tried changing it out one-for-one, but.. no good. Ardour still
zombifies after reverb tails die out. Maybe there is somewhere else
that needs changing wrt denormals, or maybe I am just clueless :).
Anyway, I then tried using something like the following....but still no
good, [ardour now doesn't zombify, it's just that freeverb sounds like
@$!&].
#define static inline float undenormalise(volatile float s) { s +=
9.8607615E-32f; return s - 9.8607615E-32f; }
You can probably see that I have no idea what I'm doing, but this seems
like it should be so _simple_. Maybe now is the time to go read up on C++.
Thanks,
Neil
21 Jan
21 Jan
9:36 p.m.
On Fri, 21 Jan 2005 17:17:43 +0000
Neil Klepeis <nklepeis(a)sbcglobal.net> wrote:
Hi all,
The denormal problem with freeverb/ardour on P-4's is killing me.
Since CMT plugin development seems to be a little stagnant, I decided
to take it into my own hands a bit, but I might need a little help from
a kind someone out there. Is there anyone who can give me a tip on
proper syntax for changing the denormals.h file in freeverb (assuming
this is where the problem lies)?
Details:
On this list and/or posts elsewhere I found that the denormals.h file
for freeverb doesn't work too well with some newer gcc compilers; one
recommendation was to exchange the first statement below with the second
definition:
#define undenormalise(sample) if(((*(unsigned
int*)&sample)&0x7f800000)==0) sample=0.0f
I think your mail client has wrapped something incorrectly there.
Personally , I would avoid doing this useing integer operations and I
would also avoid macros; inline functions are simply so much better.
static inline float
undenormalise(volatile float s)
{
s += 9.8607615E-32f;
return s - 9.8607615E-32f;
}
That looks OK to me, and the optimiser should not discard it because s
is volatile. Have you looked at the assembler output?
#define static inline float undenormalise(volatile
float s) { s +=
9.8607615E-32f; return s - 9.8607615E-32f; }
That is definitle WAAAAAY wrong. what you are doing there is replacing
all instances of the string "static" with "inline float ......".
You can probably see that I have no idea what I'm
doing, but this seems
like it should be so _simple_.
The static inline function you have above should be OK. Look at the
assembler output (use gcc -S to generate assembler) to make sure that
the addition and subtraction isn't being optimised out.
Maybe now is the time to go read up on C++.
There's never a good time to read up on C++
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"To me C++ seems to be a language that has sacrificed orthogonality
and elegance for random expediency." -- Meilir Page-Jones
22 Jan
22 Jan
3:06 a.m.
New subject: [linux-audio-dev] Re: Fixing Freeverb and Denormals
Erik de Castro Lopo wrote:
I used this new function and set all undenormalize calls in the freeverb
source code to the form:
x = undenormalize(x)
The problem is MUCH better, now the DSP% only hits 60% instead of
zooming past 80-90%, and ardour doesn't zombify. Almost useful... But
I do get xruns. There must be some other place where undenormalize
needs to be called, or perhaps the new inline function is still not
working quite right.
static inline
float
undenormalise(volatile float s)
{
s += 9.8607615E-32f;
return s - 9.8607615E-32f;
}
That looks OK to me, and the optimiser should not discard it because s
is volatile. Have you looked at the assembler output? The static inline function you have above should be
OK. Look at the
assembler output (use gcc -S to generate assembler) to make sure that
the addition and subtraction isn't being optimised out.
What exactly am I looking for? After using g++ -S, the allpass.o file,
for example, starts out with:
.file "allpass.cpp"
.text
.align 2
.p2align 2,,3
.globl _ZN7allpassC2Ev
.type _ZN7allpassC2Ev, @function
_ZN7allpassC2Ev:
.LFB11:
pushl %ebp
.LCFI0:
movl %esp, %ebp
[snip]
Thanks for your help!
Neil
3:36 a.m.
New subject: [linux-audio-dev] Re: Fixing Freeverb and Denormals
On Fri, 21 Jan 2005 23:08:50 +0000
Neil Klepeis <nklepeis(a)sbcglobal.net> wrote:
What exactly am I looking for?
I'm not too sure, but I'd know if I saw it :-).
After using g++ -S, the allpass.o file,
for example, starts out with:
Send me the whole allpass.c file by private mail (address below) and
I'll have a look.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"C++ has its place in the history of programming languages. Just as
Caligula has his place in the history of the Roman Empire."
-- Robert Firth
10:22 a.m.
New subject: [linux-audio-dev] Re: Fixing Freeverb and Denormals
Es geschah am Freitag 21 Januar 2005 18:17 als Neil Klepeis schrieb:
Hi all,
The denormal problem with freeverb/ardour on P-4's is killing me.
Since CMT plugin development seems to be a little stagnant, I decided
to take it into my own hands a bit, but I might need a little help from
a kind someone out there. Is there anyone who can give me a tip on
proper syntax for changing the denormals.h file in freeverb (assuming
this is where the problem lies)?
Details:
On this list and/or posts elsewhere I found that the denormals.h file
for freeverb doesn't work too well with some newer gcc compilers; one
recommendation was to exchange the first statement below with the second
definition:
#define undenormalise(sample) if(((*(unsigned
int*)&sample)&0x7f800000)==0) sample=0.0f
static inline float
undenormalise(volatile float s)
{
s += 9.8607615E-32f;
return s - 9.8607615E-32f;
}
I have to admit that I have not yet looked on the freeverb code, but seeing
that, I assume it's a pure C implementation.
I think for such an important piece like freeverb it might be worth to add
architecture dependant assembly optimizations. E.g. with SSE(1) you simply
have to change the SSE control register to get rid of the denormal problem.
With that no denormal fixes for individual sample points are necessary
anymore which definitely pays off in performance.
Es geschah am Samstag 22 Januar 2005 02:36 als Erik de Castro Lopo schrieb:
There's never a good time to read up on C++
Erik
lol
CU
Christian
12:49 p.m.
New subject: [linux-audio-dev] Re: Fixing Freeverb and Denormals
On Sat, Jan 22, 2005 at 03:17:28PM +0100, Christian Schoenebeck wrote:
I think for such an important piece like freeverb it
might be worth to add
architecture dependant assembly optimizations. E.g. with SSE(1) you simply
have to change the SSE control register to get rid of the denormal problem.
With that no denormal fixes for individual sample points are necessary
anymore which definitely pays off in performance.
Agreed, but I'm not sure how doing that will affect the host - ie does
-mfpumath=SSE (or whatever the option is) always leave the FPU stack in a
sane state when control goes back to the host? I dont think it would
normally return the FPU to 387 mode, which might do bad things to the
host occasionally.
OTOH it might be fine, I dont understand the interaction with the 387 and
SSE.
- Steve
2:04 p.m.
New subject: [linux-audio-dev] Re: Fixing Freeverb and Denormals
Es geschah am Samstag 22 Januar 2005 17:49 als Steve Harris schrieb:
On Sat, Jan 22, 2005 at 03:17:28PM +0100, Christian
Schoenebeck wrote:
SSE won't affect the 387 FPU stack at all. But the problem is, this doesn't
account to MMX. And you often will have to stick with MMX, e.g. when you have
to truncate / round SSE floating point values and you dont want to (or can)
use a younger instruction set than SSE1.
If you can use SSE2 (or younger) as well, than you usually you don't have to
use MMX and thus won't have that problem.
CU
Christian
I think for such an important piece like freeverb
it might be worth to
add architecture dependant assembly optimizations. E.g. with SSE(1) you
simply have to change the SSE control register to get rid of the denormal
problem. With that no denormal fixes for individual sample points are
necessary anymore which definitely pays off in performance.
Agreed, but I'm not sure how doing that will affect the host - ie does
-mfpumath=SSE (or whatever the option is) always leave the FPU stack in a
sane state when control goes back to the host? I dont think it would
normally return the FPU to 387 mode, which might do bad things to the
host occasionally.
OTOH it might be fine, I dont understand the interaction with the 387 and
SSE.
5:40 p.m.
New subject: [linux-audio-dev] Re: Fixing Freeverb and Denormals
On Sat, 22 Jan 2005 18:36:46 +1100
Erik de Castro Lopo <erikd-lad(a)mega-nerd.com> wrote:
On Fri, 21 Jan 2005 23:08:50 +0000
Neil Klepeis <nklepeis(a)sbcglobal.net> wrote:
OK, the code of interest is in the process() method of the allpass class.
This method is defined as an inline function in allpass.h. I therefore
wrote a small test file :
#include "allpass.h"
static allpass ap ;
float test (float x)
{ return ap.process (x) ;
}
and compiler that with:
g++ -S -O3 test.cpp -o test.s
In the asembler output file we get this:
.LFE6:
.size _Z41__static_initialization_and_ <snip rest of line>
.section .rodata.cst4,"aM",@progbits,4
.align 4
.LC0:
.long 201326592
.text
.align 2
.p2align 4,,15
The long above (201326592) is the integer representation of the float value.
The asm code for the test function looks like this (comments added):
.globl _Z4testf
.type _Z4testf, @function
_Z4testf:
.LFB7:
pushl %ebp
.LCFI2:
movl %esp, %ebp
.LCFI3:
subl $4, %esp
.LCFI4:
flds .LC0 ; load the float value to the fpu stack
movl ap+12, %edx
movl ap+4, %ecx
flds 8(%ebp)
movl (%ecx,%edx,4), %eax ; load buffer[bufidx] -> %eax
movl %eax, -4(%ebp) ; move %eax -> bufout
flds -4(%ebp) ; load bufout to the fpu
fadd %st(2), %st ; new top of stack = bufout + the_const
fstps -4(%ebp) ; store top of stack -> bufout
flds -4(%ebp) ; load buf out to top of stack
fsubp %st, %st(2) ; new top of stack <- bufout - the_const
and so on. This shows that even with -O3, the denormalisation
code is not being optimised out.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"O'Caml ... a "language designed for smart people" if there ever
was one." -- Mike Vanier
What exactly am I looking for?
I'm not too sure, but I'd know if I saw it :-).
After using g++ -S, the allpass.o file,
for example, starts out with:
Send me the whole allpass.c file by private mail (address below) and
I'll have a look.
7188
days inactive
7189
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Christian Schoenebeck -
Erik de Castro Lopo -
Neil Klepeis -
Steve Harris