2016-04-07 11:06 GMT+02:00 Paul Gofman gofmanp@gmail.com:
On 04/06/2016 04:43 PM, Matteo Bruni wrote:
2016-04-01 13:21 GMT+02:00 Paul Gofman gofmanp@gmail.com:
Also I get this on 32 bit:
effect.c:3838: Test succeeded inside todo block: Operation rsq, component 2, expected 0x3f2c985c, got 0x3f2c985c (0.6742). effect.c:3838: Test succeeded inside todo block: Operation rsq, component 3, expected 0x1f800001, got 0x1f800001 (5.42101e-20).
That's interesting. I am getting 0x3f2c985d and 0x1f800000 (the difference in the last bit of mantissa) on d3dx9_36 dll compiled with various gcc optimization flags set, which effectively result in rsqrt being computed using SSE opcode without glibc function call. Now when I disabled all optimizations and any SSE arch targeting I get the same result as you. The generated code has FP math been done through nasty vintage x87 opcodes in this case, and sqrt glibc function is called in pres_rsq().
Regarding the test, I could leave it as it, or remove todo, letting the test to succed todo depending on compiler flags. Or compute a benchmark rsqrt to guess which case we are having and use this for todo_wine_if. I am not sure which way is preferred for the unit tests in such a case?
The tests need to pass on Wine with default compiler settings. Comparing the obtained with the expected result allowing one (or more if necessary) ULP of tolerance is probably the nicest fix, at least WRT rsq. You could even specify the tolerance per-entry in the tests table if you want to stay bit-accurate when testing the other opcodes. I guess you could otherwise call sqrt() on some particular number and toggle todo_wine accordingly but that seems unnecessarily convoluted at the first glance.
BTW, it might be interesting to try to add some sort of configure flag to enable SSE* without having to resort to manually set CFLAGS, maybe applying the additional compilation flags only on source files which "opt-in" somehow. Just thinking out loud, not sure how the others feel about it.