3 ms·

> because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset So I suppose you still used OpenCL for AMD and

> because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset So I suppose you still used OpenCL for AMD and Intel hardware because that worked well there? That is, OpenCL only worked poorly on nvidia hardware? If that's the case, I wonder what's your take on OpenCL 3.0 reverting all OpenCL > 1.2 features, such that OpenCL 3 is essentially OpenCL 1.2. The reason given by Khronos is that _nobody_ was implementing these features anyways. Yet your story sounds like AMD had great support for OpenCL newer features, and only nvidia's support was poor, kind of contradicting Khronos themselves. Maybe you meant that nvidia has poor support for OpenCL 1 ?

hobofan 6y ago
Not sure if I can offer a good take, as I don't 100% remember. We didn't have much resources to tackle OpenCL, as it was already hard enough to compete against the other frameworks on the CUDA side alone, so that's where our focus was until our company shut down. IIRC we had all the basics working with OpenCL 1.2 (with an Intel CPU and Titan X as test devices) and were looking into transitioning towards 2.0, as the abstractions used there were much closer to those in CUDA. I remember particularly the memory management in 1.2 to be a pain and difficulties around async RAM<->VRAM copies and subsequent async kernel execution. The latter in particular accounted for the biggest performance differences when profiling the same tasks on the Nvidia GPU. I'm not really informed about what happened with OpenCL 3.0, but I would count any 2.x features as essential when trying to compete with modern CUDA. I don't think the support for OpenCL _the standard_ was bad, but there wasn't really any comparable tooling for OpenCL, and a set of good cuBLAS, cuDNN, etc. alternatives was missing. If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake.
- fluffything 6y ago
  > If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake. See: https://www.anandtech.com/show/15746/opencl-30-announced-hitting-reset-on-compute-frameworks https://www.anandtech.com/show/15746/opencl-30-announced-hit... This was also extensively discussed here in HNs. You might be able to find that thread, was really interesting.

hobofan 6y ago

Not sure if I can offer a good take, as I don't 100% remember. We didn't have much resources to tackle OpenCL, as it was already hard enough to compete against the other frameworks on the CUDA side alone, so that's where our focus was until our company shut down. IIRC we had all the basics working with OpenCL 1.2 (with an Intel CPU and Titan X as test devices) and were looking into transitioning towards 2.0, as the abstractions used there were much closer to those in CUDA. I remember particularly the memory management in 1.2 to be a pain and difficulties around async RAM<->VRAM copies and subsequent async kernel execution. The latter in particular accounted for the biggest performance differences when profiling the same tasks on the Nvidia GPU. I'm not really informed about what happened with OpenCL 3.0, but I would count any 2.x features as essential when trying to compete with modern CUDA. I don't think the support for OpenCL _the standard_ was bad, but there wasn't really any comparable tooling for OpenCL, and a set of good cuBLAS, cuDNN, etc. alternatives was missing. If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake.

fluffything 6y ago
> If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake. See: https://www.anandtech.com/show/15746/opencl-30-announced-hitting-reset-on-compute-frameworks https://www.anandtech.com/show/15746/opencl-30-announced-hit... This was also extensively discussed here in HNs. You might be able to find that thread, was really interesting.