4 ms·

EDIT: if the chart on the Anandtech review is true I have to take back what I wrote below. I didn't know the AMD Radeon Instinct MI50 (6.7 TFLOPS FP64, 16 GB me

EDIT: if the chart on the Anandtech review is true I have to take back what I wrote below. I didn't know the AMD Radeon Instinct MI50 (6.7 TFLOPS FP64, 16 GB memory with ECC and also 1 TB/s bandwidth) only costs 1000 USD, I expected it to be closer to the FirePro cards. So if you don't need active cooling this seems like a even better choice. Good that AMD reverted their decision on FP64 which means the card has 3.5 TFlops. The only real competitor in the consumer space seems to be the Nvidia Titan V which has 6.9 TFlops, 12 GByte of memory with 652.8 GB/s and costs 3000 USD. The Radeon 7 only has half of the TFLOPS for FP64 but 16 GByte with 1024 GB/s and only costs 700 USD. I don't have a use case for double precision but I'm sure people who need it will like the card.

bitL 8y ago
The compute performance was quite low for 3.5TFlops, in F@H even beaten by 2070... I am wondering if it's again drivers/SW holding AMD back, like with Deep Learning (in theory 15TFlops, in practice 7.5 etc.)
- dragontamer 8y ago
  NVidia's Turing cores are clearly more dynamic than AMD's. There are also driver issues for sure. ROCm and RadeonGPU-Pro (two different OpenCL implementations) have numerous differences in performance. ROCm 2.1 is still absolutely awful at Blender for example (definitely use RadeonGPU-PRO drivers for that instead). In some cases, I bet on Ahmdal's law. NVidia has fewer shaders at a higher clock than AMD. AMD's architecture is implicitly more parallel than NVidia's, so Ahmdal's law will hurt it (AMD's 4096 shaders on Vega64 will use more RAM than NVidia's 2304 CUDA shaders on the 2070). In others, it seems like AMD's drivers are still unoptimized. Something weird is going on with Blender's code and ROCm for example. -------- EDIT: I've seen some profiler data, and it seems like AMD's GPUs are rarely compute-ALU bound. They are often memory-bound. So AMD has far too strong compute for the graphics problems at hand. Alternatively, AMD's algorithms may be poorly tuned: they probably should be more compute heavy and try to use less RAM Bandwidth.
- throwaawyw 8y ago
  3.5 Tflops at double precision. The applied math/scientific computation people are going to love this.
  - bitL 8y ago
    I was talking about FP64 ofc.
throwaawyw 8y ago
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.
dman 8y ago
Think Anandtech has made a mistake with the price of the Instinct card.

bitL 8y ago

The compute performance was quite low for 3.5TFlops, in F@H even beaten by 2070... I am wondering if it's again drivers/SW holding AMD back, like with Deep Learning (in theory 15TFlops, in practice 7.5 etc.)

dragontamer 8y ago
NVidia's Turing cores are clearly more dynamic than AMD's. There are also driver issues for sure. ROCm and RadeonGPU-Pro (two different OpenCL implementations) have numerous differences in performance. ROCm 2.1 is still absolutely awful at Blender for example (definitely use RadeonGPU-PRO drivers for that instead). In some cases, I bet on Ahmdal's law. NVidia has fewer shaders at a higher clock than AMD. AMD's architecture is implicitly more parallel than NVidia's, so Ahmdal's law will hurt it (AMD's 4096 shaders on Vega64 will use more RAM than NVidia's 2304 CUDA shaders on the 2070). In others, it seems like AMD's drivers are still unoptimized. Something weird is going on with Blender's code and ROCm for example. -------- EDIT: I've seen some profiler data, and it seems like AMD's GPUs are rarely compute-ALU bound. They are often memory-bound. So AMD has far too strong compute for the graphics problems at hand. Alternatively, AMD's algorithms may be poorly tuned: they probably should be more compute heavy and try to use less RAM Bandwidth.
throwaawyw 8y ago
3.5 Tflops at double precision. The applied math/scientific computation people are going to love this.
- bitL 8y ago
  I was talking about FP64 ofc.

throwaawyw 8y ago

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.

dman 8y ago

Think Anandtech has made a mistake with the price of the Instinct card.