[Bug 33111] Graphical Artifacts in Diablo 3 on AMD Graphics

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=33111

--- Comment #18 from Matteo Bruni <matteo.mystral at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.