4 ms·

I wish more attention would be towards open source alternatives for CUDA, such as AMD's ROCm[1][2] and Julia framework using it - AMDGPU.jl[3]. It's sad to see

by xvilka 5y ago

I wish more attention would be towards open source alternatives for CUDA, such as AMD's ROCm[1][2] and Julia framework using it - AMDGPU.jl[3]. It's sad to see so many people praise NVIDIA which is the enemy of open source, openly hostile to anything except their oversized proprietary binary blobs. [1] https://rocmdocs.amd.com/en/latest/index.html https://rocmdocs.amd.com/en/latest/index.html [2] https://github.com/RadeonOpenCompute/ROCm https://github.com/RadeonOpenCompute/ROCm [3] https://github.com/JuliaGPU/AMDGPU.jl https://github.com/JuliaGPU/AMDGPU.jl

mixedCase 5y ago
Maybe if AMD starts caring about ROCm, users might. To this day Navi and newer cards are unsupported.
- kwertzzz 5y ago
  This is really the main problem. As far as I know, ROCm requires a quite expensive GPU for data centers (if you want to have a current GPU) which makes it quite difficult to build a community around ROCm.
krapht 5y ago
Most people hack on this stuff for work, and time is money. OpenCL is just a lot less productive than CUDA for most tasks. The NVidia price premium isn't big enough to make people switch over.
- andi999 5y ago
  Agree, been doing some cuda as part of my job since 2009, and it works very smooth, you could write non trivial programs after less than one week of learning (if you know C before). When opencl got a little hype, I had a look, I didn't manage to run a simple example, and I was asking myself: do I really want to have to use all this boilerplate code? Also at least a while back there is no good fft outside of cuda, maybe that changed though.
pjmlp 5y ago
This is not a charity. If the competition to CUDA wants to be taken serioulsy then provide the tooling and polyglot support to do so. OpenCL was stuck in their "C only with printf debugging" mentality for too long, now it is too late. AMD ROCm still isn't available in Windows. If I learned anything from wasting my time with Khronos stuff, was that I should have switched to DirectX much earlier.
dvfjsdhgfv 5y ago
I would love to, however for practically all tasks I need only the CUDA backend is available, not ROCm - an that is of course bad not just for open source, but also for the owners of AMD GPUs. The popularity of Nvidia's solution is so overwhelming AMD would need to do something revolutionary in order to catch up (supporting Windows and macOS wouldn't hurt either).
sebow 5y ago
AMD has the capacity now to make something equivalent and at least on-par.(Remember that they're way more open to open projects than Nvidia, at least on Linux) They just have to fix their documentation and release plans, their roadmap.ROCm looks decent-enough on paper, but when you try to install it and get started, suddenly you find more appealing spending hundreds of dollars more on locked-down hardware and proprietary libraries.
jpsamaroo 5y ago
AMD has done great work in a very short amount of time, but let's not forget that they're still very new to the GPU compute game. The ROCm stack is overall still pretty buggy, and definitely hard to build in ways other than what AMD deems officially supported. As AMDGPU.jl's maintainer, I do certainly appreciate more users using AMDGPU.jl if they have the ability to, but I don't want people to think that it's anywhere close in terms of maturity, overall performance, and feature-richness compared to CUDA.jl. If you already have access to an NVIDIA GPU, it's painless to setup and should work really well for basically anything you want to with it. I can't say the same about AMDGPU.jl right now (although we are definitely getting there).
- zamalek 5y ago
  Genuine question: why can't Vulkan Compute be used instead of CUDA and ROCm? Julia has all the tools required to "magically" transform code into SPIR-V kernels. Couldn't `:()` syntax be used to create kernels?
  - eigenspace 5y ago
    https://github.com/JuliaGPU/Vulkan.jl https://github.com/JuliaGPU/Vulkan.jl
  - snicker7 5y ago
    oneApi.jl has a Julia to SPIR-V (Vulkan) compiler.

by xvilka 5y ago

mixedCase 5y ago

Maybe if AMD starts caring about ROCm, users might. To this day Navi and newer cards are unsupported.

kwertzzz 5y ago
This is really the main problem. As far as I know, ROCm requires a quite expensive GPU for data centers (if you want to have a current GPU) which makes it quite difficult to build a community around ROCm.

krapht 5y ago

Most people hack on this stuff for work, and time is money. OpenCL is just a lot less productive than CUDA for most tasks. The NVidia price premium isn't big enough to make people switch over.

andi999 5y ago
Agree, been doing some cuda as part of my job since 2009, and it works very smooth, you could write non trivial programs after less than one week of learning (if you know C before). When opencl got a little hype, I had a look, I didn't manage to run a simple example, and I was asking myself: do I really want to have to use all this boilerplate code? Also at least a while back there is no good fft outside of cuda, maybe that changed though.

pjmlp 5y ago

This is not a charity. If the competition to CUDA wants to be taken serioulsy then provide the tooling and polyglot support to do so. OpenCL was stuck in their "C only with printf debugging" mentality for too long, now it is too late. AMD ROCm still isn't available in Windows. If I learned anything from wasting my time with Khronos stuff, was that I should have switched to DirectX much earlier.

dvfjsdhgfv 5y ago

I would love to, however for practically all tasks I need only the CUDA backend is available, not ROCm - an that is of course bad not just for open source, but also for the owners of AMD GPUs. The popularity of Nvidia's solution is so overwhelming AMD would need to do something revolutionary in order to catch up (supporting Windows and macOS wouldn't hurt either).

sebow 5y ago

AMD has the capacity now to make something equivalent and at least on-par.(Remember that they're way more open to open projects than Nvidia, at least on Linux) They just have to fix their documentation and release plans, their roadmap.ROCm looks decent-enough on paper, but when you try to install it and get started, suddenly you find more appealing spending hundreds of dollars more on locked-down hardware and proprietary libraries.

jpsamaroo 5y ago

AMD has done great work in a very short amount of time, but let's not forget that they're still very new to the GPU compute game. The ROCm stack is overall still pretty buggy, and definitely hard to build in ways other than what AMD deems officially supported. As AMDGPU.jl's maintainer, I do certainly appreciate more users using AMDGPU.jl if they have the ability to, but I don't want people to think that it's anywhere close in terms of maturity, overall performance, and feature-richness compared to CUDA.jl. If you already have access to an NVIDIA GPU, it's painless to setup and should work really well for basically anything you want to with it. I can't say the same about AMDGPU.jl right now (although we are definitely getting there).

zamalek 5y ago
Genuine question: why can't Vulkan Compute be used instead of CUDA and ROCm? Julia has all the tools required to "magically" transform code into SPIR-V kernels. Couldn't `:()` syntax be used to create kernels?
- eigenspace 5y ago
  https://github.com/JuliaGPU/Vulkan.jl https://github.com/JuliaGPU/Vulkan.jl
- snicker7 5y ago
  oneApi.jl has a Julia to SPIR-V (Vulkan) compiler.