Bug 3885

[Aric Cyr]

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