SSE: Check !defined(__EMSCRIPTEN__) where intrinsics are unavailable on WASM
#12917
Conversation
| @@ -445,7 +445,7 @@ void SoundDeviceNetwork::callbackProcessClkRef() { | |||
| // This disables the denormals calculations, to avoid a | |||
| // performance penalty of ~20 | |||
| // https://github.com/mixxxdj/mixxx/issues/7747 | |||
| #ifdef __SSE__ | |||
| #if defined(__SSE__) && !defined(__EMSCRIPTEN__) | |||
There was a problem hiding this comment.
Here are some details:
https://emscripten.org/docs/porting/simd.html
It sounds like denormals to zero mode IS available. Can you check that and adjust the debug message accordingly?
There was a problem hiding this comment.
Yeah, it's available but since the denormals mode is fixed, we cannot use the set functions, so there is not really a point in having these blocks execute. The flush zero mode is fixed too, but in this case to being off, which isn't the mode we want. _mm_setcsr isn't available either, so we can't use the fallbacks from denormalsarezero.h.
Can you check that and adjust the debug message accordingly?
Do mean emitting a qDebug() message when targeting __EMSCRIPTEN__? Or only cond-compiling out the actual _MM_SET invocations and emitting a debug message where the fixed mode doesn't match our desired mode?
There was a problem hiding this comment.
Ok, than just add a comment about the situation. My original concern was that this is a implementation defined thing.
The background is, that denormals are so slow, that the EQs and other filters are not usable. I am curious if they are usable with emscripten.
There was a problem hiding this comment.
Haven't gotten around to test EQ and filters in Mixxx yet (there are still some more foundational issues to be resolved, including audio support, before we can actually test that), but came across this interesting discussion upstream: WebAssembly/design#148
Looks like flush-to-zero (FTZ)/denormals-as-zero (DAZ) were deliberately avoided in favor of IEEE-compliance, though they've hinted at adding it as an opt-in.
Edit: Mentioned here: https://github.com/WebAssembly/design/blob/main/FutureFeatures.md#flushing-subnormal-values-to-zero
|
This part from the porting guide confuses me a bit:
Anyway, I've updated the comments to mention that these modes are non-configurable when targeting Emscripten/Wasm. |
|
We have a test that checks for denormals here: mixxx/src/soundio/sounddevicenetwork.cpp Line 481 in 20de6fa Did you see the warning? |
src/soundio/sounddevicenetwork.cpp
Outdated
| #ifdef __SSE__ | ||
|
|
||
| // On Emscripten (WebAssembly) denormals-as-zero/flush-as-zero is not | ||
| // configurable, for discussion and links see |
There was a problem hiding this comment.
Please add here a comment about the current situation. Do we suffer from denormals calculations or not?
There was a problem hiding this comment.
We can probably say that these are not supported, but to assess the actual performance, we'd need probably need audio, which isn't ready yet. Since it's not configurable, there is probably not much point in discussing this as a performance consideration until Emscripten/Wasm add a way to configure it.
Yes (the build deployed at https://fwcd.dev/m1xxx displays it): Though we'll probably first be able to properly test whether this is indeed a performance issue when the Web Audio backend is ready (which, unfortunately, seems to be a non-trivial roadblock due to issues with Asyncify, see PortAudio/portaudio#887 and fwcd/m1xxx#69). |
|
Calculation denormals is done on the CPU and it takes significant lower independent which programming model is used. So we can assume that this is a real issue until we have proved the opposite. Can you please adjust the comment accordingly and than we can merge. |
Some SSE intrinsics are unavailable in Emscripten, in particular
_MM_SET_DENORMALS_ZERO_MODE1, therefore we have to disable them when targeting Emscripten/WASM.Footnotes
As per https://emscripten.org/docs/porting/simd.html#id8, ↩