4 ms·

Nvidia has been contributing to open source scientific computing, ml, and simulation libraries for a while now to support CUDA's adoption

wtallis 6y ago
The userspace vs kernelspace distinction is important here. Nvidia contributing userspace code with dependencies on their hardware and proprietary drivers is part of a lock-in strategy. Contributing open-source drivers would be a very different thing, and would undermine at least some of their product segmentation strategies.
m4rtink 6y ago
Yet CUDA is still fully proprietary & total vendor lock-in...
- londons_explore 6y ago
  Kinda surprising AMD hasn't made their own CUDA compiler and set of libraries.
  - mikepurvis 6y ago
    I think the theory is that that's what OpenCL is, but for most people if you're building a dedicated cluster, you're buying Nvidia hardware anyway, and if you already are using the hardware for it, you might as well go native and get the best performance and library support.
    - pjmlp 6y ago
      OpenCL is no match for CUDA. Stuck in pure C, printf style debugging with graphical debuggers that never properly handled everything. CUDA, polyglot GPGPU development environment, graphical debuggers that allow for single stepping and conditional breakpoints in GPGPU code, interoperability with graphical APIs. OTOY just replaced their rendering code in Octane Render from Vulkan to CUDA (via Optix 7).
  - tpxl 6y ago
    They have (sort of): https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP It just isn't very good yet.
    - gnufx 6y ago
      However, it features in the preparation for the Frontier supercomputer, I think, though I can't immediately find the OCLF material I saw.
- pjmlp 6y ago
  Yet no competition was able to provice a polyglot OpenCL and IDE with graphical GPGPU debuggers. Failure of execution from the competion is also to blame. Yes, OpenCL finally adopted SPIR-V, when it was down and the referee started the countdown.
gnufx 6y ago
What's actually "open source" about what they have made themselves, as possibly opposed to modifying existing stuff? There's a significant effect of being proprietary in that people like me can't distribute packages using it for Fedora, Debian, SUSE, etc.

wtallis 6y ago

The userspace vs kernelspace distinction is important here. Nvidia contributing userspace code with dependencies on their hardware and proprietary drivers is part of a lock-in strategy. Contributing open-source drivers would be a very different thing, and would undermine at least some of their product segmentation strategies.

m4rtink 6y ago

Yet CUDA is still fully proprietary & total vendor lock-in...

londons_explore 6y ago
Kinda surprising AMD hasn't made their own CUDA compiler and set of libraries.
- mikepurvis 6y ago
  I think the theory is that that's what OpenCL is, but for most people if you're building a dedicated cluster, you're buying Nvidia hardware anyway, and if you already are using the hardware for it, you might as well go native and get the best performance and library support.
  - pjmlp 6y ago
    OpenCL is no match for CUDA. Stuck in pure C, printf style debugging with graphical debuggers that never properly handled everything. CUDA, polyglot GPGPU development environment, graphical debuggers that allow for single stepping and conditional breakpoints in GPGPU code, interoperability with graphical APIs. OTOY just replaced their rendering code in Octane Render from Vulkan to CUDA (via Optix 7).
- tpxl 6y ago
  They have (sort of): https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP It just isn't very good yet.
  - gnufx 6y ago
    However, it features in the preparation for the Frontier supercomputer, I think, though I can't immediately find the OCLF material I saw.
pjmlp 6y ago
Yet no competition was able to provice a polyglot OpenCL and IDE with graphical GPGPU debuggers. Failure of execution from the competion is also to blame. Yes, OpenCL finally adopted SPIR-V, when it was down and the referee started the countdown.

gnufx 6y ago

What's actually "open source" about what they have made themselves, as possibly opposed to modifying existing stuff? There's a significant effect of being proprietary in that people like me can't distribute packages using it for Fedora, Debian, SUSE, etc.