EA Staff (Retired)@TEZZ0FIN0, thanks for the experimental results. It's interesting that disabling speedstep seems to have stopped the issue for you. You shouldn't HAVE to disable a CPU feature to get the CPU to work. If the CPU says it will go up to a certain frequency as long as the temperature stays in range, then that frequency should work.
@Falkentyne, the function that is crashing is really quite boring. It's just doing some simple math in a loop. There's nothing that stands out as strange or tricky compared to any other part of the code. If there was anything remotely suspicious in this code, I'd probably change it just to see if "stirring the pot" caused the problem to go away.
Which brings up another interesting point. This function is templated with two nearly-identical versions (one for shadows and one for cameras). The crash has only ever happened in the one for cameras. Why doesn't the other one ever crash? I'll have to compare their disassembly soon...
EA Staff (Retired)I looked at the diff of the disassembly of the shadow and camera versions of this templated function. For most of the function, the only difference in the disassembly is what registers the compiler assigned to various things. However, the shadow version always uses a specific lod, so it skips a bunch of scalar floating point math (which is done on SSE hardware).
Also, the shadow version is actually only used for the really distant shadows, which only do partial updates when things like the drop ship are moving. Many frames we don't update them at all. Plus, the nature of the incremental updates means that it processes far fewer models. So, the shadow version does a lot less work, and does it less often. That reduced workload may be enough to explain why it never seems to crash.
Community Manager
