Re: d3dx9: Fix D3DXPlaneNormalize on 64 bits.
On 8 October 2010 16:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
This patch changes D3DXPlaneNormalize to behave as native on 64 bits, returning infinity in the fourth plane component when the norm is 0. If this is not appropriate, I can resend without the implementation changes, just fixing the tests.
I can't say this is necessarily wrong, but I do think it looks suspicious.
2010/10/11 Henri Verbeet <hverbeet(a)gmail.com>:
On 8 October 2010 16:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
This patch changes D3DXPlaneNormalize to behave as native on 64 bits, returning infinity in the fourth plane component when the norm is 0. If this is not appropriate, I can resend without the implementation changes, just fixing the tests.
I can't say this is necessarily wrong, but I do think it looks suspicious.
It looked strange to me too. But that is what I get here with native dlls and what 64 bit testbot machines return, so I assumed it to be some sort of "bug" of native 64 bit d3dx9_36.dll. Then I checked today's winetest results and it seems like native actually doesn't always have this broken behavior: http://test.winehq.org/data/0cc9c52f8c5ad5e1f821177f165fbb72be90d2d9/index_X... shows that Wylda's 64 bits machines don't fail the math test (while still failing the shader test fixed by my other patch). A peek into the version informations of these tests shows that d3dx9_36.dll version matches the one used in testbot virtual machines (as expected) but there is no d3dcompiler_43.dll, so probably Wylda has an older version of the DX SDK installed. That said, I don't know why this could happen. Given that the current output of our D3DXPlaneNormalize is arguably the best one, I'd just send a patch to accept both results in the tests without changing the implementation. Unless you have some idea, of course...
On Mon, Oct 11, 2010 at 03:53:21PM +0200, Matteo Bruni wrote:
2010/10/11 Henri Verbeet <hverbeet(a)gmail.com>:
On 8 October 2010 16:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote:
This patch changes D3DXPlaneNormalize to behave as native on 64 bits, returning infinity in the fourth plane component when the norm is 0. If this is not appropriate, I can resend without the implementation changes, just fixing the tests.
I can't say this is necessarily wrong, but I do think it looks suspicious.
It looked strange to me too. But that is what I get here with native dlls and what 64 bit testbot machines return, so I assumed it to be some sort of "bug" of native 64 bit d3dx9_36.dll. Then I checked today's winetest results and it seems like native actually doesn't always have this broken behavior: http://test.winehq.org/data/0cc9c52f8c5ad5e1f821177f165fbb72be90d2d9/index_X... shows that Wylda's 64 bits machines don't fail the math test (while still failing the shader test fixed by my other patch). A peek into the version informations of these tests shows that d3dx9_36.dll version matches the one used in testbot virtual machines (as expected) but there is no d3dcompiler_43.dll, so probably Wylda has an older version of the DX SDK installed. That said, I don't know why this could happen. Given that the current output of our D3DXPlaneNormalize is arguably the best one, I'd just send a patch to accept both results in the tests without changing the implementation. Unless you have some idea, of course...
If you are passing floats or doubles as functions arguments, this might happen if the compiler is not yet fixed (there were some issues I vaguely remember). Ciao, Marcus
participants (3)
-
Henri Verbeet -
Marcus Meissner -
Matteo Bruni