LLVM-less Mesa PKGBUILDs for Arch and its stepchildren
Posted: Tue Jul 23, 2024 7:13 pm
There's a significant change with respect to doing this, a Mesa built without LLVM now needs the softpipe driver for software rendering.
I build my Mesa without linking against LLVM libraries, using ACO for OpenGL shaders as well as Vulkan now. I have long hated that LLVM back end and the dependency on LLVM that breaks Mesa. I actually use LLVM toolchains, so I upgrade it.
This will prevent anything that needs LLVM from building. If enabled (implicitly or explicitly) it will fail to configure.
Anyway, it used to be possible to still build the swrast driver for software rendering without LLVM, but it seems they have removed that legacy path and swrast now requires llvmpipe, and turns it on if selected.
Starting with the branching to Mesa 24.3.0, they have now moved that legacy functionality to softpipe for indirect opengl instead of building the old swrast driver.
Mesa 24.2 (not yet released, but it's -rc1) and prior:
Mesa 24.3 (current git main):
For Vulkan, I only build the amd driver. I don't care about any other bollocks. I'll never be having anything else. There isn't any use for software rendered vulkan (lavapipe) on my system and as far as I'm concerned I don't have an Intel graphics adapter (I do, but it's all but disabled in BIOS such that only some ioports show up when probing)
The only reason I even care about opengl software rendering is for use with the xorg-server-xfvb (virtual framebuffer, headless) for profiling Firefox. It's program execution being profiled, not graphics rendering (and 800 FPS is way outside of reality anyway, which is about what I get for such tests). Also, some applications will just use software rendering on purpose for light usage, so it's necessary to have. I mean I don't particularly care about its performance.
It will complain, and fall back to softpipe but performance isn't a problem for the piddly things that will ever be software rendered on my system.
Software rendering displaying the frames (normal running X server) isn't much worse for that piddly test either:
Zink is 75 shit tonnes better than software rendering
(and no, evidently zink is not honouring sync to vblank)
Normal, hardware rendered opengl for comparison:
But look at that bollocks, that's certainly not true about radeonsi (gallium driver) or I wouldn't be here. I wonder if that's a symptom of not compiling against LLVM. I wouldn't ordinarily have cause to run glxgears to test MY opengl, just to troubleshoot those other things. I'm going to recompile my x servers and stuff after last night's plumbing, and I guess I'll take over mesa-utils too. I was just using the distro package for that because they are just demo/test utilities, most of the time unused.
Shit though... there's stuff I didn't even know we had in there now. glxgears ported to Vulkan
mesa-utils package binaries (Arch Linux)
I build my Mesa without linking against LLVM libraries, using ACO for OpenGL shaders as well as Vulkan now. I have long hated that LLVM back end and the dependency on LLVM that breaks Mesa. I actually use LLVM toolchains, so I upgrade it.
This will prevent anything that needs LLVM from building. If enabled (implicitly or explicitly) it will fail to configure.
Code: Select all
-D llvm=disabled
Starting with the branching to Mesa 24.3.0, they have now moved that legacy functionality to softpipe for indirect opengl instead of building the old swrast driver.
Mesa 24.2 (not yet released, but it's -rc1) and prior:
Code: Select all
-D gallium-drivers=radeonsi,zink,swrast
Code: Select all
-D gallium-drivers=radeonsi,zink,softpipe
Code: Select all
-D vulkan-drivers=amd
It will complain, and fall back to softpipe but performance isn't a problem for the piddly things that will ever be software rendered on my system.
Code: Select all
[grogan@nicetry ~]$ LIBGL_ALWAYS_SOFTWARE=true xvfb-run -s "-screen 0 1920x1080x24" glxgears
MESA-LOADER: failed to open swrast: driver not built!)
4299 frames in 5.0 seconds = 859.756 FPS
4399 frames in 5.0 seconds = 879.651 FPS
4319 frames in 5.0 seconds = 863.778 FPS
4315 frames in 5.0 seconds = 862.830 FPS
4283 frames in 5.0 seconds = 856.558 FPS
Code: Select all
[grogan@nicetry ~]$ LIBGL_ALWAYS_SOFTWARE=true glxgears
MESA-LOADER: failed to open swrast: driver not built!)
4067 frames in 5.0 seconds = 813.199 FPS
4083 frames in 5.0 seconds = 816.545 FPS
4155 frames in 5.0 seconds = 830.945 FPS
4124 frames in 5.0 seconds = 824.587 FPS
4133 frames in 5.0 seconds = 826.440 FPS
Code: Select all
[grogan@nicetry ~]$ MESA_LOADER_DRIVER_OVERRIDE=zink glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
106637 frames in 5.0 seconds = 21327.400 FPS
106664 frames in 5.0 seconds = 21332.650 FPS
106435 frames in 5.0 seconds = 21286.834 FPS
106757 frames in 5.0 seconds = 21351.330 FPS
106603 frames in 5.0 seconds = 21320.430 FPS
106961 frames in 5.0 seconds = 21392.055 FPS
104684 frames in 5.0 seconds = 20936.678 FPS
Normal, hardware rendered opengl for comparison:
Code: Select all
[grogan@nicetry ~]$ vblank_mode=0 glxgears
MESA-LOADER: failed to open radeonsi: driver not built!)
ATTENTION: default value of option vblank_mode overridden by environment.
216722 frames in 5.0 seconds = 43344.289 FPS
219615 frames in 5.0 seconds = 43922.816 FPS
219245 frames in 5.0 seconds = 43848.930 FPS
219911 frames in 5.0 seconds = 43982.008 FPS
219520 frames in 5.0 seconds = 43903.875 FPS
Shit though... there's stuff I didn't even know we had in there now. glxgears ported to Vulkan

mesa-utils package binaries (Arch Linux)
Code: Select all
usr/bin/eglgears_wayland
usr/bin/eglgears_x11
usr/bin/eglinfo
usr/bin/eglkms
usr/bin/egltri_wayland
usr/bin/egltri_x11
usr/bin/es2_info
usr/bin/es2gears_wayland
usr/bin/es2gears_x11
usr/bin/es2tri
usr/bin/glxgears
usr/bin/glxinfo
usr/bin/peglgears
usr/bin/vkgears
usr/bin/xeglgears
usr/bin/xeglthreads