Re: Avoiding llvm from ports on rpi4

Mark Millard wrote:
> 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?
> 
The mesa ports (tracking releases) need overhauling at least in this 
respect anyway to keep up with which drivers upstream and us actually 
support and actively maintain. LLVMpipe and softpipe have replaced 
swrast both in code and meson configure option. Note that softpipe is 
only a Gallium (OpenGL) driver, and the swrast Vulkan driver option is 
actually LLVMpipe, kinda confusing for those less familiar.
>>> 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.
> 
Because VC4 and V3D do not make sense to expose until the requisite 
drm-kmod bits are exposed and work.
>> 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.
> 
The question is more about deciding whether a long build time for one(!) 
port or poorly-running/performing graphical programs has the better 
quality-of-life trade-off.

-- 
Charlie Li
...nope, still don't have an exit line.

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZ7vtGQUDAAAAAAAKCRBnj5NgWEFcym1Q
AP9/vzY5Fql19hbaqVCkqV2pYdCLQKFwPkrFfJIeW8izXAEA3V0mrkmmPAkQsoYmw/xjLEi/STRA
IHGuyBSVILiQuwE=
=D28v
-----END PGP SIGNATURE-----