time.time() strangeness

[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