AMD ROCm Open-Source Stack Coming To Xilinx FPGAs

[ivan.cwb]

We have been working from the bottom up - first step was making sure we had KFD/ROCR running on all new hardware starting with Picasso and Navi1x. We are just rolling out the next step now, which is making KFD/ROCR the default OpenCL back end for all Vega and Navi parts on Linux.

Michael's OpenCL testing for the 6800/XT used the ROCm back end.

Thanks for the good work.

Currently, I'm using a amd+amd notebook (coming from a nvidia laptop) and I'm pretty satisfied with its performance on Linux.

[Setif]

Nvidia has CUDA.
Intel has OneAPI.
AMD sticks with OpenCL (with ROCm backend).
What a mess!

[oleid]

Nvidia has CUDA.
Intel has OneAPI.
AMD sticks with OpenCL (with ROCm backend).
What a mess!

It would seem you're not informed. ROCm has HIP, which can be used to make CUDA portable. So that it can run on both, Nvidia and AMD cards.
That was (AFAIR) used to port over tensorflow and friends. Instead of cuBlas, there is rocBlas and so on.

So no, AMD not only has OpenCL, but is also kind of Cuda compatible.

[bridgman]

Nvidia has CUDA.
Intel has OneAPI.
AMD sticks with OpenCL (with ROCm backend).
What a mess!

Nvidia has CUDA and OpenCL.
Intel has OneAPI and OpenCL.
AMD has HIP and OpenCL (although HIP needs more work to be ready for Navi)
HIP code runs on AMD or NVidia.

[Setif]

Nvidia has CUDA and OpenCL.
Intel has OneAPI and OpenCL.
AMD has HIP and OpenCL (although HIP needs more work to be ready for Navi)
HIP code runs on AMD or NVidia.

I know, but both Intel and Nvidia are focusing on their own APIs (support & performance) and pushing developers to use them.

[tajjada]

I just wish Vulkan was taken more seriously for compute. We could really have one truly universal and well-supported GPU API for both graphics and compute.

[bridgman]

I know, but both Intel and Nvidia are focusing on their own APIs (support & performance) and pushing developers to use them.

Yep, and so are we. The only gap right now is HIP support on consumer cards, but we are making progress there as well.

That said, HIP allows a single code base to run on both AMD and NVidia; I'm not sure about running over Intel HW with their new direction but it was looking promising a few years ago.

It's also worth noting that all of these APIs are basically single-source C++ environments, so there has been a lot of convergence already.

[andrei_me]

Yep, and so are we. The only gap right now is HIP support on consumer cards, but we are making progress there as well.

But as those efforts doesn't receive Phoronix attention, we (as phoronix's readers) have the impression that AMD is doing nothing about it

[bridgman]

Ah yes... the "if a tree falls in the forest..." problem.

Michael did mention that we were using KFD/ROCR paths for OpenCL on the new GPUs but I expect everyone scrolled past it to get to the benchmarks. I know I did

With the Radeon RX 6800 series there is at-launch support available with working OpenCL provided by the "ROCr" (runtime) path in their packaged driver.

While there are the multiple driver options for AMD Radeon GPUs when it comes to OpenGL/Vulkan support on Linux, as outlined in the prior article, fortunately there isn't that level of driver fragmentation on the OpenCL side. The only OpenCL support option right now is the ROCm-based OpenCL code path found in the packaged driver and presumably within the open-source ROCm repository shortly. (Well, there is also OpenCL support via Clover Gallium3D but that is still a work-in-progress and lacking OpenCL image support among other features... And isn't officially supported by AMD. There are also the various open-source projects like CLSPV for running OpenCL kernels atop Vulkan, but those too tend to be in early stages... So unlike the OpenGL/Vulkan AMD Linux driver and the multiple viable options, the ROCm OpenCL path is the de facto solution for now and far less confusing for Linux consumers.)

The Geekbench 5 OpenCL results is one of the few cases where the RX 6800 XT came up well short for compute performance of the RTX 3080 -- in fact, below the RTX 2080 Ti and TITAN RTX. Meanwhile though the RX 5700 / RX 5700 XT on Linux with the ROC OpenCL stack were hung during this workload, so at least Big Navi even managed to run compared to compute being an after thought on those original Navi GPUs.

I'm not 100% sure since AFAIK Michael installed multiple OpenCL back ends, but I believe that all of the tested AMD GPUs were running with the ROCr back end, ie even Navi10. Even with multiple back ends installed I *think* the default was flipped for all of the Vega and Navi cards.

EDIT - confirmed, only "legacy" and "rocr" backends were included in 20.45, so the Navi10 cards were running OpenCL over the core ROCm code along with Radeon VII and the 6800/XT cards.

If I had free time I would help get some of Michael's CUDA tests running on HIP, but I don't see "free time" happening any time soon.

[coder]

If I had free time I would help get some of Michael's CUDA tests running on HIP, but I don't see "free time" happening any time soon.

I feel you, but isn't that what interns are for? Maybe some of the more involved ports could be conducted through a summer-of-code type program.