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

[Venemo]

When comparing llvm and aco for The Witcher 3 (Wine+dxvk) on RX 5700 XT, llvm is actually slightly ahead in raw framerate. So ACO has still catching up to do.

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?

[Venemo]

Has anyone tried ACO with GTA V on an rx580? For some reason all the colors during daytime are overblown (super white), to the point that it can be impossible to see. This issue does not occur with the llvm driver.

Please report this bug if there isn't already a report about it.

[ms178]

If you are going to make that argument, then why do we need ACO? Why not put that effort into LLVM? LLVM is used for OpenCL, radeonsi OpenGL, amdvlk, as well as all of the HPC and ML stuff that is built on top of ROCm. It doesn't really make sense to invest in two compilers if resources are limited.

They evaluated this approach and decided to go their own way and long-term ACO could become also the default compiler for radeonsi. Let's put it this way, maybe it is an incentive to invest more in LLVM and apply some tricks from them or if you embrace ACO you can focus your efforts with LLVM on the compute side as ACO becomes the gaming-optimized compiler in AMD's Linux stack. I see that this is not ideal from AMD's perspective but for me as an end user, I welcome the benefits which tackle some long standing issues which hurt the gaming experience on your devices and which could have been fixed by AMD, too if they were a priority. Appearently they weren't... so the community came up with something different.

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).

[aufkrawall]

amdvlk-open is now in regular Arch repo, but this driver still doesn't even work in the probably most important Linux port of the year, Shadow of the Tomb Raider. It just crashes.
I'm sorry to say, but it's not just redundant, it's almost useless and a waste of resources. Not to speak of all the other issues like much slower compile times than even regular LLVM, broken vsync, missing FreeSync, less user-controllable features, intransparent development...
Please stop investing efforts into it and e.g. instead invest in a proper unified OpenCL driver for Windows and Linux that works equally well with both HPC and consumer workloads/apps...

[ms178]

Concerning compute capabilities on different platforms, Intel is catching up on the software side of things, AMD's offerings might not look good enough in this regard soon. As parts of the oneAPI approach might be adaptable to AMD's needs, I hope they can leaverage Intel's push as good as possible here as it might make heterogenious computing finally a thing on the desktop. HSA hasn't had the industry weight behind it and sadly never took off...

[wujashek]

Has anyone tried ACO with GTA V on an rx580? For some reason all the colors during daytime are overblown (super white), to the point that it can be impossible to see. This issue does not occur with the llvm driver.

Hi, I got the same problem with my rx570 on Fedora 31 with xxmitsu/mesa-aco repository.

[coder]

I'm sorry to say, but it's not just redundant, it's almost useless and a waste of resources. Not to speak of all the other issues like much slower compile times than even regular LLVM, broken vsync, missing FreeSync, less user-controllable features, intransparent development...
Please stop investing efforts into it

I see this effort as sort of like AMD's Mantle, which showed the potential being missed by DX11. As a result, we got Vulkan + DX12. Hopefully, the eventual result is many of ACO's optimizations being folded into LLVM.

Anyway, this is the beauty of open source. Valve didn't need AMD's permission to do this - they just did it. And if it works for you, great. If not, then at least it made a point & you might eventually benefit. I don't see the point of any controversy or drama about it.

[coder]

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).

Yeah, it's just a pipe dream. Instead, just be glad that the potential for competition exists.

[ms178]

That might actually be counter-productive, if it fits the practices described in the book "The Mythical Man-Month: Essays on Software Engineering".

Yeah, it's just a pipe dream. Instead, just be glad that the potential for competition exists.

Thanks for both of your insights, I certainly do enjoy that there is competition and that open source furthers innovation like ACO. Having ACO also certainly helps to prove their argument that there are meaningful benefits to be had. But I'd argue that more collaboration could have helped here (duplication of effort is not very efficient after all): AMD and Valve could have talked about making LLVM better, collaborating in identifying weaknesses and solutions with both committing ressources to achieve specific goals in a specific amount of time. As you were dependant on the work of the others there is a risk inherent to this approach, but pooling the manpower would mean more hands on the job and a potential greater benefit to the AMD ecosystem. As software engineering is not my profession, my thinking might be fundamentally flawed here how this would work out in practice - but that "mythical man-month" seems to be a problem for large teams and solvable with more efficient communication and task distribution. At least here with just two hands full of developers involved, I doubt that this would cross the threshold to be a problem in itself. There might have been technical reasons which made that route less viable - I cannot judge the presented arguments by the ACO developers on their merit. And maybe there were some talks in the background but no consensus on the way forward, I don't know. It certainly looks less than ideal in my eyes even more so when looking at the RADV / AMDVLK case.

[coder]

But I'd argue that more collaboration could have helped here (duplication of effort is not very efficient after all): AMD and Valve could have talked about making LLVM better,

Do we know that they didn't? The usual approach for game developers who find some bad code being generated by a compiler, GPU driver, etc. is to report a performance bug. Game development houses don't usually go around looking to take on additional tools work.

I recall reading that ACO was born out of Valve's frustration with bad shader code, which probably means they had several performance bugs that were just languishing and not being addressed. Certainly, it seems like a more ideal outcome would've been for Valve to patch LLVM. However, maybe they didn't have the time or expertise needed to go that route.

Even with the route they took, at least they made their point, and users now have another way to try and eke a little more performance out of their GPUs.