http://bugs.winehq.org/show_bug.cgi?id=33111
Bug #: 33111 Summary: Graphical Artifacts in Diablo 3 on AMD Graphics Product: Wine Version: 1.5.25 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: avstaim@gmail.com Classification: Unclassified
There is a number of annoying graphics artifacts in-game, making game uncomfortable. Artifacts only appear in wine, in Windows 7 graphics is ok, running the game in proprietary wine clone Crossover Office has no such artifacts.
My system:
Ubuntu 12.04.2 64 bit AMD Radeon HD 7600M Latest Catalist fglrx 13.1 wine 1.5.23-1.5.25 (same bug present) (haven't tried earlier versions as they are not available to install from PPA)
Tried the following actions (no luck):
1) winetricks ao=enabled 2) running game in windowed fullscreen mode 3) winetricks ddr=gdi 4) Changing fglrx version 5) Adjusting fglrx settings in amdccle
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #1 from Alexey avstaim@gmail.com 2013-03-03 03:03:28 CST --- Created attachment 43781 --> http://bugs.winehq.org/attachment.cgi?id=43781 screenshot 1
rectangle artifacts on yellow and blue passage areas between zones
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #2 from Alexey avstaim@gmail.com 2013-03-03 03:04:26 CST --- Created attachment 43782 --> http://bugs.winehq.org/attachment.cgi?id=43782 Screenshot 2
sorry for russian captions, I don't have english version available
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #3 from Alexey avstaim@gmail.com 2013-03-03 03:05:29 CST --- Created attachment 43783 --> http://bugs.winehq.org/attachment.cgi?id=43783 Screenshot 3
Water areas in Act II are displayed really ugly.
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #4 from Alexey avstaim@gmail.com 2013-03-03 03:06:00 CST --- Created attachment 43784 --> http://bugs.winehq.org/attachment.cgi?id=43784 Screenshot 4
especially sewers
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #5 from Alexey avstaim@gmail.com 2013-03-03 03:08:20 CST --- Created attachment 43785 --> http://bugs.winehq.org/attachment.cgi?id=43785 Log
Full console output of wine session.
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #6 from Henri Verbeet hverbeet@gmail.com 2013-03-04 04:41:02 CST --- It looks a bit like a certain known issue in fglrx with depth tests when the same depth buffer is also bound as texture, but I'm not sure why it would work in CrossOver and not in Wine.
http://bugs.winehq.org/show_bug.cgi?id=33111
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #43785|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #7 from Rico kgbricola@web.de 2013-04-22 03:05:22 CDT --- Well, have a look at the wine version, which crossover uses (wine-1.5.15?) and try plain wine with the same version.
Now you should be able to see, 1. if it is a regression in wine (does the old - same as crossover uses - wine version work?) 2. if it might be a configuration issue in wine (you may run with normal wine in the crossover prefix - save your data first!) 3. if some patches in crossover make it work or there may be a workaround in the fglrx driver which gets triggered by crossover but not by wine ...
http://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #8 from Alexey avstaim@gmail.com 2013-04-24 12:16:36 CDT --- crossover 11.3.1 seems to be based on wine version 1.4.1, but pure wine of this version do not support Diablo 3 at all, Diablo 3 support in wine starting from 1.5.6 ... it seems crossover has it's own patches for D3 ...
http://bugs.winehq.org/show_bug.cgi?id=33111
Mitya Mikhailov mityamikhailov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mityamikhailov@gmail.com
--- Comment #9 from Mitya Mikhailov mityamikhailov@gmail.com 2013-06-21 10:06:43 CDT --- I also have same problems with catalyst 13.1 after upgrading wine from 1.5.5 with patch to 1.5.1х and 1.6 beta
after downgrading wine to prev version diablo works
https://bugs.winehq.org/show_bug.cgi?id=33111
roger@mailinator.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roger@mailinator.com
--- Comment #10 from roger@mailinator.com --- Any update on this?
https://bugs.winehq.org/show_bug.cgi?id=33111
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com, | |dimesio@earthlink.net, | |winetest@luukku.com
--- Comment #11 from winetest@luukku.com --- (In reply to Mitya Mikhailov from comment #9)
I also have same problems with catalyst 13.1 after upgrading wine from 1.5.5 with patch to 1.5.1х and 1.6 beta
after downgrading wine to prev version diablo works
Latest update on this 3 years ago.
I did a short trial with rx480. Less than 10min. I didn't encounter such textures. I would close this bug. Drivers have evolved a lot in that time and who knows how many game updates the game has already received. And also wine has evolved a lot in 3 years. Just reopen bug or open new one if the issue is still valid...
https://bugs.winehq.org/show_bug.cgi?id=33111
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED Component|-unknown |directx-d3d
--- Comment #12 from Matteo Bruni matteo.mystral@gmail.com --- Comment 6 was probably spot-on. IIRC we did make a custom build of CrossOver at the time with a terrible hack from me to workaround the driver limitation.
Anyway, let's resolve this bug.
https://bugs.winehq.org/show_bug.cgi?id=33111
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
--- Comment #13 from Adam Bolte abolte@systemsaviour.com --- Created attachment 59907 --> https://bugs.winehq.org/attachment.cgi?id=59907 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.
Note the graphical artifacts look very similar to what used to exist in fglrx, but nowhere near as bad. Interestingly it's still shown in the same types of areas, usually when there is water or an explosion.
Seems strange the bug would show in two completely different drivers. It would be great to either reopen this, or otherwise link to the upstream Mesa bug this is believed to relate to.
https://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #14 from Adam Bolte abolte@systemsaviour.com --- Created attachment 59908 --> https://bugs.winehq.org/attachment.cgi?id=59908 Mesa 17.4.0-devel (git-4c7af87fb9) screenshot 2
I believe this is the same area of the game as in the original Screenshot 3 attachment. Note the graphical corruption is far smaller (the floor area is fine), but it looks to be of the same type.
https://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #15 from Adam Bolte abolte@systemsaviour.com --- Created attachment 59909 --> https://bugs.winehq.org/attachment.cgi?id=59909 Mesa 17.4.0-devel (git-4c7af87fb9) screenshot 3
One more example for good measure.
https://bugs.winehq.org/show_bug.cgi?id=33111
--- Comment #16 from Matteo Bruni matteo.mystral@gmail.com --- (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.
Adam, I think you should report your issue to the Mesa bug tracker for the time being and see what comes out of it.
https://bugs.winehq.org/show_bug.cgi?id=33111
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia@gmail.com
--- Comment #17 from Józef Kucia joseph.kucia@gmail.com --- (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()).
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.
https://bugs.winehq.org/show_bug.cgi?id=33111
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=33111
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #20 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.