[Development] Using SSE/NEON in Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

On 20/02/06 11:45, Lars Knoll wrote:
> Hi,
> 
> We’ve seen that in a couple of places things like matrix operations are a CPU bottleneck. Being able to provide SSE/NEON optimised versions of some of those operations could help significantly. 
> 
> On x86/x64, we require SSE2 already anyway, so we should be able to use those unconditionally. On ARM, we can make this a compile time option with a C implementation as the fallback.
> 
> One problem is, that we can only get full benefit out of those if we can offer them inline. That would basically imply making our qsimd_p.h header public and including that one from qvectornd.h and qmatrixnxn.h (so that we can implement the operations using the SSE/NEON intrinsics). If we do that, we could e.g. implement QVector4D holding a __m128 value (and the neon equivalent on ARM).
> 
> I personally don’t think including qsimd.h (and implicitly immintrin.h) from our public headers would be a problem, but I’d be happy to hear arguments for/against it.

That might work as long as it's compile-time optional. Let's split both cases here:

# SSEn

SSEn is not present on all architectures. Not all i386 machines support SSE2 for
example, and some amd64 do not support more than SSE2 (read below).

If some of this becomes mandatory then distributions will certainly not be able
to ship Qt 6. On the other hand if it can be decided at built time we could do a
double build and ship a non-optimized library in /usr/lib/ and an optimized
version in /usr/lib/sse2, /usr/lib/sse4, etc., as the linker knows what to do in
those cases.

At least in Debian we do this for qtbase on i386, and have different versions of
corelib and gui (the only ones which where directly affected by this).

Of course this might not go well with inlining.

# NEON

On Debian we have arm64, armel and armhf as arm-based supported architectures.
The only arch that can support NEON is arm64. It never existed for armel and
NEON was optional for µP builders on armhf.

I don't know if one ould do the /usr/lib/neon/ linker trick here.

# If we go the linker path route...

If this case is taken then it would be *awesome* to know exactly which libraries
do really get a benefit from this, so we only ship those with a double build.

# Other solutions?

If some other solution like the linker path is possible we can definitely
discuss it :-)

> As a side note: SSE 4.1 offers some nice additional instructions that would simplify some of the operations. Should we keep the minimum requirement for SSE at version 2, or can we raise it to 4.1?

Well, I'm currently running KDE on my machine which only supports SSE2. 10yo
machine,: yes. But I could not afford a new one so far (and this one still works
pretty fine).


# On a related note

So far my impression as a distro maintainer is that people where way more eager
to switch from qt4 to qt5 than from qt5 to qt6. If somehow the barrier gets even
higher we will have a hard time in making people to do the switch. Mind you, we
removed qt4 from Debian testing just some weeks ago...

Regards, Lisandro.