GFX1013 Target Added To LLVM 13.0 For RDNA2 APUs

[phoronix]

Phoronix: GFX1013 Target Added To LLVM 13.0 For RDNA2 APUs

Merged last week to mainline LLVM 13.0 was the new "GFX1013" target for the AMDGPU shader compiler. Well, it landed twice as at first had to be reverted after breaking the build bots / sanitizer testing...

https://www.phoronix.com/scan.php?page=news_item&px=LLVM-13.0-GFX1013

[Alexmitter]

I wonder why someone even bothered. To (hopefully) no ones surprise, LLVM turned out to be way too slow for shader compiling. ACO thankfully fully replaced it. It was a mistake to use LLVM for this job (or any job really) since the beginning and it seriously hindered Linux Graphics from performing competitively.

[zxy_thf]

I wonder why someone even bothered. To (hopefully) no ones surprise, LLVM turned out to be way too slow for shader compiling. ACO thankfully fully replaced it. It was a mistake to use LLVM for this job (or any job really) since the beginning and it seriously hindered Linux Graphics from performing competitively.

We still need LLVM for GPU Computing.

[Alexmitter]

We still need LLVM for GPU Computing.

And if GPU computing has to be performant, LLVM will eventually be replaced here too.

There is really no need for that low level virtual machine and its slowness, unreliability and unpredictability in any use case.

[aufkrawall]

I wonder why someone even bothered.

Because ACO for RadeonSI doesn't seem to be a priority and AMD seem to be commited to LLVM, apparently regardless whether it makes sense or not (which is sad).

[Alexmitter]

Because ACO for RadeonSI doesn't seem to be a priority and AMD seem to be commited to LLVM, apparently regardless whether it makes sense or not (which is sad).

ACO is focused on Vulkan. Vulkan heavily relies on a fast shader compiler, OpenGL not so much.

ACO is made for RADV while AMD still focuses on their slower and inferior amdvlk driver that still uses LLVM. It has no hand and no say in RADV and ACO at all.

[aufkrawall]

Vulkan heavily relies on a fast shader compiler, OpenGL not so much.

That is generally not true and I'm not convinced you actually understood that there would be no GPU accelerated Linux desktop without a shader compiler for RadeonSI and such an APU.

[Alexmitter]

That is generally not true and I'm not convinced you actually understood that there would be no GPU accelerated Linux desktop without a shader compiler for RadeonSI and such an APU.

I guess you are auf krawall, quite literally. I very well understand that AMD for the time selected a massively inferior shader compiler for RadeonSI. That does not change the fact that it was a bad choice, a choice that should be corrected like it was corrected with ACO for the RADV driver.

Its the days of Vulkan now, for everything beside Desktop Acceleration, and LLVM is Good Enough(TM) for that for now, so as long as AMD does not do this work on extending ACO for RadeonSI or create a proper compiler from scratch like they should have done from the beginning, no one will do it for now.

[hoohoo]

And if GPU computing has to be performant, LLVM will eventually be replaced here too.

There is really no need for that low level virtual machine and its slowness, unreliability and unpredictability in any use case.

Two points:
- LLVM compilers have nothing to do with virtual machines per se.
- ROCK uses an LLVM derived compiler and ROCm works quite well.

[StillStuckOnSI]

Two points:
- LLVM compilers have nothing to do with virtual machines per se.
- ROCK uses an LLVM derived compiler and ROCm works quite well.

Yeah, the VM in LLVM should be mostly ignored as a curiosity. It's an IR manipulation and code generation framework first and foremost.

That said, I would say device compilers for compute workloads like in ROCm and for graphics workloads like in RADV do not have the same set of requirements. The former is focused on optimal code generation with as many bells and whistles as possible, damn the time required. The second needs to have a decent latency as well to avoid stuttering and other in-game issues, especially since shaders are more likely to be compiled on the fly than compute programs.

LLVM is great for the first case because it's general purpose, comprehensive, easy to extend and battle tested. However, it's also a bit of a beast and egregiously slow (relatively speaking) for code generation. This is not a hard limitation of compilers, but rather a result of legacy and architectural decisions in LLVM itself. You could of course try to make LLVM faster, but turning such a big ship around is much harder than writing a special-purpose compiler like ACO. This assumes there are enough skilled devs around to do so, of course, but the mesa project definitely does.