Tom Spear <speeddymon <at> gmail.com> writes: > > Aric Cyr wrote: > >>>I took a look at the D3D_OK hack, and I believe the problem to be > >>>CheckDeviceFormat in wined3d/directx.c. This function should return an > >>>error if > >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. > >>>Currently > >>>it just returns OK for most formats though. This code is really just a > >>>stub as > >>>it stands, and needs to be converted to check if there are any visuals that > >>>meet > >>>the requested format's requirements, and if there is, return D3D_OK, > >>>otherwise > >>>D3D_NOTAVAILBLE. > >>> > >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case > >>>(you'll need to add it) in wined3d/directx.c in > >>>IWineD3DImpl_CheckDeviceFormat() > >>>and see if that fixes that issue or not. This would be just another hack > >>>though, so a real patch would still be necessary as I decribed above. > > Well I took a stab at adding the case for D3DFMT_D32, to the bottom of > the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed > to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes > the first one and then goes to do the second one, but crashes in a > different spot, so it seems we also have some stack corrupion (as was > mentioned in the bug).. So that hack works for now, I would suggest > that since the rest of that code is stubbed out, we should probably go > ahead and submit a patch so we can at least run the darn thing and then > start debugging the stack corruption issue.
Thanks for testing this out. You have proved my theory correct, so I'll see about making a patch which will correct CheckDeviceFormat(). Basically that whole function needs a re-write, so I'd rather do it that way than to put this hack in there. Especially since, I assume, this problem is not present on nVidia systems, only ATI. > I should add that on the first run, I disabled the title screens between > benchmarks, and changed the "Display and CPU Settings" so that I was > using 32-bit textures and triple buffering, and it ran thru several of > the tests, while on the 2nd and 3rd runs, I left all settings at > defaults; during run 2, it died just after the title screen for mark #2, > and during run 3, it died in the middle of mark #2... If I'm not mistaken, doesn't 3DMark change resolutions between benchmark and title screens? If so, it is possible, and quite likely that there is a resolution change bug in wine. If I recall, I had similar crashing problems with World of Warcraft if I tried to change resolutions from in-game. Regards, Aric