On Mon, Feb 7, 2011 at 2:14 PM, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am Montag 07 Februar 2011, 19:37:09 schrieb Misha Koshelev:
Stefan: I believe this is actually a _difference_ between Windows versions.
As you will note on the full results from winetestbot as well as my own testing on XP (what I _thought_ was SP3) is that only 3/9 platforms have this error. The rest pass fine. Thus, it seems a variance in the tests.
The results still don't make sense.
Basically it seems to me that native d3dx9 lacks support for NaN and INF. Those magic numbers are created by making the highest possible exponent a special marker(thus reduce exp_max by 1 and make exp_max + 1 special). This is why halfs end up with 65536.0 as just not reachable number. The highest exponent is 15, the highest mantissa value is 1023. This gives value = 2^15 * (1 + 1023/1024) = 65504.
However, it looks like Windows(all versions) treat e = 16 like regular numbers, allowing max numbers from -131008.0 to +131008.0. This is shown by the conversion of 0x7fff to 131008.0 and 0xffff to -131008.0, and the conversion of -INF to 0xffff (sign bit, exp=max+1=16, mantissa=max=1023). I suspect someone tested INF and saw that it was converted into something that looked like NaN and added a line like this:
if(isinf(input)) return 0x7c00; or if(input > 65504) return 0x7c00;
but didn't properly implement NaN and INF. Then someone realized such a check is just stupid given the lack of infrastructure and removed it. And since the code is maybe written in assembler the check got only removed from the 32 bit version, not the 64 bit one. (Notice how old windows versions and 64 bit ones return 0x7c00 and new 32 bit ones return 0x7fff).
I'd suggest a few more tests: See what a number like 80000.0 is converted to. Look what happens to 65503, 65504, 65505, 65534, 65535, 65536. And see what values like 0x7c01,7c02, 7ffe, 7ffd are converted to.
Thanks Stefan.
I believe I've found that the threshold value is actually 65520.0 for conversions from single to half precision (tests are still running but I checked on my machine at least so the half_ver1 values are correct; additionally, I tested half_ver2 without the negative numbers previously on winetestbot http://testbot.winehq.org/JobDetails.pl?Key=8995). The full test results with the attached patch will be here: https://testbot.winehq.org/JobDetails.pl?Key=9000
In any case, I have gotten the half to single precision conversion to work in Wine by extending to 16 bits for the exponent (changing < 31 to < 32).
However, I am still having trouble with the single to half precision and believe I am spinning my wheels a bit at this point.
Here are the errors I'm getting:
math.c:2249: Test failed: Got 7800, expected 7bff or 7bff for index 3. math.c:2249: Test failed: Got ffff, expected fc00 or fce2 for index 8. math.c:2249: Test failed: Got f800, expected fbff or fbff for index 11. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 12. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 13. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 14. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 15. math.c:2249: Test failed: Got 6400, expected 7fff or 7fff for index 18. math.c:2249: Test failed: Got 6400, expected ffff or ffff for index 19.
Any ideas?
Thanks Misha