AMD Releases ROCm AOMP 14.0 Compiler - Switches To New "amd-stg-open" Branch

[phoronix]

Phoronix: AMD Releases ROCm AOMP 14.0 Compiler - Switches To New "amd-stg-open" Branch

AMD releases AOMP 14.0 during SC21 week as the newest version of their LLVM/Clang-based compiler providing OpenMP GPU offload support for Radeon graphics processors...

https://www.phoronix.com/scan.php?page=news_item&px=AMD-Releases-AOMP-14.0

[cl333r]

"ROCm AOMP", one of the worst project names I've heard.

[bridgman]

"ROCm AOMP", one of the worst project names I've heard.

In fairness, I don't think there is anything you can pair with "AOMP" that is going to sound good

[skeevy420]

In fairness, I don't think there is anything you can pair with "AOMP" that is going to sound good

Why is it AOMP to begin with? Because, in fairness, I don't think that pairs with ROCm very well. Also, doesn't AMD ROCm technically cover the A in AOMP? Now, this suggestion kind of irks me due to my hangup on ATM machines, but ignoring redundant naming issues, what about AGOMP?

AMD Radeon Open Compute AMD GPU Open Multi-Processing

What a mouthful.

ROCm AGOMP is fun to say. No denying that. AGOMP is also much easier to figure out how to pronounce than AOMP, that's for sure.

[bridgman]

Yep, AGOMP sounds better... but AFAIK the initialism is supposed to be represent OpenMP rather than our own combination of words (and yes I know OpenMP expands out to Open Multi Processing) but that won't necessarily be clear to everyone.

Personally I would just call it the ROCm OpenMP compiler but everyone thinks my names are boring.

[skeevy420]

Yep, AGOMP sounds better... but AFAIK the initialism is supposed to be represent OpenMP rather than our own combination of words (and yes I know OpenMP expands out to Open Multi Processing) but that won't necessarily be clear to everyone.

Personally I would just call it the ROCm OpenMP compiler but everyone thinks my names are boring.

Then just "GOMP"

I almost posted that up there but I wasn't sure if the naming was brand/company specific or not.

[mphuZ]

They have switched over to using "amd-stg-open" as a new staging area for code from AMD that they are making publicly available but not yet ready (or otherwise not appropriate/applicable) for upstreaming into the LLVM monorepo.

Wow!

Why wouldn't AMD do the same with AMDVLK? We are all really looking forward to it, it will be a big step forward!
bridgman agd5f

[bridgman]

Why wouldn't AMD do the same with AMDVLK? We are all really looking forward to it, it will be a big step forward!
bridgman agd5f

AMDVLK is a periodic extract from a closed source code base that is full of IP from other OSes and APIs which we are not allowed to expose.

OpenMP is an open source only project so no such concerns.

In principle we could fork AMDVLK away from our closed source Vulkan driver and maintain it independently in an IP-clean branch but that would just mean three Vulkan drivers instead of two and a half.

[mphuZ]

AMDVLK is a periodic extract from a closed source code base that is full of IP from other OSes and APIs which we are not allowed to expose.

OpenMP is an open source only project so no such concerns.

In principle we could fork AMDVLK away from our closed source Vulkan driver and maintain it independently in an IP-clean branch but that would just mean three Vulkan drivers instead of two and a half.

I don't understand a little how this prevents us from making the development of the open part of AMDVLK more open to the community contribution?
And what closed code prevents this from being done? Aren't you ready to port LLVM part to Windows driver?

[agd5f]

Wow!

Why wouldn't AMD do the same with AMDVLK? We are all really looking forward to it, it will be a big step forward!
bridgman agd5f

The changes to LLVM on the graphics side already make their way upstream. LLVM is used by radeonsi, radv (optionally), and AMDVLK. Other than new asic support, pretty much all of the GPU LLVM development happens upstream directly.