On Sat, 26 Mar 2022 at 09:43:32 +0800, Paul Wise wrote:
> It might be worth looking at how things like Steam and Flatpak/Snap
> solve this issue
In general they don't, or to put it another way, they "solve" it to the
same extent that Debian/apt/dpkg currently does. Each binary build has
a required instruction set (often the default for its SDK's compiler,
but sometimes higher via command-line options like -msse2) and won't
work on older CPUs.
It seems like many upstreams, notably Mozilla and Rust, have effectively
chosen i686 + MMX + SSE + SSE2 to be their baseline for 32-bit builds,
because that level of functionality is nearly 20 years old and lets them
avoid the quirks of the i387 FPU.
The binaries for Steam itself are documented to require x86_64 with
CMPXCHG16B and SSE3, so Steam is higher-than-baseline even on x86_64.
The developers of Steam have no interest in supporting early 2000s
hardware, or embedded 32-bit x86 variants.
For most native Linux Steam games, the compilers in the SDK are the
version of gcc from an old version of Ubuntu (gcc 4.6, 4.8 or 5), or one
of several approximately contemporary versions of clang, or a backport
of gcc 9 from Debian, and inherit whatever our baseline was at the time
(i586 or nearly-i686); but Steam game developers are encouraged to
compile for x86_64 anyway, so it's mostly older games that have 32-bit
binaries. For games that still have 32-bit binaries, I suspect that
using -msse2 is common.
For Proton and for native Linux Steam games that use the new soldier and
sniper container runtimes (not really supported yet, but a few games jump
through the necessary hoops to do it anyway), the compiler in the SDK
is the version of gcc or clang from the Debian release that the runtime
is based on (Debian 10 or 11), or in the case of the Debian-10-based
soldier runtime, a backport of gcc 9. Again, game developers are encouraged
to compile for x86_64 when targeting these runtimes.
Most Flatpak apps are directly or indirectly based on the freedesktop.org
runtimes available from Flathub (the GNOME and KDE runtimes are derived
from the fd.o runtime), and the non-EOL versions of those runtimes no
longer directly support 32-bit builds, only x86_64 and aarch64.
Flatpak apps that need biarch x86 (i386 and x86_64 in parallel), like
the Flatpak version of Steam, use the x86_64 version of the runtime and
add the "Compat.i386" runtime extension. That extension uses multiarch
paths, but is conceptually more similar to Debian packages like lib64z1
than it is to Debian's i386 architecture - it contains 32-bit code,
but it is only for use by x86_64 CPUs in 32-bit compatibility mode, so
it can safely assume the presence of all the CPU extensions that are in
the x86_64 baseline, and in particular SSE2.
> I expect games and proprietary apps often use CPU
> features unsupported on old systems.
Yes, for large values of "old": bear in mind that, for example, SSE2 was
introduced by Intel in 2000 and adopted by AMD in 2003. If Wikipedia is
to be believed, the last new releases of mainstream pre-SSE2 CPUs were
late models of the Athlon XP (2004) and Pentium III mobile variants (2007).
(I'm aware that embedded 32-bit x86 CPUs like the AMD Geode series and
Intel Quark do not have the same functionality as mainstream desktop/laptop
CPUs of a comparable age.)
> I also wonder if qemu could be used to emulate newer CPU features on
> older systems. That would probably be unusably slow though.
For opcodes that are used to improve performance, that would be
completely self-defeating.
For opcodes that are necessary for correctness of a particular sequence
of code (like CMPXCHG16B), I don't see how that would even work; at best
it would be really expensive, and at worst it would not provide the
required semantics.
smcv
