Re: Avoiding llvm from ports on rpi4

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])

==> 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.

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