5 ms·

Interestingly, AMD is claiming that their upcoming Vega Frontier Editions chips outperform Nvidia's current P100 Deep Learning chip. http://hexus.net/media/upl

Interestingly, AMD is claiming that their upcoming Vega Frontier Editions chips outperform Nvidia's current P100 Deep Learning chip. http://hexus.net/media/uploaded/2017/5/30f5633b-1bbf-49b7-9f31-7890e20db28f.jpg http://hexus.net/media/uploaded/2017/5/30f5633b-1bbf-49b7-9f...

sp332 9y ago
I think signs are pointing to Vega being a HPC beast. But what they really need is the software ecosystem and support, and so far that hasn't been there. So while the new hardware looks cool, I'm really waiting for an announcement that OpenCL tooling got a lot better, or that CUDA is getting first-party support from AMD, anything to tempt those customers away from nvidia.
- dragandj 9y ago
  CUDA is getting support from AMD in the form of HIP. In my opinion, the problem is different: even if AMD supported CUDA proper, that still won't lead them anywhere because the reason people use Nvidia is not so much CUDA itself (although it has good tools) but Nvidia's proprietary libraries: cuBLAS, cuDNN, cuFFT etc. If AMD provided good implementations of similar libraries with OpenCL and shipped them with their drivers (similarily to Nvidia's CUDA toolkit) that would be much better than supporting CUDA, but leaving the ecosystem bare bones again...
  - gbrown 9y ago
    https://github.com/clMathLibraries https://github.com/clMathLibraries
    - dragandj 9y ago
      There are even better independent open-source equivalents for some of those, but that is not the point. Good luck compiling some of AMD's clMath libraries without issues. Then, you're "just" left with packaging them properly. Performance is also not stellar compared to Nvidia. Meanwhile, when you install Nvidia's toolkit, you're set with everything.
  - AlphaSite 9y ago
    They have rocBLAS, etc.
- varelse 9y ago
  There's a real opportunity for AMD here if NVIDIA doesn't release a consumer variant of Volta because Titan X Pascal intentionally cripples FP16 performance to drive P100 adoption. It's the same sort of nonsense they pulled with crippling FP64 performance on GTX Titan (Maxwell) to drive K20/K40/K80 adoption, but it got old a long time ago. What's more interesting is the disruptive change to the underlying programming model for Volta (thread-within-thread) that will break a lot of existing CUDA code without refactoring. So if there's no GeForce Volta option, I suspect a lot of that code won't get refactored. So Vega just needs to not suck and to deliver decent TensorFlow/Torch/Caffe performance to succeed as an alternative to NVIDIAopoly.
  - bmiranda 9y ago
    Not having fast FP64 is a design decision. Space isn't free, and FP64 takes up a lot of space that could be used on delivering higher FP32 perf, which is more important for video games.
    - varelse 9y ago
      Except that's not how it played out. The Tesla GPU all the way through Maxwell was just a different binning of the GeForce GPU, usually clocked lower for passive cooling and improved stability (sure, K80 is an exception, but K80 is a strange and tragic evolutionary dead-end IMO). Tesla P100 was the first real HW-level divergence with its 2x FP16 support. But because we still can't have nice things, GTX 1080 was the first GPU with fast INT8/INT16 instructions, followed by the mostly identical except much more expensive Tesla P40. So we ended up with the marchitecture nonsense that P100 was for training as P40 is for inference despite being mostly identical except as noted above. I'll assume Volta unifies INT8/INT16/FP16? And I think it's OK if the Tesla card has higher tensor core performance, but if the tensor core on GeForce is slower than its native FP16 support, I can only conclude NVIDIA now hates its own developers and has decided to sniff its own exhaust pipe. Isn't having to refactor all existing warp-level code for thread-within-thread enough complication for one GPU generation? Also, if consumer Volta ends up with craptastic FP16 support (ala 1/64 perf in GP102 vs GP100, slower than emulating it with FP16 loads and FP32 math), NVIDIA will create a genuine opening for AMD to be the other GPU provider in deep learning.
- ktta 9y ago
  You might be interested in knowing that OpenCL is merging with Vulkan's API[1], so there'll likely be a lot more support in the future. [1]:https://news.ycombinator.com/item?id=14383296 https://news.ycombinator.com/item?id=14383296
  - dogma1138 9y ago
    The problem with OpenCL is the lack of well performing libraries, AMDs Core Math and Performance libraries are utter garbage still. If you can't do what Blender did and write everything from scratch including your primatives you'll be much slower than CUDA. But there is also a cost to it the Blender Cycles OpenCL code is nearly 5 times as big as their CUDA code and Cycles on OpenCL is still not at a feature parity with CUDA. The change in branding would likely not yield much for it.
    - ktta 9y ago
      I haven't heard much about AMD's ACML and ArrayFire but I'm not surprised. On the other hand, I think you're underestimating the fact that OpenCL is an open spec and therefore has support from the FOSS world. CUDA has always been criticized for being closed source. Even though OpenCL doesn't get much praise, and actually get criticized a bit (I'm personally not a big fan because writing OpenCL code is like bending over backwards). It has a lot of potential with new libraries coming up[1] which can possibly make it atleast on par with CUDA. Once that happens, AMD's cost effective cards will put it in the race. [1]:https://github.com/clMathLibraries https://github.com/clMathLibraries
      - dragandj 9y ago
        [1] is actually AMD's old libraries. Judging by dev activity, it seems to be abandonware in favor of https://github.com/RadeonOpenCompute https://github.com/RadeonOpenCompute which is itself not ready for prime time.
        dogma1138 9y ago
        ROCm is an amalgamation of a lot of things, some new some (very) old. It still relies on many pretty old libraries with questionable performance at best. The newer stuff is good but it's tailored to AMD GPUs, don't expect interoperability when it comes to any reasonable performance if you want to run ROCm OpenCL on NVIDIA or Intel hardware.
- nicwilson 9y ago
  I am working on [dcompute](https://github.com/libmir/dcompute https://github.com/libmir/dcompute) which I hope will bring an equivalent experience when running on OpenCL and CUDA, and being written in D will provide all the advantages it does to writing kernels as it does with writing host code (with of course the ability to share compile time information across host and device). I believe that this levelling of the playing field will let the best hardware win. If you have any question, please ask!
jbmorgado 9y ago
The question is not AMD's processing power, the question is the tools available for AMD cards, which are scant to say the best. While AMD doesn't create something like cuDNN to go along with their cards, no real work will start being done in porting most important DL libraries to AMD cards. And even in that case, it will be a lost generation for AMD, only in the 2nd generation where AMD actually offers a real alternative in DL to NVIDIA, you will start to see some real progress being done with it.
- redtuesday 9y ago
  They stated at the analyst day that they will support TensorFlow, Theano, Caffee etc. And will release something called MiOpen. They also stated this last year: > On top of ROCm, deep-learning developers will soon have the opportunity to use a new open-source library of deep learning functions called MIOpen that AMD intends to release in the first quarter of next year. This library offers a range of functions pre-optimized for execution on Radeon Instinct cards, like convolution, pooling, activation, normalization, and tensor operations http://techreport.com/review/31093/amd-opens-up-machine-learning-with-radeon-instinct http://techreport.com/review/31093/amd-opens-up-machine-lear...
  - PeterisP 9y ago
    That would be nice, more competition is better for the consumer. Still, it will affect purchasing decision only when it happens, and it hasn't happened yet.
  - throwaway32131 9y ago
    They don't have an implementation of in-place convolutions AFAIK. The im2col trick may be too slow in practice (read x2.5-10 slower) to make any difference in terms of adoption. We already see this with Caffe and cl-Torch.
dogma1138 9y ago
AMDs benchmarks are highly doubtful. DeepBench isn't a benchmark it's a benchmarking tool they haven't released what dataset nor what code were they running. Their SpecPerf View benchmarks were a total FUD they compared NVIDIAs consumer (GeForce) drivers against Radeon Pro drivers. The SPV benchmarks look impressive until you realize they are lower than a Quadro M5000 which is based on the same Maxwell chip that drives the 980ti. NVIDIA's consumer drivers (and the non Pro AMD ones) are simply horrible for CAD and other professional workloads. AMD has been touting better performance than NVIDIA GPUs in compute since Fiji and they do not deliver. It's also important to note that VEGA will have FP64 performance at 1/32 while the P100 is at 1/2. I'm sure you can find an OpenCL workload that NVIDIA would be utterly trash in because the code is not optimized heck working with 256 batches as recommended for AMD rather than 1024 as recommended for NVIDIA would achive that alone.
- AlphaSite 9y ago
  Deep learning doesn't use FP64 at all, does it?

sp332 9y ago

I think signs are pointing to Vega being a HPC beast. But what they really need is the software ecosystem and support, and so far that hasn't been there. So while the new hardware looks cool, I'm really waiting for an announcement that OpenCL tooling got a lot better, or that CUDA is getting first-party support from AMD, anything to tempt those customers away from nvidia.

dragandj 9y ago
CUDA is getting support from AMD in the form of HIP. In my opinion, the problem is different: even if AMD supported CUDA proper, that still won't lead them anywhere because the reason people use Nvidia is not so much CUDA itself (although it has good tools) but Nvidia's proprietary libraries: cuBLAS, cuDNN, cuFFT etc. If AMD provided good implementations of similar libraries with OpenCL and shipped them with their drivers (similarily to Nvidia's CUDA toolkit) that would be much better than supporting CUDA, but leaving the ecosystem bare bones again...
- gbrown 9y ago
  https://github.com/clMathLibraries https://github.com/clMathLibraries
  - dragandj 9y ago
    There are even better independent open-source equivalents for some of those, but that is not the point. Good luck compiling some of AMD's clMath libraries without issues. Then, you're "just" left with packaging them properly. Performance is also not stellar compared to Nvidia. Meanwhile, when you install Nvidia's toolkit, you're set with everything.
- AlphaSite 9y ago
  They have rocBLAS, etc.
varelse 9y ago
There's a real opportunity for AMD here if NVIDIA doesn't release a consumer variant of Volta because Titan X Pascal intentionally cripples FP16 performance to drive P100 adoption. It's the same sort of nonsense they pulled with crippling FP64 performance on GTX Titan (Maxwell) to drive K20/K40/K80 adoption, but it got old a long time ago. What's more interesting is the disruptive change to the underlying programming model for Volta (thread-within-thread) that will break a lot of existing CUDA code without refactoring. So if there's no GeForce Volta option, I suspect a lot of that code won't get refactored. So Vega just needs to not suck and to deliver decent TensorFlow/Torch/Caffe performance to succeed as an alternative to NVIDIAopoly.
- bmiranda 9y ago
  Not having fast FP64 is a design decision. Space isn't free, and FP64 takes up a lot of space that could be used on delivering higher FP32 perf, which is more important for video games.
  - varelse 9y ago
    Except that's not how it played out. The Tesla GPU all the way through Maxwell was just a different binning of the GeForce GPU, usually clocked lower for passive cooling and improved stability (sure, K80 is an exception, but K80 is a strange and tragic evolutionary dead-end IMO). Tesla P100 was the first real HW-level divergence with its 2x FP16 support. But because we still can't have nice things, GTX 1080 was the first GPU with fast INT8/INT16 instructions, followed by the mostly identical except much more expensive Tesla P40. So we ended up with the marchitecture nonsense that P100 was for training as P40 is for inference despite being mostly identical except as noted above. I'll assume Volta unifies INT8/INT16/FP16? And I think it's OK if the Tesla card has higher tensor core performance, but if the tensor core on GeForce is slower than its native FP16 support, I can only conclude NVIDIA now hates its own developers and has decided to sniff its own exhaust pipe. Isn't having to refactor all existing warp-level code for thread-within-thread enough complication for one GPU generation? Also, if consumer Volta ends up with craptastic FP16 support (ala 1/64 perf in GP102 vs GP100, slower than emulating it with FP16 loads and FP32 math), NVIDIA will create a genuine opening for AMD to be the other GPU provider in deep learning.
ktta 9y ago
You might be interested in knowing that OpenCL is merging with Vulkan's API[1], so there'll likely be a lot more support in the future. [1]:https://news.ycombinator.com/item?id=14383296 https://news.ycombinator.com/item?id=14383296
- dogma1138 9y ago
  The problem with OpenCL is the lack of well performing libraries, AMDs Core Math and Performance libraries are utter garbage still. If you can't do what Blender did and write everything from scratch including your primatives you'll be much slower than CUDA. But there is also a cost to it the Blender Cycles OpenCL code is nearly 5 times as big as their CUDA code and Cycles on OpenCL is still not at a feature parity with CUDA. The change in branding would likely not yield much for it.
  - ktta 9y ago
    I haven't heard much about AMD's ACML and ArrayFire but I'm not surprised. On the other hand, I think you're underestimating the fact that OpenCL is an open spec and therefore has support from the FOSS world. CUDA has always been criticized for being closed source. Even though OpenCL doesn't get much praise, and actually get criticized a bit (I'm personally not a big fan because writing OpenCL code is like bending over backwards). It has a lot of potential with new libraries coming up[1] which can possibly make it atleast on par with CUDA. Once that happens, AMD's cost effective cards will put it in the race. [1]:https://github.com/clMathLibraries https://github.com/clMathLibraries
    - dragandj 9y ago
      [1] is actually AMD's old libraries. Judging by dev activity, it seems to be abandonware in favor of https://github.com/RadeonOpenCompute https://github.com/RadeonOpenCompute which is itself not ready for prime time.
      - dogma1138 9y ago
        ROCm is an amalgamation of a lot of things, some new some (very) old. It still relies on many pretty old libraries with questionable performance at best. The newer stuff is good but it's tailored to AMD GPUs, don't expect interoperability when it comes to any reasonable performance if you want to run ROCm OpenCL on NVIDIA or Intel hardware.
nicwilson 9y ago
I am working on [dcompute](https://github.com/libmir/dcompute https://github.com/libmir/dcompute) which I hope will bring an equivalent experience when running on OpenCL and CUDA, and being written in D will provide all the advantages it does to writing kernels as it does with writing host code (with of course the ability to share compile time information across host and device). I believe that this levelling of the playing field will let the best hardware win. If you have any question, please ask!

jbmorgado 9y ago

The question is not AMD's processing power, the question is the tools available for AMD cards, which are scant to say the best. While AMD doesn't create something like cuDNN to go along with their cards, no real work will start being done in porting most important DL libraries to AMD cards. And even in that case, it will be a lost generation for AMD, only in the 2nd generation where AMD actually offers a real alternative in DL to NVIDIA, you will start to see some real progress being done with it.

redtuesday 9y ago
They stated at the analyst day that they will support TensorFlow, Theano, Caffee etc. And will release something called MiOpen. They also stated this last year: > On top of ROCm, deep-learning developers will soon have the opportunity to use a new open-source library of deep learning functions called MIOpen that AMD intends to release in the first quarter of next year. This library offers a range of functions pre-optimized for execution on Radeon Instinct cards, like convolution, pooling, activation, normalization, and tensor operations http://techreport.com/review/31093/amd-opens-up-machine-learning-with-radeon-instinct http://techreport.com/review/31093/amd-opens-up-machine-lear...
- PeterisP 9y ago
  That would be nice, more competition is better for the consumer. Still, it will affect purchasing decision only when it happens, and it hasn't happened yet.
- throwaway32131 9y ago
  They don't have an implementation of in-place convolutions AFAIK. The im2col trick may be too slow in practice (read x2.5-10 slower) to make any difference in terms of adoption. We already see this with Caffe and cl-Torch.

dogma1138 9y ago

AMDs benchmarks are highly doubtful. DeepBench isn't a benchmark it's a benchmarking tool they haven't released what dataset nor what code were they running. Their SpecPerf View benchmarks were a total FUD they compared NVIDIAs consumer (GeForce) drivers against Radeon Pro drivers. The SPV benchmarks look impressive until you realize they are lower than a Quadro M5000 which is based on the same Maxwell chip that drives the 980ti. NVIDIA's consumer drivers (and the non Pro AMD ones) are simply horrible for CAD and other professional workloads. AMD has been touting better performance than NVIDIA GPUs in compute since Fiji and they do not deliver. It's also important to note that VEGA will have FP64 performance at 1/32 while the P100 is at 1/2. I'm sure you can find an OpenCL workload that NVIDIA would be utterly trash in because the code is not optimized heck working with 256 batches as recommended for AMD rather than 1024 as recommended for NVIDIA would achive that alone.

AlphaSite 9y ago
Deep learning doesn't use FP64 at all, does it?