[Development] Updating x86 SIMD support in Qt

[Tor Arne Vestbø]

Hey hey,

On 19 Jan 2022, at 04:01, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

3) add a way to have multi-arch glibc-based Linux builds

If we go down this road I ask that we align both the porcelain and plumbing (configure, build system, C++ APIs, etc) . We already have universal builds on macOS and iOS done one way, and multi-arch/abi on Android another way. Let’s not add a third slightly different way, but instead use the opportunity to pay off some of the technical debts in this area.


4) up the defaults from where they are today

Question:
- iOS simulator builds are x86, but currently only SSE2. Does anyone know if
raising to SSE4, which *ALL*  64-bit Mac machines support, would be a problem?

That should be fine. The only reason SSE2 was chosen at the time was to ensure we built the draw helpers for the simulator build.

6) for macOS, raise the minimum to v3 (x86_64h)


macOS has supported an extra architecture called "x86_64h" for some time (the
"h" stands for "haswell"). Apple ceased offering macOS updates to processors
without AVX2 back with the Mojave release (10.14) in 2018. Since that's the
minimum version we require for Qt, it means all Intel-based Macs Qt can run on
also support this sub-arch.

One data point here, that I don’t know is worth anything, is that on macOS 12 at least, none of the system binaries in /bin or /sbin are x86_64h, they are all x86_64+arm64e (arm64e reserved for Apple for now).

On the other hand, the dyld shared cache (of all the system frameworks) provides x86_64h:

❯ ls /System/Library/dyld/
aot_shared_cache.0            aot_shared_cache.3            aot_shared_cache.t8027.2      dyld_shared_cache_arm64e.1    dyld_shared_cache_x86_64.1    dyld_shared_cache_x86_64.map  dyld_shared_cache_x86_64h.2
aot_shared_cache.1            aot_shared_cache.t8027.0      aot_shared_cache.t8027.3      dyld_shared_cache_arm64e.map  dyld_shared_cache_x86_64.2    dyld_shared_cache_x86_64h     dyld_shared_cache_x86_64h.3
aot_shared_cache.2            aot_shared_cache.t8027.1      dyld_shared_cache_arm64e      dyld_shared_cache_x86_64      dyld_shared_cache_x86_64.3    dyld_shared_cache_x86_64h.1   dyld_shared_cache_x86_64h.map

It might also need some more work than just changing our default. E.g, changing the arch in a simple Xcode project gives:

The run destination My Mac is not valid for Running the scheme 'rasterwindow’.
My Mac doesn’t support any of rasterwindow.app’s architectures. You can set rasterwindow.app’s Architectures build setting to Standard Architectures to support My Mac.

This is on a 2019 MBP

Xcode’s ARCH_STANDARD build variable is [x86_64, arm64].

The same problem persists after updating VALID_ARCHS from the default [arm64 arm64e i386 x86_64] to [arm64 arm64e i386 x86_64 x86_64h].

I'd like to do this for all libraries and by default on binaries from qt.io<http://qt.io>.
However, I understand the ARM translation application cannot deal with the AVX
instructions, so it would fail to run our default binaries for the
applications that couldn't rebuild as ARM. Is it acceptable to require those
application developers to rebuild Qt from source?

I believe we detect that situation at runtime and explicitly turn off AVX support, so we wouldn’t be hitting any of those AVX code paths, if I understand things correctly?

Cheers,
Tor Arne

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220119/c1e8d9d8/attachment-0001.htm>