> On 6 Feb 2020, at 21:54, Allan Sandfeld Jensen <[email protected]> wrote: > > On Donnerstag, 6. Februar 2020 21:17:02 CET Lars Knoll wrote: >>> On 6 Feb 2020, at 19:29, Allan Sandfeld Jensen <[email protected]> wrote: >>> making the default SSE4.1 enabled but still offer users (linux distros >>> really), the option to force it down to only SSE2. >> >> >> We should at least default to SSE2 as the minimum requirement. We’ll anyway >> need some pure C/C++ code as fallback, so if someone really needs to run it >> on a CPU from 1999, he can compile things with SSE turned off. > > Isn't that the current status?. The question is if we should now do the same > for SSE4 we have been doing for SSE2 the last several years. Or do you mean > we > perhaps now can remove the option to non-SSE2?
The main difference is that I want to use SSE inline in public headers and unconditionally if enabled (which it is by default on x86/x64). The same for NEON on arm64. > >>> >>> You could do the same with NEON, but I think we already use that >>> unconditionally if detected at configure time. >> >> >> We do use NEON conditionally in some cases (e.g. qimagescale.cpp), but for >> most embedded devices it simply makes most sense to do the choice at Qt >> configuration time. > > Hmm, all the NEON-runtime check got disabled long ago when we had issues with > instructions leaking from one compile unit to another through headers. That > issue later got solved when it also threatened x86 by leaking AVX > instructions, and while I never reinstated the removed runtime checks for > NEON > in painting code, I do appear to have written new runtime switches where I > added new NEON code (at least in qimagescale.cpp) Didn't even remember I did > that, or why. That probably makes it limited to only a few places in image > handling, and it probably shouldn't be there either. It could be ok changing that to always select at compile time. I don’t think we need the same level of runtime checking for NEON as we do for different SSE/AVX versions on the desktop. Cheers, Lars _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
