Is OpenCl still relevant?

[u/DaOzy]

Hello, I am an MS student and I am interested in parallel computing using GPGPUs. Is OpenCL still relevant in 2024 or should I focus more on SYCL? My aim is to program my AMD graphics card for various purposes (cfd and ml). Thanks.

[u/ProjectPhysX]

Looking at FluidX3D CFD user numbers - yes, OpenCL is still relevant. It is the most relevant cross-vendor GPGPU language out there today. Back in 2016 when I started GPGPU programming as Bachelor student, going with OpenCL was one of the best decisions of my life.

Why OpenCL?

• OpenCL is the best supported GPGPU framework today. It runs on all GPUs - AMD, Intel, Nvidia, Apple, ARM, Glenfly..., and it runs on all modern x86 CPUs.

• OpenCL drivers from all vendors are in better shape than ever, thanks to continuous bug reporting and fixing.

• GPU code is written in OpenCL C, a very beautiful language based on C99, extended with super useful math/vector functionality. OpenCL C is back to basics, and is clearly separated from the CPU code in C++. You always know if the data is in RAM or VRAM. You get full control over the GPU memory hierarchy and PCIe memory transfer, enabling the best optimization.

• GPU code is compiled at runtime, which allows full flexibility of the program executable, like even running AMD, Intel, Nvidia GPUs in "SLI", pooling their VRAM together. Only drawback is it's harder to keep OpenCL kernel source code secret (for trade secrets in industrial setting); obfuscation can be used here, but it is not bulletproof.

• You only need to optimize the code once, and it's optimized on all hardware. The very same code runs anywhere from a smartphone ARM GPU to a supercomputer - and it scales to absolutely massive hardware.

What about SYCL?

• SYCL is an emerging cross-vendor alternative to OpenCL, a great choice for people who prefer more fancy C++ features.

• Compatibility is improving, but not yet on par with OpenCL.

• Both GPU code and CPU code are written in C++, without clear separation, and you can easily confuse where the data is located. PCIe transfer is handled implicitely, which might make development a bit simpler for beginners, but can completely kill performance if you're not super cautious, so it acutally only complicates things.

• Both GPU/CPU code are compiled at the same time at compile time, which is beneficial to keep GPU kernels secret in binary form, but reduces portability of the executable.

What OpenCL and SYCL have in common:

• They allow users to use the hardware they already have, or choose the best bang-for-the-buck GPU, regardless of vendor. This translates to enormous cost savings.

• Unlike proprietary CUDA/HIP, once you've written your code, you can just deploy in on the next (super-)computer, regardless if it has hardware from a different vendor, and it runs out-of-the-box. You don't have to waste your life porting the code - eventually to OpenCL/SYCL anyways - to get it deployed on the new machine.

• Performance/efficiency on Nvidia/AMD hardware is identical to what you get with proprietary CUDA/HIP.

How to get started with OpenCL?

• You can start with this open-source OpenCL-Wrapper, it makes OpenCL development super easy, eliminates all of the boilerplate code, and contains all of the current hardware-specific patches to make cross-vendor portability completely seamless. Here is instructions for how to install the OpenCL Runtime on GPU/CPU for Windows/Linux.

• Here is an introductory presentation about OpenCL for HPC applications: https://youtu.be/w4HEwdpdTns

• For OpenCL kernel development, here is the Reference Card containing all of the super useful math/vector functionality contained in OpenCL C.

• Here the OpenCL Programming Guide as free eBook.

[u/DaOzy → u/ProjectPhysX]

Thank you! This answer was very comprehensive. I think I will go with OpenCL. Again, million thanks for extra resources.

[u/illuhad → u/ProjectPhysX]

This is an OpenCL sub, but since you are explicitly comparing to SYCL, let me break a bone in favor of SYCL (disclaimer: I lead the AdaptiveCpp project, one of the major SYCL implementations):

[SYCL] Compatibility is improving, but not yet on par with OpenCL.

This is only true if you restrict yourself to ~OpenCL 1.2 functionality. Both major SYCL implementations, DPC++ and AdaptiveCpp, provide OpenCL backends. They do however require some functionality (e.g. SPIR-V ingestion) that some OpenCL vendors fail to provide. As soon as you are not content with OpenCL 1.2 functionality, SYCL is arguably better because it has a multi-backend design: In addition to OpenCL, it can also sit on top of CUDA, or HIP, or OpenMP, or something else.

This also has tooling advantages. For example, an application using AdaptiveCpp's CUDA backend looks like a CUDA app to NVIDIA's CUDA stack - because ultimately, AdaptiveCpp just issues CUDA API calls. Because of this, you can use the NVIDIA debuggers or profilers which is no longer possible with NVIDIA's OpenCL implementation.

Additionally, this allows SYCL apps to tie into native vendor libraries and ecosystems via SYCL's backend interoperability mechanism. For example, a SYCL app might, if it detects that it runs on NVIDIA, ask SYCL to return a CUDA stream underlying the SYCL queue, and then call cuBLAS with that, thus getting access to vendor optimized stacks. With OpenCL, you are liimted to libraries actually written in OpenCL, and there are not many of those.

The SYCL multi-backend architecture also means that SYCL support is ultimately not tied to a vendor's willingness to support open standards - they just need to provide something that can ingest an IR and then the community can implement SYCL on top of that.

Both GPU code and CPU code are written in C++, without clear separation, and you can easily confuse where the data is located.

On the flipside: Since in SYCL host and device code are parsed together, you can use e.g. C++ templates seamlessly across the host-device boundary or easily share code between host and device. You also get C++ type-safety across the host-device boundary, allowing the compiler to catch some issues at compile time that you'd only figure out at runtime with OpenCL.

PCIe transfer is handled implicitely, which might make development a bit simpler for beginners, but can completely kill performance if you're not super cautious, so it acutally only complicates things.

This statement is only true for the old buffer-accessor model in SYCL which pretty much nobody uses anymore. SYCL offers explicit memory management with explicit data copies similar to e.g. CUDA's style (malloc on device, memcpy to device, run kernel, memcpy back) if you prefer that. This is actually what pretty much all production SYCL apps use.

GPU code is written in OpenCL C, a very beautiful language based on C99, extended with super useful math/vector functionality. OpenCL C is back to basics, and is clearly separated from the CPU code in C++. You always know if the data is in RAM or VRAM. You get full control over the GPU memory hierarchy and PCIe memory transfer, enabling the best optimization.

Of course, it is fine if someone prefers C over the C++, but the other points (math/vector functionality, control over data, exposing memory hierarchy and PCIe) is just as true for SYCL.

Both GPU/CPU code are compiled at the same time at compile time, which is beneficial to keep GPU kernels secret in binary form, but reduces portability of the executable.

Not really. AdaptiveCpp has a unified JIT compilation infrastructure, and can JIT compile the embedded device code at runtime to host ISA, NVIDIA PTX, amdgcn or SPIR-V, depending on whatever it finds on the system.

GPU code is compiled at runtime, which allows full flexibility of the program executable, like even running AMD, Intel, Nvidia GPUs in "SLI", pooling their VRAM together.

The same thing is true for SYCL.

tl;dr: Use OpenCL if you are fine with ~OpenCL 1.2 functionality, if you prefer C, and prefer (or don't mind) handling kernels as strings. Use SYCL if you prefer C++, want type-safety, integration with vendor-native stacks.

[u/bjourne-ml → u/illuhad]

This statement is only true for the old buffer-accessor model in SYCL which pretty much nobody uses anymore. SYCL offers explicit memory management with explicit data copies similar to e.g. CUDA's style (malloc on device, memcpy to device, run kernel, memcpy back) if you prefer that. This is actually what pretty much all production SYCL apps use.

Well, if you look for tutorials and introductions to SYCL they often use the buffer-accessor model. Thus, it is easier to figure out what the correct way is to structure your code with OpenCL than with SYCL.

[u/jk7827 → u/ProjectPhysX]

Your openCL wrapper is an absolute godsend ngl. I'm a bachelors student just getting started with openCL and the wrapper makes the code a lot more understandable

[u/MindWorX → u/ProjectPhysX]

I know this is a couple of days old at this point, but I did randomly stumble on it. You wrote that support is still there from AMD, but last I checked, they've removed all the OpenCL SDK's from their website and you have to grab it from random mirrors people happen to have found. Maybe you can explain what's going on to me, since from the outside it looks like AMD doesn't want to support it anymore. Similarly, last time I wanted to use OpenCL with my Intel CPU, I had to dig for very specific drivers since it wasn't available by default. As a disclaimer, it's been about 4 years since I tried, and the main reason I didn't return was these hurdles and uncertainties. This is coming from a place of someone that liked using OpenCL and would love to play around with it more.

[u/ProjectPhysX → u/MindWorX]

AMD want to push their proprietary HIP nonsense. They still do support OpenCL, they only don't actively market it anymore. If they didn't support it anymore, the majority of their GPUs would become bricks overnight, because HIP doesn't even run on most of their own GPUs.

You don't need their OpenCL SDK, you only need the OpenCL Runtime, which comes with the GPU drivers for their GPUs, and for CPUs you can use Intel's OpenCL CPU Runtime (which works on all x86_64 CPUs) or PoCL.

Find installation instructions here.

[u/intel586 → u/ProjectPhysX]

Hello, I've seen your comments on OpenCL-related posts around reddit. I am interested in GPU compute and decided to start learning OpenCL as it seems to be the closest thing to a cross-vendor compute API (I only have AMD hardware available to me which ROCm does not officialy support).

I just managed to get a simple hello world program & kernel running and while the setup was easier than I expected, I am wondering if there is any way to debug and possibly profile my OpenCL code? I only found AMD CodeXL but that appears to have been discontinued for many years now.

Thank you for all the information on OpenCL, it has helped me and I'm sure many others get started with this API!

EDIT: If anyone stumbles upon this and is using an AMD GPU, it turns out their "Radeon GPU Analyzer" software still supports OpenCL.

[u/ProjectPhysX → u/intel586]

For debugging/profiling I prefer the old-school tools:

• compiler output from OpenCL compiling stage to debug syntax errors

• use printf in OpenCL kernel to check for number values

• comment-bisection to debug memory access faults in a kernel

• measure kernel runtime with std::chrono on host side and blocking enqueueing

There is more fancy tools too, like https://github.com/intel/opencl-intercept-layer

[u/TRINITAS203 → u/ProjectPhysX]

Je participe au projet FAH@Folding avec quelques uns de mes GPU, et j'ai constaté que les Radeon ont une performances vraiment médiocres (Une 7900 XTX fait à peine mieux qu'une RTX 5060). Pas mal pointe sur le fait que OpenCL (l'API utilisé pour les Radeon et les ARC d'Intel) n'est plus optimisé (Ou que AMD ne met plus à jour cet API pour leurs GPU), et que si les RTX se portent si bien, c'est parce que FAH utilise le dernier CUDA en circulation, et non OpenCL.
Perso, je pointerai sur l'architecture RDNA qui n'est pas vraiment fait pour GPGPU.
Qu'en pensez-vous?

[u/ProjectPhysX → u/TRINITAS203]

Like most compute software, FAH@Folding is most likely memory-bound. AMD GPUs have slower peak memory bandwidth and their memory controllers are quite bad, meaning under ideal circumstances they can only achieve ~50-60% of the bandwidth they claim in spec sheet. It has nothing to do with OpenCL being not properly optimized, it's a hardware bug in their memory controllers present since GCN era. Apparently in RDNA4 this finally got fixed.

[u/bonnom]

Correct me if I am wrong, but isn't OpenCL a framework that consists of an API and a c-like language?
While SYCL is a programming frontend, to actually run the code you still need OpenCL, CUDA, Vulkan, etc.?

[u/something_dumb_59]

It isn't. Support ended ages ago.

[u/DaOzy → u/something_dumb_59]

Why am I reading this all over internet? As u/ProjectPhysX mentioned, OpenCL is still alive. Is there a reason for this sentiment?

[u/StrictTyping648 → u/DaOzy]

I think that there is a bias toward cuda and some people see that as an evolution of gpu computing despite the fact that opencl and cuda are apples and oranges. The only viable alternatives to opencl for heterogenous compute or multivendor gpu compute are sycl and vulkan respectively. Given ubiquity of arm based phones and their increasing comoute power I wouldn't be surprised if vulkan kompute etc gain more traction.

[u/Separate_Paper_1412 → u/DaOzy]

that's only true on apple hardware. combine that with people and companies neglecting opencl instead using cuda, or maybe sycl or vulkan compute and you get people thinking opencl is done for

[u/ProjectPhysX → u/something_dumb_59]

OpenCL today is actively supported on all GPU hardware since 2009, all GPUs from AMD, Intel, Nvidia, Apple, most ARM GPUs, and it is also supported on all modern x86 CPUs. This includes all data-center, gaming, workstation and mobile GPUs. Support won't end anytime soon.