We have this player with Intel i7 980X (Extreme), who is running our game and it’s crashing on “Illegal instruction”.
When I load crash dump and look into disassembly there’s VMOVAPD, which is part of AVX instruction set.
The CPU supports only SSE 4.2.
Our Burst AOT Settings is setup to SSE2, SSE4, AVX2
from what I understand, Burst builds these versions of libraries and chooses appropriate one at runtime.
If that’s the case, it makes a wrong choice.
I’ve attached part of the log file, crash dump and lib_burst_generated.dll
Is there some command line setting to force different architecture when starting the game (at least as temporary fix)?
No, the cpu detection does not have any overrides, unfortunately.
Looking at the lib_burst_generated you attached, I can see both an sse2 path and an avx2 path. So unfortunately, this looks like a bug, Which version of Burst was used here?
The only potential workaround I can suggest is to disable the avx2 code generation (just have SSE2) and release a patch (replace the lib_burst_generated.dll).
Its unlikely to be half, at best I would expect a 30-40% increase in performance with avx2, however like all performance related things, the only way to know for sure is to profile the code in question.
Could you please log a bug for the above, ideally with a sample project, but at a minimum with the crash dump, lib burst and the lib_burst_generated.pdb attached?
I don’t have the CPU, so I’m unable to create sample project. I’ve attached crash dump with exact lib_burst_generated.dll, which was used during the crash.
And also attached separate lib_burst_generated.dll with PDB (rebuilt from same revision, but as development build).
If you build for multiple targets, then yes, burst should automatically choose the closest target to the users system. However as noted in this thread, there is currently a bug that causes burst to mistakenly throw away multiple versions of some scalar math routines keeping only one (randomly depending on compilation order), which can cause the SSE2 path to hit an AVX2 path, or vice versa.