http://bugs.winehq.org/show_bug.cgi?id=31046
--- Comment #3 from Kevin Meyer billy65bob@gmail.com 2012-09-08 21:23:27 CDT --- The description is somewhat inaccurate anyhoo, I need to clear up a few things. The second screenshot should read: title screen; 24bit Z-buffer + logz in Windows (DirectX9 Hardware). Wine provided identical results if I hex edit the embedded shaders in the plugin to force on logz.
I had a quick look through the code in both places. pcsx2 requests a D3DFMT_D32 surface (followed by D3DFMT_D32F_LOCKABLE and D3DFMT_D24S8 as fallbacks) wine provides one, which is mapped to a GL_DEPTH_COMPONENT32 surface. This is where the 32bit value comes from.
In Windows, the 24bit value comes from the fact that both D3DFMT_D32 and D3DFMT_D32F_LOCKABLE allocations fail, causing pcsx2 to fall back to the D3DFMT_D24S8 format. - but this is of no matter since a DirectX11 backend is provided (it uses a 32bit depth + 8bit stencil format there), but alas it doesn't work in wine... yet.
So to conclude, it would seem that wine is doing the right thing, but something is terribly wrong in the way it works. I've been talking to the pcsx2 devs a bit, and they seem to believe that a D3DFMT_D32 surface should provide ideal results (ie, as seen in the Windows screenshot) as opposed to what is seen in wine.
Since Identical results are possible in wine with D32 and Windows with D24S8. I currently have two theories - both of which are pure conjecture. 1) perhaps NVIDIA cannot allocate a GL_DEPTH_COMPONENT32 surface and silently falls back to GL_DEPTH_COMPONENT24. 2) genuine bugs and oversights in wined3d.
Also as a note, since the removal of the "Big X Lock," the GSdx plugin has been locking up almost every boot, and forgoing that, after a few seconds of rendering which makes it almost impossible to get anywhere there's actual 3D stuff. I think someone else already reported that though. But until that is fixed, I'll be unable to test any hacks or patches that make their way here to address this bug.