[v9 4/6] d3dx9: Add basic opcodes to preshader.

Matteo Bruni matteo.mystral at gmail.com
Thu Apr 7 09:03:25 CDT 2016


2016-04-07 11:06 GMT+02:00 Paul Gofman <gofmanp at gmail.com>:
> On 04/06/2016 04:43 PM, Matteo Bruni wrote:
>> 2016-04-01 13:21 GMT+02:00 Paul Gofman <gofmanp at 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.



More information about the wine-devel mailing list