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.
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...
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
Hi,
On Thursday 22 December 2005 03:29, Aric Cyr wrote:
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.
No, as x11 only handle 24 bpp buffers (instead of 32), GLX always reports 24 bpp on such cards (for depth buffers) and many games want 16 or 32 Depth Buffers (only few support 24 bits)
for exemple in mine card, i have a lot of config as: id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None ... 0x67 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon ...
always 24-bpp for Depth Buffer for 32-bpp Pixel Buffer (stupid limitation ?)
I hate X11 limitations :( Maybe one day we will have a native alpha support and 32-bpp for buffers on X
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.
Wine cannot change resolution "in-game". as created window and associated context are managed by x11drv init we cannot handle this case (and never manage case you want to change bpp because of x11 limitations). Anyway i plan (when i'll have time, and when ddraw will use wined3d) to rethink x11drv glx init to only init glx window context on need (so in future only for opengl32 and wined3d) using wanted rendering options.
Regards, Aric
Regards, Raphael
--- Aric Cyr Aric.Cyr@gmail.com wrote:
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'm part of the way through re-writing this function to use an inclusive list per usage instead of an exclusive list for all usages and should hopefully have the re-write finished by the end of the week along with CheckDeviceType and friends.
Oliver.
Regards, Aric
___________________________________________________________ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com
-
Aric Cyr -
Oliver Stieber -
Raphael -
Tom Spear