https://bugs.winehq.org/show_bug.cgi?id=43406
Bug ID: 43406 Summary: NieR:Automata - Bloom to bright Product: Wine Version: 2.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: dark.shadow4@web.de Distribution: ---
Created attachment 58749 --> https://bugs.winehq.org/attachment.cgi?id=58749 How it looks on linux
NieR:Automata is an 64Bit DX11 game on Steam. It has some rendering issues, most areas of the game are to bright, especially the bloom. Screenshots attached.
I made an apitrace, but unfortunately this comes at a whooping 1.4GB (543MB compressed). If you still want it, I uploaded it here: http://www.mediafire.com/file/me8dsk3asiuqoiw/automata.7z I don't know if it's possible to trim apitraces at the start, but if so, please tell me and I'll shrink it down. It's just that I can't skip those parts of the game. Screenshots from frame 2430(windows) and 2432(linux).
Using wine-2.12-staging on Arch Linux for my tests.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Created attachment 58750 --> https://bugs.winehq.org/attachment.cgi?id=58750 How it should look like
https://bugs.winehq.org/show_bug.cgi?id=43406
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #2 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 58754 --> https://bugs.winehq.org/attachment.cgi?id=58754 Wine Bloom effect GTA V
I have a similar if not the same issue in Grand Theft Auto V.
You can compare the attached screen shot with this one from Internet:
http://ic.pics.livejournal.com/far01/27437403/284603/284603_original.jpg
GTA V can do DX10/10.1/11. The attached screen shot was made in DX10 mode.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Created attachment 58757 --> https://bugs.winehq.org/attachment.cgi?id=58757 Scene from the beginning on linux
Adding a more extreme sample.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #4 from Fabian Maurer dark.shadow4@web.de --- Created attachment 58758 --> https://bugs.winehq.org/attachment.cgi?id=58758 Scene from the beginning on windows
https://bugs.winehq.org/show_bug.cgi?id=43406
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #5 from Michael Müller michael@fds-team.de --- I think the apitrace log and the screenshots won't help much to debug the issue. They only show the end result after the d3d -> OpenGL translation was done. Since the issues is caused by the translation itself, it would better to provide log files. They can for example reveal if the software hits some unimplemented code path.
https://bugs.winehq.org/show_bug.cgi?id=43406
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fjfrackiewicz@gmail.com
--- Comment #6 from fjfrackiewicz@gmail.com --- (In reply to Michael Müller from comment #5)
I think the apitrace log and the screenshots won't help much to debug the issue. They only show the end result after the d3d -> OpenGL translation was done. Since the issues is caused by the translation itself, it would better to provide log files. They can for example reveal if the software hits some unimplemented code path.
What logfiles do you need exactly? I have NieR Automata and access to Wine Staging 2.13 and I can compile the latest Wine git on my system with no problem...
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #7 from Fabian Maurer dark.shadow4@web.de --- Created attachment 58809 --> https://bugs.winehq.org/attachment.cgi?id=58809 Log when replaying second trace with wine2.13-staging and CSMT
(In reply to Michael Müller from comment #5)
I think the apitrace log and the screenshots won't help much to debug the issue. They only show the end result after the d3d -> OpenGL translation was done.
No, it's an apitrace from DX calls. You can use apitrace.exe under wine to replay it, and it will show the issue. It replays fine on windows.
I thought this was the easiest way to get the issue across, but I'll gladly provide logs, too. I just need to know with what parameters, for now I added a log without WINEDEBUG.
Another apitrace, this time from the starting scene where the extreme bloom from my second screenshots is visible: http://www.mediafire.com/file/xiphsl3xx1dlfr3/bloom.7z (570MB, 1.7GB uncompressed)
https://bugs.winehq.org/show_bug.cgi?id=43406
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #8 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- I remember Assassin's Creed Revelations had a similar issue too in recent wine versions. The bloom was so bright in the snow storm at the beginning of the game, that the screen was all white except the player character and very close objects, appearing link sun blind silhouettes. It was triggered by the eagle-view feature of the game.
I don't have access to that game right now, I can't provide any logs or screen shots.
https://bugs.winehq.org/show_bug.cgi?id=43406
Zeke Sonxx zeke@zekesonxx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zeke@zekesonxx.com
--- Comment #9 from Zeke Sonxx zeke@zekesonxx.com --- Created attachment 58820 --> https://bugs.winehq.org/attachment.cgi?id=58820 Roadhog's Gun in Overwatch is way too bright
It sounds like this is the same issue causing Roadhog's gun to be super bright in Overwatch.
https://bugs.winehq.org/show_bug.cgi?id=43406
Philip Rebohle philip.rebohle@tu-dortmund.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |philip.rebohle@tu-dortmund. | |de
--- Comment #10 from Philip Rebohle philip.rebohle@tu-dortmund.de --- Is anyone expriencing this issue *not* running Mesa? Given that the video on the test page for this game looks fine, it seems to render correctly on Nvidia drivers.
I have this problem as well on both my RX 480 and my Kaveri notebook. Tested with Mesa 17.1.5, 17.0.6 and 17.2-rc2 on Arch, wine-staging 2.14.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #11 from Fabian Maurer dark.shadow4@web.de --- You could be right, I'm also running mesa. I tried making an OpenGL apitrace, but while it replays fine on linux+mesa, when replaying it on a windows machine it just freezes when entering the game.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #12 from Fabian Maurer dark.shadow4@web.de --- Software renderer doesn't work either.
Since I can't test it without crashes, can anyone with proprietary drivers (preferably nvidia) test replaying the apitrace?
Uploaded it here: http://www.mediafire.com/file/n3n1jn4cndizb5k/nier-opengl.7z(732MB compressed, 5.1GB unpacked)
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #13 from Fabian Maurer dark.shadow4@web.de --- Sorry, link broke: http://www.mediafire.com/file/n3n1jn4cndizb5k/nier-opengl.7z
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #14 from Philip Rebohle philip.rebohle@tu-dortmund.de --- Created attachment 58937 --> https://bugs.winehq.org/attachment.cgi?id=58937 Custom version of the brightness compute shader
This issue seems to be caused by a misbehaving compute shader that is involved in computing the average brightness level of the rendered image.
The attachment contains a custom version of the shader that should be functionally equivalent to the original shader, but seems to work correctly. In order to test it, save it somewhere (do not change the file name) and run the game or d3dretrace.exe with
export MESA_SHADER_READ_PATH=/your/shader/directory
Please let me know if it works for you. Note that this may not work with any wine version other than wine-staging 2.14, as the file name depends on the generated GLSL.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #15 from Philip Rebohle philip.rebohle@tu-dortmund.de --- One thing I noticed when rewriting the shader is that wine inserts barrier() calls when encountering a sync_g_t instruction, but does not insert a memory barrier to synchronize shared memory access. I'm not sure if this is correct.
Manually inserting such barriers does not fix the original shader on radeonsi though. I'm pretty sure that this is indeed a Mesa bug.
https://bugs.winehq.org/show_bug.cgi?id=43406
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=102218
--- Comment #16 from Fabian Maurer dark.shadow4@web.de --- Thanks for looking into this, I can confirm that the edited shader fixes the issue. It works with both my d3d trace and my opengl trace from my last post.
Reported the issue to mesa, see the "See Also" field.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #17 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- My issue is not the same.
I use a NVidia GTX970 with proprietary driver.
I've moved my issue to bug 43780.
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #18 from Philip Rebohle philip.rebohle@tu-dortmund.de --- Seems like the root cause of the compute shader misbehaving is that it reads from an image resource that is currently bound to the frame buffer for rendering. According to [1] and [2], the values read by the compute shader are undefined as a consequence.
In order to fix this, wine should unbind the FBO prior to calling glDispatchCompute.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=102218#c5 [2] https://www.khronos.org/opengl/wiki/Memory_Model#Framebuffer_objects
https://bugs.winehq.org/show_bug.cgi?id=43406
--- Comment #19 from Fabian Maurer dark.shadow4@web.de --- Sent in a patch to address this issue: https://source.winehq.org/patches/data/138902
https://bugs.winehq.org/show_bug.cgi?id=43406
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |0d45106054b8fedd8b05bada8e0 | |e589c11bf6375 Resolution|--- |FIXED
--- Comment #20 from Fabian Maurer dark.shadow4@web.de --- Fixed as of 0d45106054b8fedd8b05bada8e0e589c11bf6375. Thanks for investigating the issue!
https://bugs.winehq.org/show_bug.cgi?id=43406
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.0-rc1.