Radeon RADV Driver Merge Request Opened To Use ACO By Default

[CochainComplex]

Looking at this https://github.com/googlestadia, makes it pretty likely that they use llpc/llvm.

quick OT side note they are using 1000Hz timer and preemption https://github.com/googlestadia/kern.../kokoro/config

[mphuZ]

I said above why.

And I said above why this is not necessary. What's next?
Ideally, if AMDVLK is switched to ACO. This way everyone will benefit.

[shmerl]

And I said above why this is not necessary. What's next?

Nothing is necessary, Stadia itself probably isn't. It's about some options with better features (like radv/aco having better performance).

[agd5f]

And I said above why this is not necessary. What's next?
Ideally, if AMDVLK is switched to ACO. This way everyone will benefit.

Wouldn't everyone benefit if valve focused on llvm instead of aco?

[mphuZ]

Wouldn't everyone benefit if valve focused on llvm instead of aco?

Yes, it`s would. But Valve are known for their stubbornness...

[FireBurn]

Wouldn't everyone benefit if valve focused on llvm instead of aco?

Maybe if Valve carry on working on the graphics side AMD can spend their time getting open source OpenCL working across their card range

[MoJoRising]

Wouldn't everyone benefit if valve focused on llvm instead of aco?

They created ACO because they believe llvm is too bloated. The issue with LLVM is it's multi-target so there is a lot of compromise and bloat when it comes to targetting GPU.

Everyone would benefit more if everyone focused on making an open source compiler for GPUs (like ACO) and got away from using LLVM, which was designed for x86 RISC architecture and presents many problems for non-x86 RISC architectures. I'd prefer to see AMD and Google focus on RADV/ACO.

[MoJoRising]

And I said above why this is not necessary. What's next?
Ideally, if AMDVLK is switched to ACO. This way everyone will benefit.

How's that? ACO is a backend. I'd prefer AMD use RADV/ACO but if anything, they should use at least ditch llpc and use RADV/AMDGPU.

AMD could ensure compiler support for new archs day 1 no matter which way they go, than ACO wouldn't have to be almost a year behind in supporting new targets/subtargets.

[qarium]

The llvm backend is used in the ROCm compilers (HCC, HIP, OpenCL, OpenMP), and AFAIK our compute teams do most of the work adding llvm support for new HW.

As shmerl mentioned llvm is also the only compiler option for Mesa OpenGL at the moment.

yes... yes yes well.... in 6 month ACO will do OpenGL and in 1 year ACO is faster in Compute to (ACO is already faster) . means in 1 year we celebrate the death of LLVM...

[qarium]

Don't hold your breath yet, this PR won't fix this particular situation. It's just a runtime default change, Mesa still needs a recent LLVM to compile and link against.
When radeonsi gets the ACO compiler treatment, they may implement making the LLVM dependency optional.

But for now, both backends are available in radv (allowing to switch between them) and only LLVM in radeonsi.

it is not sure yet if they do radeonSI OpenGL with ACO or they do it the other way arround and make openGL over Vulkan. then radeonSI/LLVM is death.