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.