Re: Avoiding llvm from ports on rpi4

Hello all,

Well this was a good exercise of better understanding about clang and llvm.
As I understand better how things works now, thats make not much sense to
hack
mesa-{dri,libs} at least for my use case of x11/i3/firefox test.

I will try other ways of dealing with port llvm to reduce build time by
removing
options not needed for my use case.

Build pkgs on a second system with more resources makes all sense too.

Thanks all and sorry for the noise :)

Cheers,

Mark Millard <marklmi@yahoo.com> escreveu (segunda, 24/02/2025 à(s) 04:08):

> On Feb 23, 2025, at 17:51, Nuno Teixeira <eduardo@freebsd.org> wrote:
>
> > Hello,
> >
> > OPTIONS ZSTD+X11+WAYLAND ON and rest *OFF*
> >
> > ==> Original port (llvm)
> >
> > [1] ZSTD+X11+WAYLAND
> > meson.build:456:3: ERROR: Feature egl cannot be enabled: EGL requires
> DRI, Haiku, Windows or Android
> >
> > **[2] ZSTD+X11+WAYLAND+swrast
> > OK
> >
> > [3] ZSTD+X11+WAYLAND+swrast_vk
> > meson.build:328:2: ERROR: Problem encountered: swrast vulkan requires
> gallium swrast
> >
> > [4] ZSTD+X11+WAYLAND+swrast +swrast_vk
> > OK (same performance as [2])
>
> swrast is for OpenGL programs using the OpenGL API.
> swrast_vk is for Vulkan programs using the Vulkan API.
>
> Having both might mean ending up with support for
> both types of programs (at least at this level).
>
> I'll note that replacing swrast and/ior swrast_vk
> with the modern LLVMpipe puts LLVM back into the
> build requirements for this level of material.
>
> > ==> Port patched (no llvm):
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238906#c24
> >
> > graphics/mesa-dri/Makefile
> > -USES+=         llvm:lib,noexport
> >
> > graphics/mesa-dri/Makefile.common
> > -MESON_ARGS+=   -Dllvm=enabled \
> > +MESON_ARGS+=   -Dllvm=disabled \
> >
> > mesa-libs/Makefile
> > -USES=          llvm:noexport
> >
> > **[2] ZSTD+X11+WAYLAND+swrast
> > OK
> >
> > main-n275605-dbbcbaae1d7b arm64 (rpi4):
> >
> >
> https://people.freebsd.org/~eduardo/logs/mesa-nollvm/mesa-dri-24.1.7_4.log
> >
> https://people.freebsd.org/~eduardo/logs/mesa-nollvm/mesa-libs-24.1.7_1.log
> >
> > ** The minimum software accel for a working graphics
> > -------
> >
> > Next test will be build firefox with base compiler to achieve
> x11+i3+firefox collection without ports llvm.
>
> That means needing to have rust built and in use during the build.
> Having rust involves having LLVM as rust uses LLVM infrastructure.
> rust's port has an option for if rust uses an internel LLVM vs.
> if it uses a LLVM package. rust can be very picky about which
> vintage of LLVM is needed.
>
> If you are trying to build a somewhat normal desktop environment
> based on any of the major desktop software variants, then you are
> unlikely to avoid much to get it all in place. You could avoid
> support for targeting other CPU/core families. You likely can
> avoid support for targetting BE_AMDGPU. But, for
> firefox/thunderbird, you need WASI (and the packages that put
> WASI to use) and you need clang/clang++ (so: a substantial LLVM
> package overall), and you need rust (that you might be able to
> resuse the LLVM for instead of building a rust-internal one as
> well).
>
> The (un?)reasonableness of your activity is very dependent on
> what your overall goals require. Referencing the likes of
> firefox needing to be involved likely suggests painful time
> frames for using a RPi4 as the builder machine. Even more so
> if keeping up with security updates is part of the requirements.
>
> May be having 2 systems, with one being the builder that can be
> building while the other system uses the prior build materials?
>
> > Thanks,
> >
> > Mark Millard <marklmi@yahoo.com> escreveu (domingo, 23/02/2025 à(s)
> 03:04):
> > On Feb 22, 2025, at 17:12, Charlie Li <vishwin@freebsd.org> wrote:
> >
> > > Mark Millard wrote:
> > >> On Feb 22, 2025, at 11:08, Nuno Teixeira <eduardo@freebsd.org> wrote:
> > >>> Good point! I forgot to check options on port that are suitable for
> an rpi4!
> > >>> I was straight to hacking stuff :)
> > >>>
> > >>> As I don't know if any graphics acceleration is working on rpi4, I'm
> building with:
> > >>>
> > >>> _OPTIONS_READ=mesa-dri-24.1.7_4
> > >>> _FILE_COMPLETE_OPTIONS_LIST=ZSTD panfrost r300 r600 radeonsi swrast
> zink X11 WAYLAND radv swrast_vk
> > >>> OPTIONS_FILE_SET+=ZSTD
> > >>> OPTIONS_FILE_UNSET+=panfrost
> > >>> OPTIONS_FILE_UNSET+=r300
> > >>> OPTIONS_FILE_UNSET+=r600
> > >>> OPTIONS_FILE_UNSET+=radeonsi
> > >>> OPTIONS_FILE_UNSET+=swrast
> > >>> OPTIONS_FILE_UNSET+=zink
> > >>> OPTIONS_FILE_SET+=X11
> > >>> OPTIONS_FILE_SET+=WAYLAND
> > >>> OPTIONS_FILE_UNSET+=radv
> > >>> OPTIONS_FILE_UNSET+=swrast_vk
> > >>>
> > >>> While I'm really don't sure is panfrost os working or not...
> > >> Warning that I'm not literate in the subject area overall.
> > >> You have panfrost UNSET . You only have ZSTD, X11, and
> > >> WAYLAND SET.
> > >> It does not look to me like any of the lowercase names
> > >> apply to the RPi4's VideoCore VI hardware from Broadcom.
> > >> If true, then the UNSET's would seem to be right for
> > >> what is listed above. (Unsure for swrast and swrast_vk
> > >> which seem to be software-rasterization instead of
> > >> hardward tied. Also, zink is "OpenGL on top of Khronos’
> > >> Vulkan API" instead of being hardware.)
> > > swrast has been deprecated for over four years now, despite the code
> still existing in the current mesa source tree. Those options should have
> been removed from the port already. LLVMpipe and softpipe are the
> recommended software rasteriser drivers, in that order.
> >
> > I do not see a LLVMpipe option in any mesa-dri/Makefile* . May be the
> > swrast is there because the port does not yet support LLVMpipe and
> > removal of swrast would eliminate the category completely?
> >
> > >> https://docs.mesa3d.org/drivers/panfrost.html does not
> > >> indicate VideoCore VI hardware from Broadcom as a
> > >> "Model". So I expect that it does not apply to a
> > >> VideoCore VI context.
> > > Correct, panfrost has nothing to do with VideoCore.
> > >>> I will see if I get working graphics this way and check if llvm dep
> is gone.
> > >> So you are only intending to build: ZSTD, X11, WAYLAND ?
> > >> (But I do not see how that gets into potential acceleration
> > >> specific to the RPi4 VideoCore VI hardware from Broadcom.
> > >> So I'm confused relative to the wording.)
> > >> It does seem that the hardware names I recognize are UNSET
> > >> and do not seem likely to be involved with VideoCore VI
> > >> hardware. I'm assuming the video context is the native RPi4
> > >> context, and not any somehow added alternative video
> > >> hardware.
> > > For all VideoCore (Raspberry Pi) you need the VC4 mesa driver. For
> Raspberry Pi >= 4 you also need the V3D mesa driver.
> >
> > The mesa-dri port does not seem to have these as options
> > (yet?), per also the notes below.
> >
> > > The mesa drivers communicate directly with the Linux kernel
> counterparts, which we currently do not expose in, or even support
> building, drm-kmod for aarch64. Additional port options to expose building
> these mesa drivers do not make sense until the kernel bits are ported.
> > >
> >
> > It seems that Nuno's attempt to avoid large build times
> > for lack of any notable benefit is reasonable for the
> > current status of things for the RPi4 (and related), even
> > if swrast ends up involved in order to do that.
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

-- 
Nuno Teixeira
FreeBSD UNIX:  <eduardo@FreeBSD.org>   Web:  https://FreeBSD.org