Update: just got a new AMD GPU (RX6800) and it looks like the issue doesn't appear with RADV:

Tested with my Nvidia 730M (460.32.03 + DXVK 1.7.3) and your trace and the issue is present. So it could be a bug with Nvidia GPUs.

The game tries to lerp between some number x and INF which results in NaN on nvidia and intel.
This hack works around the issue, but meh 🐸:

diff --git a/src/dxso/dxso_compiler.cpp b/src/dxso/dxso_compiler.cpp
index f15efd44..d2fdfdf2 100644
--- a/src/dxso/dxso_compiler.cpp
+++ b/src/dxso/dxso_compiler.cpp
@@ -2059,10 +2063,22 @@ namespace dxvk {
         }
         break;
       case DxsoOpcode::Lrp:
+        std::array<uint32_t, 3> srcTmp;
+
+        srcTmp[0] = emitRegisterLoad(src[0], mask).id;
+        srcTmp[1] = emitRegisterLoad(src[1], mask).id;
+        srcTmp[2] = emitRegisterLoad(src[2], mask).id;
+
+        if (m_moduleInfo.options.d3d9FloatEmulation) {
+          for (int i = 0; i < 3; i++)
+            srcTmp[i] = m_module.opNMin(typeId, srcTmp[i],
+            m_module.constfReplicant(FLT_MAX, result.type.ccount));
+        }
+
         result.id = m_module.opFMix(typeId,
-          emitRegisterLoad(src[2], mask).id,
-          emitRegisterLoad(src[1], mask).id,
-          emitRegisterLoad(src[0], mask).id);
+          srcTmp[2],
+          srcTmp[1],
+          srcTmp[0]);
         break;
       case DxsoOpcode::Frc:
         result.id = m_module.opFract(typeId,

I am more interested in how the INF got there in the first place... does it come from the constant buffer?

Oh right, it's coming out of a fma instruction, probably makes more sense to nmin the result of this. Seems to be working fine.

diff --git a/src/dxso/dxso_compiler.cpp b/src/dxso/dxso_compiler.cpp
index f15efd44..72d32842 100644
--- a/src/dxso/dxso_compiler.cpp
+++ b/src/dxso/dxso_compiler.cpp
@@ -1796,6 +1796,10 @@ namespace dxvk {
             result.id,
             emitRegisterLoad(src[2], 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::Mul:
         result.id = m_module.opFMul(typeId,

I mean even further back...

I'll take a look tomorrow

You cant debug this just with this trace, as it happen in other places in a game always slightly differently... anyway I was playing/testing this game years back with nine and without regression fix was:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=394420ebb3eec6d8956588ee13380d5059e14bea
Anyway try just force FLT_MAX/2 for RCP on dxvk, to fix it for else vendor drivers, like nvidia, amdvlk, whatever.... might even fix some god of rays inconsistencies in other apps on these drivers for free. 🤣

I know the cause exactly, I'd prefer to just fix it properly.

Sure thing, here comes Nine years of properness 🤣
https://bugs.winehq.org/show_bug.cgi?id=30550

Well, I more mean, writing a Vulkan extension to have proper anything * 0 behaviour. It'll happen eventually, I just need to find time for it :)