New Activity Around Adapting ACO Compiler Back-End For RadeonSI

[phoronix]

Phoronix: New Activity Around Adapting ACO Compiler Back-End For RadeonSI

As part of the work on the Mesa Radeon Vulkan "RADV" driver, Valve engineers developed the "ACO" compiler back-end that is now used by default for RADV and has shown to deliver better performance at least for RADV than using AMD's official AMDGPU LLVM shader compiler back-end. There has long been talk about adding ACO support to RadeonSI while in recent weeks there has been new code activity on that front...

https://www.phoronix.com/scan.php?page=news_item&px=ACO-Refactor-Binary-Build

[ms178]

Purely a guess, but another motivating factor for this transition could be the work needed to adapt to changes for LLVM-15. With less places where LLVM is used inside Mesa, the less work needs to be spent on that front. At least it appears to me that the conclusion was that the development time is better spend on integrating ACO inside RadeonSI than on the RadeonSI/LLVM-15 adaptation work. But how much effort can be saved by this is beyond my comprehension.

The timeline seems to be challenging though, as LLVM-15 / Mesa 22.2 compatibility was stated to be desireable by September.

[MrCooper]

Purely a guess, but another motivating factor for this transition could be the work needed to adapt to changes for LLVM-15. With less places where LLVM is used inside Mesa, the less work needs to be spent on that front. At least it appears to me that the conclusion was that the development time is better spend on integrating ACO inside RadeonSI than on the RadeonSI/LLVM-15 adaptation work. But how much effort can be saved by this is beyond my comprehension.

The timeline seems to be challenging though, as LLVM-15 / Mesa 22.2 compatibility was stated to be desireable by September.

Yeah, no way ACO is replacing LLVM for radeonsi in time for the Fedora 37 release. Even if there was, it wouldn't solve that issue for llvmpipe and the Gallium draw module anyway.

I think the main motivation for ACO with radeonsi is Rusticl.

[JacekJagosz]

I simply think the motivation among Valve developers is that they already have a light and fast compiler, so why not used it for OpenGL too?
Also I think it might be useful if they wanted to build a stripped-down version of Mesa, with only AMD Graphics support and only one compiler. But I still find that unlikely.
So I really think the only motivation is performance.

[ms178]

I simply think the motivation among Valve developers is that they already have a light and fast compiler, so why not used it for OpenGL too?
Also I think it might be useful if they wanted to build a stripped-down version of Mesa, with only AMD Graphics support and only one compiler. But I still find that unlikely.
So I really think the only motivation is performance.

While that's the primary reason to get ACO to work with RadeonSI at all, as it wouldn't make sense to put effort into it if there were no benefits, there must be some other reason to get it moving as ACO has been around for a while and it hasn't been a top priority to get it wired up inside RadeonSI. Maybe ACO is considered mature enough or the devs have more time to spend to work on that front, maybe it is the reason I gave above with LLVM-15's changes which means to save some work they'd need to do otherwise, maybe there are several other good reasons we haven't talked about yet or several of these factors coming together?

[user1]

While that's the primary reason to get ACO to work with RadeonSI at all, as it wouldn't make sense to put effort into it if there were no benefits, there must be some other reason to get it moving as ACO has been around for a while and it hasn't been a top priority to get it wired up inside RadeonSI. Maybe ACO is considered mature enough or the devs have more time to spend to work on that front, maybe it is the reason I gave above with LLVM-15's changes which means to save some work they'd need to do otherwise, maybe there are several other good reasons we haven't talked about yet or several of these factors coming together?

Another benefit of ACO I've seen mentioned is simply that it's part of Mesa unlike LLVM, so you have some benefits like faster bug fixes. LLVM's release pace is slower than Mesa's, so if there's a bug in the compiler, you'll have to wait longer for it to get fixed. I guess cases like these also affect the development of the driver itself.

[Quackdoc]

I hope this clover aco stuff can be put towards rusticl working on amd, I would be quite a happy dude if so

[mazumoto]

Mhhh, it also says "clover" in the git branch name. Might be that OpenCL is the motivation behind it. It'd be nice to get a nicely working, easily distributable OpenCL solution inside mesa, so I hope MrCooper is right pointing to rusticl ...

Though I don't have much faith in OpenCL competing against CUDA and whatever AMD and intel make up on that front ... but you have to start somewhere.

[Quackdoc]

Mhhh, it also says "clover" in the git branch name. Might be that OpenCL is the motivation behind it. It'd be nice to get a nicely working, easily distributable OpenCL solution inside mesa, so I hope MrCooper is right pointing to rusticl ...

Though I don't have much faith in OpenCL competing against CUDA and whatever AMD and intel make up on that front ... but you have to start somewhere.

IIRC I was told that OCL and CUDA have different targets anyways, OCL to me has always felt like an API being pushed far beyond what it was intended to do. I think vulkan compute can take up a good chunk of CUDA target too, but in the end, we need something like ROCM-HIP/oneAPI to properly compete against cuda