5 ms·

A pathetic attempt to lock developers into their hardware.

daniel-thompson 6y ago
I think CUDA itself is the locking attempt; this is just a tiny cherry on top.
jpz 6y ago
They seem to be pushing the barrier on innovation on GPU compute. It seems a little unfair to call that pathetic, whatever strategic reasons they have to find OpenCL unappetising (which simply enables their sole competitor in truth.) Their decision making seems rational, of course it's not ideal if you're consumer. We would like the ability to bid off NVidia with AMD Radeon. Convergence to a standard has to be driven by the market, but it's impossible to drive NVidia there because they are the dominant player and it is 100% not in their interests. It doesn't mean they're a bad company. They are rational actors.
- my123 6y ago
  With nvc++, they are converging towards a standardised source code standard: https://developer.nvidia.com/blog/accelerating-standard-c-with-gpus-using-stdpar/ https://developer.nvidia.com/blog/accelerating-standard-c-wi... However, this notably doesn't cover binaries, which are GPU vendor specific in that case, so AMD for example would have to provide a C++ compiler implementing stdpar for GPUs targeted to their hardware.
- deleted 6y ago
  [deleted]
gj_78 6y ago
Agree++. They are good at hardware and should stay that way.
- my123 6y ago
  The thing is: that hardware isn't very usable without good software, and an easy to use software stack at that. That's what NVIDIA understood and made them what they are today.
  - gj_78 6y ago
    A lot of hardware has builtin software, either inside a firmware or as a driver. Keeping the software part in firmware lets customer free to use any kind of OS. Using host cpu and memory is bad design IMHO.
    - my123 6y ago
      > Keeping the software part in firmware lets customer free to use any kind of OS Raspberry Pi initially shipped with such a graphics stack, with the Arm side just being a communication driver in the kernel and an RPC stack in user-space. It isn't a good idea (for numerous reasons, including security) and is even more closed in practice than what ships today.
      - gj_78 6y ago
        Raspberry Pi is not marketed for graphics as nvidia is doing with their GPUs. What I mean is that firmware is running on a usually small cpu and memory that is sold as a part of the GPU. No security issues here as the main security issue is to plug the whole GPU inside your PC.
        my123 6y ago
        With the complexity of GPU driver stacks, what you are asking for is not firmware, but a multi GHz+ set of CPUs just for that purpose. + RPC needed all the time... with its latency would tank the performance It'd also be not tinkerable at all unlike what we have today, it's exactly advocating for the opposite of open.
    - dahart 6y ago
      Can you elaborate on what you mean? This is an open source library for developers to write code that can compile without changes on both CPU and GPU. This solves a problem that can’t be solved in firmware, and this is not a case of nvidia using cpu and host memory - whether to use cpu and host memory is strictly up to the developer.
- blelbach 6y ago
  We employ more software engineers than hardware engineers. Our hardware doesn't really do much in isolation, software is part of the product.
  - gj_78 6y ago
    The question is not about the head count. How many software engineers at nvidia produce software that is expected run/compile on the host CPU of the customer, like this library ? I expect not too much.
    - blelbach 6y ago
      The majority of software engineers at NVIDIA write software that runs on the host CPU. The majority of software written at NVIDIA (by any metric, lines of code, number of projects, etc) runs either solely on the CPU, or on both the CPU and the GPU.
pjmlp 6y ago
The other vendors are to blame for sticking with outdated C and printf style debugging.
- einpoklum 6y ago
  1. printf-style debugging is what we use on NVIDIA hardware too. 2. OpenCL 2.x allows for C++(ish) source code. Not sure how good the AMD support is though.
  - pjmlp 6y ago
    1. Ever heard of Nights and Visual Studio plugins? 2. OpenCL 2.0 was a failure, so OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped and SYSCL is now backend agnostic.
    - einpoklum 6y ago
      > 1. Ever heard of Nights and Visual Studio plugins? Those are apples and oranges... also, you forget cuda-gdb. > OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped Well, yes, but also no. They were made optional, and transitioned to some other C++-cum-OpenCL initiative: https://github.com/KhronosGroup/Khronosdotorg/blob/master/api/opencl/assets/CXX_for_OpenCL.pdf https://github.com/KhronosGroup/Khronosdotorg/blob/master/ap... I'm not exactly sure how this differs and what's usable in practice though.
      - pjmlp 6y ago
        While SYSCL might stand a chance against CUDA, thanks to it being backend agnostic and a compiler neutral standard, C++ for OpenCL is a clang specific project which remains to be seen if it ever will get any adoption. > For C++ kernel development, the OpenCL Working Group has transitioned from the original OpenCL C++ kernel language, defined in OpenCL 2.2, to the ‘C++ for OpenCL’ community, open-source project supported by Clang. C++ for OpenCL provides compatibility with OpenCL C, enables developers to use most C++17 features in OpenCL kernels, and is compatible with any OpenCL 2.X or OpenCL 3.0 implementation that supports SPIR-V™ ingestion. https://www.khronos.org/news/press/khronos-group-releases-opencl-3.0 https://www.khronos.org/news/press/khronos-group-releases-op...
blelbach 6y ago
> A pathetic attempt to lock developers into their hardware Ah-ha, you've caught us! Our plan is to lock you into our hardware by implementing Standard C++. Once you are all writing code in Standard C++, then you won't be able to run it elsewhere, because Standard C++ only runs on NVIDIA platforms, right? ... What's that? Standard C++ is supported by essentially every platform? Darnit! Foiled again.

I think CUDA itself is the locking attempt; this is just a tiny cherry on top.

jpz 6y ago

They seem to be pushing the barrier on innovation on GPU compute. It seems a little unfair to call that pathetic, whatever strategic reasons they have to find OpenCL unappetising (which simply enables their sole competitor in truth.) Their decision making seems rational, of course it's not ideal if you're consumer. We would like the ability to bid off NVidia with AMD Radeon. Convergence to a standard has to be driven by the market, but it's impossible to drive NVidia there because they are the dominant player and it is 100% not in their interests. It doesn't mean they're a bad company. They are rational actors.

my123 6y ago
With nvc++, they are converging towards a standardised source code standard: https://developer.nvidia.com/blog/accelerating-standard-c-with-gpus-using-stdpar/ https://developer.nvidia.com/blog/accelerating-standard-c-wi... However, this notably doesn't cover binaries, which are GPU vendor specific in that case, so AMD for example would have to provide a C++ compiler implementing stdpar for GPUs targeted to their hardware.
deleted 6y ago
[deleted]

gj_78 6y ago

Agree++. They are good at hardware and should stay that way.

my123 6y ago
The thing is: that hardware isn't very usable without good software, and an easy to use software stack at that. That's what NVIDIA understood and made them what they are today.
- gj_78 6y ago
  A lot of hardware has builtin software, either inside a firmware or as a driver. Keeping the software part in firmware lets customer free to use any kind of OS. Using host cpu and memory is bad design IMHO.
  - my123 6y ago
    > Keeping the software part in firmware lets customer free to use any kind of OS Raspberry Pi initially shipped with such a graphics stack, with the Arm side just being a communication driver in the kernel and an RPC stack in user-space. It isn't a good idea (for numerous reasons, including security) and is even more closed in practice than what ships today.
    - gj_78 6y ago
      Raspberry Pi is not marketed for graphics as nvidia is doing with their GPUs. What I mean is that firmware is running on a usually small cpu and memory that is sold as a part of the GPU. No security issues here as the main security issue is to plug the whole GPU inside your PC.
      - my123 6y ago
        With the complexity of GPU driver stacks, what you are asking for is not firmware, but a multi GHz+ set of CPUs just for that purpose. + RPC needed all the time... with its latency would tank the performance It'd also be not tinkerable at all unlike what we have today, it's exactly advocating for the opposite of open.
  - dahart 6y ago
    Can you elaborate on what you mean? This is an open source library for developers to write code that can compile without changes on both CPU and GPU. This solves a problem that can’t be solved in firmware, and this is not a case of nvidia using cpu and host memory - whether to use cpu and host memory is strictly up to the developer.
blelbach 6y ago
We employ more software engineers than hardware engineers. Our hardware doesn't really do much in isolation, software is part of the product.
- gj_78 6y ago
  The question is not about the head count. How many software engineers at nvidia produce software that is expected run/compile on the host CPU of the customer, like this library ? I expect not too much.
  - blelbach 6y ago
    The majority of software engineers at NVIDIA write software that runs on the host CPU. The majority of software written at NVIDIA (by any metric, lines of code, number of projects, etc) runs either solely on the CPU, or on both the CPU and the GPU.

pjmlp 6y ago

The other vendors are to blame for sticking with outdated C and printf style debugging.

einpoklum 6y ago
1. printf-style debugging is what we use on NVIDIA hardware too. 2. OpenCL 2.x allows for C++(ish) source code. Not sure how good the AMD support is though.
- pjmlp 6y ago
  1. Ever heard of Nights and Visual Studio plugins? 2. OpenCL 2.0 was a failure, so OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped and SYSCL is now backend agnostic.
  - einpoklum 6y ago
    > 1. Ever heard of Nights and Visual Studio plugins? Those are apples and oranges... also, you forget cuda-gdb. > OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped Well, yes, but also no. They were made optional, and transitioned to some other C++-cum-OpenCL initiative: https://github.com/KhronosGroup/Khronosdotorg/blob/master/api/opencl/assets/CXX_for_OpenCL.pdf https://github.com/KhronosGroup/Khronosdotorg/blob/master/ap... I'm not exactly sure how this differs and what's usable in practice though.
    - pjmlp 6y ago
      While SYSCL might stand a chance against CUDA, thanks to it being backend agnostic and a compiler neutral standard, C++ for OpenCL is a clang specific project which remains to be seen if it ever will get any adoption. > For C++ kernel development, the OpenCL Working Group has transitioned from the original OpenCL C++ kernel language, defined in OpenCL 2.2, to the ‘C++ for OpenCL’ community, open-source project supported by Clang. C++ for OpenCL provides compatibility with OpenCL C, enables developers to use most C++17 features in OpenCL kernels, and is compatible with any OpenCL 2.X or OpenCL 3.0 implementation that supports SPIR-V™ ingestion. https://www.khronos.org/news/press/khronos-group-releases-opencl-3.0 https://www.khronos.org/news/press/khronos-group-releases-op...

blelbach 6y ago

> A pathetic attempt to lock developers into their hardware Ah-ha, you've caught us! Our plan is to lock you into our hardware by implementing Standard C++. Once you are all writing code in Standard C++, then you won't be able to run it elsewhere, because Standard C++ only runs on NVIDIA platforms, right? ... What's that? Standard C++ is supported by essentially every platform? Darnit! Foiled again.