The ROCm Enablement Tool Makes It Easier To Setup AMD's Open-Source Compute Stack

[phoronix]

Phoronix: The ROCm Enablement Tool Makes It Easier To Setup AMD's Open-Source Compute Stack

While there are the Debian/RPM packages offered of the Radeon Open Compute (ROCm) stack for Linux users on supported distributions, the new "ROCm Enablement Tool" could assist in setting up this GPU compute stack on supported Linux distributions and elsewhere...

http://www.phoronix.com/scan.php?page=news_item&px=ROCm-RET-Enablement-Tool

[Nille_kungen]

Does rocm work on raven ridge?

Maybe i should try on my 2500u.

[jrch2k8]

Honestly i'm way more excited about AMDGPU kernel driver getting HMM support and the NIR OpenCL work Karol and company are doing.

I believe this will be another RADV where the OpenCL will be just better and easier to use except certain corner cases, specially since is very likely Mesa support will be way faster and in all honesty due to the work Karol is doing and the complexity of OpenCL it should open the doors to someone else implement CUDA on NIR without much difficulty(and even add SPIRV support for interoperability).

I have nothing against Rocm but i think its design is way too complex and honestly overkill outside certain enterprise scenarios

[Brisse]

I believe this will be another RADV where the OpenCL will be just better and easier to use except certain corner cases

Meh, I don't think that's going to happen, at least not any time soon. Easier to use perhaps, but if it's going to be better then it has a really really long road ahead to get there. Meanwhile, ROCm OpenCL is fairly feature complete and performant, and has been so for a while now. Not hard to use on Debian based distros using AMD's repo, but I can see the issue on other distros where it has to be built from source.

[Farmer]

Honestly i'm way more excited about AMDGPU kernel driver getting HMM support and the NIR OpenCL work Karol and company are doing.

I believe this will be another RADV where the OpenCL will be just better and easier to use except certain corner cases, specially since is very likely Mesa support will be way faster and in all honesty due to the work Karol is doing and the complexity of OpenCL it should open the doors to someone else implement CUDA on NIR without much difficulty(and even add SPIRV support for interoperability).

I have nothing against Rocm but i think its design is way too complex and honestly overkill outside certain enterprise scenarios

From what I can see I'd agree. Developing it outside of the normal trees has resulted in it being pretty specific to a distro and they don't appear to be doing anything about that. For Fedora, as an example, it's already outdated and thus not really maintained. https://github.com/RadeonOpenCompute...scripts/Fedora

Fedora 30 is out. That's 28 and 29. While 29 might work, it's just a sign that it's just not being kept up to date - due to it being outside the norm.

AMD OpenCL on Fedora does point out the advantages of developing "in tree" with the usual software.

I'm aware of the various rumblings of Fedora working with AMD to include ROCm in Fedora but progress appears to be glacial.

[Soul_keeper]

The project is just too large and fragmented. There is too much redundancy. Various projects that are already installed on people's systems are avoided in favor of internal copies.
And good luck trying to find which svn address or version needs to be used between the various subprojects. ROCm needs to be a single unified project with an actual build system instead of dozens of shell scripts. And please follow the gnu/linux philosophy, upstream the stuff to llvm or any other project instead of duplicating projects. When every distro can create packages easily (ie: installing to bin, lib, include dirs without hacking the thing to work), then maybe it'll be a respectable project.

[darkbasic]

The project is just too large and fragmented. There is too much redundancy. Various projects that are already installed on people's systems are avoided in favor of internal copies.
And good luck trying to find which svn address or version needs to be used between the various subprojects. ROCm needs to be a single unified project with an actual build system instead of dozens of shell scripts. And please follow the gnu/linux philosophy, upstream the stuff to llvm or any other project instead of duplicating projects. When every distro can create packages easily (ie: installing to bin, lib, include dirs without hacking the thing to work), then maybe it'll be a respectable project.

Exactly.

[Aeder]

Meh, I don't think that's going to happen, at least not any time soon. Easier to use perhaps, but if it's going to be better then it has a really really long road ahead to get there. Meanwhile, ROCm OpenCL is fairly feature complete and performant, and has been so for a while now. Not hard to use on Debian based distros using AMD's repo, but I can see the issue on other distros where it has to be built from source.

Sometimes. being the easier to use choice is all it takes for a specific solution to reach widespread usage and support, it doesn't have to be the better solution. It's kinda sad to see one of the biggest obstacles to using Rocm remain, which is the fact that it's not easy to install on anything that isn't Ubuntu.

It's one of the reasons I ended up running Tensorflow on a CPU instead. The second issue is that they haven't even upstreamed their patches to tensorflow so you have to use their fork that, at least back then, was outdated, and didn't play nice with newer libraries.

[smitty3268]

I believe this will be another RADV where the OpenCL will be just better and easier to use except certain corner cases, specially since is very likely Mesa support will be way faster and in all honesty due to the work Karol is doing and the complexity of OpenCL it should open the doors to someone else implement CUDA on NIR without much difficulty(and even add SPIRV support for interoperability).

I don't think it's like radv, unfortunately, because that would be a lot more ideal. The mesa CL support has been in progress for years, however, and it's still not in reasonable shape. There's just not enough manpower interested in getting it running, unlike the radv case. Also, I think the userbase of radv is much more interested in trying out various options to see what works best, while the CL userbase is much more enterprise-centric and just wants something official and tested from AMD they can download.

[gsedej]

Does rocm work on raven ridge?

Maybe i should try on my 2500u.

OpenCL only. No hip ("cuda").

These APUs are enabled in the upstream Linux kernel drivers and the ROCm Thunk. Support for these APUs is enabled in the ROCm OpenCL runtime. However, support for them is not enabled in our HCC compiler, HIP, or the ROCm libraries. In addition, because ROCm is currently focused on discrete GPUs, AMD does not make any claims of continued support in the ROCm stack for these integrated GPUs.

https://rocm.github.io/hardware.html