4 ms·

Oh man, this is exactly what I want to see on HN frontpage! I commented on another article about an AMD chip that had no OpenCL support that it made it dead in

Oh man, this is exactly what I want to see on HN frontpage! I commented on another article about an AMD chip that had no OpenCL support that it made it dead in the water for me, and was downvoted; surely everyone understands how important CUDA is, and everyone should understand how important open standards are (e.g. FreeSync vs Nvidia's GSync), so I can't understand why more people don't share my zeal for OpenCL. I've shipped two commercial products based on it which still works perfectly today on all 3 desktop platforms from all GPU vendors... what's not to love?

jjoonathan 3y ago
For a long time, AMD promoted OpenCL as viable without it actually being viable. This leaves scars and resentment. Mine come from about 10 years ago. They run deep. I'm glad to hear your experience was better, but I'm fresh out of trust. This time, I need to see major projects in my application areas working on AMD before I buy, because AMD has taught me that "trust us" and "just around the corner" can mean "10 years later and it still hasn't happened." I'm pretty sure that this time is different, but the green tax is dirt cheap compared to learning this lesson the hard way, so I'm letting others jump first this time.
Vvector 3y ago
But is this just more BS from AMD? https://www.bit-tech.net/reviews/tech/cpus/amd-betting-everything-on-opencl/1/ https://www.bit-tech.net/reviews/tech/cpus/amd-betting-every... AMD Betting Everything on OpenCL (2011)
- jjoonathan 3y ago
  I'm pretty sure the NVDA pump finally convinced the AMD board / C-Suite to prioritize this, but it takes time to steer a big ship. I'm hopeful, but there are still bad incentives to jump the gun on announcements so I'll let others take the plunge first.
Conscat 3y ago
OpenCL isn't very useful now that we have Vulkan. Its biggest advantage is that there exist C++ compilers for its kernels. But AMD's OpenCL runtime inserts excessive memory barriers not required by the spec (they won't fix this due to Hyrum's Law) and Vulkan gives you more control over the memory allocation and synchronization anyways. If we had better Vulkan shader compilers, OpenCL would serve basically no purpose, at least for AMD hardware.
- cpill 3y ago
  AI libs could use it and we'd break the bonds in CUDA. Also Rust might get an implementation which would give it they non-intervention to overtake C++
  - pjmlp 3y ago
    No it wouldn't, until it provides the same polyglot support and graphical tooling as CUDA. At least Intel is trying with oneAPI into that direction.
- raphlinus 3y ago
  Yeah, that's a big if. In theory there's nothing preventing good compilation to Vulkan compute shaders, in practice people just aren't doing it, as CUDA actually works today. I also agree that Vulkan is more promising than OpenCL. With recent extensions, it has real pointers (buffer device address), cooperative matrix multiplication (also known as tensor cores or WMMA), scalar types other than 32 bits, proper barrier (including device-scoped, needed for single pass scan), and other important features.
- 20k 3y ago
  Its not that they're supporting buggy code, they just downgraded the quality of their implementation significantly. They made the compiler a lot worse when they swapped to rocm https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/issues/143 https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/iss... is the tracking issue for it filed a year ago, which appears to be wontfix largely because its a lot of work OpenCL still unfortunately supports quite a few things that vulkan doesn't, which makes swapping away very difficult for some use cases
parl_match 3y ago
> I can't understand why more people don't share my zeal for OpenCL. When I last worked with it, it was difficult, unstable, and performed poorly. CUDA, on the other hand, has been nothing but good (at least). Well, nvidia pricing aside ;) OpenCL might be a lot better now, but for a lot of us, we remember when it was actively a bad choice.
tysam_and 3y ago
If they can make a 288 GB $4.4-6.8k prosumer, home-computer-friendly graphics card, I will be extremely happy. Might be a pipe dream (today at least, lol, and standard in like...what, 5 years?), but if they can pull that off, then I think things would really change a lot. I don't care if it's slow, bottom-of-the-barrel GDDR6, or whatever, just being able to enter the high-end model finetuning & training regime for ML models on a budget _without_ dilly-dallying with multiple graphics cards (a monstrous pain-in-the-neck from a software, engineering, & experimentation perspective)_ would enable so much large-scale development work to happen. The compute is extremely important, and in most day-to-day usecases, the memory bandwidth even moreso, but boy oh boy would I love to enter the world offered by a large unified card architecture. (Basically, in my experience, parallelizing a model across multiple GPUs is like compiling from code to a binary -- technically you can 'edit' it, but it's like directly hex editing strings in a binary blob, extremely limited. Hence why I try to stick with models that take only a few seconds (minutes at most) to train on highly-representative tasks, distill first principles, and then expand and exploit that to other modalities from there).
kldx 3y ago
> I've shipped two commercial products based on it which still works perfectly today on all 3 desktop platforms from all GPU vendors... what's not to love? In my experience, if commercial products involved any sort of hand-optimized, proprietary OpenCL, one would be shocked by the lack of documentation and zero consistency across AMD's GPUs. Intel has SPIRV and Nvidia has PTX and this works pretty well. But some AMD cards support SPIR or SPIRV, and some don't and this support matrix keeps changing over time without a single source of truth. Throw in random segfaults inside AMD's OpenCL implementation and you have a fun day debugging! Dockerizing OpenCL on AMD is another nightmare I don't want to get into. Intel is literally installing the compute runtime and mapping `/dev/dri` inside the container. On paper, AMD has the same process but in reality I had to run `LD_DEBUG=binding` so many times just to figure out why AMD runtime breaks inside docker. There may be great upsides to AMD's hardware in other domains though

jjoonathan 3y ago

For a long time, AMD promoted OpenCL as viable without it actually being viable. This leaves scars and resentment. Mine come from about 10 years ago. They run deep. I'm glad to hear your experience was better, but I'm fresh out of trust. This time, I need to see major projects in my application areas working on AMD before I buy, because AMD has taught me that "trust us" and "just around the corner" can mean "10 years later and it still hasn't happened." I'm pretty sure that this time is different, but the green tax is dirt cheap compared to learning this lesson the hard way, so I'm letting others jump first this time.

Vvector 3y ago

But is this just more BS from AMD? https://www.bit-tech.net/reviews/tech/cpus/amd-betting-everything-on-opencl/1/ https://www.bit-tech.net/reviews/tech/cpus/amd-betting-every... AMD Betting Everything on OpenCL (2011)

jjoonathan 3y ago
I'm pretty sure the NVDA pump finally convinced the AMD board / C-Suite to prioritize this, but it takes time to steer a big ship. I'm hopeful, but there are still bad incentives to jump the gun on announcements so I'll let others take the plunge first.

Conscat 3y ago

OpenCL isn't very useful now that we have Vulkan. Its biggest advantage is that there exist C++ compilers for its kernels. But AMD's OpenCL runtime inserts excessive memory barriers not required by the spec (they won't fix this due to Hyrum's Law) and Vulkan gives you more control over the memory allocation and synchronization anyways. If we had better Vulkan shader compilers, OpenCL would serve basically no purpose, at least for AMD hardware.

cpill 3y ago
AI libs could use it and we'd break the bonds in CUDA. Also Rust might get an implementation which would give it they non-intervention to overtake C++
- pjmlp 3y ago
  No it wouldn't, until it provides the same polyglot support and graphical tooling as CUDA. At least Intel is trying with oneAPI into that direction.
raphlinus 3y ago
Yeah, that's a big if. In theory there's nothing preventing good compilation to Vulkan compute shaders, in practice people just aren't doing it, as CUDA actually works today. I also agree that Vulkan is more promising than OpenCL. With recent extensions, it has real pointers (buffer device address), cooperative matrix multiplication (also known as tensor cores or WMMA), scalar types other than 32 bits, proper barrier (including device-scoped, needed for single pass scan), and other important features.
20k 3y ago
Its not that they're supporting buggy code, they just downgraded the quality of their implementation significantly. They made the compiler a lot worse when they swapped to rocm https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/issues/143 https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/iss... is the tracking issue for it filed a year ago, which appears to be wontfix largely because its a lot of work OpenCL still unfortunately supports quite a few things that vulkan doesn't, which makes swapping away very difficult for some use cases

parl_match 3y ago

> I can't understand why more people don't share my zeal for OpenCL. When I last worked with it, it was difficult, unstable, and performed poorly. CUDA, on the other hand, has been nothing but good (at least). Well, nvidia pricing aside ;) OpenCL might be a lot better now, but for a lot of us, we remember when it was actively a bad choice.

tysam_and 3y ago

If they can make a 288 GB $4.4-6.8k prosumer, home-computer-friendly graphics card, I will be extremely happy. Might be a pipe dream (today at least, lol, and standard in like...what, 5 years?), but if they can pull that off, then I think things would really change a lot. I don't care if it's slow, bottom-of-the-barrel GDDR6, or whatever, just being able to enter the high-end model finetuning & training regime for ML models on a budget _without_ dilly-dallying with multiple graphics cards (a monstrous pain-in-the-neck from a software, engineering, & experimentation perspective)_ would enable so much large-scale development work to happen. The compute is extremely important, and in most day-to-day usecases, the memory bandwidth even moreso, but boy oh boy would I love to enter the world offered by a large unified card architecture. (Basically, in my experience, parallelizing a model across multiple GPUs is like compiling from code to a binary -- technically you can 'edit' it, but it's like directly hex editing strings in a binary blob, extremely limited. Hence why I try to stick with models that take only a few seconds (minutes at most) to train on highly-representative tasks, distill first principles, and then expand and exploit that to other modalities from there).

kldx 3y ago

> I've shipped two commercial products based on it which still works perfectly today on all 3 desktop platforms from all GPU vendors... what's not to love? In my experience, if commercial products involved any sort of hand-optimized, proprietary OpenCL, one would be shocked by the lack of documentation and zero consistency across AMD's GPUs. Intel has SPIRV and Nvidia has PTX and this works pretty well. But some AMD cards support SPIR or SPIRV, and some don't and this support matrix keeps changing over time without a single source of truth. Throw in random segfaults inside AMD's OpenCL implementation and you have a fun day debugging! Dockerizing OpenCL on AMD is another nightmare I don't want to get into. Intel is literally installing the compute runtime and mapping `/dev/dri` inside the container. On paper, AMD has the same process but in reality I had to run `LD_DEBUG=binding` so many times just to figure out why AMD runtime breaks inside docker. There may be great upsides to AMD's hardware in other domains though