http://bugs.winehq.org/show_bug.cgi?id=35207
Bug ID: 35207 Summary: Rendering issues in Outlast Product: Wine Version: 1.7.9 Hardware: x86 OS: Linux Status: NEW Keywords: regression Severity: minor Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: stefan@codeweavers.com Classification: Unclassified Regression SHA1: 667f4225b5cc25c5e4f2f725d55a7c011e12c388
Created attachment 46958 --> http://bugs.winehq.org/attachment.cgi?id=46958 terminal output
In certain areas like the opening scene some of the textures are missing (replaced by empty white rectangles). The problem exists when effects quality in the video options menu set anything but <very low>. The game uses Unreal Engine 3, no demo has been released. Installing native d3dx9 libraries doesn't solve the problem, but 'winetricks glsl-disable' is a workaround.
The problem is present since
667f4225b5cc25c5e4f2f725d55a7c011e12c388 is the first bad commit commit 667f4225b5cc25c5e4f2f725d55a7c011e12c388 Author: Stefan Dösinger stefan@codeweavers.com Date: Tue Apr 2 14:54:01 2013 +0200
wined3d: Put local constants into the shader code again.
This is essentially a revert of cd7825c89374fb9dd4c20aef2dbfd258713efe6a, with proper precision.
:040000 040000 f34c4237fad97c7435396d2fe4644e6a4dd94046 a4cf4d8af7ce2b467dff61ad7e5825884c8fcb36 M dlls
Let me know if you need further tests or debug logs.
Fedora 19 Nvidia binary drivers 325.15
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #1 from GyB gyebro69@gmail.com --- Created attachment 46959 --> http://bugs.winehq.org/attachment.cgi?id=46959 screenshot
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #2 from Stefan Dösinger stefan@codeweavers.com --- Have you tested my command stream patches I've sent to wine-devel a while ago? Did they fix the problem?
The Nvidia driver has some problems with handling single-precision float values accurately when the FPU is set to single precision mode. D3D (Wine and on Windows) sets this FPU mode by default. The command stream work works around that issue by moving GL calls to a separate thread that does not have the non-standard FPU setup.
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #3 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Stefan Dösinger from comment #2)
Have you tested my command stream patches I've sent to wine-devel a while ago? Did they fix the problem?
The Nvidia driver has some problems with handling single-precision float values accurately when the FPU is set to single precision mode. D3D (Wine and on Windows) sets this FPU mode by default. The command stream work works around that issue by moving GL calls to a separate thread that does not have the non-standard FPU setup.
The problem is still present in wine-1.7.13-118-g0eb6265. I tried your CS patches applied on Wine 1.7.1, and the problem is present with your patches as well.
Fedora 20 Nvidia binary drivers 334.16
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #4 from Stefan Dösinger stefan@codeweavers.com --- Smells like a different problem then. Is there a demo of this game that I can use to reproduce the problem?
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Stefan Dösinger from comment #4)
Smells like a different problem then. Is there a demo of this game that I can use to reproduce the problem?
Unfortunately no demo version has been released. Let me now if you need further tests or debug logs.
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #6 from Stefan Dösinger stefan@codeweavers.com --- Oh, I just saw the "no demo has been released" in your original post.
Does the problem happen with ARB shaders? (UseGLSL=disabled)
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #7 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Stefan Dösinger from comment #6)
Does the problem happen with ARB shaders? (UseGLSL=disabled)
Disabling GLSL is a workaround.
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #8 from Stefan Dösinger stefan@codeweavers.com --- Er, another info I missed in the original comment :-( .
I'll see if I can acquire the game somewhere. I don't think I'll get anywhere with logs.
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #9 from Stefan Dösinger stefan@codeweavers.com --- I can reproduce the problem, and it seems that it is indeed not related to the FPU setup. I'll keep investigating.
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #10 from Stefan Dösinger stefan@codeweavers.com --- Created attachment 47730 --> http://bugs.winehq.org/attachment.cgi?id=47730 Prevent the GLSL compiler from using local constants for optimizations
I think we're dealing with a driver bug here, specifically a broken optimization the driver applies based on the immediate values available at compile time. This hack prevents the driver from doing so by making the constants uniforms that could in theory be changed after compiling the shader. It works around the bug for me.
Please give the hack a try. In the meantime I'll try to find out which shader is affected by this and what the nature of the broken optimization is. (My gut feeling says it involves a NaN or INF value, just because they're always fun.)
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #11 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Stefan Dösinger from comment #10)
Created attachment 47730 [details] Prevent the GLSL compiler from using local constants for optimizations
I think we're dealing with a driver bug here, specifically a broken optimization the driver applies based on the immediate values available at compile time. This hack prevents the driver from doing so by making the constants uniforms that could in theory be changed after compiling the shader. It works around the bug for me.
Please give the hack a try. In the meantime I'll try to find out which shader is affected by this and what the nature of the broken optimization is. (My gut feeling says it involves a NaN or INF value, just because they're always fun.)
The patch fixes the issue here as well, thanks.
Fedora 20 Nvidia binary drivers 334.21
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #12 from Stefan Dösinger stefan@codeweavers.com --- I have compared the assembly generated from the bad and good shaders and I have an idea what is going on. The game has some code similar to this:
float mul_plus_one(float a, float b) { float c = a + 1.0; return c * b; }
With the 1.0 not hardcoded in the shader code, the compiler generates code like this
ADD c, a, {uniform_holding_one} MUL ret, c, b
With the 1.0 known at compile time, the code looks like this:
MAD ret, a, b, b
which calculates ret = a * b + b. I guess that's cheaper in the hardware, and mathematically it's equivalent.
the problem happens with
mul_plus_one(0.0, INF);
in the first case that's INF * 1.0 = INF. I the second case that's INF * 0.0 + INF = NaN + INF = NaN. The NaN results in a 0.0 alpha output from the shader. whereas INF would be 1.0. A later shader reads the texture, calculates 1 - alpha and writes the result to the screen.
I haven't confirmed that this is what's going on beyond a doubt, but I'm quite convinced that this is the problem here. So the problem is essentially bug 26967. (I think 26967 shouldn't have been closed INVALID just because it's fixed on the nvidia drivers by luck.)
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #13 from Henri Verbeet hverbeet@gmail.com --- (In reply to Stefan Dösinger from comment #12)
I haven't confirmed that this is what's going on beyond a doubt, but I'm quite convinced that this is the problem here. So the problem is essentially bug 26967.
Only in the generic "GLSL underspecifies fp behaviour" way. In principle this is an invalid optimization. You can't optimize "(x + 1.0) * y" into "x * y + y" in IEEE fp mode, unless you have additional contraints on x and y. That's a different problem from the application depending on d3d9 fp rules. The only reason the driver can get away with this is because under a strict interpretation the GLSL spec before GL4 allows the driver to do just about anything, and even e.g. GLSL 4.30 says very little about infinities and NaNs.
I'd still argue that what the driver does isn't particularly useful behaviour, and it should either just use d3d9 floating point mode, or follow IEEE fp rules wrt. optimizations.
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #14 from Stefan Dösinger stefan@codeweavers.com --- The parameters are as I suspected. The real uniform involved is 0.0, the other value is the output of a log_pp instruction, which can be INF. There's a slim chance that log_pp behaves differently from log and shouldn't produce an INF result. I doubt it though, but will check on Windows.
I'll try to contact the game dev and Nvidia and see how they respond.
http://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #15 from Stefan Dösinger stefan@codeweavers.com --- As expected log_pp(0.0) is INF on Windows, GeForce GT 650M (NVE0).
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #16 from Andrey Gusev andrey.goosev@gmail.com --- I actually have a fully black screen ingame, only the main menu and options menu are good. Disabling GLSL is a workaround. Wine 1.7.35 and Nvidia driver 346.35
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #17 from Stefan Dösinger stefan@codeweavers.com --- Fyi, I am in contact with Nvidia about problems regarding the floating point special behavior. They are aware of the issue and debating potential solutions, but I don't know if or when we'll see a fixed driver.
I don't want to work around this in our GLSL code. If we write generic workarounds for the different bugs experienced by one game each we'll end up with terribly slow shader code. As long as using the ARB backend works (and I'm keeping an eye on ARB regressions) disabling GLSL is my suggested workaround for affected users.
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #18 from Béla Gyebrószki gyebro69@gmail.com --- Still present in 1.8-rc1 and with Nvidia binary drivers 340.96. Can't reproduce with Nouveau/Mesa.
https://bugs.winehq.org/show_bug.cgi?id=35207
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #19 from Béla Gyebrószki gyebro69@gmail.com --- Still an issue in wine-1.9.14-181-ga711285.
OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL version string: 4.5.0 NVIDIA 367.35
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #20 from Henri Verbeet hverbeet@gmail.com --- (In reply to Stefan Dösinger from comment #17)
Fyi, I am in contact with Nvidia about problems regarding the floating point special behavior. They are aware of the issue and debating potential solutions, but I don't know if or when we'll see a fixed driver.
Did that go anywhere? I'm inclined to say the optimisation is just invalid, and resolve this as NOTOURBUG.
https://bugs.winehq.org/show_bug.cgi?id=35207
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #21 from Stefan Dösinger stefan@codeweavers.com --- I don't think the driver has ever changed, and I don't have access to the game to retest myself.
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #22 from Béla Gyebrószki gyebro69@gmail.com --- No change as of wine-2.0-rc4-41-g05f9b02 when GLSL is enabled.
OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 375.26
https://bugs.winehq.org/show_bug.cgi?id=35207
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.goosev@gmail.com
--- Comment #23 from Andrey Gusev andrey.goosev@gmail.com --- Works fine with wine-2.5-186-g6926564 and driver 375.39
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #24 from Béla Gyebrószki gyebro69@gmail.com --- Still present in wine-2.5-186-g6926564677.
OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 378.13
https://bugs.winehq.org/show_bug.cgi?id=35207
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=35207
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |debuser1@mt2014.com
--- Comment #25 from Henri Verbeet hverbeet@gmail.com --- *** Bug 37728 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=35207
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED
--- Comment #26 from Henri Verbeet hverbeet@gmail.com --- Unfortunately it doesn't seem likely this will be resolved on NVIDIA's end at this point, but I think NOTOURBUG is the correct resolution.
https://bugs.winehq.org/show_bug.cgi?id=35207
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=35207
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #28 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.
https://bugs.winehq.org/show_bug.cgi?id=35207
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #29 from Paul Gofman gofmanp@gmail.com --- Created attachment 63660 --> https://bugs.winehq.org/attachment.cgi?id=63660 Disable 'fastmath' optimization on NVIDIA
Can anyone please test this patch with Outlast / NVIDIA if possible (provided the issue is reproducible with the present drivers)?
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #30 from Andrey Gusev andrey.goosev@gmail.com --- (In reply to Paul Gofman from comment #29)
The issue is still reproducible. Driver 415.27, wine-4.2-118-g812d03129d
With the attached patch the white squares are present. (In case the commented block should be commented)
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #31 from Béla Gyebrószki gyebro69@gmail.com --- The patch works and fixes the problem for me. The trickery here with the patch is that the 'Direct3D' registry key must exists. As you may already know that registry key is not present in a clean wineprefix and the problem with the white squares are present even though the patch is applied. After creating Direct3D under HKCU/Software/Wine, the patch works indeed and textures are rendered correctly.
wine-4.2-159-gb3c5b7da94 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 418.31.03
https://bugs.winehq.org/show_bug.cgi?id=35207
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #63660|0 |1 is obsolete| |
--- Comment #32 from Paul Gofman gofmanp@gmail.com --- Created attachment 63671 --> https://bugs.winehq.org/attachment.cgi?id=63671 Disable 'fastmath' optimization on NVIDIA
(In reply to Béla Gyebrószki from comment #31)
The patch works and fixes the problem for me. The trickery here with the patch is that the 'Direct3D' registry key must exists.
Oh yeah, thank you very much for testing and for your finding. I did a last second change to the patch trying to make the option always work for testing instead of mentioning how to turn it on, but apparently did it wrong. I am attaching the one which hopefully does have the option enabled by default now for testing.
Just in case, it is meant to be controlled by HKCU\Software\Wine\Direct3D\DisableNVIDIAFastmath text registry value ('enabled' to make it work) and disabled by default. In this patch it should be on by default but still manageable through the registry value.
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #33 from Paul Gofman gofmanp@gmail.com --- (In reply to Andrey Gusev from comment #30)
(In reply to Paul Gofman from comment #29)
The issue is still reproducible. Driver 415.27, wine-4.2-118-g812d03129d
With the attached patch the white squares are present. (In case the commented block should be commented)
Thank you very much for your testing. I am sorry I made a stupid mistake in an attempt to make the patch work regardless of settings for testing, so the first version actually required the HKCU\Software\Wine\Direct3D key to be present for the patch to be active. Could you please confirm if the patch actually fixes the issue for you or not (either the new one, or the old one with the key created)?
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #34 from Andrey Gusev andrey.goosev@gmail.com --- (In reply to Paul Gofman from comment #33)
Well, yeah, the key do the trick.
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #35 from Paul Gofman gofmanp@gmail.com --- An option to disable Nvidia aggressive optimization has been added in 32b6ccb9c17b0d4c1d9acd6cbb91b28e7cbd97de.
It is turned on by setting HKCU\Software\Wine\Direct3D\strict_shader_math DWORD value to non zero.
Please note that the workaround has nothing to do with "0 * Inf" problem (like Bug #34266 and it's duplicates) when it does not result from operations reordering.
https://bugs.winehq.org/show_bug.cgi?id=35207
--- Comment #36 from Andrey Gusev andrey.goosev@gmail.com --- Also works for The Vanishing of Ethan Carter.