Floating point precision on different machines

25 views
Skip to first unread message

Alan Wolfe

unread,
Feb 9, 2012, 6:07:52 PM2/9/12
to native-cli...@googlegroups.com
Hey There!
 
Does anyone know if different machines, running the same .nexe files can have significantly different levels of floating point precision?
 
Why I ask is that after launching my raytraced snake game, besides the locking problem (resolved in another thread, thank you guys so much!) another issue I've encountered is that when some people run it, they are randomly getting black pixels.
 
I am able to compile and run my code in a directx wrapper in a similar way that i can compile and run on nacl so i looked into it on the directx side and was able to repro an issue very similar to this by changing my floating point compile settings from "precise" to "fast".
 
As a test, i found where it was failing for ME in floating point fast mode and "corrected it" to work ok in fast mode.
 
I made a test NaCl build with this change, put it up on my site, and had some of the people reporting black pixels try it out and their black pixels were fixed too!
 
So, I'm curious... is this expected behavior?  If so, i think the "propper" fix may be to make the scale of my world larger... the width and height of my screen view of the world is from 0 to 1 on each axis, so you can understand the units im dealing with at resolutions of 500x500 or 1000x1000.
 
Also, if this is expected behavior, this sort of makes me worry about the quality of normalized vectors on some machines.
 
Any community / developer thoughts on this subject?  Am i misdiagnosing the issue?
 
Just trying to better understand the platform specific issues we have to deal with on NaCl.
 
Thanks!

Mark Seaborn

unread,
Feb 9, 2012, 7:28:55 PM2/9/12
to native-cli...@googlegroups.com
On 9 February 2012 15:07, Alan Wolfe <alan....@gmail.com> wrote:
Hey There!
 
Does anyone know if different machines, running the same .nexe files can have significantly different levels of floating point precision?
 
Why I ask is that after launching my raytraced snake game, besides the locking problem (resolved in another thread, thank you guys so much!) another issue I've encountered is that when some people run it, they are randomly getting black pixels.
 
I am able to compile and run my code in a directx wrapper in a similar way that i can compile and run on nacl so i looked into it on the directx side and was able to repro an issue very similar to this by changing my floating point compile settings from "precise" to "fast".

Are you aware of the general issue with extended precision on x86?  Values stored in registers can have greater precision than those stored in memory.  Potentially, your program can behave differently with different compiler settings, depending on whether the compiler spills variables to the stack (e.g. see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255).  So the x86-32 and x86-64 builds could behave differently.  But I'm not sure from your description whether that could be the problem.

Also, there used to be a difference between OSes in whether extended precision was enabled by default at runtime in NaCl (http://code.google.com/p/nativeclient/issues/detail?id=253).  I think this has been fixed (by http://code.google.com/p/nativeclient/issues/detail?id=2358), but in favour of enabling extended precision.  We should probably change it to disable extended precision instead.

Cheers,
Mark

Alan Wolfe

unread,
Feb 9, 2012, 7:50:58 PM2/9/12
to native-cli...@googlegroups.com
Interesting info thanks!  I was aware of it internally having more or less bits but the rest of the info is new to me.
 
If I read you correctly I agree that it would be nicer (from a development POV) to take the FP settings down to the lower common denominator by default.
 
This way, if people out there were going to hit floating point issues, we would also hit them while developing the software in the first place
 
Although if it is a setting i can toggle, i guess i could just toggle it off and develop in that mode, if FP issues mattered enough to my software.
 
Thanks Mark!

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

Reply all
Reply to author
Forward
0 new messages