https://bugs.winehq.org/show_bug.cgi?id=46821
Bug ID: 46821 Summary: Alan Wake has light rendering issue Product: Wine Version: 4.3 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: andrey.goosev@gmail.com Distribution: ---
Created attachment 63844 --> https://bugs.winehq.org/attachment.cgi?id=63844 screenshot
Staying in a safe zone shows this. Contrast depends on angle.
Reproducible after commit dd0ea0a61463db83c647a9367ca61e2b69a98eb3. Solves with cleaning shaders cache and disabling CSMT.
After that: err:d3d:wined3d_debug_callback 0x1c589c0: "GL_INVALID_OPERATION error generated. <program> has not been linked, or is not a program object.". err:d3d:wined3d_debug_callback 0x1c589c0: "GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.".
NVIDIA Driver 418.43, wine-4.3-229-g6d82b2f1ad
https://bugs.winehq.org/show_bug.cgi?id=46821
Oliver Klee dev+wine@oliverklee.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dev+wine@oliverklee.de
https://bugs.winehq.org/show_bug.cgi?id=46821
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46821
David Gámiz Jiménez david.gamiz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.gamiz@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46821
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46821
--- Comment #1 from David Gámiz Jiménez david.gamiz@gmail.com --- Sorry I see your bug report right now.
Maybe similar to my report? https://bugs.winehq.org/show_bug.cgi?id=46933
https://bugs.winehq.org/show_bug.cgi?id=46821
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- (In reply to Andrey Gusev from comment #0)
After that: err:d3d:wined3d_debug_callback 0x1c589c0: "GL_INVALID_OPERATION error generated. <program> has not been linked, or is not a program object.". err:d3d:wined3d_debug_callback 0x1c589c0: "GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.".
NVIDIA Driver 418.43, wine-4.3-229-g6d82b2f1ad
Can you please attach a full log catching the issue WINEDEBUG=+d3d9,+d3d,+d3d_shader? Or if it is not reproducible right away and the log can't be uploaded even compressed, at least the one with WINEDEBUG=+d3d9,+d3d_shader?
https://bugs.winehq.org/show_bug.cgi?id=46821
--- Comment #3 from Paul Gofman gofmanp@gmail.com --- Created attachment 64116 --> https://bugs.winehq.org/attachment.cgi?id=64116 Debug patch working around 0 * inf issue (expect a few time loss in shader performance with it)
Andrey sent me required logs by e-mail and run a few tests with debug patches. Thanks for the great help in debugging this, I think the issues here are now clear. There are actually 2 of them.
1. Difference in behaviour between CSMT enabled and disabled, GL_INVALID_OPERATION error.
The fact the rendering issue is fixed with CSMT off looks like a coincidence caused by one shader just not working while it is supposed to. GL_INVALID_OPERATION is due to a shader failing to compile, the error is:
0(110) : error C0153: floating point constant overflow
and offending constant in generated GLSL shader code is
const vec4 ps_lc19 = vec4(-3.40282347e+38, 3.40282347e+38, 2.00000000e+00, -1.00000000e+00);
This is FLT_MAX value. Under some not entirely clear circumstances NVIDIA compiler complains about these values, but sometimes not. I could not reproduce such a failure in the test when switching CSMT on / off, but I could get exactly the same failure when setting maximum GL version to 1.0 (I didn't check all the possible versions). The constant 3.40282347e+38 is technically above maximum value, but adding some decimal points and getting 3.4028234660e+38 doesn't make compiler happy either. The patch avoiding FLT_MAX values was tested with the game, it makes CSMT on / off cases behave the same, avoid GL_INVALID_OPERATION and the issue becomes reproducible with both CSMT on and off. I am suggesting the fix for it: https://source.winehq.org/patches/data/162425 Since GLSL specifications does not seem to specify an exact way of setting FLT_MAX or what happens if the constant is above limit, we might be hitting an unspecified behaviour and working it around might be a right thing to do. I might be missing something here though. But in respect to the issue concerned by this bug the reported end effect of this patch is just making the glitch reproducible more reliably.
2. The issue which leads to the glitch when all GLSL shaders are compiled as they are supposed to is a duplicate of Bug #34266 (0 * inf in shaders).
I am attaching the patch which was used to confirm it (reported to fix the glitch). The patch workarounds the bug in a more or less universal way (doesn't touch 1 / x function or such, but checks values for 0 at every multiplication or dot product. I made this patch for checking for 0 * inf problem only, I don't think it is usable as the expected performance loss on shader execution is really great (I would expect it to be like 2-3 times or maybe even more). The patch also computes normalize() in the overflow safe manner just in case.
If someone wants to make an app specific build usable for avoiding the glitches, I suggest to test less universal but much less invasive hacks, like the one I will attach to the next message for testing.
https://bugs.winehq.org/show_bug.cgi?id=46821
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- Created attachment 64117 --> https://bugs.winehq.org/attachment.cgi?id=64117 Avoid infinity in 1 / x, 1 / sqrt(x) result
This is a less invasive but less universal hack to test if it is enough to workaround the rendering issue.
https://bugs.winehq.org/show_bug.cgi?id=46821
--- Comment #5 from Paul Gofman gofmanp@gmail.com --- In addition to my Comment #3, p1. After testing a bit more I figured out the exact conditions after which shaders are accepted by NVIDIA driver with FLT_MAX float literal or not. My initial tests were biased by the fact I did not clear shader cache each time while this is required here.
It is actually influenced by x87 FPU control word precision bits, and as it can be expected reproducible only in 32 bit tests and not in x64. When FPU precision (bits 8. 9 of FPU control word) is set to double (0x2, Windows default) or extended (0x3, Linux default) precision, the issue does not happen, compiler accepts FLT_MAX literal value. The issue happens when precision is set to single (0x0).
That's where CSMT comes into play here. When CSMT is on, all GL calls go from a thread created by wined3d code, and there is no explicit FPU control there. So thread gets default Windows precision and its ok. When there is no CSMT, GL calls go from an application thread, and the FPU flags ultimately depend on the application. If the application does nothing with FPU flags, but also does not specify D3DCREATE_FPU_PRESERVE flag on d3d9 device creation, d3d9 initializes x87 FPU precision to single. Given CSMT is enabled by default in Wine and have a purpose to solve a number of issues, this one seems to be just one of them and I don't think anymore there is anything to fix in respect to it.
https://bugs.winehq.org/show_bug.cgi?id=46821
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE
--- Comment #6 from Matteo Bruni matteo.mystral@gmail.com --- I assume this one is not affected by strict_shader_math / bug 35207, so resolving as duplicate of bug 34266. Interesting bit about the Nvidia driver and x87 FPU precision BTW...
*** This bug has been marked as a duplicate of bug 34266 ***
https://bugs.winehq.org/show_bug.cgi?id=46821
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Duplicate.
-
wine-bugs＠winehq.org