PPC FPU handling [was: Re: NaN patch]
michdaen at iiic.ethz.ch
Tue Nov 20 04:02:18 EST 2001
On Tue, 2001-11-20 at 16:44, Keith Whitwell wrote:
> Keith Whitwell wrote:
> > >
> > > I'd consider adding NaN-checking code to the indirect rendering path,
> > > since it's slow anyway but am hesitant to add it to client-side (and
> > > hardware) code for performance reasons.
> > >
> > Well rather than doing this, can we isolate where the bug is and wrap that
> > section in START_FAST_MATH/END_FAST_MATH. I'm pretty sure this sort of
> > explicit NaN checking isn't in the SI, and if you think about what code is in
> > the indirect path but not the direct path, it doesn't add up to much -
> > certainly not worth this heavyhanded approach. Alternately there might be
> > some code that could be slightly tweaked to avoid the crashes.
> OK. There is no implementation of START_FAST_MATH/END_FAST_MATH for PPC (this
> is a macintosh-specific problem).
No, it's not. :) But it's funny you mention this, the following code in
mmath.h doesn't look right to me:
/* The mac float really is a float, with the same precision as a
* single precision 387 float.
Shouldn't that rather be #if defined(__powerpc__) ?
> One is required for this and every
> architecture which runs Mesa, otherwise there is a need for a check on every
> single float that comes into the api, which is in the squillions. Have a look
> at mmath.h in xc/extras/Mesa/src, and try and do something similar.
> The big requirement is to turn off the ieee inf/nan exceptions (on the x86 we
> also stop the fpu keeping excess precision). Turn the exceptions off in
> START_FAST_MATH (and back to their original state in END_FAST_MATH) and your
> problem should go away. The documentation of these macros only talks about
> precision in 3.4.2, but is accurate in 4.0.
Also, further down:
#if defined(__i386__) || defined(__sparc__) || defined(__s390x__) || \
( defined(__alpha__) && ( defined( __IEEE_FLOAT ) || !defined( VMS )
#define IEEE_ONE 0x3f7f0000
Shouldn't these be defined for __powerpc__ too, or isn't the PPC FPU
IEEE conformant (or what do these defines mean anyway)?
Looking forward to any insights...
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev