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

[Teggs]

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

Those Flightless Mango (and what mango isn't flightless, unless someone throws it?) datasets are well presented, but I wonder how many runs were done. It looks like one each, and that's not reliable. Not DXVK in this case, but native Vulkan. That also explains why AMDVLK might be in the lead, because that's what Windows (and Stadia) game devs target for Vulkan.

Isn't Red Dead a Stadia title? It's amusing if it runs faster in Wine, but it's frustrating that someone is blocking a native Linux release when there is a deployed native Linux build. See also: every other Stadia title.

[bridgman]

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.

I can't speak for the AMDVLK team, but in general we like these community initiatives. When they look promising and supporting a new initiative means we can stop working on the previous approach we generally get on board fairly quickly - a good example is the 300g and 600g Gallium3D drivers vs classic Mesa drivers. We didn't start either of those initiatives (it was mostly Jerome and Corbin IIRC) but they seemed like good ideas.

ACO is a bit different because supporting it means we take on a big pile of new work but don't get to stop doing any existing work, since the llvm back end is also the foundation for a number of other AMD compiler chains.

If ACO could replace the proprietary shader compiler we use for other APIs and OSes (the ones that are not yet using llvm) that would make it a lot more interesting because we could support it without taking on a big pile of new work that we don't have people for. Same if it was able to completely replace llvm in all our compute stacks as well.

Replacing llvm in radv and radeonsi doesn't free up any people to work on ACO since we still need to support the llvm backend for our compute stacks, so it's just a bunch of extra work for people we don't have yet.

It's easy to fall into the trap of thinking that every driver stack is totally independent with its own organization working on it, but the reality is that one of the reasons a small company like AMD is able to do such big things is that we leverage technology all across the company wherever possible, and compilers are probably the biggest example of that on the SW side.

[qarium]

I can't speak for the AMDVLK team, but in general we like these community initiatives. When they look promising and supporting a new initiative means we can stop working on the previous approach we generally get on board fairly quickly - a good example is the 300g and 600g Gallium3D drivers vs classic Mesa drivers. We didn't start either of those initiatives (it was mostly Jerome and Corbin IIRC) but they seemed like good ideas.

ACO is a bit different because supporting it means we take on a big pile of new work but don't get to stop doing any existing work, since the llvm back end is also the foundation for a number of other AMD compiler chains.

If ACO could replace the proprietary shader compiler we use for other APIs and OSes (the ones that are not yet using llvm) that would make it a lot more interesting because we could support it without taking on a big pile of new work that we don't have people for. Same if it was able to completely replace llvm in all our compute stacks as well.

Replacing llvm in radv and radeonsi doesn't free up any people to work on ACO since we still need to support the llvm backend for our compute stacks, so it's just a bunch of extra work for people we don't have yet.

It's easy to fall into the trap of thinking that every driver stack is totally independent with its own organization working on it, but the reality is that one of the reasons a small company like AMD is able to do such big things is that we leverage technology all across the company wherever possible, and compilers are probably the biggest example of that on the SW side.

Sounds very good. lets replace LLVM for ACO.
In my knowledge ACO is already faster for Compute tasks...

If i would be CEO of AMD (sure many hope I never will be and i have no problem with that)
then i would go for ACO all over the place and i would even focus on Compute over Vulkan+ACO.
(means no more OpenCL-Nvidia-bullshit)
I think this will happen even if AMD will not switch from LLVM to ACO just because the community and valve and redhat and others are in favor of ACO.

this means you can speed it up or you can slow it down but you can not change the end result in my point of view.

[smitty3268]

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.

ACO was born out of Valve's dissatisfaction with AMD's drivers holding back their Steam on Linux push. Having games broken for 6 months until the next LLVM release just wasn't ever going to cut it, and they seemed to switch from backing a statically linked llvm solution over to writing a new compiler from scratch once they realized it was actually feasible and that no one wanted to fork llvm into mesa.

I'll admit I'm a little concerned what will happen to ACO if Valve ever gets tired of supporting it. It's not really a big burden to them, but it's not their core business either. In the meantime, though, it's so much nicer from a consumer and distro perspective than the LLVM drivers are that it's going to be unlikely to slow down it's expanding use anytime soon.

[bridgman]

Sounds very good. lets replace LLVM for ACO.
In my knowledge ACO is already faster for Compute tasks...

Um... that's pretty much the opposite of what I said, but don't let that get in the way

Do you have any examples of ACO being faster for compute ? I don't think I have seen any yet.

[pal666]

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

amd developers are developing compute shaders compiler and nobody moves away from it yet

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.

so, what's your point? amd shouldn't produce drivers because community of excited forum posters can do it without amd?

[CochainComplex]

ACO was born out of Valve's dissatisfaction with AMD's drivers holding back their Steam on Linux push. Having games broken for 6 months until the next LLVM release just wasn't ever going to cut it, and they seemed to switch from backing a statically linked llvm solution over to writing a new compiler from scratch once they realized it was actually feasible and that no one wanted to fork llvm into mesa.

I'll admit I'm a little concerned what will happen to ACO if Valve ever gets tired of supporting it. It's not really a big burden to them, but it's not their core business either. In the meantime, though, it's so much nicer from a consumer and distro perspective than the LLVM drivers are that it's going to be unlikely to slow down it's expanding use anytime soon.

Honestly, I dont't get your point. ACO was initiated by Valve true but still we have LLVM as fallback. And Steam supports Mesa with or without ACO. Wine or DXVK also does not care much about it. Yes bugs will be resolved in a ping pong approach and in an itterative manner they optimze for each other. Eventually if ACO will ever be dropped once, then llvm will be again in the race. Mesa with RADV for sure will not die soon. Besides it is opensource, we are not totally depending on Valve. Yes know how is there and a lot of work is done by them but it is not closed.

[arsenm]

Having games broken for 6 months until the next LLVM release just wasn't ever going to cut it, and they seemed to switch from backing a statically linked llvm solution over to writing a new compiler from scratch once they realized it was actually feasible and that no one wanted to fork llvm into mesa.

llvm does not need to be forked, it just needs to be treated as a core component of mesa rather than relying on whatever version of llvm the distro happens to package. This nearly every other user of LLVM does, especially the various GPU drivers. They all are on their own independent release schedules and pick whatever llvm revision they want. Mesa is really the only major public user of the llvm releases. In my opinion the LLVM releases are for clang as a drop in replacement for system GCC, and it doesn't make sense to tie the GPU compiler release schedule to that.

[qarium]

Um... that's pretty much the opposite of what I said, but don't let that get in the way
Do you have any examples of ACO being faster for compute ? I don't think I have seen any yet.

well yes.... why not test it ? write a compute task in vulkan and test it with LLVM and ACO ?
if ACO is already faster AMD should make a plan to switch workers from LLVM to ACO.
it is much better to use the best FLOSS technology instead of the second best solution.
and both are open source and free.

this is pragmatic viewpoint. AMD should always use the best technology.

and in my point of view the ACO compiler is better than LLVM.

[humbug]

so, what's your point? amd shouldn't produce drivers because community of excited forum posters can do it without amd?

LOL you're projecting. My point is what I said, nothing else. What I said was below.
I hope AMD can reflect on why the Linux community moved away in these two instances.

I know they do have good reasons for their development directions, timelines and resource allocations.