RadeonSI Can Begin Using Valve's ACO Compiler For Certain Shaders

[Venemo]

It was sent in by someone with a Gmail address but was reviewed by Marek, so looks like its independent work which isn't being held back by AMD

Qiang actually works at AMD. He has been already doing a lot of good work on code refactoring to allow this. And there is still more work to be done to cover other shader stages besides PS.

[Eirikr1848]

Isn't the main difference between AMDVLK and AMDGPU-PRO Vulkan driver the shader compiler (foss LLVM vs proprietary one)? If so I think he might refer to that, hoping that ACO would improve radeonsi performance in a similar way.

Noticed your signature. You think the ACO compiler will eventually reach your r300 and r600 driver cards? And your gallium i915 and crocus/iris drivers?

that being said… what do you use now for OpenCL on the HD 5000 series?

[darkbasic]

Noticed your signature. You think the ACO compiler will eventually reach your r300 and r600 driver cards? And your gallium i915 and crocus/iris drivers?

that being said… what do you use now for OpenCL on the HD 5000 series?

Unfortunately my signature hasn't been updated in a long time (it doesn't even show up anymore for me). Nowadays I use an RX 570 and I'm pretty happy with it apart from the continuous DP MST regressions which make major new versions of the kernel often unbootable.

[Venemo]

You think the ACO compiler will eventually reach your r300 and r600 driver cards? And your gallium i915 and crocus/iris drivers?

ACO developer here. ACO is not a full compiler on its own but rather a NIR backend that is specific to GCN/RDNA. NIR is the compiler infrastructure shared between several drivers. ACO is very specific to GCN/RDNA and is not fit for any other architecture. That being said, many of the ideas and algorithms we use in ACO are also used in other backends too. The old r300 and r600 GPUs have a totally different architecture and they have their own compiler backend in Mesa (which is also based on NIR). Same can be said about Intel.

As an analogy, this question is like asking whether GCC's x86 backend will compile code for ARM. It won't because it is made for x86. But GCC also has different backends for different architectures which were designed for those.

I hope this helps explain it.

[smitty3268]

AFAIK the main problem with LLVM as graphics shader compiler is compilation times. The performance of the generated code is not too bad, albeit ACO seems to be better in this regard aswell most of the time. The main benefit of ACO however, is less hitching in games that compile shaders on-demand.

In addition to avoiding shader jank, the other big thing it does is remove LLVM as a dependency, which means that bugs in the driver for new hardware or new games being released can quickly and easily be fixed. It's somewhat of a nightmare to get that done in LLVM, release it, and then have distros update to use it. Which means you end up with a bunch of ugly workarounds in Mesa for old versions of LLVM, which can just be directly fixed in ACO instead.

I wouldn't expect many things to be particularly noticeably better in terms of performance. If they can just match the existing LLVM driver and be a couple percent faster in most things, that will be pretty good.

[kiffmet]

smitty3268 I haven't thought about the maintainability aspect and I totally agree.

[marlock]

regarding the maintainability aspect of llvm...

would it make sense to package some sort of mesa-llvm and point mesa there instead of the general-purpose copy of llvm so distros can update this faster while still keeping the other lib on a slower update pace if necessary

or is this a gibberish idea?

[smitty3268]

regarding the maintainability aspect of llvm...

would it make sense to package some sort of mesa-llvm and point mesa there instead of the general-purpose copy of llvm so distros can update this faster while still keeping the other lib on a slower update pace if necessary

or is this a gibberish idea?

It would definitely make sense to statically link llvm directly into mesa, but distros seem to be unwilling to do so. That wouldn't solve all problems, either.

A better solution would probably be to maintain a fork of llvm vendored within mesa, which is how pretty much every other user of llvm does it, but the AMD devs were unwilling to do that - probably too much effort on their end.

Luckily it doesn't seem to be a big deal anymore, now that most new apps are using Vulkan and the GL support in Mesa is fairly mature. But it used to be pretty painful while they were still bringing the drivers up.

[Venemo]

regarding the maintainability aspect of llvm...

would it make sense to package some sort of mesa-llvm and point mesa there instead of the general-purpose copy of llvm so distros can update this faster while still keeping the other lib on a slower update pace if necessary

or is this a gibberish idea?

Many distros are not willing to go for that and frown upon dependencies that bundle other libraries. Some distros even go as far as patch out these in favour of the library version that ships with the distro.

Also, we (Mesa devs) are not really interested in becoming LLVM maintainers. We would have preferred if LLVM could become a normal library that we can depend on that ships fixes in a timely manner, but unfortunately this isn't the case. It seems that GPU backends are a second-class citizen in upstream LLVM and they are not willing to release quick bugfixes for them.

And then even when LLVM does have a bugfix release, distros are usually reluctant to upgrade it in a timely manner too, so the end result is a pretty bad user experience where bugs are present on users' systems for months or more.