3 ms·

The only disappointment is that AMD's software stack is very lacking for compute. While, Nvidia commands absurd prices for 2080Ti with a mere 11GB GDDR6, Radeon

The only disappointment is that AMD's software stack is very lacking for compute. While, Nvidia commands absurd prices for 2080Ti with a mere 11GB GDDR6, Radeon's with 16 GB of HBM2 are closer to the memory spec of Titan V100. OpenCL, while being a much cleaner API, suffers badly from the lack of quality libraries. The requirements aren't even that large for the killer application of DL - BLAS, a few convolution kernels, and random number generation. Darknet's {of the YOLO fame} interface to CUDA, for instance is composed of fewer than 10-15 functions. AMD's efforts in this regards have not been very satisfactory IMO. Infact third party work such as CLBLAST are of much higher code quality than libraries like AMD's own CLBLAS (or it was). Sadly, AMD over the past few years has seems to have come under the belief that building a transpiler from CUDA bytecode to AMD's would be the magic bullet. It remains to be seen if this will suffice, but it does seem like a quixotic solution to a straightforward problem. Had such a foundational software libraries (which mind you requires a lot of harware tailored optimization ) been perfected over the past few years (even while being multiple years behind NVDA), they could easily have turned the game, more so considering NVDA's shady tactics of banning GTX/RTX cards in the cloud. I don't know what went wrong. It's not like AMD didn't have engineers working on ML applications; the direction seems misguided - AMD's engineers (unlike NVDIA's) seem to have focussed on porting frameworks onto low quality libraries, rather than securing the foundation. I'm afraid the ROCm effort will have the same effect.

dman 8y ago
Could not agree with you more - tracking the AMD compute story has been painful. Talks about having Tensorflow / Torch upsptream support have been going on forever. Reading between the lines OpenCL seems to not be the favored way to do compute anymore, so its unclear if I was starting today what the canonical forward looking path is for writing compute on AMD cards.
- dragontamer 8y ago
  > I was starting today what the canonical forward looking path is for writing compute on AMD cards. HCC and HIP seem to be the canonical compute path forward, with compiled ahead-of-time OpenCL being supported as well. There's some "#pragma openmp target" tests in the Github repos. So AMD is clearly working on that as well. If HCC got OpenMP support, it would be significantly easier for typical programmers to write GPU code. -------- If I were starting a project today, it'd be OpenCL 1.2 on the AMDGPU-pro drivers (the old proprietary driver is more stable for sure), but with a careful eye on HCC / HIP advancements. HCC and HIP have gotten a huge amount of attention / github commits in the past year, so its clearly where AMD's main effort is going into.
dragontamer 8y ago
I disagree with OpenCL being a "clean" API. CUDA's API is far simpler than OpenCL, if only because you don't have to rewrite structures between your host-code and device code. Any "struct" or any other data you pass between CPU and GPU is automatically compiled by CLang / CUDA, and works on both. OpenCL on the other hand is... C-only (CUDA has C++), requires double-speak and has a compiler in the lol-device code. So compiler bugs are fixed by updating AMD Device Drivers on the client. Its... horrifying. This is not a way to build libraries. In contrast, CUDA compiler bugs are fixed by updating the programmer's compiler. > AMD's efforts in this regards have not been very satisfactory IMO. Infact third party work such as CLBLAST are of much higher code quality than libraries like AMD's own CLBLAS (or it was). Sadly, AMD over the past few years has seems to have come under the belief that building a transpiler from CUDA bytecode to AMD's would be the magic bullet. It remains to be seen if this will suffice, but it does seem like a quixotic solution to a straightforward problem. I happen to agree with it. AMD's CUDA transpiler is built on top of AMD's HCC efforts (a C++ single source environment). The code for HCC is far cleaner than anything I've ever seen in OpenCL, and is mostly compatible with CUDA (thanks to the efforts of HIP).
zozbot123 8y ago
Vulkan is actually intended as a stack for compute, not just graphics. That's probably our best chance for a cross-platform approach to GPU compute that can work roughly equally well on NV, AMD and the upcoming Intel GPU hardware.

dman 8y ago

Could not agree with you more - tracking the AMD compute story has been painful. Talks about having Tensorflow / Torch upsptream support have been going on forever. Reading between the lines OpenCL seems to not be the favored way to do compute anymore, so its unclear if I was starting today what the canonical forward looking path is for writing compute on AMD cards.

dragontamer 8y ago
> I was starting today what the canonical forward looking path is for writing compute on AMD cards. HCC and HIP seem to be the canonical compute path forward, with compiled ahead-of-time OpenCL being supported as well. There's some "#pragma openmp target" tests in the Github repos. So AMD is clearly working on that as well. If HCC got OpenMP support, it would be significantly easier for typical programmers to write GPU code. -------- If I were starting a project today, it'd be OpenCL 1.2 on the AMDGPU-pro drivers (the old proprietary driver is more stable for sure), but with a careful eye on HCC / HIP advancements. HCC and HIP have gotten a huge amount of attention / github commits in the past year, so its clearly where AMD's main effort is going into.

dragontamer 8y ago

I disagree with OpenCL being a "clean" API. CUDA's API is far simpler than OpenCL, if only because you don't have to rewrite structures between your host-code and device code. Any "struct" or any other data you pass between CPU and GPU is automatically compiled by CLang / CUDA, and works on both. OpenCL on the other hand is... C-only (CUDA has C++), requires double-speak and has a compiler in the lol-device code. So compiler bugs are fixed by updating AMD Device Drivers on the client. Its... horrifying. This is not a way to build libraries. In contrast, CUDA compiler bugs are fixed by updating the programmer's compiler. > AMD's efforts in this regards have not been very satisfactory IMO. Infact third party work such as CLBLAST are of much higher code quality than libraries like AMD's own CLBLAS (or it was). Sadly, AMD over the past few years has seems to have come under the belief that building a transpiler from CUDA bytecode to AMD's would be the magic bullet. It remains to be seen if this will suffice, but it does seem like a quixotic solution to a straightforward problem. I happen to agree with it. AMD's CUDA transpiler is built on top of AMD's HCC efforts (a C++ single source environment). The code for HCC is far cleaner than anything I've ever seen in OpenCL, and is mostly compatible with CUDA (thanks to the efforts of HIP).

zozbot123 8y ago

Vulkan is actually intended as a stack for compute, not just graphics. That's probably our best chance for a cross-platform approach to GPU compute that can work roughly equally well on NV, AMD and the upcoming Intel GPU hardware.