Triton Codec uses AVX instructions; is there an SSE4.2 version available? about projectacoustics HOT 2 OPEN

@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

from projectacoustics.

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.

from projectacoustics.