Questioning the depth_clamp_test in d3d8:visual
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 24.01.2011 um 13:02 schrieb <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)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.
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNPW01AAoJEN0/YqbEcdMw7+0QAIASHnfadfVtST4r5ZKUR54p 2eZjo6zwkF6v/uY0V6PTpiIKFmnXwLus37de7/A0r8x7f/C9cjpo0YpcGKBX5pAo Qht6AtNuQup6U9EAZ+cVksqyRwfYLL4GC43v18nf1wugdxnGeg7tMM6Btz0wE3id WmVL82k2Y0unqPttFIGrE5MVK6vjmm/Xy5W00U1jP7rbSaKn6maycAIeAl3nh6oa sBQD6qoU6wy63vQImhy37mc4LNETmxMOYDMabfgcypZXiPx7V9/xst8NyJU9cmJg 03+K5/PkyxknM7wZWHiJe0cmEOf1iNlk7qrDDMUGukvsQKwqEr1AeaMQnqALMnuV b+aK7k13dMI+aJ3EDWlyQq7DGaASSHVW6N7A8ZaApaX/ldBvBBRzg/3Ueb0tWv/j /Iik1CIVQ2YbDw6Zx9YxxBYVr7kTNS6CDvQ96+o448QPekdFVNZpFHuly7R1inZF anOw7zQJuzCuOyo5dksmyq3oe4raFL3hkrR0APHh33eFaGIKeoaxIBmhPsYHF7da LzlChwGAJpbwNm1A7zebGd33lmc5ll6ewYB3rT4XElb4Gsxs3yAcaWklSN85NidK ngLx7x448u1HsH+3ueqz4gDvjMv+J+IE067bS/K7UsZGqz9OM8OPlQQ9/S3TnAcO 95agLGJfYmme9XO3jFNN =7yAs -----END PGP SIGNATURE-----
participants (3)
-
Henri Verbeet -
Joerg-Cyril.Hoehle@t-systems.com -
Stefan Dösinger