[pokeypokes]

Important to understand that with these kinds of libraries, it's one thing to get everything working, and a whole other to have it all be fast. Given finite resources AMD are (rightfully) focused on the second, for a narrower set of use cases - namely big customers with big pockets, using the latest compute cards.

See, for example, the world's fastest super computer. That's a whole lot more than a presentation tick box.

As someone doing relatively small scale work, on gaming cards, you just aren't the target user. While these kinds of users are well represented on forums, they're a rounding error in terms of actual $.

Switching to SYCL makes no sense. They need to unseat Nvidia, and specifically CUDA. The whole point of HIP is to clone CUDA, make it easy for users to switch and piggy back on Nvidias success.

I used to work in this space (not at AMD lol), and generally I don't think the comments on HN are fair to AMD. Obviously ROCm has a long way to go (CUDA and libs are some truly amazing work), but it's going.

[throwaway81523]

Don't know about the libs but CUDA itself is a C++ dialect targeted at a family of quirky array processors (GPU's). That takes some dev work by compiler hackers but doesn't seem amazing. Am I missing something? It's of course still easy to mess up such a project by not bringing enough clue, and AMD might have done that with ROCm. Is that what happened, or is it something different?

[pjmlp]

CUDA is more than a C++ dialect, which is a big thing people keep missing with all those "CUDA replacements".

Until CUDA 3.0, it was similar to OpenCL, a C dialect, however afterwards it became a C, C++ dialect, with common infrastructure PTX.

PGI targeted PTX, with their C, C++, and very relevant, Fortran compilers for HPC.

PGI was acquired by NVidia, and became the main set of CUDA compilers.

Given PTX, many other languages started targeting CUDA as well, Java, .NET, Haskell, Julia, at very least.

NVidia is now invested into a Python JIT for CUDA as well.

So yeah, while C++20 is the main language in CUDA, there is also a whole ecosystem of programming languages, that the "CUDA replacements" keep ignoring.

[throwaway81523]

In these CUDA vs ROCm comparisons I think they mostly compare the C++ dialects. And it's not even particularly the language implementation where ROCm is weak, but rather, the whole tool chain. Am I mistaken?

[pjmlp]

Which is why it will never be a CUDA replacement, for most C++ users maybe, for the whole ecosystem definitly not.

[throwaway81523]

Well the C++ segment is important and from what I gather, ROCm is failing at that. AMD would be a lot better off if the C++ part worked, even if the other parts don't.

[pjmlp]

True, not even that works that well.

[imtringued]

>As someone doing relatively small scale work, on gaming cards, you just aren't the target user.

He didn't use gaming cards. He bought the expensive $1.5k "workstation" graphics cards. What exactly is one going to use these GPUs for, other than GPGPU? Play video games? Really?

>While these kinds of users are well represented on forums, they're a rounding error in terms of actual $.

There are only three thousand developers who have ever committed to pytorch. Compared to a datacenter contract, that is a rounding error in terms of sales. Hence AMD shouldn't waste time on letting people independently work on AMD support for pytorch. They should only work on pytorch, whenever there is a big contract.

However, switching to SYCL makes no sense because Mesa is getting SYCL support. The likelihood that the mesa drivers cause a kernel panic is much lower.