The State Of ROCm For HPC In Early 2021 With CUDA Porting Via HIP, Rewriting With OpenMP

[qarium]

In case it helps, the "limited to an older kernel" issue only applies if you are using our DKMS kernel driver package.
The kernel source code goes upstream quite aggressively (with the exception of a couple of non-upstreamable bits like RDMA) and the binary packages are organized so that you can either install userspace only (with a newer kernel) or userspace and kernel drivers (with an enterprise distro's older kernel).
If you have a newer kernel that the DKMS package doesn't support just install the rocm-dev meta-package only, although going to the newest easily obtainable kernel is a good idea in that case.
https://rocmdocs.amd.com/en/latest/I...r-AMD-GPU.html
This seems to have disappeared from the top level install instructions again - I'll go find out what happened.
Another option is to build everything from source, but last time I looked it was still a bit clunky until the build frameworks get cleaned up and harmonized a bit more.
Most of our major customers build from source, by the way.
Minor nitpick - I think it's actually Radeon Open Compute platforM.

why not just release it for the newest fedora?

"Most of our major customers build from source, by the way."

this really sounds like you screw any normal customer and you only target some HPC Super Computer customers.

it really sounds like i am not a AMD customer at all... but all my hardware CPU+GPU is from AMD...

[phred14]

ROCm's attitude of "we don't care desktop use case" is precisely what makes CUDA popular and ROCm/OpenCL unpopular. It's too hard to experiment OpenCL through ROCm in one's own PC. OpenCL was supposed to be portable. Blender has CG render via CUDA/OpenCL. LibreOffice implements OpenCL-assisted spreadsheet calculation. LeelaZero plays Go games in OpenCL (and inspires various small projects to do AI in GPU for various chess type or strategy type games) GPU compute can be huge if AMD really make their OpenCL implementation work out of box. But sadly, no. They are busy chasing something out of reach of personal users and after so many years, their chase seems fail to lure those CUDA-specific frameworks and applications runnable by AMD hardware out of box.

Sometimes i wonder, if AMD could focus on making their OpenCL implementation rock solid and work out of box (or at least within reach of simple installation with 100% success rate) to all their APU/GPU, those frameworks that AMD chased hard by creating HIP or OpenMP or whatever would have already ported themselves to OpenCL and users rejoice. The "general purpose" in GPGPU shouldn't be only about academic HPC.

I've already done some of this, though I haven't been able to put much time into it. This is on Gentoo, and I built the ROCm packages as my OpenCL implementation, then found an OpenCL test suite. About 2/3 or so of the tests passed, a few completely failed, and the rest partially failed. I haven't actually tried to OpenCL-enable any applications yet. I've installed mandelbulber, largely for the purposes of testing OpenCL, but haven't been able to actually get it to rebuild for OpenCL yet. I did a little bit on my previous computer with OpenCL, notably mandelbulber, and remember having trouble building it that time, too.

[boboviz]

ROCm's attitude of "we don't care desktop use case" is precisely what makes CUDA popular and ROCm/OpenCL unpopular. It's too hard to experiment OpenCL through ROCm in one's own PC. OpenCL was supposed to be portable. ....... The "general purpose" in GPGPU shouldn't be only about academic HPC.

This is the first Boinc project that is trying to create an rocm app to distribute to pc ('cause Pytorch does not have offical opencl support).

https://www.mlcathome.org/mlcathome/

[MadeUpName]

While I agree that there have been and probably still are issues how AMD has handled ROCm all of the blame can not be laid at AMDs feet at least as far as smaller users are concerned. AMD wrote the code and released it as open source. Where the bigger issue is right now is with the distros that refuse to package it. Fedora for example finally compiled a rocm-runtime version that includes image support in Koji but didn't include the other pieces needed to provide image support. The person that updated the rocm-runtime said they were going to do the other packages as well but if you look at Bugzilla it has been reassigned a number of times and the whole thing now seems to be abandon-ware. If you want it to just work like mesa then it needs to be packaged by the distros.

As for amdgpu-pro wow is that thing hit and miss. Some times it works some times it doesn't. My finding is if I upgrade the kernel it breaks the graphics so bad that the kernel won't even boot to rescue mode meaning you have to re-install. My desktop runs Fedora because I need packages that aren't based on 10 year old tech but then I have a separate disk that I dual boot to Centos that has what I finally got to work. I have then dd'd that off so I can get back to it if I need to. Then backed that image up in two different places. I then never ever patch. Needless to say none of this is stuff that any sane person is going to want to put up with.

Right now both the distros and AMD seem to have taken the approach that if you don't have a super computer you shouldn't want compute which then brings up the question why do they put it in their consumer graphics cards? I have supported AMD through thik and thin even through Bulldozer. But I am really coming to hate AMD solely because of all the sh_it with ROCm/AMDGPU-pro and for the first time in over a decade I am rooting for Intel to finally let normal Linux user have access to compute.

[MadeUpName]

Is it possible to use ROCm to run Folding@home with RDNA2-card on Fedora? Do I compile the OpenCL-runtime from https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/tree/rocm-4.0.0 ?

Do you know if Folding@home needs image support? If not you may be be able to run it with the packages available from the distro. I would give you a list of which ones to load but I have installed so many different packages over the last couple of years desperately trying to get it to work I don't know which ones contributed to making it work (with out image support) and which ones are just taking up space.

[bridgman]

why not just release it for the newest fedora?

The generic answer to most "why not do XYZ ?" questions is that we didn't have the money/staff to do all these things at once and so we had to initially focus on a subset of the market. I wasn't a fan of focusing on large datacenter customers first, but we are now starting to get enough revenue to fill some of the money/staff gaps and get the ROCm stack extended across all of our products.

"Most of our major customers build from source, by the way."

this really sounds like you screw any normal customer and you only target some HPC Super Computer customers.

it really sounds like i am not a AMD customer at all... but all my hardware CPU+GPU is from AMD...

You're taking that comment out of context - someone posted about how Google would not be willing to put up with package installation challenges, and my response was to that comment only. That said, I don't think we have done a good enough job of supporting individual developers/users on the compute side and have been working for a couple of years (with some success) to change that. We have discussed that before.

[bridgman]

Right now both the distros and AMD seem to have taken the approach that if you don't have a super computer you shouldn't want compute which then brings up the question why do they put it in their consumer graphics cards? I have supported AMD through thik and thin even through Bulldozer. But I am really coming to hate AMD solely because of all the sh_it with ROCm/AMDGPU-pro and for the first time in over a decade I am rooting for Intel to finally let normal Linux user have access to compute.

Not sure I understand the first part of your question - most of the flak we have received recently is because we are *not* supporting the ROCm stack on consumer cards yet.

If you are asking why we support it on older consumer cards the answer is simply that we were using the same GPU in consumer and datacenter cards. We were not able to get funding/staffing at the time to implement on newer consumer cards after the CDNA/RDNA fork, but we are making progress on catching up again.

[wallcarpet40]

Do you know if Folding@home needs image support? If not you may be be able to run it with the packages available from the distro. I would give you a list of which ones to load but I have installed so many different packages over the last couple of years desperately trying to get it to work I don't know which ones contributed to making it work (with out image support) and which ones are just taking up space.

I don't know, if FAH needs image support. I was able to install rocm-opencl-runtime from AUR on Arch and it pulled some dependencies https://i.imgur.com/pmUdpyM.png
so I guess those would be the packages to look for on Fedora.

But I guess the RDNA1/RDNA2 cards aren't supported yet according to https://github.com/RadeonOpenCompute/ROCm/issues/1376

I tried FAH on Arch and it recognizes the 5700XT on rocm, but once started, it just stays at 0%. I guess I'll keep an eye on the github-thread above.

[MadeUpName]

Not sure I understand the first part of your question - most of the flak we have received recently is because we are *not* supporting the ROCm stack on consumer cards yet.

I am asking why I have to pay for the expense of the compute units if they can't be used due to the drivers. It just runs up the cost of the card. I want working compute but I don't want to pay for it if it doesn't work.

[MadeUpName]

I don't know, if FAH needs image support. I was able to install rocm-opencl-runtime from AUR on Arch and it pulled some dependencies https://i.imgur.com/pmUdpyM.png
so I guess those would be the packages to look for on Fedora.

But I guess the RDNA1/RDNA2 cards aren't supported yet according to https://github.com/RadeonOpenCompute/ROCm/issues/1376

I tried FAH on Arch and it recognizes the 5700XT on rocm, but once started, it just stays at 0%. I guess I'll keep an eye on the github-thread above.

If you run clinfo what does it say? clinfo is a seperate package.