Date: Sun, 23 Feb 2025 20:08:15 -0800 From: Mark Millard <marklmi@yahoo.com> To: Nuno Teixeira <eduardo@freebsd.org> Cc: Charlie Li <vishwin@freebsd.org>, FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: Re: Avoiding llvm from ports on rpi4 Message-ID: <3377C812-42B3-41CA-A07D-3153E3FAB2DB@yahoo.com> In-Reply-To: <CAFDf7U%2BE%2Bk=EmQf5c0GNQcM=0Po6SfH%2BrHoyVqws3j70k3H%2BDA@mail.gmail.com> References: <CAFDf7UKmCNR8NUMz5xk-MAw9nruimV1C86MJzk%2Byo1MVqfXXrg@mail.gmail.com> <41144AE6-2C81-4762-84C7-57CEB81F448C@yahoo.com> <CAFDf7U%2B8V_QUM3z0z%2B5afNg3b-sRiVyafue%2BWnZEXtxncgP2TQ@mail.gmail.com> <43C70901-A871-4044-9353-89A82DB2F2E6@yahoo.com> <722e1fd5-f969-4856-b8af-84046ddd896a@freebsd.org> <5B72C2FD-1C24-4B81-B6CB-F6993ED136B5@yahoo.com> <CAFDf7U%2BE%2Bk=EmQf5c0GNQcM=0Po6SfH%2BrHoyVqws3j70k3H%2BDA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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.comhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3377C812-42B3-41CA-A07D-3153E3FAB2DB>