4 ms·
AMD chips have almost always had a lead over Nvidia from a per-flops perspective, and AMD's architecture is definitely ahead of Nvidia as far as supporting inte
by tcoppi 10y ago
AMD chips have almost always had a lead over Nvidia from a per-flops perspective, and AMD's architecture is definitely ahead of Nvidia as far as supporting integer operations and bitwise ops efficiently(see their dominance of cryptocurrency mining). However, Nvidia's software tooling has always been superb, and they basically own the GPGPU-for-HPC space because of it. On top of that, one of the biggest growth areas of consumers of GPGPU in recent years has been "deep learning", for which Nvidia has embraced and has great tooling and software for their hardware. AMD has potential to compete with Nvidia in this area, but they don't seem to have the resources to develop optimized Neural Network software to run on their GPUs like Nvidia does, so they are way behind. Basically, GFLOPS per Watt is nice and all, but if nothing you care about runs on the hardware, you won't buy it. AMD seems to have been stuck in this position for HPC, and it doesn't seem to be changing sadly.
- valarauca1 10y agoAMD pulls off better compute in pure GFLOPS but you'll have to extract that compute power in OpenCL. AMD still doesn't have a good answer to CUDA.
- Athas 10y agoOpenCL is however a fairly nice target for compilers, which opens up different ways of using it. Witness also PyOpenCL versus PyCUDA - both are essentially equally convenient to use, while raw OpenCL C is a nightmare compared to CUDA C.
- m_mueller 10y agoI think the near future in compilers is going to be dominated by accelerator capable LLVM variants (such as NVVM). Ideally, all Nvidia, AMD and Intel would and should need to do is to provide LLLVM based backends. Frontends just need a sane way of specifying SIMT. And no, loop + directive based stuff like OpenMP and OpenACC is IMO just a stopgap measure in order to serve higher ups the lie that portation is going to be swift and easy. There's basically one sane way to deal with data parallel problems, and that's to treat what's going on in one core as a scalar program with precomputed indices (i.e. the CUDA / OpenCL way). Python has some good support for this already. I haven't done a project like this yet, but if setting up something fresh I'd immediately jump on NumPy interacting with my own kernels and some Python glue for the node level parallelism.
- discardorama 10y ago> AMD still doesn't have a good answer to CUDA. I don't understand why AMD doesn't just jump on the CUDA bandwagon and support the API?
- robbies 10y ago1. They have no say in the API so NV would just steer the API in ways to make sure it would be suboptimal on AMD hardware. 2. It's not just the API. It's the entire SDK that has NV specific hooks that AMD can't tap into
- saturncoleus 10y agoAlternatively they could make their own API, independent from OpenCL. I have written a small amount in each languages (a rainbow table generator), and found the CUDA version much more pleasant to use. CUDA made it really easy to get a good idea of the underlying hardware, and make architectural changes in order to make the code faster. OpenCL (using an ATI card) was much harder to program, since the abstraction level was much higher. Writing two separate kernels and have them each be faster than a generic version that ends up compromising for compatibility. The OpenCL one ended up being faster, but I suspect that's due to ATI hardware being superior at the time.
- maaku 10y agoThey do. They have a retargeting compiler. It's performance sucks.
- dharma1 10y agoThey are working on something like that - http://www.extremetech.com/extreme/218092-amds-boltzmann-initiative-targets-the-high-performance-computing-market http://www.extremetech.com/extreme/218092-amds-boltzmann-ini... The current versions only work with a couple of latest AMD chips though. And CUDA is just one part of it, they have nothing equivalent to CuDNN
- elementalest 10y agoAMD are supporting open standards like OpenCL, which is effectively their answer to CUDA. The problem is that Nvidia refuse to keep their drivers up to date with the latest OpenCL capabilities. The latest version nVidia supports is OpenCL 1.1, but its now up to OpenCL 2.2. nVidia are years behind on OpenCL. This is pretty much the primary reason why CUDA seems so far ahead. nVidia released new features and capabilities on CUDA that later versions of OpenCL also supported, but were not available on nVidia cards due to lack of OpenCL driver support. Hence, lots of people developed libraries and tools for CUDA, with great encouragement and support from nVidia (which attracted developers). These tools were useful and powerful, encouraging others to also use nVidia hardware to take advantage of those tools. CUDA has now taken root. If nVidia were to start keeping their drivers updated with the latest version of OpenCL, i suspect CUDA's dominance would start to wane. Though the CUDA roots have gone deep, so it may take several years to reverse its dominance. However, its highly unlikely that nVidia will update their drives any time soon. The only thing that would probably force them is AMD gaining market dominance for a few years.
- nl 10y agoAMD are "supporting" OpenCL as in it works. If you compare the resources NVidia are putting into their deep learning support vs AMD it is miles ahead. If you read between the lines of how dismissive AMD were of NVidia's work on self driving cars you can see they don't care about compute. They are chasing the VR market, and that is fine.
- puzzlingcaptcha 10y agoAMD is also developing a tool to convert CUDA into HIP but I haven't looked into that http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/09/7637-HIP-Datasheet-V1_4-US-Letter.pdf http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/... https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP