RADV's ACO Back-End Is Helping Radeon Navi Linux Gaming Performance

[grigi]

I feel some of the reasons for AMDVLK's existence is both political AND pragmatic in nature.
"It is needed to be done for the Windows driver already."
"It is good to have a contingency in case the other thing falls through somehow."
"Getting developers to spend the time to talk to each other is really difficult."
etc...

The reason for ACO is very much more pragmatic, is because it is a response in DOING the other option. AMD GPU devs (some employed by Valve) have been getting fixes into LLVM, but releases of that bugfix would often drag by half a year. Or fixes got undone because they were regressing something else.
This was an obvious pain point for years, and wasn't getting better.
It was then decided to see if one would re-create the LLVM portions of the compiler (which they probably were experts in already) and see if they can fix a few fundamental issues. The experiment proved highly promising, so more effort got invested into it.

[aufkrawall]

I feel some of the reasons for AMDVLK's existence is both political AND pragmatic in nature.
"It is needed to be done for the Windows driver already."

Yeah, but AMD's Windows Vulkan driver doesn't screw up vsync and FreeSync, has other features like a frame rate limiter and is easily installed onto every Windows PC.
The Linux driver feels more like a by-product that isn't loved by anyone.

[shmerl]

I remember you reported this before aco-navi was merged into upstream mesa. Have you done the comparison since then? Is this still the case?

I'll test it again shortly, and will post a comparison.

[shmerl]

I remember you reported this before aco-navi was merged into upstream mesa. Have you done the comparison since then? Is this still the case?

It's still behind. Posted the result here: https://github.com/daniel-schuermann...ment-557847351

[Linuxxx]

In my dreams AMD, Valve and all other concerned parties would sit together from time to time and discuss these things internally first to plan a way ahead for adressing these problems in a more coordinated manner and to make better use of their ressources. But different goals and corporate agendas seem to make this impossible to happen (see AMDVLK / RADV as precedent).

Actually, it looks like Valve is a lot LESS powerful than we all thought!

Recently, a very sensible proposal was made that would have benefitted the majority of their Linux customers:
Namely, to get "irqbalance" out of a default install of Ubuntu (and by logical extension, off its derivatives, too), which has been shown to hurt not only the gaming but also overall performance of a system running Ubuntu with active 'irqbalance'.
However, that proposal was closed because Valve felt like they don't have any power or voice when it comes to third-party companies, even when their very own interests are concerned!

Source:

https://github.com/ValveSoftware/Proton/issues/3243

[coder]

Actually, it looks like Valve is a lot LESS powerful than we all thought!

...
However, that proposal was closed because Valve felt like they don't have any power or voice when it comes to third-party companies, even when their very own interests are concerned!

Source:
https://github.com/ValveSoftware/Proton/issues/3243

Sounds to me like it was closed as a Proton issue, because it's not an issue with Proton, itself - it shouldn't even be filed, there. The Valve person who closed it said the proper way to raise the issue was with the distro, itself. That makes sense, to me.

BTW, the Valve person also didn't say they have no influence, with the distro. That's purely your speculation.

[shmerl]

Namely, to get "irqbalance" out of a default install of Ubuntu (and by logical extension, off its derivatives, too), which has been shown to hurt not only the gaming but also overall performance of a system running Ubuntu with active 'irqbalance'.

Debian already removed it from default install. Ubuntu being behind just didn't get that change yet.

[microcode]

LLVM is a very large and general-purpose optimizing compiler framework, like most things of this sort, you can often win against goliaths like this with simpler software. I've now had the pleasure of cutting the fat in big programs a few times, and the results are usually very satisfying.

Excellent work on ACO, hope it keeps going. Maybe Zink comes through on the performance side, and we can run super-lean LLVM-free Mesa on our AMD cards. :- )

[Venemo]

In my dreams AMD, Valve and all other concerned parties would sit together from time to time and discuss these things internally first to plan a way ahead for adressing these problems in a more coordinated manner and to make better use of their ressources. But different goals and corporate agendas seem to make this impossible to happen (see AMDVLK / RADV as precedent).

Keep in mind that AMD makes its money selling hardware, so they are happy that whatever the community is doing, we're doing it with AMD hardware and not using the competition.

Believe it or not, the RADV/ACO people are actually on pretty good terms with the guys who work at AMD. Discussions happen every day on IRC, and face-to-face during various conferences, etc. There is even some common code which is shared between radv and radeonsi. (Not a lot, but it's a start.) Most of the AMD people are very helpful, I think we can't complain.

AMD has invested a lot of time and money into making LLVM work well, so it's not realistic to expect them drop it overnight. LLVM, despite its shortcomings, is a proven piece of technology that is useful for a broad range of use cases and sees investment from other big companies. On the other hand ACO is quite new, developed by a handful of people for one specific purpose, and is still a little rough around the edges and not yet ready for all use cases. I think if ACO proves itself and matures over time, it will see better reception and will be taken more seriously. We're working on making this happen.

[ms178]

Believe it or not, the RADV/ACO people are actually on pretty good terms with the guys who work at AMD. Discussions happen every day on IRC, and face-to-face during various conferences, etc. There is even some common code which is shared between radv and radeonsi. (Not a lot, but it's a start.) Most of the AMD people are very helpful, I think we can't complain.

AMD has invested a lot of time and money into making LLVM work well, so it's not realistic to expect them drop it overnight. LLVM, despite its shortcomings, is a proven piece of technology that is useful for a broad range of use cases and sees investment from other big companies. On the other hand ACO is quite new, developed by a handful of people for one specific purpose, and is still a little rough around the edges and not yet ready for all use cases. I think if ACO proves itself and matures over time, it will see better reception and will be taken more seriously. We're working on making this happen.

Thanks for your work and as I mentioned in my comments I do take ACO seriously and what you guys brought to the table in such a short time frame. I also hope the other part of my comment made it clear that I am aware of the investments and importance of LLVM to AMD, too. I also follow your interactions on Github/Gitlab and am aware of that form of cooperation with Intel and AMD developers which already exists (e.g. on the NIR parts), but of course I don't get to see what is actually discussed and what opinions were exchanged on other channels you mentioned nor can I judge the technical arguments.

My critical point was more about the perceived lack of coordination on a strategic level. I mean at one point someone had to decide to go either the ACO route or the LLVM route, and Daniel Schürmann mentioned the thinking (briefly) behind the decision from the ACO-side. Concerning the LLVM side, I've seen some initiatives on the mailing list to improve its usefulness for GPUs and other accelerators, that might have been a viable alternative to invest ressources in (other interested parties next to AMD seem to be Intel and ARM). And maybe someone could add technical insights why that approach wasn't favored. At least I take agd5f's comment that he personally would have prefered if Valve had chosen the latter option... I am also not exactly clear about ACO's strategic goals. From your to-do-list it seems to me that you want ACO to become the central gaming-focused compiler for the open AMD stack, both RadeonSI (OpenGL) and RADV (Vulkan), right? And it might serve the AMD Linux desktop customer base well, but I also see AMD's point that it might not save them much development efforts as they still need to support LLVM for gaming on other platforms and/or AMDVLK. These are ressources which could have been pooled or spend elsewhere. Maybe there is still the option for some middleground to maximize the benefits of this investment for both AMD and Valve? I just hope that this is also part of healthy discussions...