Radeon ROCm 2.7.2 Released

[FireBurn]

So ebuilds landed for ROCm in Gentoo recently so decided to give it a try, unfortunately it doesn't work with either my M395X (Tonga based) or my Ryzen 2400G - when are they going to have a solution that'll work on all their cards, or at the very least fail gracefully

[finalzone]

Edit: I have not tried it and you possibly have issues with AMDGPU-PRO. RHEL 8 is what they are intended for and that is based on Fedora 28, so Fedora 30 might not play well with those packages. For ROCm you could try to use the upstream kernel instead.

OpenCL from AMDGPU-PRO is running fine on Fedora 31 prerelease tested with both Blender, Gimp, LibreOffice and Darktable. rocm version is currently broken with segmentation fault when testing with clinfo.

[Marc Driftmeyer]

Wake me when it eliminates 32 bit libs. The > 2GB foot print is another horrific requirement. I installed the August 29 debs on Debian Sid and eventually got around the fact the updates weren't correctly listing versions in Apt. With that aside, to see if CLInfo showed a workable Accelerator and all it did was hang the terminal and force a root kill to end it. Even then I had to completely reboot for systemd to fully flush it. Gutted the packages and the system was much more responsive as I'd expect.

The sheer piss poor management of the OpenCL stack aside, the fact you can't even get a working stable solution after 5 years of the HSA initiative should have a house cleaning and hiring of expertise in the areas of OpenCL or just scrap it all together. You know there is little to zero resources dedicated on it when the ATMI package maintainer is asking for my feedback on its viability and how I would plan to use it.

You'd think AMD would have much deeper ties with Apple and it's OpenCL/LLVM teams to have worked out the kinks, but that's obviously something Lisa Sui needs to figure out and invest time and money in.

I have a suggestion, shit can it all together, replicate the rich capabilities of Metal with a new version of Vulkan with Compute Shaders and Computation ala Metal 2 API and gut the OpenCL code in Blender with its replacement.

The entire project has been a continual kicking of the can for 5 years.

[aht0]

Yes!
Kubuntu 18.04 comes with KDE Plasma 5.12
Kubuntu 19.04 comes with KDE Plasma 5.15, upgradeable to 5.16
There is a huge difference between KDE Plasma 5.12 and 5.16.
For this I tried to install first Kubuntu 19.10 from nightly builds, but ROCm refused to install.
Tried again with Kubuntu 19.04 and I was suprised to see that ROCm refused again to install so I had to go back until last year.
This is insane, since it's mostly an artificial limitation, it's not like the newer distros are worse or don't have what the old ones had.
Plus newer CPUs and GPUs require newer kernel, which ROCm doesn't like.
ROCm developers should stop thinking that people use their computers just for ROCm and they don't need anything else and they can be stuck in the past.

Looking at changelogs, most changes cover Wayland or graphics design. Which is to say, are cosmetic changes unless you are actually using Wayland as well - latter of which is available in 19.04 "for testing" and sane user should not use anyway.. So, I still fail to see, what's the precise problem of using Plasma 5.12 LTS. It's LTS, so it should be stable to use.

ROCm devs might be out of their teens, more satisfied with mature code (as people age, they become more conservative) and thus might not give flying fuck about "newest and shiniest".. Plus, developing for older kernels actually does help non-Linux OS'es where another set of dev's have to work around 'Linuxisms' in code in order to port the driver. More deviations: harder it becomes.

[Danny3]

Amazing cry-story. Is the "1y old distro" functionally so different from bleeding edge, or what? Most would never notice differences, except by checking version numbers..

Yes!
Kubuntu 18.04 comes with KDE Plasma 5.12
Kubuntu 19.04 comes with KDE Plasma 5.15, upgradeable to 5.16
There is a huge difference between KDE Plasma 5.12 and 5.16.
For this I tried to install first Kubuntu 19.10 from nightly builds, but ROCm refused to install.
Tried again with Kubuntu 19.04 and I was suprised to see that ROCm refused again to install so I had to go back until last year.
This is insane, since it's mostly an artificial limitation, it's not like the newer distros are worse or don't have what the old ones had.
Plus newer CPUs and GPUs require newer kernel, which ROCm doesn't like.
ROCm developers should stop thinking that people use their computers just for ROCm and they don't need anything else and they can be stuck in the past.

[finalzone]

I have a Radeon RX 460 running on Fedora 30, with the radeon and radv drivers working just fine.

How do I go about enabling ROCm so that I gain OpenCL acceleration?

Take a look at https://github.com/RadeonOpenCompute...dora/Fedora_29 to install the repository and

sudo dnf install rocm-opencl

Note that OpenCL is currently broken on rocm 2.7.2.

[aht0]

They should improve the insanely hard way to install ROCm on the latest distributions.
Not everyone wants to be stuck with a more than 1 year old distribution and kernel just to use ROCm.
After I found out that the install refuses to work because I have a distribution and kernel too new I had to format everything and:
Install Kubuntu 18.04 -> Install ROCm -> Upgrade to Kubuntu 19.04 -> Upgrade KDE Plasma -> Upgrade Kernel to 5.2
Just to get closer to what I want a system with latest KDE plasma and kernel that it be good for everything including some gaming.
They should stop with versions checking on distribution and kernel and just try to install it anyway, not put put us to install more than 1 year old distribution and kernel just to make it work.
I think that the whole ROCm installation is just pure crap and they should stop immediately with these artificial limitations.

Amazing cry-story. Is the "1y old distro" functionally so different from bleeding edge, or what? Most would never notice differences, except by checking version numbers..

[mannerov]

I try from time to time (about every 6 months) RocM, using a ubuntu installation just for that.
More things work overtime, but there is always things that are supposed to work that don't, or are incredibly hard to set up, and essential things that don't work.

I also don't get the hip vs opencl. For example they have a very good clFFT. Why spend time write a hip version (which last I checked was performing worse). If hip worked well with opencl they wouldn't need that.

I think the focus should be on getting things they started finish and upstream them as soon as possible. The more things are upstreamed, the easier it is to install and use, and the low the chances of bugs. It should also help maintenance.

[Naquatis]

Even the compile times on opencl-amd take far too long.
No idea who like to use ROCm if it does not work in real world applications like Blender?

[MadeUpName]

A few months ago I tried to setup TensorFlow with ROCm support and gave up at some point. The ROCm toolchain seems to be insanely complicated (IMHO it's a complete mess).
Your best bet would be a LTS distro and the AMD-built package repositories. Have a look here: https://rocm-documentation.readthedo...m-repositories
Good luck!

I have Centos 7 on a different disk and boot into it when ever I need to use Davinci Resolve. That is all that is installed there as I wil never ever patch it because if you do it is permanently broken and needs to be reinstalled from scratch. It is a real mess.

i had read some where in the past that one of the reasons that it hasn't made it into the distros properly is that the source was in bad shape due to a sea of bad paths and links. I thought some one that frequents here was talking to AMD about how "make" could help them out with those issues. Any one know if that ever got any traction?