Re: [2/5] d3d9: The depth clamp test fails on Nvidia Windows drivers
I tried a lot of things, and I couldn't get these tests working on this box(gf9600,win7 x86). d3drs_clipping doesn't do what the test expects, in either d3d version. If anyone knows what's wrong feel free to bring up a better solution. I also can't get pop3d working on this system to see if the game that needed the original clipping hack. renders properly. If I had to guess the Nv driver probably runs things through some d3d9->d3d10 mapper provided by ms. That could explain why nv d3d10 setups fail but d3d9 ones work. Wrt ddraw/d3d8, I'd prefer to get the d3d9 testsuite working on my box first. Currently I get thousands of test failures, making development of new bugfixes pretty much impossible. I'll take care of ddraw/d3d8 too, but first i want to regain the ability to write new tests. Henri Verbeet <hverbeet(a)gmail.com> schrieb:
I'm not sure blindly marking these as broken is the way to go. Either way, ddraw and d3d8 have the same failure.
On 5 July 2010 17:11, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I tried a lot of things, and I couldn't get these tests working on this box(gf9600,win7 x86). d3drs_clipping doesn't do what the test expects, in either d3d version. If anyone knows what's wrong feel free to bring up a better solution.
There's probably an issue with depth buffer precision and the direction of the depth compare function.
Wrt ddraw/d3d8, I'd prefer to get the d3d9 testsuite working on my box first. Currently I get thousands of test failures, making development of new bugfixes pretty much impossible. Sounds like a problem with your setup. I get about 90 failures in Win 7 with an AMD card, with an nvidia card you should be getting something like 25. What makes fixing tests difficult is that you need to understand the failure before you mark something broken.
Am Montag 05 Juli 2010 17:41:36 schrieb Henri Verbeet:
On 5 July 2010 17:11, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I tried a lot of things, and I couldn't get these tests working on this box(gf9600,win7 x86). d3drs_clipping doesn't do what the test expects, in either d3d version. If anyone knows what's wrong feel free to bring up a better solution.
There's probably an issue with depth buffer precision and the direction of the depth compare function. I tested various depth test parameters, including disabling the Z buffer and changing the depth compare logic. Under no conditions I managed to get any geometry with Z > 1.0 drawn.
Wrt ddraw/d3d8, I'd prefer to get the d3d9 testsuite working on my box first. Currently I get thousands of test failures, making development of new bugfixes pretty much impossible.
Sounds like a problem with your setup. I get about 90 failures in Win 7 with an AMD card, with an nvidia card you should be getting something like 25. What makes fixing tests difficult is that you need to understand the failure before you mark something broken. The Stream source tests break the device, and no draw after them succeeds, causing all other tests to fail. I haven't figured out what exactly is wrong in those tests, so far I disabled them in my tree to attend to other tests. Maybe it is just some invalid state change that sticks, maybe
Among the other failures: * My system refuses ps_3_0 without a vs_3_0 vertex shader and vice versa, breaking many pixel shader tests. Easy to fix by providing a simple vertex shader. Consequently the shader version varying tests are moot. * d3d10 sRGB+Fog. That issue is well known. * Problems with viewport > framebuffer sizes(unlike MinZ/MaxZ it doesn't reject the SetViewport call, but rather the following draw call) * Clears with a NULL rectangle array need a clear count of 0, not 1. Easy to fix. I have all the patches from the Windows tree attached. I think there are no test failures left with them, but patch 8 comments out a number of tests. Patch 12 needs to move the check for vertex shader support. The Stream source tests, among other things, test what happens when a vertex shader reads an attribute that is not listed in the vertex declaration, and what happens when you use nonstandard attribute formats for fixed function attribs(e.g. D3DCOLOR texcoords, FLOAT4 colors). As far as I can see either of the 3 tests is enough to break the device.
participants (2)
-
Henri Verbeet -
Stefan Dösinger