5 ms·

are there insurmountable technical constraints there, or could it be resuscitated?

by abiox 9y ago

diab0lic 9y ago
It could be resuscitated but it is unlikely without the backing of a major player.
Athas 9y ago
OpenCL is a very sound design on a technical level. Unfortunately, it's mostly designed to be a good target for code generation/libraries, and is awkward to use directly. The problems are that everything is very explicit and spelled out, and the kernel language itself is based on C, not C++, and segmented from the rest of the code base. In practice, you use OpenCL API calls to submit strings containing code to the OpenCL backend, which then compiles it and hands you back an opaque compiled program that you can execute. This makes it hard to write modular and maintainable code with OpenCL directly. The issues go away if you use a good OpenCL frontend. PyOpenCL for Python goes a long way towards this, and is not really any more awkward than the corresponding PyCUDA, and higher-level languages that generate OpenCL code, like Lift[0] or Futhark[1] (tooting my own horn here), remove the awkwardness completely. [0]: http://www.lift-project.org/ http://www.lift-project.org/ [1]: https://futhark-lang.org https://futhark-lang.org
- pjmlp 9y ago
  I think that has been the major failure from Khronos, being stuck with C mentality for their APIs. OpenGL ES only took off thanks to gaming on the iPhone, and now is deprecated on Apple platforms. Vulkan still lives in a C world, and the semi-official C++ bindings only exist thanks NVidia. OpenCL waited too long to support C++, Fortran and providing an infrastructure for compiler writers to add GPU support to their own languages. And two years later the majority of drivers are not there yet.
  - roel_v 9y ago
    Khronos' problem is that they want to do everything, or not do it at all. Sycl would be 'real' c++ support, way beyond the 'oo wrapper around c api' that already exists in opencl headers. Nvidia is more 'good enough? Ship it' which has shown itself many times in the past to be a dominant strategy. (As much as I hate to admit that).
  - mellinoe 9y ago
    It seems like a C API is a much better choice if you want your library to be callable from many different languages. What is a reasonable alternative without giving that up?
    - pjmlp 9y ago
      A bytecode format, like what CUDA, Metal Compute and DirectX Compute use. Which Khronos finally adopted as SPIR, but the drivers aren't there yet. Regarding the other Khronos APIs, a C API is like being stuck in a PDP-11 world. Many mix the idea of C API with OS ABI, it only happens to be the same if the OS APIs are exposed as plain C. There many cases where this isn't like it, e.g. mainframes, mobile OSes, and most userspace on OS X (Obj-C runtime) and Windows (.NET and COM).
      - mellinoe 9y ago
        D3D, Vulkan, OpenGL (optionally) etc. do use a bytecode format, but that only covers shader modules, which are a small part of the overall API. I'm not that familiar with CUDA, but it looks like a large portion of it is delivered as a C API, judging by the bindings I see online.
      - nicwilson 9y ago
        having a bytecode, and having a C API are completely orthogonal. And thankfully we now have both with SPIR-V, although the C API needs to be wrapped unless you like writing C-like code in higher languages that abstract most of the tedium. Yes driver support is a bit lacking, although I hop that I can convince the OpenCL working group of the need to get a backend (such as https://github.com/thewilsonator/llvm-target-spirv https://github.com/thewilsonator/llvm-target-spirv) into mainline LLVM so that writing drivers becomes easier for vendors.
- gcp 9y ago
  The OpenCL kernel language is very similar to the CUDA one, before they started adding more C++ support. It's pretty easy to translate between the two if you don't use hw intrinsics. And segmenting the codebase is a MAJOR feature. With CUDA you are stuck on an old compiler until NVIDIA issues an update. How anyone can think this is a good idea...
  - pjmlp 9y ago
    Because NVidia understands the GPU world has moved beyond C. "Designing (New) C++ Hardware” https://www.youtube.com/watch?v=86seb-iZCnI https://www.youtube.com/watch?v=86seb-iZCnI CUDA has had C++, Fortran support since the early days, with PTX for additional compiler backends added in version 1.4. That was 2007, Khronos waited until 2015 to specific similar capabilities.
    - gcp 9y ago
      What GPU world though? People still write regular shaders in languages that are much more C like. People writing GPGPU code are few. Most of the DL GPU use is in Python through several layers, and in the end you are running hand-written SASS assembly sitting in an NVIDIA DLL or whatever. I guess some people must think it's handy to have C++ support in GPU kernels, or they wouldn't have added the feature. But for it to drive technology, hard to believe.
      - pjmlp 9y ago
        The only GPU shaders that are C like are the OpenGL ones. The Metal, DirectX, PS3, PS4, Nintendo and several middleware engines are C++ like. Also the fact that OpenCL lost to CUDA for being stuck in C for so long, shows what most GPU devs actually prefer.
        gcp 9y ago
        Also the fact that OpenCL lost to CUDA for being stuck in C for so long, shows what most GPU devs actually prefer. Aw come on, you're sure it has nothing to do with the largest GPGPU vendor pushing CUDA very heavily and intentionally gutting their OpenCL tools? Or putting out a ton of very high performance libraries with no OpenCL equivalent? Putting out a shitton of marketing and tutorial videos for CUDA only? Yeah, that surely was totally unrelated. Also pushing a proprietary standard goes faster than a standardized one. No surprise there.
- nicwilson 9y ago
  > ... and is awkward to use directly You're not wrong there. However with the advent of SPIR-V it is possible to write code in whatever language you please (with the caveat that at the moment you need an LLVM backend using https://github.com/thewilsonator/llvm-target-spirv https://github.com/thewilsonator/llvm-target-spirv or the Khronos repo I forked that off of. Then comes the issue of making the code generator friendly interface user friendly, which I have done for D so that you get the ease of use of CUDA.
roel_v 9y ago
It's purely political. If nvidia would have a team of 3-5 ppl working op their opencl drivers/tooling, opencl would be as good as cuda. Nvidia would be stupid to do that, of course. Hence the Khronos play to fold opencl into vulkan. We'll see how that plays out.

are there insurmountable technical constraints there, or could it be resuscitated?

by abiox 9y ago

are there insurmountable technical constraints there, or could it be resuscitated?

diab0lic 9y ago

It could be resuscitated but it is unlikely without the backing of a major player.

Athas 9y ago

OpenCL is a very sound design on a technical level. Unfortunately, it's mostly designed to be a good target for code generation/libraries, and is awkward to use directly. The problems are that everything is very explicit and spelled out, and the kernel language itself is based on C, not C++, and segmented from the rest of the code base. In practice, you use OpenCL API calls to submit strings containing code to the OpenCL backend, which then compiles it and hands you back an opaque compiled program that you can execute. This makes it hard to write modular and maintainable code with OpenCL directly. The issues go away if you use a good OpenCL frontend. PyOpenCL for Python goes a long way towards this, and is not really any more awkward than the corresponding PyCUDA, and higher-level languages that generate OpenCL code, like Lift[0] or Futhark[1] (tooting my own horn here), remove the awkwardness completely. [0]: http://www.lift-project.org/ http://www.lift-project.org/ [1]: https://futhark-lang.org https://futhark-lang.org

pjmlp 9y ago
I think that has been the major failure from Khronos, being stuck with C mentality for their APIs. OpenGL ES only took off thanks to gaming on the iPhone, and now is deprecated on Apple platforms. Vulkan still lives in a C world, and the semi-official C++ bindings only exist thanks NVidia. OpenCL waited too long to support C++, Fortran and providing an infrastructure for compiler writers to add GPU support to their own languages. And two years later the majority of drivers are not there yet.
- roel_v 9y ago
  Khronos' problem is that they want to do everything, or not do it at all. Sycl would be 'real' c++ support, way beyond the 'oo wrapper around c api' that already exists in opencl headers. Nvidia is more 'good enough? Ship it' which has shown itself many times in the past to be a dominant strategy. (As much as I hate to admit that).
- mellinoe 9y ago
  It seems like a C API is a much better choice if you want your library to be callable from many different languages. What is a reasonable alternative without giving that up?
  - pjmlp 9y ago
    A bytecode format, like what CUDA, Metal Compute and DirectX Compute use. Which Khronos finally adopted as SPIR, but the drivers aren't there yet. Regarding the other Khronos APIs, a C API is like being stuck in a PDP-11 world. Many mix the idea of C API with OS ABI, it only happens to be the same if the OS APIs are exposed as plain C. There many cases where this isn't like it, e.g. mainframes, mobile OSes, and most userspace on OS X (Obj-C runtime) and Windows (.NET and COM).
    - mellinoe 9y ago
      D3D, Vulkan, OpenGL (optionally) etc. do use a bytecode format, but that only covers shader modules, which are a small part of the overall API. I'm not that familiar with CUDA, but it looks like a large portion of it is delivered as a C API, judging by the bindings I see online.
    - nicwilson 9y ago
      having a bytecode, and having a C API are completely orthogonal. And thankfully we now have both with SPIR-V, although the C API needs to be wrapped unless you like writing C-like code in higher languages that abstract most of the tedium. Yes driver support is a bit lacking, although I hop that I can convince the OpenCL working group of the need to get a backend (such as https://github.com/thewilsonator/llvm-target-spirv https://github.com/thewilsonator/llvm-target-spirv) into mainline LLVM so that writing drivers becomes easier for vendors.
gcp 9y ago
The OpenCL kernel language is very similar to the CUDA one, before they started adding more C++ support. It's pretty easy to translate between the two if you don't use hw intrinsics. And segmenting the codebase is a MAJOR feature. With CUDA you are stuck on an old compiler until NVIDIA issues an update. How anyone can think this is a good idea...
- pjmlp 9y ago
  Because NVidia understands the GPU world has moved beyond C. "Designing (New) C++ Hardware” https://www.youtube.com/watch?v=86seb-iZCnI https://www.youtube.com/watch?v=86seb-iZCnI CUDA has had C++, Fortran support since the early days, with PTX for additional compiler backends added in version 1.4. That was 2007, Khronos waited until 2015 to specific similar capabilities.
  - gcp 9y ago
    What GPU world though? People still write regular shaders in languages that are much more C like. People writing GPGPU code are few. Most of the DL GPU use is in Python through several layers, and in the end you are running hand-written SASS assembly sitting in an NVIDIA DLL or whatever. I guess some people must think it's handy to have C++ support in GPU kernels, or they wouldn't have added the feature. But for it to drive technology, hard to believe.
    - pjmlp 9y ago
      The only GPU shaders that are C like are the OpenGL ones. The Metal, DirectX, PS3, PS4, Nintendo and several middleware engines are C++ like. Also the fact that OpenCL lost to CUDA for being stuck in C for so long, shows what most GPU devs actually prefer.
      - gcp 9y ago
        Also the fact that OpenCL lost to CUDA for being stuck in C for so long, shows what most GPU devs actually prefer. Aw come on, you're sure it has nothing to do with the largest GPGPU vendor pushing CUDA very heavily and intentionally gutting their OpenCL tools? Or putting out a ton of very high performance libraries with no OpenCL equivalent? Putting out a shitton of marketing and tutorial videos for CUDA only? Yeah, that surely was totally unrelated. Also pushing a proprietary standard goes faster than a standardized one. No surprise there.
nicwilson 9y ago
> ... and is awkward to use directly You're not wrong there. However with the advent of SPIR-V it is possible to write code in whatever language you please (with the caveat that at the moment you need an LLVM backend using https://github.com/thewilsonator/llvm-target-spirv https://github.com/thewilsonator/llvm-target-spirv or the Khronos repo I forked that off of. Then comes the issue of making the code generator friendly interface user friendly, which I have done for D so that you get the ease of use of CUDA.

roel_v 9y ago

It's purely political. If nvidia would have a team of 3-5 ppl working op their opencl drivers/tooling, opencl would be as good as cuda. Nvidia would be stupid to do that, of course. Hence the Khronos play to fold opencl into vulkan. We'll see how that plays out.