Created attachment 196405 [details] For Mesa 18.1
Created attachment 196406 [details] v1 Oops, drop patch that will conflict with bug 230298.
Hi! llvm70 is still in RC in the ports tree. I would like to see it get bumped to a release version before this goes in. I also hope that gecko ports and other big consumers of ports llvm70 gets bumped at the same time. That way there won't be a window where you would need two llvm versions installed.
FYI, llvm70 is definitely currently broken on i386 (it generates lib calls for atomics what we don't implement). dim@ is working on getting the change that caused this fixed.
(In reply to Niclas Zeising from comment #2) > I also hope that gecko ports and other big consumers of ports llvm70 > gets bumped at the same time. That way there won't be a window > where you would need two llvm versions installed. I'd like to start somewhere. - bug 230790 will bump 10.4/11.1 users to Clang 7.0 but after 10.4/11.1 EOL that change would be nop. - gecko@ needs clang-sys to support "clang_7_0" bindings or bindgen may crash when building Stylo but, surprisingly, it doesn't, see https://ptpb.pw/mpif (In reply to Brooks Davis from comment #3) Mesa doesn't use LLVM for atomics, so the change here builds fine on all Clang architectures. For one, llvmpipe (installed as swrast_dri.so) works fine on 10.4 i386 (tested Firefox 63 with WebRender enabled).
I plan to land this shortly after 2018Q4 branches. Mesa itself needs newer LLVM in order to support recent (mainly AMD) hardware better. llvm60 is unlikely to receive upstream backports now that llvm70 is stable. Projects that support more than one stable branch are actually rare due to tremendous waste of resources. Even Mesa quickly sunsets previous branch after X.Y.1 release.
As I've stated before, I'd like for this to happen to most of the ports tree at once. Only bumping mesa just means that everyone will need to have two versions of llvm installed in order to get other desktop applications, such as gecko ports.
(In reply to Niclas Zeising from comment #6) > As I've stated before, I'd like for this to happen to most of the > ports tree at once. What's the plan to make this happen? > Only bumping mesa just means that everyone will need to have two > versions of llvm installed in order to get other desktop applications, > such as gecko ports. Since ports r481071 Gecko ports require llvm70 to build as well.
Ping? Another month has passed. Can we be clued into the roadmap to llvm70 here?
(In reply to Tobias Kortkamp from comment #8) We recently switched wayland default to on for mesa ports. I'd like for that to settle before switching this as well. We have a graphics team meeting next week, after that.
Created attachment 199665 [details] v2 Hop onto DEFAULT_VERSIONS train after ports r485466. Obviously, if x11@ is gonna drag progress during the next bump Mesa would return to the local default.
(In reply to Niclas Zeising from comment #9) > We have a graphics team meeting next week, after that. Are you still planning on publishing meeting notes like in October?
(In reply to Tobias Kortkamp from comment #11) > Are you still planning on publishing meeting notes like in October? Yes, that's the plan. I'm looking into why this hasn't happened yet.
After bug 235215 lands v2 will switch mesa-* to llvm80. Pick v1 if you want to stay on llvm70.
mesa-dri-18.3.2 with llvm80-8.0.0.r1 and amdgpu needs a backport of [1] to avoid '+vgpr-spilling' is not a recognized feature for this target (ignoring feature) errors. [1] https://gitlab.freedesktop.org/mesa/mesa/commit/9cab8ccd6cb5aa8a4748dd6d7fc15d9747624df6
Created attachment 201531 [details] beignet + llvm80 (After v2) lang/beignet fails with DEFAULT_VERSIONS+=llvm=80, so here's a fix. Tested on Skylake GT2 via graphics/waifu2x-converter-cpp. Rationale is in the patch header. I suspect Debian will send a similar fix upstream but given bug 233652 there's not much hope.
A commit references this bug: Author: jbeich Date: Mon Mar 4 10:42:24 UTC 2019 New revision: 494579 URL: https://svnweb.freebsd.org/changeset/ports/494579 Log: graphics/mesa-dri: switch to llvm70 PR: 230789 Approved by: maintainer timeout (2 weeks) Changes: head/devel/libclc/Makefile head/graphics/libosmesa/Makefile head/graphics/mesa-dri/Makefile head/graphics/mesa-dri/Makefile.common head/lang/beignet/Makefile head/lang/clover/Makefile
A commit references this bug: Author: jbeich Date: Mon Mar 4 10:56:14 UTC 2019 New revision: 494583 URL: https://svnweb.freebsd.org/changeset/ports/494583 Log: graphics/mesa-dri: back out r494579 Landed by mistake. x11@ is immune to maintainer timeout nowadays. PR: 230789 Changes: head/devel/libclc/Makefile head/graphics/libosmesa/Makefile head/graphics/mesa-dri/Makefile head/graphics/mesa-dri/Makefile.common head/lang/beignet/Makefile head/lang/clover/Makefile
As mesa-* continues to drag updates jumping on LLVM_DEFAULT may become harder in future. The plan is to bump LLVM_DEFAULT to 90 around October.
(In reply to Jan Beich from comment #15) This patch work for me to build beignet with llvm80. You can commit it before decided to remove beignet or not.
Any updates here? I do not see anything related to moving Mesa to a newer LLVM in recent graphics team meeting notes (latest mention in 2019-01-30 notes, after that nothing).
A commit references this bug: Author: zeising Date: Sun Jun 30 14:56:14 UTC 2019 New revision: 505425 URL: https://svnweb.freebsd.org/changeset/ports/505425 Log: Switch mesa and related ports to llvm80 Switch mesa over to use llvm80 instead of llvm60. Make it use the global LLVM_DEFAULT instead of deciding for ourself which llvm version to use. [1] Fix build of lang/beginet [1] Add patch from upstream to fix build of devel/libclc. The patch is taken from the git mirror of devel/libclc rather than the SVN repo, for convenience. Add a patch from mesa upstream preventing certain error messages when using amdgpu [2] Add a notice to bsd.default-versions.mk asking that the graphics team be informed before the llvm version is changed. Enable llvm and gallium on MIPS. As far as I can tell, this used to be the default before this change. Bump portrevisions since dependencies changed. PR: 230789 [1], [2] Submitted by: jbeich [1], tobik [2] Obtained from: FreeBSD Graphics Team development repo https://github.com/FreeBSDDesktop/freebsd-ports/commits/feature/mesa-llvm80 Sponsored by: B3 Init (zeising) Changes: head/Mk/bsd.default-versions.mk head/devel/libclc/Makefile head/devel/libclc/files/patch-62a9191.c head/graphics/libosmesa/Makefile head/graphics/mesa-dri/Makefile head/graphics/mesa-dri/Makefile.common head/graphics/mesa-dri/files/patch-9cab8cc.c head/graphics/mesa-libs/Makefile head/lang/beignet/Makefile head/lang/beignet/files/patch-llvm8 head/lang/clover/Makefile
Committed. Leaving this open for a bit in case there's fallout.
Just tested build with python 3.6: --- graphics/mesa-dri/Makefile.common.orig +++ graphics/mesa-dri/Makefile.common @@ -45,7 +45,7 @@ .endif USES+= compiler:c++11-lib bison gettext-tools gmake libtool \ - localbase pathfix pkgconfig python:2.7,build shebangfix tar:xz + localbase pathfix pkgconfig python:3.6,build shebangfix tar:xz USE_LDCONFIG= yes GNU_CONFIGURE= yes Build without errors. May be time to move to new version of the python?…
One issue: if llvm80 was not built with the BE_STANDARD option (e.g., BE_FREEBSD instead), then you get this error in graphics/mesa-dri at configure time: . . checking for XLIB_RANDR... yes checking for EXPAT... yes checking for RADEON... yes checking for RADEON... yes checking for I915... yes checking for AMDGPU... yes configure: error: LLVM target 'amdgpu' not enabled in your LLVM build. Required by radv. ===> Script "configure" failed unexpectedly. The fix is to build llvm80 with BE_STANDARD of course, but the failure is a bit ungraceful. If nothing else, it's documented here for the unaware to find.
I can add amdgpu to BE_FREEBSD if this is likely to be an issue.
(In reply to John Hein from comment #24) > One issue: if llvm80 was not built with the BE_STANDARD option (e.g., > BE_FREEBSD instead), then you get this error in graphics/mesa-dri at > configure time: > [snip error > > The fix is to build llvm80 with BE_STANDARD of course, but the failure is a > bit ungraceful. If nothing else, it's documented here for the unaware to > find. Interesting. I have to think for a second if it's possible to detect if this is enabled in llvm/clang before starting the build. Otherwise, perhaps enabling it for BE_FREEBSD, as brooks@ suggest in comment #25 might be the best option.
FYI, 'llvm-config80 --targets-built' is how mesa-dri's configure tries to detect if AMDGPU is supported.
Any change in the status of this? I really hate having to build all the standard backends. Just building with BE_FREEBSD takes a very long time. (No, I have not compared.)
(In reply to rkoberman from comment #28) > Any change in the status of this? I really hate having to build all the > standard backends. Just building with BE_FREEBSD takes a very long time. > (No, I have not compared.) You probably have to talk to the llvm maintainer about always enabling the AMDGPU backend. Trying to get mesa to only build amdgpu if AMDGPU is available in llvm will probably be tricky, although I am willing to consider it if you can help out with providing patches.
Is AMDGPU the only backed used by mesa?
(In reply to Brooks Davis from comment #30) > Is AMDGPU the only backed used by mesa? See https://gitlab.freedesktop.org/mesa/mesa/blob/mesa-18.3.2/meson.build#L1173-1187 For one, with_gallium_opencl is currently part of lang/clover.
A commit references this bug: Author: brooks Date: Wed Aug 7 19:53:27 UTC 2019 New revision: 508349 URL: https://svnweb.freebsd.org/changeset/ports/508349 Log: Assorted minor improvements: - Add a build conflict for commonmark-cmark-* when DOCS are enabled. This prevents a failure later on in the build. [0] - Add a new option BE_AMDGPU which can be used to enable the AMDGPU backed used by mesa when BE_NATIVE or BE_FREEBSD is set. Enable this option by default to limit later surprises. [1] - Use LLVM_ENABLE_Z3_SOLVER instead of the now removed CLANG_ANALYZER_ENABLE_Z3_SOLVER to disable Z3 discovery and linkage. PR: 239636 [0], 230789 [1] Changes: head/devel/llvm90/Makefile
(In reply to VVD from comment #23) --- graphics/mesa-dri/Makefile.common.orig +++ graphics/mesa-dri/Makefile.common @@ -45,7 +45,7 @@ .endif USES+= compiler:c++11-lib bison gettext-tools gmake libtool \ - localbase pathfix pkgconfig python:2.7,build shebangfix tar:xz + localbase pathfix pkgconfig python:build shebangfix tar:xz USE_LDCONFIG= yes GNU_CONFIGURE= yes Work fine with python 3.6 and 3.7 on 12.0 amd64 and i386.
(In reply to VVD from comment #33) Can you open a separate bug to track this?
(In reply to Niclas Zeising from comment #34) Ok: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239939
A commit references this bug: Author: brooks Date: Fri Sep 6 11:04:45 UTC 2019 New revision: 511300 URL: https://svnweb.freebsd.org/changeset/ports/511300 Log: Assorted build improvements: - Add a build conflict for commonmark-cmark-* when DOCS are enabled. This prevents a failure later on in the build. [0] - Add a new option BE_AMDGPU which can be used to enable the AMDGPU backed used by mesa when BE_NATIVE or BE_FREEBSD is set. Enable this option by default to limit later surprises. [1] - New option PYCLANG to add python binding for clang. [2] PR: 239636 [0], 230789 [1], 239990 [2] Submitted by: chardon.frederic@gmail.com [2] Sponsored by: DARPA, AFRL Changes: head/devel/llvm80/Makefile head/devel/llvm80/pkg-plist