Hacker News Reader

Comment by valarauca1 | Hacker News Reader

AMD 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.

View on HN

AMD 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.

AMD 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/...

https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

AMD 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.

OpenCL 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.

I 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.

> 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?

Alternatively 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.

They are working on something like that - 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

1. 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

They do. They have a retargeting compiler. It's performance sucks.

Reply on news.ycombinator.com