Re: Avoiding llvm from ports on rpi4
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On Feb 22, 2025, at 17:12, Charlie Li <[email protected]> wrote: > Mark Millard wrote: >> On Feb 22, 2025, at 11:08, Nuno Teixeira <[email protected]> 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