Re: d3dx9: Implement D3DXFloat32To16Array and D3DXFloat16To32Array. (try 2)
Hi Misha,
...
I'm attaching your patch with some modifications (mostly I took some missing pieces from my old, way broken, patch). It seems to help a bit but it's not perfect yet. It fixes handling of > 65520.0 values and denormalized numbers. The interesting bit was to have some ad-hoc rounding for the denormalized case. The current implementation doesn't match native on some rounding cases, but it's not clear what really the issue is. If you replace >= with a > in "if (tmp - mantissa >= 0.5f) mantissa++;" you essentially switch some failing cases with others. Maybe it has something to do with floating point CPU rounding mode, but that seems unlikely to me. Some testing under Windows is also needed.
Ok, that's all. Please continue your work, correct 32/16 bit float conversion functions are really a good thing to have (and you can fix the implementation in wined3d after this is done ;))
Hi Guys, Just thought I'd forward to the list (I hope it's ok Matteo). I'm pretty stumped. Matteo's patches were a big help. I did test on Windows and saw same result. My own (very unhelpful) diagnosis of the pattern is that, for the mantissa values: 2018.5 should round to 2018 2019.5 should round to 2020 2016.5 should round to 2016 2017.5 should round to 2018 2014.5 should round to 2014 2015.5 should round to 2016 2012.5 should round to 2012 2013.5 should round to 2014 1954.5 should round to 1954 1955.5 should round to 1956 1952.5 should round to 1952 1953.5 should round to 1954 1950.5 should round to 1950 1951.5 should round to 1952 1948.5 should round to 1948 1949.5 should round to 1950 I have attached a patch that makes this explicit and has just one failing test. Unfortunately, if we change the increment from 0xfff to 0xff, we seem to have a lot more disagreements. If anyone has any ideas pls let me know. I am stumped. I am going to see if perhaps I can make the relevant game work better by stubbing, and, if so, will submit a stub patch for now. Thank you Misha p.s. Note: the singles2halfp function is not mine, and is licensed under the BSD license. I modified it slightly to see if it would make things better. It didn't. It is not meant to actually be included in Wine but is useful for testing. http://www.mathworks.com/matlabcentral/fileexchange/23173 Thank you
Hi Misha,
My own (very unhelpful) diagnosis of the pattern is that, for the mantissa values:
2018.5 should round to 2018 2019.5 should round to 2020
The pattern appears to be "round half to even", which you may read about on Wikipedia: http://en.wikipedia.org/wiki/Rounding#Round_half_to_even --Juan
On Sat, Feb 26, 2011 at 4:48 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
Hi Misha,
My own (very unhelpful) diagnosis of the pattern is that, for the mantissa values:
2018.5 should round to 2018 2019.5 should round to 2020
The pattern appears to be "round half to even", which you may read about on Wikipedia: http://en.wikipedia.org/wiki/Rounding#Round_half_to_even --Juan
Thanks Juan. I have implemented this in the patch. I am, unfortunately, still pretty stumped. There are quite a few cases per Matteo's wonderful rounding code for truncation of very small (?) numbers where rounding should _not_ occur. I have included relevant output from running make math.ok for those cases. Note, that it is not the specific mantissa #'s per se (I checked), not even combinations of mantissa #'s and exp's, and not mantissa #'s and exp's and <= 0.25f difference between ((unsigned int) tmp) and (((unsigned int) tmp) & 0x3ff) - I checked all these. There is apparently some pattern in the original single #'s themselves that I am not seeing. If anyone has a keener eye than I let me know. Also, I am assuming a stub of this function would actually not be accepted into Wine (can't return E_NOTIMPL, e.g.). If I am _incorrect_ about this please let me know. Thank you. Have a great Saturday! Misha
participants (2)
-
Juan Lang -
Misha Koshelev