ROCm and HIP - https://github.com/ROCm-Developer-Tools/HIP, as it has been for the last 3-4 years

unless you have navi, in which case rocm is not supported and doesn't work and I guess AMD expects you to use opencl.

Navi just began to compile a week or two ago. Still 'unsupported', but its slowly gaining features.

ROCm is a bit uneven with what cards it supports. Ex: Rx 550 never was supported (even though Polaris, the rest of the 5xx series worked). It seems like the only cards ROCm works for are the ones that share a chip and/or driver with AMD's "Machine Intelligence" line of cards. (MI50, MI60, etc. etc.). Which are Fiji (Rx Fury), Polaris (Rx 580), Vega, and Radeon VII.

CUDA is a "works on all NVidia devices" kind of thing. So I think people are surprised when they have to read the docs for AMD's ROCm.

> Navi just began to compile a week or two ago. Still 'unsupported', but its slowly gaining features.

14 months after release, still unsupported. AMD needs to step up to the plate if they want to be seriously considered in the AI world.

Its pretty clear what's going on: AMD doesn't have the resources to support all the GPUs they release on ROCm. They focus on the "MI" line of cards, which have similarities to the consumer GPUs. (Ex: Rx Fury is very similar to MI8).

Because MI8 and Rx Fury have similarities, AMD gives ROCm support to both. Ditto with MI25 and Vega, and MI6 and Rx 580.

EDIT: With "Navi" gaining features in ROCm repos, my bet is that a new MI-card based on RDNA2 might be coming out soon. Maybe its Arcturus (the Exascale GPU for the Frontier supercomputer).

No, Arcturus is CDNA (the Compute rather than Render architecture). Still with the Radeon VII EOL it would be good if they had a consumerish ROCm card, so RDNA2-support would be great.

Last time I tried, PCIe 3.0 was also a requirement, although that wasn't much of an issue unless it was some nonstandard configuration like an RX 580 in a junkyard find A4 APU machine.

The industry at large is moving to SYCL, which can be implemented on top of OpenCL / CPUs / FPGAs.

I'm not sure what part of 'the industry' you're referring to, but last time I looked (which was admittedly more than a year ago), there is only one serious SYCL implementation, it's proprietary and the only people pushing SYCL are... drum roll... the people selling that implementation. That's not even considering that OpenCL is in most cases (way) behind CUDA in performance, not to mention that the tooling for OpenCL is outright primitive. And all of that is not even mentioning that nvidia drags their feet massively in supporting newer OpenCL version on their GPU's.

Maybe things have changed massively very recently, but I came back from iwocl (the OpenCL and SYCL conference) two years ago massively disappointed. And I still don't see anyone in the slice of the HPC space I'm familiar with (environmental & GIS-related modeling) using it, for a reason I presume.

Intel are supporting SYCL in a big way. They are implementing SYCL in the open source LLVM project, the project is called DPC++. Argonne National Labs are also using SYCL to program the exascale supercomputer (Aurora) they are building. Whilst it's not the best solution for everyone there is certainly industry support for it.

https://software.intel.com/content/www/us/en/develop/tools/o... https://github.com/intel/llvm/blob/sycl/sycl/doc/GetStartedG... https://www.alcf.anl.gov/support-center/training-assets/road...

Oh, the third option, with absolutely no library support. Or, looking at Khronos's page, even device support. At least OpenCL has the benefit of wide compatibility, even if its performance meant it was unsuitable.

Nvidia has settled on CUDA, and has maintained 13 years of compatibility. If SYCL is going to ever compete with CUDA, it's going to need to stick around long enough for people to build on it.

My firm does GPGPU programming for audio processing. Nobody in this area even thinks of using anything other than CUDA. It has far more support, tools, compilers, etc.

What about the Mac side of things ? Mac's are still pretty big in audio production, but they don't support CUDA (and don't come with Nvidia GPUs any more anyway). How does Metal Compute stack up ?

We don't use Macs. While many uusicians use macs, the people on the engineering/scientific side of things don't. We're not doing music audio.

Well, Nvidia invented CUDA, it's no surprise that they won't give up their competitive advantage by properly supporting OpenCL or SYCL.

Edit: Also, SYCL should be supported by most things already supporting OpenCL, like Tensorflow for example.

I think OpenMP device offload has a better chance than SYCL or OpenCL. But I'm not in the industry.

CUDA's single-source environment is very good compared to SYCL or OpenCL. OpenMP still has single-source (just #pragma target), and is already adopted by the HPC crowd for multithreaded programming. NVidia and AMD support seems to be growing, especially because OpenMP is important to the supercomputer folks. (Summit and Frontier)

ROCm is CUDA-like and mostly works. The main issue is that CUDA will always remain a few steps ahead as AMD is forced to play "catchup". (ex: Cooperative groups are useful but unimplemented for now in ROCm). ROCm's main issue is being stuck in Linux, they need some Windows support if they want ROCm to really take off.

Didn't they plan to merge OpenCL and Vulkan?

this is nice, do you have any more details?