LLVM is a huge beast. Of the 353 ports installed on my VM (running X11), llvm80 amounts to 45% of the total disk space used in /usr/local - over 800M. However I don't need it as I don't run any accelerated X. Can we add a (close to) trivial option that avoids RUN_DEPENDS and BUILD_DEPENDS on devel/llvm80 and just does CONFIGURE_ARGS+=--disable-llvm? That would also dramatically reduce compile time for this simplified case.
What features does llvm provide/enable? Is it *only* for 'accelerated' X ?
(In reply to Kubilay Kocak from comment #1) LLVM is required only for: GALLIUM_DRIVERS=SRWAST GALLIUM_DRIVERS=R300 GALLIUM_DRIVERS=RADEONSI VULKAN_DRIVERS=RADEON It's not needed for anything else. Broadly speaking, if you don't have a Radeon card or don't need acceleration, it's just bloat. (Besides I'm kind of puzzled why we don't simply use the base system's LLVM which for 12-STABLE and above is already LLVM80. Maybe just my lack of understanding.)
(In reply to Helge Oldach from comment #2) > It's not needed for anything else. Broadly speaking, if you don't have a > Radeon card or don't need acceleration, it's just bloat. > LLVM is actually needed for *non-accelerated* graphics, particularly with LLVMpipe. Many desktop environments/toolkits expect some sort of acceleration anymore (even if you don't think it does), and LLVMpipe and the like provide that software rendering. > (Besides I'm kind of puzzled why we don't simply use the base system's LLVM > which for 12-STABLE and above is already LLVM80. Maybe just my lack of > understanding.) -RELEASEs don't change the toolchain originally available upon release, so for 12.0-RELEASE, LLVM is fixed at 6.0.0. Besides, the base system LLVM is built as static libraries and binaries, and some LLVM components not needed/useful to build the base system are stripped away. Think, the base system uses a compiler toolchain *based on LLVM*, in the same way that the base system GCC isn't vanilla either. I won't hesitate to post this wiki page again: https://wiki.freebsd.org/WhyDoIHaveToBuildLLVMWhenIAlreadyHaveClangInstalled
Hi! Adding more options and complexity to mesa is not desirable. It is a big enough beast as is. Furthermore, as Charlie Li points out in Comment #3, llvm is used for non-accelerated graphics as well. The reason we use llvm from ports is two fold. First off, it gives us one unified version of llvm+mesa across all of FreeBSD, which lessens the diversity and makes the port easier to test and maintain. Secondly, and perhaps more importantly, as already been pointed out, the libraries that mesa needs are not provided by base llvm. We understand that this can be resource intensive for some people, but for the reasons listed above, there is no good way around it. Regards Niclas FreeBSD Graphics Team
(In reply to Charlie Li from comment #3) > > It's not needed for anything else. Broadly speaking, if you don't have a > > Radeon card or don't need acceleration, it's just bloat. > > > > LLVM is actually needed for *non-accelerated* graphics, particularly with > LLVMpipe. Not quite, it's needed with SWRAST only. If SWRAST is not compiled in, LLVM is obsolete. As described above.
(In reply to Helge Oldach from comment #5) It's also needed by radeonsi and it's used if you're a guest in virtual machines.
(In reply to Niclas Zeising from comment #4) > Adding more options and complexity to mesa is not desirable. Actually this option was in place until a few days ago! It was called MESA_LLVM_VER. Setting this Makefile variable to an empty string had effectively suppressed any LLVM dependency. Please cross-check with the previous Makefile and Makefile.common before the recent update. And yes, Mesa has indeed been working fine in the non accelerated case. I understand the background of the recent build unification for other platforms, however for the common amd64 and i386 cases this took away a nice feature. > The reason we use llvm from ports is two fold. First off, it gives us > one unified version of llvm+mesa across all of FreeBSD, which lessens > the diversity and makes the port easier to test and maintain. Secondly, > and perhaps more importantly, as already been pointed out, the libraries > that mesa needs are not provided by base llvm. Story is clear, but the price is extremely high. In my case it has almost doubled the disk size of port installation. Also compilation is a burden - LLVM takes hours to build on less capable platforms - it's an order of magnitude more than just Mesa alone! Furthermore this price is paid even when it's not needed - for example in the not too unusual case of a stock Intel CPU with built-in graphics. > We understand that this can be resource intensive for some people It's not the people, it basically disallows using 3d graphics on less capable platforms, and even on decent platforms it's a burden. This really should be made more lightweight.
(In reply to Johannes Lundberg from comment #6) > It's also needed by radeonsi True. I had mentioned the four cases above. > it's used if you're a guest in virtual machines. I can't follow. Virtualbox here. Mesa / X11 running fine without LLVM. Can you explain what I am missing?
(In reply to Helge Oldach from comment #8) LLVMPipe is used in the new DRM based graphics drivers for virtual machines. They're still WIP but coming soon and will improve performance and usability of FreeBSD in VMs. As for asking for special treatment, there's nothing stopping you from keeping your own branch or set of local patches. We all do for stuff we don't want to/shouldn't upstream. What should be done on the other hand, is have poudriere or ports have the ability to install build dependencies (like LLVM) from pre-built packages instead of building from source.
(In reply to Helge Oldach from comment #7) > (In reply to Niclas Zeising from comment #4) > > Adding more options and complexity to mesa is not desirable. > > Actually this option was in place until a few days ago! It was called > MESA_LLVM_VER. Setting this Makefile variable to an empty string had > effectively suppressed any LLVM dependency. Please cross-check with the > previous Makefile and Makefile.common before the recent update. And yes, > Mesa has indeed been working fine in the non accelerated case. This was never supported, and the fact that it did work was an accident. > > I understand the background of the recent build unification for other > platforms, however for the common amd64 and i386 cases this took away a nice > feature. > > > The reason we use llvm from ports is two fold. First off, it gives us > > one unified version of llvm+mesa across all of FreeBSD, which lessens > > the diversity and makes the port easier to test and maintain. Secondly, > > and perhaps more importantly, as already been pointed out, the libraries > > that mesa needs are not provided by base llvm. > > Story is clear, but the price is extremely high. In my case it has almost > doubled the disk size of port installation. Also compilation is a burden - > LLVM takes hours to build on less capable platforms - it's an order of > magnitude more than just Mesa alone! > > Furthermore this price is paid even when it's not needed - for example in > the not too unusual case of a stock Intel CPU with built-in graphics. > > > We understand that this can be resource intensive for some people > > It's not the people, it basically disallows using 3d graphics on less > capable platforms, and even on decent platforms it's a burden. This really > should be made more lightweight. It is possible to install both llvm and mesa from pkg, they work quite well, and you don't have to build everything yourself. Changing the mesa ports to make llvm optional, even if possible, makes these already quite complex ports even more complex, and adds further use cases to test for. All this requires more man power. Regards Niclas Zeising FreeBSD Graphics Team
(In reply to Johannes Lundberg from comment #9) > What should be done on the other hand, is have poudriere or ports > have the ability to install build dependencies (like LLVM) from pre-built > packages instead of building from source. For poudriere see https://github.com/freebsd/poudriere/issues/319 For ports someone should teach USE_PACKAGE_DEPENDS/USE_PACKAGE_DEPENDS_ONLY to try "pkg install", not just "pkg add".
Created attachment 205492 [details] patch adding a LLVM configure knob
(In reply to Niclas Zeising from comment #10) > Changing the mesa ports to make llvm optional, even if possible, makes these > already quite complex ports even more complex, and adds further use cases to > test for. All this requires more man power. Glad to help out with a quick patch. Note this actually simplifies the --enable-llvm/--disable-llvm logic.
(In reply to Helge Oldach from comment #13) > (In reply to Niclas Zeising from comment #10) > > Changing the mesa ports to make llvm optional, even if possible, makes these > already quite complex ports even more complex, and adds further use cases to > test for. All this requires more man power. > > Glad to help out with a quick patch. Note this actually simplifies the > --enable-llvm/--disable-llvm logic. Hi! Thank you for the patch. Unfortunately, we won't be able to use it. LLVM is a hard dependency for the radeonsi and amdgpu drivers. It's also required for llvmpipe, which is the default software renderer and used by all desktops without a GPU. Working through all the dependencies for a mesa port without LLVM would be quite complex. Graphics is a complex area and to provide the best possible experience for the vast majority of our users, we want to ensure all the options we offer work. Making LLVM optional would create a testing matrix that is beyond our ability to even spot check, let alone ensure works for the majority of all our users. It would be an ongoing burden to the team with each new mesa release, as which drivers use what bits of LLVM are constantly changing. Taking all these factors into account, we're simple unable to support making this optional at this time. We do not have the manpower for it. Of course, you are welcome to continue using your patch, for as long as it works, but you'll have to work out any issues that are caused by it. Regards Niclas Zeising FreeBSD Graphics Team