Seems like it's some INF fun:

This patch adds float emulation for mul, which fixes the rendering issue in this game, but i guess other instructions need this treatment too, or some other solution (i haven't checked what native d3d9 does in this case).

diff --git a/src/dxso/dxso_compiler.cpp b/src/dxso/dxso_compiler.cpp
index 0e5fa38c..f63fc42a 100644
--- a/src/dxso/dxso_compiler.cpp
+++ b/src/dxso/dxso_compiler.cpp
@@ -1797,6 +1797,10 @@ namespace dxvk {
         result.id = m_module.opFMul(typeId,
           emitRegisterLoad(src[0], mask).id,
           emitRegisterLoad(src[1], mask).id);
+        if (m_moduleInfo.options.d3d9FloatEmulation) {
+          result.id = m_module.opNMin(typeId, result.id,
+            m_module.constfReplicant(FLT_MAX, result.type.ccount));
+        }
         break;
       case DxsoOpcode::Rcp:
         result.id = m_module.opFDiv(typeId,

I really don't want to do an NMin on every MUL for this one game.

Cheers, CME. Will test.

"I really don't want to do an NMin on every MUL for this one game."

If it's any consolation, maybe some other D3D9 do similarly weird shit. I dunno, though.

This same issue also affects wined3d, so I filed https://bugs.winehq.org/show_bug.cgi?id=49133

So, this particular issue is fixed by a combination of Josh's changes to DXVK, along with some patches for Mesa.

Not sure whether I should close it or not...

Still happens on Proton 5.0-9 / Nvidia 450.66 / GTX 1070 / Arch Linux