[Bug 35579] New: d3d8:visual test_scalar_instructions() fails on Windows
http://bugs.winehq.org/show_bug.cgi?id=35579 Bug ID: 35579 Summary: d3d8:visual test_scalar_instructions() fails on Windows Product: Wine Version: 1.7.12 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Classification: Unclassified The conformance test errors are: visual.c:1803: Test failed: rcp_test: Got unexpected color 0x00ffffff, expected 0x00808080. visual.c:1803: Test failed: rsq_test: Got unexpected color 0x00ffffff, expected 0x00b4b4b4. visual.c:1803: Test failed: exp_test: Got unexpected color 0x00d6d6d6, expected 0x00404040. visual.c:1803: Test failed: expp_test: Got unexpected color 0x00ffffff, expected 0x00404040. visual.c:1803: Test failed: log_test: Got unexpected color 0x00000000, expected 0x00ffffff. visual.c:1803: Test failed: logp_test: Got unexpected color 0x0000ff00, expected 0x00ffffff. These errors occur on my Acer laptop: Windows 8.1 running on real hardware with an Intel HD4000 graphics card. It turns out they also happen on my fg-win2000-uplast and fg-win7u64-0sp VMware VMs. And interestingly also on the WineTestBot w864 VM which should help with tests. http://test.winehq.org/data/tests/d3d8:visual.html The commit that introduced these tests is: commit 27dc41d0dc31f02476a008cbe1a517bc9a425a30 Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Thu Dec 12 10:23:29 2013 +0100 wined3d: Fix the source swizzle for WINED3DSIH_LOG and WINED3DSIH_LOGP. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35579 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression, source URL| |http://test.winehq.org/data | |/tests/d3d8:visual.html Regression SHA1| |27dc41d0dc31f02476a008cbe1a | |517bc9a425a30 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35579 --- Comment #1 from Henri Verbeet <hverbeet(a)gmail.com> --- At first sight it looks like it's using the .x component instead of .w. I'm afraid that pretty much qualifies as driver bug, or at least unwanted behaviour, since (several) applications depend on using .w here. I can add broken() cases for this if that's really what we want, although at least in the past I think we've always let the tests just fail for driver issues, with the testbot being the one big exception. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35579 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- I have retested this on my laptop with the latest Intel driver which I got from: https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Gr... (the page labels it as 15.33.8.64.3345 presumably it's a bundle with the audio driver) But the test still fail.
I'm afraid that pretty much qualifies as driver bug, or at least unwanted behaviour
So there are two impacted drivers: * The VMware SVGA 3D 7.14.1.5025 (2013/12/7) driver. (as well as the older 7.14.1.1134 (2011/11/11) one). * The Intel HD4000 10.18.10.3345 (2013/10/31) driver. (the corresponding driver download is tagged as 15.33.8.64.3345 presumably it's a bundle with the audio driver) If it's valid but unwanted behavior then it MUST be tagged as broken() rather than left to fail. If it's a driver bug then it should really be reported so it's fixed and we don't have to deal with this failure forever. The report should be made by someone who will be able to answer technical questions, know which applications are impacted, etc. (so definitely not me). That leaves the question of what to do until the drivers are fixed. This impacts more than just the WineTestBot. I'm trying to get my laptop under the new 50 failing tests limit and while one test is not an issue, it would not do to leave the 40 DirectX/OpenGL tests to fail just because a very maintream driver is buggy. Also even one failure means no green for Windows 8 on the test.winehq.org results, which in turns makes it harder to know when there are new failing tests. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35579 --- Comment #3 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to comment #2)
So there are two impacted drivers: * The VMware SVGA 3D 7.14.1.5025 (2013/12/7) driver. (as well as the older 7.14.1.1134 (2011/11/11) one). * The Intel HD4000 10.18.10.3345 (2013/10/31) driver. (the corresponding driver download is tagged as 15.33.8.64.3345 presumably it's a bundle with the audio driver)
If it's valid but unwanted behavior then it MUST be tagged as broken() rather than left to fail.
Well, there isn't any public spec for this, or most parts of the Win32 API really, so in that regard it's always hard to say what's valid and what isn't. What we've always cared about is applications, and failing these tests means breaking them. For example, exp_test is for bug 27850, and IIRC failing the rcp and rsq ones would break Battlefield 1942.
If it's a driver bug then it should really be reported so it's fixed and we don't have to deal with this failure forever. The report should be made by someone who will be able to answer technical questions, know which applications are impacted, etc. (so definitely not me).
I wish anyones who wants to try that good luck, but my experience it pretty much that if you want something fixed you need to do it yourself, with very few exceptions.
That leaves the question of what to do until the drivers are fixed. This impacts more than just the WineTestBot. I'm trying to get my laptop under the new 50 failing tests limit and while one test is not an issue, it would not do to leave the 40 DirectX/OpenGL tests to fail just because a very maintream driver is buggy. Also even one failure means no green for Windows 8 on the test.winehq.org results, which in turns makes it harder to know when there are new failing tests. Every time I write a new test, it seems more and more tempting to either just skip the D3D tests completely on anything that isn't AMD or NVIDIA, or to just stop writing new tests.
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35579 Henri Verbeet <hverbeet(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b22ee99fe948a30dc0c0aad5f3d | |f711cffaa9596 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Henri Verbeet <hverbeet(a)gmail.com> --- Should no longer happen since commit b22ee99fe948a30dc0c0aad5f3df711cffaa9596. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35579 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.13. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org