Running AVX version of code on CPU which does not support that

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)?

Mono path[0] = 'C:/Games/Steam/steamapps/common/Volcanoids/Volcanoids_Data/Managed'
Mono config path = 'C:/Games/Steam/steamapps/common/Volcanoids/MonoBleedingEdge/etc'
Initialize engine version: 2022.2.12f1 (022dac4955a3)
[Subsystems] Discovering subsystems at path C:/Games/Steam/steamapps/common/Volcanoids/Volcanoids_Data/UnitySubsystems
GfxDevice: creating device client; threaded=1; jobified=1
Direct3D:
    Version:  Direct3D 11.0 [level 11.1]
    Renderer: NVIDIA GeForce RTX 2060 (ID=0x1f03)
    Vendor:   NVIDIA
    VRAM:     12075 MB
    Driver:   31.0.15.3129
Begin MonoManager ReloadAssembly
- Loaded All Assemblies, in  0.331 seconds
- Finished resetting the current domain, in  0.003 seconds
1.29.433.0 (EarlyAccess), Release, MONO: NetStandard20,
2023-03-31 16:42:00Z
RELEASE BUILD
C:\Games\Steam\steamapps\common\Volcanoids\Volcanoids.exe
StorePlatform: Steam
OS: Windows 10  (10.0.19044) 64bit
CPU: Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz
CPU Cores: 12
CPU Frequency: 3317
RAM: 24567
GPU DeviceVendorID: 4318
GPU DeviceVendor: NVIDIA
GPU DeviceID: 7939
GPU DeviceName: NVIDIA GeForce RTX 2060
GPU DeviceType: Direct3D11
GPU DeviceVersion: Direct3D 11.0 [level 11.1]
GPU Memory: 12075
GPU ShaderLevel: 50
GPU 3DRenderTextures: True
GPU ComputeShaders: True

8918774–1221713–volc-ng-crashdump3-31-23 MOST NEWEST.rar (4.61 MB)
8918774–1221719–lib_burst_generated.zip (67.1 KB)

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).

1 Like

Burst 1.8.4
Unity 2022.2.12f1

What performance hit can we expect on AVX2 CPUs in the code paths using AVX2?
Half performance?

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?

1 Like

Report created: IN-37410

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).

1 Like

Just to be clear, if we build for all instruction sets, we should expect Unity to select SSE2 for old CPUs, for example?

We’ve had a bunch of crash reports with ‘illegal instruction’, and I had no idea that it was a bug, we’ve just moved to only using up to SSE4 for now…

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.

1 Like