Check out our Monthly Survey Page to see what our users are running.
Something cool, you can now use ACO for RadeonSI OpenGL in Mesa 24
Grogan Nov 2, 2023
I know the focus of this site isn't neckbeardery, but this is the kind of stuff I'm interested in, and I'm sure it's going to be of interest to someone else too.

Since Mesa branched to 24.0.0 in git-master, the ACO shader compiler is now feature complete to use for RadeonSI OpenGL instead of the LLVM back end.

It may seem like a problem that didn't need solving, as OpenGL shaders aren't like Vulkan shaders, but newer OpenGL specs support more features now and I'd rather have a more efficient compiler.

This can be tested with the following environment variable (but defaults to that if built without LLVM)

AMD_DEBUG=useaco

However, what interests me more than that, is the ability to ditch the dependency on LLVM! It just burns my ass, that upgrading my LLVM toolchain breaks my graphics driver libraries. At the very least I have to have a mesa build ready to go, but it also needs caution because it's more than just a compiler suite, it's the back end for mesa. I don't wait for Arch to curate things either, they are often months behind my toolchain upgrades because of blocking issues with some stupid package.

So this frees me up.

It's not bad to do, but it does involve ditching some things in Mesa that I never use anyway. I long ago stopped building drivers I don't use (i.e. why build intel or nouveau... I'll be having those on the 21st of Never)

Firstly, these are the drivers that can be built like this:

-D gallium-drivers=radeonsi,swrast,zink
-D vulkan-drivers=amd


swrast for OpenGL can still be built, because it will fall back to legacy rather than llvmpipe if no LLVM.
swrast for Vulkan can't, because that uses lavapipe (llvmpipe)

OSMesa can still be built (off screen rendering), no need to disable that

-D gallium-nine=false

The gallium nine state tracker needs LLVM, so Nine can't be built. That's the old D3D9 support, I don't use WineD3D for anything anymore, I use DXVK (D9VK) now for DirectX 9 games.

-D gallium-omx=disabled

The OpenMax state tracker needs LLVM too, so OMX/Bellagio can't be built. I don't have any software that uses openmax, and to be honest I'd never even heard of it before I started compiling Mesa in Arch.

-D gallium-opencl=disabled

Gallium opencl (uses LLVM's libclc) can't be built. That might be a show stopper for some, but I don't use it. To me it's only ever been good for causing build failures, as it's super fussy on SPIRV headers and tools.

Finally, the business end of the change:

-D llvm=disabled

My Mesa is LLVM free :-)

I have tried every single OpenGL thing that I have and have not seen a single problem caused by this change. EGL in Firefox is fine too, no change to WebGL benchmark scores or anything (slightly better if anything, but didn't do enough repetitions to validate that). I've been using Mesa in this configuration since it branched on Oct. 26, anyway.

Last edited by Grogan on 2 November 2023 at 12:37 am UTC
Shmerl Nov 2, 2023
how does zink work without llvm? Or it was never using it?

And what about gallium-va? Does it need llvm too?

Last edited by Shmerl on 2 November 2023 at 1:36 am UTC
Grogan Nov 2, 2023
It was never using llvm, because it uses Vulkan shaders, not OpenGL (well, since RADV switched to ACO)

I built vaapi support, I don't use it, but it didn't complain

meson setup mesa _build \
       -D buildtype=release \
       -D b_ndebug=true \
       -D b_lto=false \
       --wrap-mode=nofallback \
       -D prefix=/usr \
       -D sysconfdir=/etc \
       -D platforms=x11,wayland \
       -D gallium-drivers=radeonsi,swrast,zink \
       -D vulkan-drivers=amd \
       -D vulkan-layers=device-select,overlay \
       -D dri3=enabled \
       -D egl=enabled \
       -D gallium-extra-hud=true \
       -D gallium-nine=false \
       -D gallium-omx=disabled \
       -D gallium-va=enabled \
       -D gallium-vdpau=enabled \
       -D gbm=enabled \
       -D gles1=disabled \
       -D gles2=enabled \
       -D glvnd=true \
       -D glx=dri \
       -D libunwind=disabled \
       -D llvm=disabled \
       -D lmsensors=enabled \
       -D osmesa=true \
       -D shared-glapi=enabled \
       -D gallium-opencl=disabled \
       -D valgrind=disabled \
       -D zstd=enabled \
       -D microsoft-clc=disabled \
       -D video-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc \
       -D tools=[]


Last edited by Grogan on 2 November 2023 at 1:44 am UTC
Shmerl Nov 2, 2023
I'll give it a try. What is -D zstd used for?
Shmerl Nov 2, 2023
I agree that getting rid of llvm in the build simplifies things a lot. No need to bother with llvm breaking the build too which happens often.

I'll probably update my Mesa build script to make llvm optional or remove it altogether from there:

https://gist.github.com/shmerl/f4e5f76871239158cf083e37c5da56f4

Last edited by Shmerl on 2 November 2023 at 1:52 am UTC
Grogan Nov 2, 2023
I just did a quick test with VLC on Arch... I changed the video acceleration to VAAPI and it works (it was on auto before, not sure what it was using)
Grogan Nov 2, 2023
I'll give it a try. What is -D zstd used for?

It enables zstd compression. Got to realize that alot of those settings are unnecessary (library would be auto detected), they are carry-overs from the original PKGBUILD I hacked up, which is why you may not have seen it before in there.

Last edited by Grogan on 2 November 2023 at 2:03 am UTC
Shmerl Nov 2, 2023
It enables zstd compression. Got to realize that alot of those settings are unnecessary (library would be auto detected), they are carry-overs from the original PKGBUILD I hacked up, which is why you may not have seen it before in there.

Yeah, I mean I wonder where zstd compression is actually used there? I can look around.

I generally take configuration settings from Debian repos build and simplify it to only have some common set of features for AMD, so similar approach to yours.

Last edited by Shmerl on 2 November 2023 at 2:23 am UTC
StoneColdSpider Nov 2, 2023
I saw "ACO" and got really excited....... Then I came here and found out it was a different ACO to the one I was thinking of

My disappointment is immeasurable...... And my day is ruined
Grogan Nov 2, 2023
how does zink work without llvm? Or it was never using it?

Zink itself doesn't, but the back end it seems to be choosing might (e.g. llvmpipe vulkan)

So it builds just fine, but I can't seem to get it to work now. I haven't tried it in a long time, so I don't know if it worked before.

$ MESA_LOADER_DRIVER_OVERRIDE=zink glxgears
DRI3 not available
failed to load driver: zink
Error: couldn't get an RGB, Double-buffered visual


I'm going to have to do some more testing here before I can say for sure.
Grogan Nov 2, 2023
Yeah, I mean I wonder where zstd compression is actually used there? I can look around.

Sorry, shader cache. Zstd instead of zlib for the shader cache files. I guess it's better :-)

I use the fossilize (.foz) database format though with MESA_DISK_CACHE_SINGLE_FILE=1 (still not the default, I'm a bit surprised by that) so I don't know if that zstd thing comes into play for me.
Grogan Nov 2, 2023
Zink stuff

I just did a quick flip back to my last mesa build before the change (still 23.3.0+spaghetti in versioning) and zink still fails with the same error. I actually remember it from before, but shrugged and thought it would get "fixed" eventually. Zink is just a curiosity to me at this time (I really don't have a problem with OpenGL, not good programming anyway) awaiting the day when even proper OpenGL can get better performance through the Zink driver with Vulkan.

Since I cannot believe that it could be "broken" for all that time, I must have a misconfiguration somewhere (or need additional configuration, somewhere). I don't think it's the LLVM though.

Now I have to figure out why Zink isn't working lol

Last edited by Grogan on 2 November 2023 at 3:45 am UTC
Shmerl Nov 2, 2023
I tested zink (over radv) a while ago and it was working fine.

Here is a recent build test (llvm is enabled for the build):

![](https://i.imgur.com/vqhaPMB.png)
Grogan Nov 2, 2023
I saw "ACO" and got really excited....... Then I came here and found out it was a different ACO to the one I was thinking of Automobile_Club_de_l'Ouest

Well, I suppose it's somewhat related, I'm always trying to increase speed and get better times and scores.

Damnit, it was the best tie-in that I could come up with, anyway :-)
Grogan Nov 2, 2023
I tested zink (over radv) a while ago and it was working fine.

Early on, when I heard it was making progress I tested it and it worked for glxgears, glxinfo and I even played Tomb Raider (2013), the Feral Linux port which still worked at that time. It was horrible (not playable) but I could still move and what was important was that everything looked like it was rendering correctly.

Some time later, and currently, I get that DRI3 error above. I kept Zink in my Mesa builds but never got around to trying it again until today. I booted to my from-scratch system and get the same error there too now. In both cases, DRI3 is certainly available, the extension is loaded.

A headscratcher for later.
Shmerl Nov 5, 2023
Just tried building Mesa without llvm.

Playing Black Geyser Couriers of Darkness didn't work. It crashes on startup. Plays OK when it's built with llvm. So it's not really ready in this sense.

May be I report it to the developers to take a look.

Last edited by Shmerl on 5 November 2023 at 5:57 am UTC
Grogan Nov 5, 2023
I still haven't found anything opengl that I have that doesn't work because of this change.

I also still haven't found what I'm missing for Zink to work yet either. It doesn't make sense. Even with a full build of Mesa it doesn't work for me, it's like it's not dispatching correctly or something. I tried a build without glvnd too (which isn't so easy anymore, it uses older sonames than libglvnd now when you do that). I've only got one Vulkan (RADV) and I made sure there are no old .icd files in there. Zink doesn't have to work, it just bugs me when something doesn't.

Last edited by Grogan on 5 November 2023 at 11:04 am UTC
Grogan Nov 8, 2023
Heheh... something else I noticed. Without llvmpipe, using xvfb with the GLX extension (e.g. profiling firefox for PGO) it tries to use zink first, fails (because zink doesn't work for me), and falls back to my legacy swrast driver. I could pass LIBGL_ALWAYS_SOFTWARE=true in the command to shut that up next time (harmless, and its use is just so the application will run off screen) but it feels like this zink problem I have is taunting me

However, today I have realized the fruits of my labour, as I was able to rip out and upgrade LLVM without affecting my X session and just carry on with all the rest of my builds after that with no interruption. I just built a mesa yesterday and don't have to do it again because of this either. So I have been successful at solving the problem I set out to, without sacrificing anything I care about.

Last edited by Grogan on 8 November 2023 at 2:59 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register