Hi,
Trying to understand bugs #10636 and #19773 , I glanced at the d3d8 visual.ok directx test results. It appears that the green colour on test.winehq does not mean much.
- All (any exception?) WTB machines skip the tests because d3d8 is not installed. - Same for Francois Gouget's virtual machines. That alone explains green colour.
- Wylda's *real* machine #1 (NVidia gfx) produces 5 errors: visual.c:1411: Test failed: color 0x00ffffff. visual.c:1413: Test failed: color 0x00ffffff. visual.c:1415: Test failed: color 0x00ffffff. - "geniuh"'s (NVidia) machine as well. - Saulius' (NVidia) XP and w7 machines shows only these 3 errors.
- Wylda's Intel-based machine #2 passes the tests. Hurray! - One unknown win7 machine with Intel gfx also passes them. - Aurimas' machine produces one different error (also Intel gfx).
BTW, Wylda recently mentioned that the d3d tests produce vastly different graphics on his 2 machines.
My conclusion: the tests only prove that Wine wants to mimic Intel graphics, but they do not account for the variety of observed test results. Danger: one may draw false conclusions from the ok() and wrongly generalize supposed behaviour of the tested functions.
Looking at Wine test data (from 1.3.12), it appears that Wine implements exactly the opposite behaviour: the NVidia (+ 1 ATI) machines pass the tests, e.g. behave like Intel on native, while the Intel gfx one (eeepc) produces the 3 errors known from native NVidia!
This smells wrong...
Regards, Jörg Höhle
On 24 January 2011 13:02, Joerg-Cyril.Hoehle@t-systems.com wrote:
My conclusion: the tests only prove that Wine wants to mimic Intel graphics, but they do not account for the variety of observed test results.
The issue is more subtle than that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 24.01.2011 um 13:02 schrieb Joerg-Cyril.Hoehle@t-systems.com Joerg-Cyril.Hoehle@t-systems.com:
- Wylda's Intel-based machine #2 passes the tests. Hurray!
- One unknown win7 machine with Intel gfx also passes them.
- Aurimas' machine produces one different error (also Intel gfx).
Afaik the test passes on Windows everything but Nvidia(well, it passes on Intel according to your observations, and I know it passes on my ATI box). I tried to understand the Nvidia failure, as far as I know the depth clamp state just doesn't do anything on this card. A game that depends on the behavior tested by the test is Prince of Persia 3D, a ddraw/d3d7 game. I could not test this game on my Windows 7 machine(s), it failed to install.
Any decent explanation why the test fails on Nvidia on Windows, or clear proof that the driver is broken(e.g. POP3D doesn't render properly) would be very welcome.
Looking at Wine test data (from 1.3.12), it appears that Wine implements exactly the opposite behaviour: the NVidia (+ 1 ATI) machines pass the tests, e.g. behave like Intel on native, while the Intel gfx one (eeepc) produces the 3 errors known from native NVidia!
We don't have card-specific behavior in wined3d. wined3d implements the behavior according to what the test says is correct. I suspect the Intel driver used to run the failing Linux test does not implement GL_NV_depth_clamp or GL_ARB_depth_clamp, or implements it incorrectly.
-
Henri Verbeet -
Joerg-Cyril.Hoehle＠t-systems.com -
Stefan Dösinger