[Bug 46821] Alan Wake has light rendering issue

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=46821

--- Comment #3 from Paul Gofman <gofmanp at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.