6 ms·

More great hardware being stuck behind proprietary CUDA when OpenCL is the thing they should be helping with. Once again proprietary lock in that will result in

More great hardware being stuck behind proprietary CUDA when OpenCL is the thing they should be helping with. Once again proprietary lock in that will result in inflexibility and digital blow-back in the long run. Yes I understand OpenCL has some issues and CUDA tends to be a bit easier and less buggy, but that doesn't detract from the principles of my statement.

MichaelBurge 9y ago
Nobody else is even bothering to compete, so standards don't really matter. Let them do their job: I'd rather have faster GPUs.
- tanderson92 9y ago
  Standards matter if you care about software and hardware freedom.
  - nightski 9y ago
    You really don't have freedom if there are no legitimate competitors.
    - throw2016 9y ago
      But accepting a monopoly standard guarantees loss of freedom and rules out any future prospect of legitimate competition.
      - deleted 9y ago
        [deleted]
      - deleted 9y ago
        [deleted]
  - deleted 9y ago
    [deleted]
  - zurn 9y ago
    Successful open systems tend to have standards that "just happened", not prescriptive standards. Like x86 PCs or Linux or most programming languages. Cuda seems to be clearly winning over OpenCL in the real world so other vendors should just adopt it. AMD already has a CUDA compiler IIRC.
    - slizard 9y ago
      The point where you suggested that x86 PCs are "open systems" (listing it next to "Linux" of all things!) I realized that you don't get it. We are where we are with Intel ripping off the consumers and companies alike exactly because nobody realized that x86 is everything but open. A similar mistake is about to happen, but luckily on the software side where losses can be cut quick and mistakes can be reversed easier -- though many will suffer when they have to reimplement their precious library from ground up because they did (or could) not take into account the fact that CUDA is as proprietary as it gets. AMD has no CUDA compiler BTW. And CUDA is not a programming language FYI. ;)
      - zurn 9y ago
        I'm pretty sure I referred to open systems and CUDA in their commonly understood meanings. Here are some links that may help to clarify the concepts: http://www.pcmag.com/encyclopedia/term/48478/open-system http://www.pcmag.com/encyclopedia/term/48478/open-system http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initiative-announced-c-and-cuda-compilers-for-amd-gpus http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia... Aside: I have no position on whether is CUDA's Fortran and C++ dialects constitute their own languages, nor did I refer to CUDA as a programming language.
        slizard 9y ago
        > http://www.pcmag.com/encyclopedia/term/48478/open-system http://www.pcmag.com/encyclopedia/term/48478/open-system Sadly, that's a very problematic, borderline BS definition. "A system that allows third parties to make products that plug into or interoperate with it. For example, the PC is an open system." Intel allows some third parties to interoperate with their system (ref Intel vs NVIDIA etc.) and they pick and choose to their liking, kill some and promote others exactly because they control the open-ness of their systems. > http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initiative-announced-c-and-cuda-compilers-for-amd-gpus http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia... HIP is still not a CUDA compiler. http://gpuopen.com/compute-product/hip-convert-cuda-to-portable-c-code/ http://gpuopen.com/compute-product/hip-convert-cuda-to-porta... > nor did I refer to CUDA as a programming language. You did refer to "CUDA compiler". My comment was admittedly a nitpick as well as a serious point too. CUDA can be seen as a C++ language + extensions -- something you can compile --, but it's also more than that (stuff that you can't compile), e.g.: API, programming tools, etc. all strongly adapted for NVIDIA hardware.
- slizard 9y ago
  I don't wish you the suffering vendor lock-in can cause after 10 years (hell, even less) of faithfully following the NVIDIA path, but... actually I do because that probably the best way to realize what's wrong with proprietary systems that pitch themselves as "de-facto" standards.
ahelwer 9y ago
I thought NVIDIA GPUs support OpenCL? Or do they not do that anymore?
- eslaught 9y ago
  It's always been 10-20% slower than CUDA and frankly NVIDIA doesn't have an incentive to make it faster than that. On the other hand, I believe Google is working on a CUDA compiler [1] so we may actually see meaningful improvement in the sense that it may become possible to run CUDA on other GPUs. (Edit: And Google actually has an incentive to achieve performance parity, so it might really happen.) [1]: https://research.google.com/pubs/pub45226.html https://research.google.com/pubs/pub45226.html
  - qb45 9y ago
    Interesting, appears to have been merged upstream: http://llvm.org/docs/CompileCudaWithLLVM.html http://llvm.org/docs/CompileCudaWithLLVM.html But it still targets NVIDIA GPUs and uses NVIDIA libraries so not that universal yet.
  - mrb 9y ago
    "It's always been 10-20% slower than CUDA" This is an untrue, yet often repeated statement. For example Hashcat migrated their CUDA code to OpenCL some time ago, with zero performance hits. What is true is that Nvidia's OpenCL stack is less mature than CUDA. But you can write OpenCL code that performs just as well as CUDA.
    - chronic940 9y ago
      What is Hashcat and why should we care?
      - PetahNZ 9y ago
        Because its a performance critical application that has made the switch so is a good comparison.
      - 9y ago
paulsutter 9y ago
Build your systems around GEMM/blas. Every vendor will give you a fast GEMM, and you'll be set for basically all the architectures that are coming out.
- arcanus 9y ago
  Except that not all problems in computation are GEMMs. CNNs in Machine learning certainly are, but many 'real' systems cannot be posted in such a manner. In supercomputing this is the problem with using high performance linpack for benchmarks, which typically exceeds actual scientific codes by an order of magnitude in terms of floating point operations per second.
  - paulsutter 9y ago
    Yes but to the extent you can, it's an easy win. I switched to a GEMMable method for a preprocessing step today based on the Volta and recent TPU news. Hopefully Tensorflow XLA or other optimization frameworks could solve this problem in a more general way in the medium term: http://www.kdnuggets.com/2017/04/deep-learning-virtual-machine-rule-all.html http://www.kdnuggets.com/2017/04/deep-learning-virtual-machi...
nicwilson 9y ago
I am the author of DCompute, a compiler/library/runtime framework for abstracting OpenCL/CUDA for D. You can write kernels already, although the API automation is still a work in progress. I'm hoping that this should level the field a bit, because let's face it, people use CUDA for two reasons: the OpenCL driver API sucks; and the utility libraries (cuDNN et al) for CUDA. Possibly driver quality as well. By having an API thats not horrible to use, that advantage is gone. The utility libraries will be more of a challenge to undermine, but since it targets CUDA natively there is no disadvantage to users of nvidia's hardware, but there is no advantage to others, yet (see GLAS[1] for what is possible with relative ease). Using D as the kernel language will also bring significant advantages over C/C++, static reflection, sane templates and compile time code generation to name a few. You can find it at https://github.com/libmir/dcompute https://github.com/libmir/dcompute. If you have any question, please ask! [1] https://github.com/libmir/mir-glas https://github.com/libmir/mir-glas
hawski 9y ago
Can Vulkan fill that space?
- nicwilson 9y ago
  Nvidia will have to support the SPIR-V Vulkan environment that is different to the OpenCL SPIR-V environment. But Vulkan is a graphics API not a compute API. Yes in theory you can write compute shaders but from my experience if you have a compute workload: use a compute API, they're much more suited for the job. So, no.
slizard 9y ago
^ This! Please read this before moving on: https://twitter.com/jrprice89/status/667466444355993600 https://twitter.com/jrprice89/status/667466444355993600 Also, NVIDIA's CUDA compilers are built on clang which does have OpenCL frontend, so all they would need to do is to put some resources into making that frontend work with their current nvcc toolchain. Many request and want this, but instead they are trying hard to hold back OpenCL just because providing OpenCL 2.0 support (and extensions for their GPUs features) may help adoption of OpenCL which in turn may end up helping other folks and companies too.

MichaelBurge 9y ago

Nobody else is even bothering to compete, so standards don't really matter. Let them do their job: I'd rather have faster GPUs.

tanderson92 9y ago
Standards matter if you care about software and hardware freedom.
- nightski 9y ago
  You really don't have freedom if there are no legitimate competitors.
  - throw2016 9y ago
    But accepting a monopoly standard guarantees loss of freedom and rules out any future prospect of legitimate competition.
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
- deleted 9y ago
  [deleted]
- zurn 9y ago
  Successful open systems tend to have standards that "just happened", not prescriptive standards. Like x86 PCs or Linux or most programming languages. Cuda seems to be clearly winning over OpenCL in the real world so other vendors should just adopt it. AMD already has a CUDA compiler IIRC.
  - slizard 9y ago
    The point where you suggested that x86 PCs are "open systems" (listing it next to "Linux" of all things!) I realized that you don't get it. We are where we are with Intel ripping off the consumers and companies alike exactly because nobody realized that x86 is everything but open. A similar mistake is about to happen, but luckily on the software side where losses can be cut quick and mistakes can be reversed easier -- though many will suffer when they have to reimplement their precious library from ground up because they did (or could) not take into account the fact that CUDA is as proprietary as it gets. AMD has no CUDA compiler BTW. And CUDA is not a programming language FYI. ;)
    - zurn 9y ago
      I'm pretty sure I referred to open systems and CUDA in their commonly understood meanings. Here are some links that may help to clarify the concepts: http://www.pcmag.com/encyclopedia/term/48478/open-system http://www.pcmag.com/encyclopedia/term/48478/open-system http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initiative-announced-c-and-cuda-compilers-for-amd-gpus http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia... Aside: I have no position on whether is CUDA's Fortran and C++ dialects constitute their own languages, nor did I refer to CUDA as a programming language.
      - slizard 9y ago
        > http://www.pcmag.com/encyclopedia/term/48478/open-system http://www.pcmag.com/encyclopedia/term/48478/open-system Sadly, that's a very problematic, borderline BS definition. "A system that allows third parties to make products that plug into or interoperate with it. For example, the PC is an open system." Intel allows some third parties to interoperate with their system (ref Intel vs NVIDIA etc.) and they pick and choose to their liking, kill some and promote others exactly because they control the open-ness of their systems. > http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initiative-announced-c-and-cuda-compilers-for-amd-gpus http://www.anandtech.com/show/9792/amd-sc15-boltzmann-initia... HIP is still not a CUDA compiler. http://gpuopen.com/compute-product/hip-convert-cuda-to-portable-c-code/ http://gpuopen.com/compute-product/hip-convert-cuda-to-porta... > nor did I refer to CUDA as a programming language. You did refer to "CUDA compiler". My comment was admittedly a nitpick as well as a serious point too. CUDA can be seen as a C++ language + extensions -- something you can compile --, but it's also more than that (stuff that you can't compile), e.g.: API, programming tools, etc. all strongly adapted for NVIDIA hardware.
slizard 9y ago
I don't wish you the suffering vendor lock-in can cause after 10 years (hell, even less) of faithfully following the NVIDIA path, but... actually I do because that probably the best way to realize what's wrong with proprietary systems that pitch themselves as "de-facto" standards.

ahelwer 9y ago

I thought NVIDIA GPUs support OpenCL? Or do they not do that anymore?

eslaught 9y ago
It's always been 10-20% slower than CUDA and frankly NVIDIA doesn't have an incentive to make it faster than that. On the other hand, I believe Google is working on a CUDA compiler [1] so we may actually see meaningful improvement in the sense that it may become possible to run CUDA on other GPUs. (Edit: And Google actually has an incentive to achieve performance parity, so it might really happen.) [1]: https://research.google.com/pubs/pub45226.html https://research.google.com/pubs/pub45226.html
- qb45 9y ago
  Interesting, appears to have been merged upstream: http://llvm.org/docs/CompileCudaWithLLVM.html http://llvm.org/docs/CompileCudaWithLLVM.html But it still targets NVIDIA GPUs and uses NVIDIA libraries so not that universal yet.
- mrb 9y ago
  "It's always been 10-20% slower than CUDA" This is an untrue, yet often repeated statement. For example Hashcat migrated their CUDA code to OpenCL some time ago, with zero performance hits. What is true is that Nvidia's OpenCL stack is less mature than CUDA. But you can write OpenCL code that performs just as well as CUDA.
  - chronic940 9y ago
    What is Hashcat and why should we care?
    - PetahNZ 9y ago
      Because its a performance critical application that has made the switch so is a good comparison.
    - 9y ago

paulsutter 9y ago

Build your systems around GEMM/blas. Every vendor will give you a fast GEMM, and you'll be set for basically all the architectures that are coming out.

arcanus 9y ago
Except that not all problems in computation are GEMMs. CNNs in Machine learning certainly are, but many 'real' systems cannot be posted in such a manner. In supercomputing this is the problem with using high performance linpack for benchmarks, which typically exceeds actual scientific codes by an order of magnitude in terms of floating point operations per second.
- paulsutter 9y ago
  Yes but to the extent you can, it's an easy win. I switched to a GEMMable method for a preprocessing step today based on the Volta and recent TPU news. Hopefully Tensorflow XLA or other optimization frameworks could solve this problem in a more general way in the medium term: http://www.kdnuggets.com/2017/04/deep-learning-virtual-machine-rule-all.html http://www.kdnuggets.com/2017/04/deep-learning-virtual-machi...

nicwilson 9y ago

I am the author of DCompute, a compiler/library/runtime framework for abstracting OpenCL/CUDA for D. You can write kernels already, although the API automation is still a work in progress. I'm hoping that this should level the field a bit, because let's face it, people use CUDA for two reasons: the OpenCL driver API sucks; and the utility libraries (cuDNN et al) for CUDA. Possibly driver quality as well. By having an API thats not horrible to use, that advantage is gone. The utility libraries will be more of a challenge to undermine, but since it targets CUDA natively there is no disadvantage to users of nvidia's hardware, but there is no advantage to others, yet (see GLAS[1] for what is possible with relative ease). Using D as the kernel language will also bring significant advantages over C/C++, static reflection, sane templates and compile time code generation to name a few. You can find it at https://github.com/libmir/dcompute https://github.com/libmir/dcompute. If you have any question, please ask! [1] https://github.com/libmir/mir-glas https://github.com/libmir/mir-glas

hawski 9y ago

Can Vulkan fill that space?

nicwilson 9y ago
Nvidia will have to support the SPIR-V Vulkan environment that is different to the OpenCL SPIR-V environment. But Vulkan is a graphics API not a compute API. Yes in theory you can write compute shaders but from my experience if you have a compute workload: use a compute API, they're much more suited for the job. So, no.

slizard 9y ago

^ This! Please read this before moving on: https://twitter.com/jrprice89/status/667466444355993600 https://twitter.com/jrprice89/status/667466444355993600 Also, NVIDIA's CUDA compilers are built on clang which does have OpenCL frontend, so all they would need to do is to put some resources into making that frontend work with their current nvcc toolchain. Many request and want this, but instead they are trying hard to hold back OpenCL just because providing OpenCL 2.0 support (and extensions for their GPUs features) may help adoption of OpenCL which in turn may end up helping other folks and companies too.