Bug 248155 - graphics/qt5-3d: fails to build with CPUTYPE>=haswell (anything with AVX2 I guess)
Summary: graphics/qt5-3d: fails to build with CPUTYPE>=haswell (anything with AVX2 I g...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-kde (Team)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-21 22:16 UTC by Greg V
Modified: 2021-06-19 11:52 UTC (History)
7 users (show)

See Also:
tcberner: maintainer-feedback+


Attachments
patch to avoid issue (808 bytes, patch)
2021-04-29 15:54 UTC, Steve Wills
swills: maintainer-approval? (kde)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Greg V 2020-07-21 22:16:08 UTC
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'
class 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;
                                                                         ^
Comment 1 Tobias C. Berner freebsd_committer 2020-07-25 08:39:09 UTC
Moin moin 


Indeed, it also fails when I set it to znver1 here.


mfg Tobias
Comment 2 Tobias C. Berner freebsd_committer 2020-07-25 09:16:32 UTC
Could you verify that you also get 

  Use SSE2 instructions .................. yes
  Use AVX2 instructions .................. no

in the configure output?
Comment 3 Greg V 2020-07-29 13:29:56 UTC
(In reply to Tobias C. Berner from comment #2)
Yes
Comment 4 break19 2020-10-14 10:26:21 UTC
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
Comment 5 eborisch+FreeBSD 2020-11-23 21:39:07 UTC
Adding

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.
Comment 6 Tobias C. Berner freebsd_committer 2020-11-24 05:24:56 UTC
(In reply to eborisch+FreeBSD from comment #5)

Yeah, someone should invest some time in why the AVX2 detection fails.
Patches, welcome :)

mfg Tobias
Comment 7 Steve Wills freebsd_committer 2021-04-29 15:54:46 UTC
Created attachment 224533 [details]
patch to avoid issue
Comment 8 Tobias C. Berner freebsd_committer 2021-04-29 16:03:20 UTC
(In reply to Steve Wills from comment #7)
Thanks, ship it :)
Comment 9 commit-hook freebsd_committer 2021-05-03 18:35:46 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=ae0a4238316456c6b26aff686d5d7e331e5ffb78

commit ae0a4238316456c6b26aff686d5d7e331e5ffb78
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
    PR:             248155

 graphics/qt5-3d/Makefile                                  |  2 +-
 graphics/qt5-3d/files/patch-src_core_configure.json (new) | 11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)
Comment 10 crahman 2021-05-25 03:34:45 UTC
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.
Comment 11 Steve Wills freebsd_committer 2021-05-25 21:13:55 UTC
(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.
Comment 12 Steve Wills freebsd_committer 2021-05-25 21:20:29 UTC
(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.
Comment 13 crahman 2021-05-27 03:58:50 UTC
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
QMAKE_LIBS_LIBDL = 
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
QT_HOST_CFLAGS_DBUS += 

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.
Comment 14 Steve Wills freebsd_committer 2021-05-27 13:38:57 UTC
(In reply to crahman from comment #13)
I don't see anything problematic here.
Comment 15 Steve Wills freebsd_committer 2021-06-19 11:52:15 UTC
Needs to be reverted in favor of fix in PR 255753