https://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #18 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Józef Kucia from comment #17)
(In reply to Matteo Bruni from comment #16)
(In reply to Adam Bolte from comment #13)
Created attachment 59907 [details] Mesa 17.4.0-devel (git-4c7af87fb9) screenshot 1
I'm still seeing similar issues in current Mesa builds. Tested on an AMD Fury X.
Interesting. It might not be the exact same issue but it does at least look similar.
The original issue had to do with sampling from a depth texture also bound as depth buffer (obviously with depth writes disabled, so no feedback loop). That's generally supported by OpenGL drivers although the spec is intentionally vague on the matter. Actually I noticed a SIMULTANEOUS_TEXTURE_AND_DEPTH_TEST query exposed by ARB_internalformat_query2 which seems to target exactly this case. Anyway, even if this technically might not be a driver "bug", it's a missing feature.
I think OpenGL allows this behavior with ARB_texture_barrier. AFAIK it can still be a Wine bug if we do not rebind FBO attachment after writing to it (or, alternatively, call glTextureBarrier()).
How so? That was with d3d9, the depth buffer was updated "naturally" by previous draws. It was just that sampling the depth buffer (via the INTZ d3d9 hack format) while still using it for the depth test broke, showing some tile-looking artifacts. Admittedly I don't know if this new Mesa issue is with the d3d9 game backend or otherwise has anything to do with the old fglrx bug.