Re: [Algorithms] FIST optimization

[Pierre T. <p.t...@wa...>]

Well,

I've just experienced the very same bug, just today, with some skeletal
animation code:

- it works in Debug build
- it works in Release build without /Qifist
- it fails in Release build with /Qifist

After some time, I managed to find the wacked line. Just that:

 curidx  = udword(mPlayTime);

...where mPlayTime is obviously a float.

This modification fixed it:

  curidx  = (udword)floorf(mPlayTime);

...which means one way or another the FPU rounding mode actually had been
modified before, somewhere. This is quite "fun" to face that bug just when
the topic comes to the list. But this is frightening to realize it
*actually* happens. And since I'm *always* compiling with /Qifist, I wonder
how many of them silently lie all over the place, ready to bomb.

Then I thought about the recent mails here. I then changed the way I
initialize Direct3D, and used DDSCL_FPUPRESERVE instead of DDSCL_FPUSETUP.
Nothing changed.


...but the guilty one is D3D anyway...

When I reset the FPU to the "chop" rounding mode before calling
Renderer->Init(), it still does not work.

When I reset the FPU to the "chop" rounding mode after Renderer->Init(), it
*does* work.

Hence:
1) Initializing D3D changes the rounding mode.
2) ...even if you use DDSCL_FPUPRESERVE..... !
3) So the probable best way so far is to use DDSCL_FPUPRESERVE anyway, *and*
reset the FPU after D3D has been initialized.

Maybe I'm missing something with D3D (perhaps another magic flag in another
place), but for the moment and for my particular bug, I clearly found the
guilty one.

Hope it helps.

Pierre



----- Original Message -----
From: John Ratcliff <jra...@ve...>
To: <gda...@li...>
Sent: Saturday, September 09, 2000 7:27 PM
Subject: [Algorithms] FIST optimization


> As many of you already know, the call to 'ftol' can be one of the biggest
> hotspot spikes in a 3d application.  Every time a floating point number is
> converted into an integer, rather than simply producing a 'fist'
> instruction, MSVC will instead invoke a very slow procedure call to
'ftol'.
> I have heard this is to ensure that the rounding behaviour of the
operation
> conforms to ANSI standard or something like that.
>
> Back when I was an assembly programmer I just used the fist instruction
> wherever needed.  With MSVC there is a compiler optimization switch called
> /Qifist, which allows MSVC to use the 'fist' instruction instead of the
call
> to 'ftol'.
>
> When I enable this optimization my performance profile is greatly
improved.
> At the heart of my collision detection routines is a hash, where I take
the
> floating point x,y co-ordinate in world space and remap it into an index
to
> this precomputed collision detection table.  This is a critical operation
> that requires the conversion from floating point to int, very efficiently.
>
> However, the behavior I am experiencing is as if the rounding mode were
> occasionally set to something other than truncate behavior.  Meaning,
where
> I expect a conversion from 2.99999 to int to produce a 2, not a 3.  The
> behaviour is spurious and unpredictable.  When I worked in assembly code I
> never had this problem.
>
> My main question is, how can the rounding mode ever get changed?  Or am I
> missunderstanding the behavior possibly?
>
> The symptom is as follows.  Without the /Qifist option enabled my
collision
> detection works flawlessly.  With the /Qifist enabled it behaves
spuriously,
> exactly as if sometimes it rounds the float to hash index incorrectly,
thus
> accessing the wrong pre-computed collision detection polygon set.
>
> Why can't you guarentee that the rounding mode is set to truncate
throughout
> the application?  I could switch to inline assembly I suppose, but I
prefer
> to have the compiler generate the code naturally with all of it's normal
> optimizations enabled.  Does anyone know the preferred method to guarentee
> the processor is in a rounding mode which causes truncation to always
occur?
> Or am I missinterpreting the problem entirely?
>
> Thanks,
>
> John
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list