RADV's ACO Back-End Can Be A Massive Win For Vulkan Compute - Not Just Gaming

[Peter Fodrek]

I wish similiar impovements in performce for solving "Zen Bug"

AMD Developers Looking At GNU C Library Platform Optimizations For Zen
Written by Michael Larabel in AMD on 25 March 2020
Stemming from Glibc semantics that effectively "cripple AMD"

while AMD CPUs with Glibc are not even taking advantage of Haswell era CPU

https://www.phoronix.com/scan.php?page=news_item&px=GNU-libc-Platform-Optimize-Zen

via

Glibc-HWCAPS To Help With AMD Zen Optimizations, Other Per-CPU Performance Bits
Written by Michael Larabel in GNU on 7 July 2020

https://www.phoronix.com/scan.php?page=news_item&px=glibc-hwcaps-RFC

in glibc 3.33 early next year



And It s possible

Nov 18th, 2019 10:53
MATLAB is a popular math computing environment in use by engineering firms, universities, and other research institutes. Some of its operations can be made to leverage Intel MKL (Math Kernel Library), which is poorly optimized for, and notoriously slow on AMD Ryzen processors. Reddit user Nedflanders1976 devised a way to restore anywhere between 20 to 300 percent performance on Ryzen and Ryzen Threadripper processors, by forcing MATLAB to use advanced instruction-sets such as AVX2. By default, MKL queries your processor's vendor ID string, and if it sees anything other than "GenuineIntel...," it falls back to SSE, posing a significant performance disadvantage to "AuthenticAMD" Ryzen processors that have a full IA SSE4, AVX, and AVX2 implementation

https://www.techpowerup.com/261241/matlab-mkl-codepath-tweak-boosts-amd-ryzen-mkl-performance-significantly?cp=3

[GruenSein]

People seem to forget that the AMD backend in LLVM needs to be maintained anyway. The reason is simple: Lots of people use clang or flang for HPC stuff and they want OpenMP offloading and potentially SYCL for GPU compute. This will be increasingly important with the compute focused Instinct cards in the future. ACO is not targeting this use case. From a perspective purely concerned with consolidating the development efforts, it makes sense to use LLVM in their driver as well and I am under the impression that they are lacking Linux driver and ecosystem developers anyway.

With all this said, the accomplishments of the Valve/Google-led ACO efforts are quite impressive. Same goes for RADV. One has to credit AMD with providing a solid foundation for this work, though. RADV started out with LLVM. Then, ACO came along. All of this is only possible because there is a good open source kernel driver. Maybe, AMD's strategy is not that bad: Providing a working reference implementation which shares large portions with their Windows drivers to lessen the development burden while being open enough so that platform specific solutions can be derived/built on this. At least with Vulkan, it has worked out very well so far. And let's be fair: AMDVLK isn't terrible either. For any open source GPU driver, it was a milestone.

[bridgman]

Interest in using llvm as a shader compiler goes right back to 2007 - it was part of the initial rollout of Gallium3D and TGSI at XDS.

[arsenm]

This is not just a benchmark of the llvm backend, but also RADV's suboptimal usage of it. The results are substantially better with amdvlk. I'm seeing similar times comparing amdvlk and aco, with each being faster in some cases

[StillStuckOnSI]

People seem to forget that the AMD backend in LLVM needs to be maintained anyway. The reason is simple: Lots of people use clang or flang for HPC stuff and they want OpenMP offloading and potentially SYCL for GPU compute. This will be increasingly important with the compute focused Instinct cards in the future. ACO is not targeting this use case. From a perspective purely concerned with consolidating the development efforts, it makes sense to use LLVM in their driver as well and I am under the impression that they are lacking Linux driver and ecosystem developers anyway.

I use GPU compute on the daily and would love to have a SPIR-V compiler that absolutely smokes the current LLVM-based one. The biggest issue is not a backend but a front/middleend one: Vulkan's SPIR-V shader dialect still lacks many QoL features for compute. If ACO can be adapted to ingest something like the dialect that OpenCL/oneAPI share and Clover (or some derivative) was successfully raised from the dead, we'd have a pretty compelling, open source compute stack on Linux (I believe airlied has talked about this before).

[Volta]

This is not just a benchmark of the llvm backend, but also RADV's suboptimal usage of it. The results are substantially better with amdvlk. I'm seeing similar times comparing amdvlk and aco, with each being faster in some cases

So you're claiming it's automagically optimal with ACO which is much younger? Insane.

[FLHerne]

So you're claiming it's automagically optimal with ACO which is much younger? Insane.

Reverse the logic in that case -- ACO was written to be the new backend for RADV, so of course it fits perfectly with RADV's lowering passes and overall design.

[Volta]

Reverse the logic in that case -- ACO was written to be the new backend for RADV, so of course it fits perfectly with RADV's lowering passes and overall design.

True. That's why llvm should be put into trash.

[smitty3268]

This is not just a benchmark of the llvm backend, but also RADV's suboptimal usage of it. The results are substantially better with amdvlk. I'm seeing similar times comparing amdvlk and aco, with each being faster in some cases

Interesting. I wonder what radv is doing that's so suboptimal with their llvm usage, but I suppose it doesn't really matter at this point since it's no longer the default.

It'd be nice if Michael could run a new set of tests with amdvlk so we could see how it compares.

[pal666]

They should burn llvm back-end with fire, so no one will have dilemma what to focus on.

who will write windows drivers? you?