38 ms·

AMD's OpenCL implementation and tooling were really, really rough. Lots of hard lockups, memory leaks, and forum threads ending in the person with the question

AMD's OpenCL implementation and tooling were really, really rough. Lots of hard lockups, memory leaks, and forum threads ending in the person with the question giving up and switching to team green. I followed this path eventually, too. The breaking point happened when I had spent an entire day trying to get a bit of OpenCL working, thinking that I was at fault, but then I tried running it on a NVidia box, hoping to get a more descriptive error, but the code Just Worked. NVidia's OpenCL implementation was better than AMD's, and not by a small amount. CUDA was better still. I realized I had thrown away $n0000 of my own time chasing a $n00 discount on the AMD card (controlling for perf). Never again. Now that AMD has money, hopefully they have fixed their stack, but I'm still in "once bitten, twice shy" mode. I want to see someone else in my field using AMD on tasks I care about before I try team red again.

dotnet00 4y ago
Same experience here, as recently as with AMD's 5000 series GPUs. As far as I'm aware their OpenCL stack is still terrible, they're focusing mainly on HIP and ROCm, but it too has terrible consumer side support and an update model that makes it essentially useless as a long term investment. They include device code for every supported GPU, so they have to drop support for older cards to keep the binaries reasonably sized. In contrast, CUDA compiles down to a device agnostic intermediate language so they can support the same code on several generations of hardware, limited only by the CUDA feature level available on the hardware. AMD still has a long way to go for now. Both in terms of 'primary' functionality like supported hardware and compilers and 'secondary' functionality like detailed profiling and debugging tools.
mort96 4y ago
If it truly was/is as dire as you make it sound, maybe it's true that CUDA really was the only reasonable way to get something to work. Interesting.
cameldrv 4y ago
It's amazing to me that AMD didn't put more resources behind better GPGPU and DL software tooling like NVIDIA did. This was an excusable error in 2015, but not in 2018. This probably cost AMD tens of billions of dollars in lost market cap.

dotnet00 4y ago

Same experience here, as recently as with AMD's 5000 series GPUs. As far as I'm aware their OpenCL stack is still terrible, they're focusing mainly on HIP and ROCm, but it too has terrible consumer side support and an update model that makes it essentially useless as a long term investment. They include device code for every supported GPU, so they have to drop support for older cards to keep the binaries reasonably sized. In contrast, CUDA compiles down to a device agnostic intermediate language so they can support the same code on several generations of hardware, limited only by the CUDA feature level available on the hardware. AMD still has a long way to go for now. Both in terms of 'primary' functionality like supported hardware and compilers and 'secondary' functionality like detailed profiling and debugging tools.

mort96 4y ago

If it truly was/is as dire as you make it sound, maybe it's true that CUDA really was the only reasonable way to get something to work. Interesting.

cameldrv 4y ago

It's amazing to me that AMD didn't put more resources behind better GPGPU and DL software tooling like NVIDIA did. This was an excusable error in 2015, but not in 2018. This probably cost AMD tens of billions of dollars in lost market cap.