On Wed, 29 Sep 2021 at 22:41:03 +0200, bret curtis wrote: > To be honest, if you're still running on hardware that is older than yourself > then I would have to pragmatically ask if you or anyone actually runs > openal-soft on that particular hardware platform.
While I agree with this, and I have suggested in the past that Debian's baseline on i386 should reflect i386's major use case this decade as a compatibility layer to run legacy 32-bit binaries[1] on x86_64 CPUs[2], other people in the project have resisted that change on the basis that they apparently do still use x86 hardware that is genuinely only 32-bit; most vocally, we have people using AMD Geode CPUs, which are i686 minus one non-essential opcode. As a result, Debian's current i386 baseline is the instruction set of those Geode CPUs. Early in the bookworm development cycle, gcc-11 briefly generated code with CET (a control-flow security feature that makes use of opcodes that were not supported on i686 and are "long NOPs" on all SSE-capable CPUs) when building for i386, but this caused crashes on sufficiently old CPUs and was reverted. If there is anything that will finally make us raise the baseline at some point in future, it is probably going to be CET (or rustc, which has trouble targeting such old i386 variants). > This can be disabled with the ALSOFT_ENABLE_SSE2_CODEGEN=FALSE > cmake option, which will let it use the compiler default, though it's > not recommended. Debian policy is currently that we should do that, despite its performance impact. > So disabling SSE2 codegen > will allow it to work for pre-SSE2 CPUs, but worsen 32-bit performance > for SSE2-capable CPUs This is apparently what the project has chosen, even if only via inertia. While I personally don't think this is necessarily a great strategy, it is not a particularly high priority for me, so I have not asked the Technical Committee[3] to overrule whoever it is that makes this decision[4]. > So we either use the SSE extensions, or don't even bother shipping i386 > openal-soft. Please continue to ship i386 openal-soft. 32-bit Wine needs it. smcv [1] either proprietary native Linux binaries, 32-bit Windows binaries via 32-bit Wine, or open source that is *still* not 32-bit-safe [2] all x86_64 CPUs have MMX, SSE and SSE2 [3] disclosure: I am a member of the Technical Committee myself [4] if we wanted to overrule whatever maintainers are responsible for setting the i386 baseline, the first step would be to find out who they are, since there is no i386 porting team, and the other obvious candidate (the gcc maintainer) seems to have wanted to raise the baseline but then been overruled by *someone*