Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
Cristián Maureira-Fredes wrote: > Even if it's a special module we have around only for Qt6 Hopefully that will be a long time! I sure hope you are not already planning yet another backwards-incompatible release. A lot of stuff has not even moved to Qt 6 yet! Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updating x86 SIMD support in Qt
Thiago Macieira wrote: > By default, I'd like us to produce x86-64 v2 code, which is SSE4. But v1 will still be available for distribution packaging? As long as that is the case, I do not see a major issue, it will just be one more caveat for distribution packaging. (Distributions still supporting v1, which I think is most of the distros these days, will have to enable it explicitly, possibly along with newer vn (n>1) if optimized builds are desired.) But dropping support for v1 entirely causes headaches for distributions. There are still (end) users of old hardware. E.g., my notebook is a Core 2 Duo that supports up to SSSE3 (so v1 + SSE3 + SSSE3), but no SSE4. So it unfortunately falls one generation short of v2. (My desktop supports v2, but not v3, because it is missing at least AVX2.) But as long as the distribution packages work on it, I do not really care about what vn or SSEn the Qt upstream binaries require. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updating x86 SIMD support in Qt
On 19/1/2022 1:01 PM, Thiago Macieira wrote: I've also found that macOS universal builds, WASM, Android and maybe some more are improperly detecting support. Specifically for universal builds, what we detect depends on the order in which you specify the architectures. This is buggy at a minimum, surprising at best. wasm is a special case, as we turn it off by default, regardless of detection. We cannot allow detection by default (specified by some configure argument which is currently -sse2) because browsers do not support it by default, and there is no way to just not use it once it is compiled in. -- Lorn Potter Freelance Qt Developer. Platform Maintainer Qt WebAssembly, Maintainer QtSensors Author, Hands-on Mobile and Embedded Development with Qt 5 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Updating x86 SIMD support in Qt
For Qt 6.4, I'd like to propose we change the way we detect and enable SIMD
support. TL;DR:
* Assume all compilers support 5-year-old stuff
* Up the minimum CPU for Linux, Window and macOS/x86
* Fix macOS Universal builds to use the minimum
* Add an option to cmake to choose a minimum matching one of the Linux x86-64
ABI revisions
* Make it easy to build QtCore, QtGui ad Qt3D multi-arch on Linux
Long version:
1) assume all compilers support what we need
Our current tests for compiler support go all the way back to SSE2, which is
mandatory on x96-64. While testing some changes, I've confirmed that all
compilers in the CI support x86 CPU features matching the Intel Cannon Lake
architecture, which is more than we need, except for the QCC compiler missing
one intrinsic that we can workaround.
I've also found that macOS universal builds, WASM, Android and maybe some more
are improperly detecting support. Specifically for universal builds, what we
detect depends on the order in which you specify the architectures. This is
buggy at a minimum, surprising at best.
I propose we remove the tests for the intrinsics of each individual CPU
feature. Instead, let's just assume they all have everything up to 2016. This
will shorten cmake time a little and fix the macOS universal builds. It'll
also change how 32-bit non-SSE2 builds are selected (see below).
The change https://codereview.qt-project.org/c/qt/qtbase/+/386738 is going in
this direction but retains a test (all or nothing). I'm proposing now we
remove the test completely and just assume.
Question:
- the QT_COMPILER_SUPPORTS_xxx macros are in qconfig.h (public config). Do we
keep compatibility? We can easily just move them to qprocessordetection.
2) add options to select the target architecture revision
Linux established 3 new revisions of the architecture:
* x86-64 v1 (baseline): SSE2 support
* x86-64 v2: baseline + SSE3, SSSE3, SSE 4
* x86-64 v3: v2 + AVX + AVX2 + FMA + BMI + F16C
* x86-64 v4: v3 + AVX512F + BW + DQ + VL + ER
For i386, we can consider a "v0" of the non-SSE2 original baseline from the
1980s.
I propose adding a CMake option to make it easy to opt in to one of those.
Yes, you can just set CMAKE_C(XX)FLAGS_{RELEASE,DEBUG,RELWITHDEBINFO}, so this
part would be convenience.
For the default, see #4.
3) add a way to have multi-arch glibc-based Linux builds
The revisions also match subdirectory searches by the Linux dynamic linker.
The subdirectories"x86-64-v2", "x86-64-v3" and "x86-64-v4" are new in glibc
2.33, but glibc has supported "haswell" (for v3) and "avx512_1" (for v4) for a
number of years prior to that.
The proposal is to allow the user to specify more than one architecture in the
list above. We can query the dynamic linker to find out if it supports the new
names and, if not, use the old ones.
For example, if I specified QT_X86_SUBARCH="v2;v3;v4", it would compile QtCore
three times. The build products would be:
lib/libQt6Core.so.6.4.0
lib/haswell/libQt6Core.so.6.4.0 OR
lib/glibc-hwcaps/x86-64-v3/libQt6Core.so.6.4.0
lib/haswell/avx512_1/libQt6Core.so.6.4.0 OR
lib/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.4.0
with their matching symlinks.
This would apply to only a few select libraries. I'm thinking QtCore, QtGui,
QtQml and some of the Qt3D libraries.
I don't currently see a need to do this for any plugins and there is no
standardised way to name them anyway.
This would replace the current "-mno-sse2" option that is required to turn
i386 32-bit builds from SSE2 support back to the original baseline. For a 32-
bit build, one would use QT_x86_SUBARCH="v0;v1" and get both baseline and the
SSE2-optimised version.
4) up the defaults from where they are today
Today, your default Qt build will always target the x86-64 baseline[*],
including for i386, despite as I said no CPU failing to meet the next level
for 9 years. I'd like to request we up that minimum.
By default, I'd like us to produce x86-64 v2 code, which is SSE4. There are a
number of optimisations in QtCore and QtGui that get automatically enabled. In
particular, qstring.cpp does not do runtime detection, so you've been leaving
performance on the table on your computers, unless you build Qt from source
yourself and set -march= to match your CPU.
I'm told that Red Hat 9 will increase their minimum to v2, which is why the
architecture selection features now exist.
This would apply to source and binary builds from qt.io. Android and macOS
would be unaffected because they already default to this level.
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?
5) for glibc-based Linux, add v3 sub-arch by default
I'd like to raise the default on Linux from baseline to v2 *and* add a v3 sub-
arch build, as described by point #3 above.
Device-specific Qt builds (Yocto Project, Boot2Qt)
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
On Dienstag, 18. Januar 2022 15:10:48 CET Cristián Maureira-Fredes wrote: > Hello, > > I would like to nominate Sona as maintainer [1] > for the qt5compat module, which at the moment doesn't > have one. Even if it's a special module we have around > only for Qt6, we need a responsible person in charge of it. > > She has been working mainly in qtbase in the last years > and took care of many tasks when the module was created [2]. > > Due to her contributions in qtbase and other modules [3], > I firmly believe she will manage to maintain it. > > Cheers > > +1 Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
Another +1. Thanks for stepping up, Sona! Cheers, Lars > On 18 Jan 2022, at 16:36, Mårten Nordheim wrote: > > +1 from me as well > > > From: Development on behalf of Cristián > Maureira-Fredes > Sent: Tuesday, January 18, 2022 15:10 > To: development > Subject: [Development] Nominating Sona Kurazyan as maintainer of qt5compat > > Hello, > > I would like to nominate Sona as maintainer [1] > for the qt5compat module, which at the moment doesn't > have one. Even if it's a special module we have around > only for Qt6, we need a responsible person in charge of it. > > She has been working mainly in qtbase in the last years > and took care of many tasks when the module was created [2]. > > Due to her contributions in qtbase and other modules [3], > I firmly believe she will manage to maintain it. > > Cheers > > > [1] https://wiki.qt.io/Maintainers#Qt_Maintainers > [2] > https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged > [3] > https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged > > -- > Dr. Cristián Maureira-Fredes > R Manager > > The Qt Company GmbH > Erich-Thilo-Str. 10 > D-12489 Berlin > > Geschäftsführer: Mika Pälsi, > Juha Varelius, Jouni Lintunen > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
+1 from me as well From: Development on behalf of Cristián Maureira-Fredes Sent: Tuesday, January 18, 2022 15:10 To: development Subject: [Development] Nominating Sona Kurazyan as maintainer of qt5compat Hello, I would like to nominate Sona as maintainer [1] for the qt5compat module, which at the moment doesn't have one. Even if it's a special module we have around only for Qt6, we need a responsible person in charge of it. She has been working mainly in qtbase in the last years and took care of many tasks when the module was created [2]. Due to her contributions in qtbase and other modules [3], I firmly believe she will manage to maintain it. Cheers [1] https://wiki.qt.io/Maintainers#Qt_Maintainers [2] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged [3] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged -- Dr. Cristián Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
that's no-brainer +1 From: Development on behalf of Cristián Maureira-Fredes Sent: Tuesday, January 18, 2022 3:10 PM To: development Subject: [Development] Nominating Sona Kurazyan as maintainer of qt5compat Hello, I would like to nominate Sona as maintainer [1] for the qt5compat module, which at the moment doesn't have one. Even if it's a special module we have around only for Qt6, we need a responsible person in charge of it. She has been working mainly in qtbase in the last years and took care of many tasks when the module was created [2]. Due to her contributions in qtbase and other modules [3], I firmly believe she will manage to maintain it. Cheers [1] https://wiki.qt.io/Maintainers#Qt_Maintainers [2] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged [3] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged -- Dr. Cristián Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
+1 from me. Her help and support on Qt Remote Objects has been great. Brett ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
+1 On 1/18/22 15:10, Cristián Maureira-Fredes wrote: Hello, I would like to nominate Sona as maintainer [1] for the qt5compat module, which at the moment doesn't have one. Even if it's a special module we have around only for Qt6, we need a responsible person in charge of it. She has been working mainly in qtbase in the last years and took care of many tasks when the module was created [2]. Due to her contributions in qtbase and other modules [3], I firmly believe she will manage to maintain it. Cheers [1] https://wiki.qt.io/Maintainers#Qt_Maintainers [2] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged [3] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
On 1/18/22 15:10, Cristián Maureira-Fredes wrote: >> Due to her contributions in qtbase and other modules [3], >> I firmly believe she will manage to maintain it. Jörg Bornemann (18 January 2022 15:15) replied > +1 > > I share your belief. :) That makes two of us ;^> +1 Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
+1 from me -- Alex From: Development on behalf of Jörg Bornemann Sent: Tuesday, 18 January 2022 15:15 To: development@qt-project.org Subject: Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat On 1/18/22 15:10, Cristián Maureira-Fredes wrote: > Due to her contributions in qtbase and other modules [3], > I firmly believe she will manage to maintain it. +1 I share your belief. :) -- Jörg Bornemann | The Qt Company ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
+1 Sone indeed does a very good job! Best regards Jarek From: Development on behalf of Cristián Maureira-Fredes Sent: Tuesday, January 18, 2022 3:10 PM To: development Subject: [Development] Nominating Sona Kurazyan as maintainer of qt5compat Hello, I would like to nominate Sona as maintainer [1] for the qt5compat module, which at the moment doesn't have one. Even if it's a special module we have around only for Qt6, we need a responsible person in charge of it. She has been working mainly in qtbase in the last years and took care of many tasks when the module was created [2]. Due to her contributions in qtbase and other modules [3], I firmly believe she will manage to maintain it. Cheers [1] https://wiki.qt.io/Maintainers#Qt_Maintainers [2] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged [3] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged -- Dr. Cristián Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat
On 1/18/22 15:10, Cristián Maureira-Fredes wrote: Due to her contributions in qtbase and other modules [3], I firmly believe she will manage to maintain it. +1 I share your belief. :) -- Jörg Bornemann | The Qt Company ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Sona Kurazyan as maintainer of qt5compat
Hello, I would like to nominate Sona as maintainer [1] for the qt5compat module, which at the moment doesn't have one. Even if it's a special module we have around only for Qt6, we need a responsible person in charge of it. She has been working mainly in qtbase in the last years and took care of many tasks when the module was created [2]. Due to her contributions in qtbase and other modules [3], I firmly believe she will manage to maintain it. Cheers [1] https://wiki.qt.io/Maintainers#Qt_Maintainers [2] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged [3] https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged -- Dr. Cristián Maureira-Fredes R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
