https://bugs.winehq.org/show_bug.cgi?id=34266
--- Comment #34 from Paul Gofman gofmanp@gmail.com --- A patch with two distinct workarounds for this bug has been added to Staging. They are controlled by HKCU\Software\Wine\Direct3D\multiply_special registry value (DWORD value). None of the workarounds are enabled by default. Both workarounds have no effect on shaders 4.0 and higher (that is, Directx 10+), the workarounds concern Directx 8 and 9 shaders only.
1. Setting multiply_special to 1 avoids infinity in RCP, RSQ and LOG instructions (returns [-]FLT_MAX instead of infinity). This is supposed to avoid rendering problems in most, if not all, games affected by this bug. Yet there can potentially exist games which suffer from this bug but for which this won't help. It can happen if, e. g., the game gets infinity through floating point overflow which is later multiplied by zero, or passes infinity or nan through shader constants. I observed the latter in some games but ironically those were not affected by this bug. This approach can have some impact on shader performance, but the impact is supposed to be not very big. It is also potentially possible that some games which are not affected by this bug will regress when using it, though I am not aware of real examples of that.
2. Setting multiply_special to 2 wraps each multiplication and dot product in shader with a check for zero operand, so that 0 * something result is always 0. This is supposed to workaround this bug more or less universally. But this approach is disastrous for shader performance. So it is mostly meant for debugging purposes. Yet maybe if the game is not GPU bound on the given hardware this mode can be used to play it, if setting multiply_special to 1 does not help.
What is particularly interesting for testing is:
1. Are there any games which are fixed by setting multiply_special to 2 but not to 1?
2. Are there any games (not affected by this bug) which have rendering problems with multiply_special set to 1?
Any reports on that are appreciated.