RADV+ACO Lands FP16 Features - One Step Closer To Making ACO The Default

[CochainComplex]

So what's the deal with the LLVM-implementation then? Wasn't the purpose of using LLVM that it could leverage a lot from that project, and that it would be more general and benefit other drivers as well?
Is there some write up to what went wrong and why it was a bad choice? Or at least a summary of pros and cons, and why they've now shifted?

The general issue of "all-rounder" vs. "specialist"

[CochainComplex]

So, does that get ACO to the point that LLVM is not needed at all anymore?
Up until now I was under the impression that ACO only replaced compilation for certain shaders, not all of them (and for those LLVM would still be used).

The LLVM will be still there, especially for performance comperision. AFAIK ACO ist going to be defaulted once it is on parity with the LLVM implementation for RADV - this is the reason of the merge request.

[Azpegath]

This announcement explains it all.

Thank you, exactly what I was looking for. The Mesa mailing list message summed it up well.

[TemplarGR]

So, does that get ACO to the point that LLVM is not needed at all anymore?
Up until now I was under the impression that ACO only replaced compilation for certain shaders, not all of them (and for those LLVM would still be used).

Actually, right now ACO can compile all shaders AFAIK, in MESA 20.1.x already. The only thing that was missing were the tesselation stages and those were added in 20.1 . Some minor things left that it seems will be added in 20.2, and then it can replace it for end users (=gamers) completely i think.

[CochainComplex]

https://www.youtube.com/watch?v=6T_-HMkgxt0 I got the feeling Anthony is somehow under us.

Besides Red Dead Redemption 2 ...is faster with AMD+ACO under wine/DXVK than under windows o.O

https://flightlessmango.com/benchmarks/6RfJoH1N6IQ

[mphuZ]

So, does that get ACO to the point that LLVM is not needed at all anymore?
Up until now I was under the impression that ACO only replaced compilation for certain shaders, not all of them (and for those LLVM would still be used).

https://www.youtube.com/watch?v=6RfJoH1N6IQ

AMDVLK > RADV ACO

It's not about the compiler... ACO does not create miracles. Everything is decided by the direct hands of developers.

[humbug]

Where does this leave AMD's developers? Are they frustrated at users moving away from their work?

People already are using the RadV Vulkan drivers rather than AMD's amdvlk.
Now we are moving to ACO and away from AMD's shader compiler.

[Sethox]

Where does this leave AMD's developers? Are they frustrated at users moving away from their work?
People already are using the RadV Vulkan drivers rather than AMD's amdvlk.
Now we are moving to ACO and away from AMD's shader compiler.

Well all I am going to say is, competition is good.

[humbug]

Well all I am going to say is, competition is good.

No doubt. But i'm sure that their devs would prefer to have a userbase.

So I hope AMD can reflect on why the Linux community moved away in these two instances. in the case of amdvlk it took too long to come out so the community stopped waiting and did it themselves.

[mazumoto]

Actually, right now ACO can compile all shaders AFAIK, in MESA 20.1.x already. The only thing that was missing were the tesselation stages and those were added in 20.1 . Some minor things left that it seems will be added in 20.2, and then it can replace it for end users (=gamers) completely i think.

Thank you, that's what I wanted to know. :-)
I'm aware that this won't get Mesa rid of llvm (I do want OpenGL after all), but it's a step in that direction - it is some effort for me to build llvm from source (even though I'm on gentoo - it takes long and breaks quite often), so I'm hoping that this dependency will become optional at some point. Especially since I read Big Navi will require llvm 11 and I plan to get such a card later this year.