With errors like:
jobs/abstractpickingjob.cpp:110:33: error: no viable conversion from 'const Matrix4x4' (aka 'const Qt3DCore::Matrix4x4_SSE') to incomplete type 'const Qt3DCore::Matrix4x4_AVX2'
nearPos = nearPos.unproject(viewMatrix, projectionMatrix, viewport);
../../include/Qt3DCore/5.15.0/Qt3DCore/private/../../../../../src/core/transforms/vector3d_sse_p.h:68:7: note: forward declaration of 'Qt3DCore::Matrix4x4_AVX2'
../../include/Qt3DCore/5.15.0/Qt3DCore/private/../../../../../src/core/transforms/vector3d_sse_p.h:182:74: note: passing argument to parameter 'modelView' here
Q_3DCORE_PRIVATE_EXPORT Vector3D_SSE unproject(const Matrix4x4_AVX2 &modelView, const Matrix4x4_AVX2 &projection, const QRect &viewport) const;
Indeed, it also fails when I set it to znver1 here.
Could you verify that you also get
Use SSE2 instructions .................. yes
Use AVX2 instructions .................. no
in the configure output?
(In reply to Tobias C. Berner from comment #2)
also hitting this bug on -current with cputype=znver1:
# uname -a
FreeBSD zenstation 13.0-CURRENT FreeBSD 13.0-CURRENT #1 494ba3d79-c119(master): Fri Oct 9 16:11:27 CDT 2020 root@zenstation:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
CPUTYPE= ivybridge # (Select the most recent CPU without AVX2 support)
lets it build, but it would be nice to enable avx2 on local builds where it the instructions are supported.
(In reply to eborisch+FreeBSD from comment #5)
Yeah, someone should invest some time in why the AVX2 detection fails.
Patches, welcome :)
Created attachment 224533 [details]
patch to avoid issue
(In reply to Steve Wills from comment #7)
Thanks, ship it :)
A commit in branch main references this bug:
Author: Steve Wills <swills@FreeBSD.org>
AuthorDate: 2021-05-03 18:29:24 +0000
Commit: Adriaan de Groot <adridg@FreeBSD.org>
CommitDate: 2021-05-03 18:35:02 +0000
graphics/qt5-3d: fix AVX2 detection
Fails to build with CPUTYPE set to AVX2-enabled CPU (e.g. haswell).
Reported by: GregV
graphics/qt5-3d/Makefile | 2 +-
graphics/qt5-3d/files/patch-src_core_configure.json (new) | 11 +++++++++++
2 files changed, 12 insertions(+), 1 deletion(-)
Unfortunately this fix breaks pyside2 on machines that do not support avx2 instructions, because it causes avx2 instructions to be generated on cpus that do not support them.
I've verified this on my penryn machine using lldb.
See bug #255753.
(In reply to crahman from comment #10)
Were all of your packages built on the system that doesn't support AVX2? Or have you maybe used some binary packages from the official repo or other hosts and then only built pyside2 locally? The reason I ask, there's something saved in another QT package somewhere (I forget the details, will try to re-track them down) that stores what is available, so I think mixing and matching could possibly cause this issue.
(In reply to Steve Wills from comment #11)
Ah, found it, /usr/local/lib/qt5/mkspecs/qmodule.pri from qt5-qmake (devel/qt5-qmake). Could you please share the content of your copy of that file? If it mentions avx2, that might be the source of the problem.
I have inspected /usr/local/lib/qt5/mkspecs/qmodule.pri and indeed it contains some problematic data:
QT_CPU_FEATURES.x86_64 = mmx sse sse2
QT.global_private.enabled_features = sse2 alloca avx2 dlopen network posix_fallocate reduce_exports reduce_relocations relocatable sql system-zlib testlib xml
QT.global_private.disabled_features = alloca_h alloca_malloc_h android-style-assets private_tests dbus dbus-linked gc_binaries gui intelcet libudev release_tools stack-protector-strong widgets zstd
PKG_CONFIG_EXECUTABLE = pkgconf
QT_COORD_TYPE = double
QMAKE_LIBS_ZLIB = -lz
CONFIG -= precompile_header
CONFIG += sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2 avx512f avx512bw avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi avx512vl compile_examples f16c largefile rdrnd rdseed shani x86SimdAlways
QT_BUILD_PARTS += libs tools
I built this package on a penryn on Dec 10, 2020 - I just inspected the package itself (qt5-make) and the qmodule.pri in the package is exactly what I have reproduced above.
(In reply to crahman from comment #13)
I don't see anything problematic here.
Needs to be reverted in favor of fix in PR 255753