This is all more or less true with the current public code. We're building our own standalone stack that will interop with TF, Keras, PyTorch, etc. Basically we are fixing the problem for AMD and Intel on desktop but also embedded chip vendors as well. Currently our stack runs Google's Xception net in Keras slightly faster than TF 1.2 + cuDNN 5.1 on Tesla K80 so there's good evidence OpenCL itself is not that slow.
This is an admirable effort and thanks for doing it.
Have you experienced problems related to the lack of active support from AMD or Intel for OpenCL drivers? Thats been my experience with OpenCL several years ago. On a related note drivers for OpenGL on Linux and Windows from AMD and Intel have been a huge problem for developer for years. Somehow only NVidia cares and invests enough in non-windows driver support. This may be changing with Vulkan however and more focus on GPU compute.
We have found bugs in both AMD and NVIDIA drivers but nothing that didn't get fixed or that we couldn't work around. More difficult are the "special" quirks in some embedded GPUs. I keep an eye on Vulkan etc but right now OpenCL looks like the right choice for portability.
