time.time() strangeness

[Nitro]

Nevertheless time.time() shouldn't fail here unless DirectX is really

badly tinkering with my system.

I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
the DirectX device the bug does not appear. This flag means "Direct3D
defaults to single-precision round-to-nearest" (see [1]) mode.
Unfortunately it is not an option to pass this flag, I need the
performance boost it gives.

Can somebody tell me how this interacts with python's time.time()? I
suppose it's some kind of double vs. float thing or some fpu asm code
issue...

-Matthias

References:
[1] http://msdn2.microsoft.com/en-us/library/bb172527(VS.85).aspx

 

[Ross Ridge]

I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
the DirectX device the bug does not appear. This flag means "Direct3D
defaults to single-precision round-to-nearest" (see [1]) mode.
Unfortunately it is not an option to pass this flag, I need the
performance boost it gives.

Using D3DCREATE_FPU_PRESERVE is extreamly unlikely to affect the
performance of your code. Almost all 3D computation these days is done
either on the video card or using SSE math on the CPU, neither which is
affected by the use of this flag and the state of the FPU's precision
setting. If you're mixing Python and Direct3D I would strongly recommend
using D3DCREATE_FPU_PRESERVE. It will save you a lot of headaches
because time.time() is probably not the only thing that will break.

Can somebody tell me how this interacts with python's time.time()? I
suppose it's some kind of double vs. float thing or some fpu asm code
issue...

If you let Direct3D change the FPU settings, then the calculation made to
compute the floating-point value returned by time.time() gets rounded to
a 32-bit single-precision floating-point value. This means that number
returned by time.time() only has 24 bits of precision, which for current
time values, only gives you an accuracy of a hundred seconds or so.

Ross Ridge

 

[Roel Schroeven]

Nitro schreef:

Nevertheless time.time() shouldn't fail here unless DirectX is really
badly tinkering with my system.

I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
the DirectX device the bug does not appear. This flag means "Direct3D
defaults to single-precision round-to-nearest" (see [1]) mode.
Unfortunately it is not an option to pass this flag, I need the
performance boost it gives.

Can somebody tell me how this interacts with python's time.time()? I
suppose it's some kind of double vs. float thing or some fpu asm code
issue...

I got bitten by this some time ago in a project at work. At first time
values in floats where wrong, but I didn't see why. Then I started
seeing very strange results in other calculations, and it took me some
time to find out it was because of DirectX.

If you don't pass D3DCREATE_FPU_PRESERVE, DirectX puts the FPU in
low-precision mode behind your back, which effects all floating point
operations in your process, such as the calculation of time.time(). All
in the name of performance, but in my opinion that should certainly not
be the default.


Cheers,
Roel