Triton Codec uses AVX instructions; is there an SSE4.2 version available?

[Kalmalyzer]

We are using Project Acoustics together with Wwise and Unreal 5.3. The min spec of UE 5.3 and all other software components that we use at runtime is SSE4.2. However, it appears that Project Acoustics uses AVX instructions without validating CPU capabilities. Is that intentional? What are the chances of a non-AVX-required version of Project Acoustics? We are happy to build from source and hammer a bit on it ourselves if necessary.

---

The reliance on AVX instructions means that AMD's pre-Zen architecture CPUs (i.e. any AMD CPUs before 2017) and any of Intel's Pentium/Celeron branded CPUs up till Tiger Lake (i.e. some low-end CPUs from Intel before 2020) cannot run Project Acoustics. This is a narrower minspec than we would like for our game. It is also more difficult than necessary to explain to a customer what the minspec is in a concise manner; they know how many cores their CPU has, they might know what processor generation their CPU is, but they don't know what instruction set their CPU supports.

The first place where the current Project Acoustics implementation hits an AVX instruction is in a static initialization method; this is either compiler-generated logic, or it is the constructor for a statically constructed object. Either way, this piece of code gets run by the C runtime before main() even is reached, and the code bytes originate from Triton.Codec.lib:

000001B988882830 48 83 EC 28          sub         rsp,28h  
000001B988882834 C5 FA 10 05 68 9B 08 00 vmovss      xmm0,dword ptr [__real@42422884 (01B98890C3A4h)]  
000001B98888283C FF 15 06 C4 07 00    call        qword ptr [__imp_lroundf (01B9888FEC48h)]  
000001B988882842 89 05 0C 5E 0B 00    mov         dword ptr [std::_Facetptr<std::codecvt<char,char,_Mbstatet> >::_Psave+24h (01B988938654h)],eax  
000001B988882848 48 83 C4 28          add         rsp,28h  
000001B98888284C C3                   ret  

(__real@42422884 is a float containing the value 48.5395660)

The AVX code is not wrapped in any "only do this if the CPU supports AVX" logic with fallback code paths. We don't know whether the Triton codec has such logic in place for its processing kernels. If that is the case, well, then that feature selection logic seems to be not present for the initialization logic for the static objects.

[NoelCross]

@Kalmalyzer Thanks for bringing this to our attention. We did add compiler options to utilize AVX instructions over the past year and didn't realize that UE still supports minspec PCs without AVX support.

I'll create a bug report in our tracking database and we'll discuss internally if this is something we can service. We don't have any plans on releasing an updated set of plugins for the UE marketplace until the UE5.4 release which requires us to submit a fresh update.

As far as source code access, we do not provide access to the source at this time. The only option that I can think of at this time is to modify UE to catch this exception while loading the plugin to avoid the crash. It doesn't give you the support for lower end machines that you are looking for, but it should allow for the process to stay alive.

Best regards,
Noel

[Kalmalyzer]

Thanks for the quick response. Hm.

Short term

Unreal does build each plugin as a separate, dynamically-loadable DLL when building for running the game within the editor, but when building a standalone shipping game all the plugins' code get statically linked in to the main executable. There is no good way to "wrap" the initialization of the entire Project Acoustics Unreal plugin and capture potential exceptions.

I think a more feasible option to make Project Acoustics "not crash" for us is to link all the Triton.*.lib code into a DLL, outside of Unreal, and then make the Project Acoustics Unreal plugin dynamically load that DLL (but only if the current CPU supports AVX) and return dummy values to calling code(return 0, "status: inactive", etc) otherwise. That seems like a hefty chunk of work though.

Not sure what we'll do here. This causes some problems during our community playtests and performance profiling on low-end hardware. Our game is not publicly released yet (target is Q3 2024) so it doesn't hit huge numbers of players.

Long term

I recommend that you build the libs without AVX enabled across the board for the next major release(s). If you are concerned about resulting performance loss, then I'd suggest identifying a few specific kernels in your current code and writing those in ISPC; in many cases, you can claw back the majority of performance lost on AVX machines that way (and also potentially get slightly higher perf thanks to AVX2/AVX512 paths being autogenerated), while having decent SSE fallback paths generated for you.