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.

This is just an appreciation post for OpenCL. It's great. The only other performance portable API that comes close is KernelAbstractions.jl.

OpenCL is just so good:

1. Kernels are compiled at runtime, which means you can do whatever "metaprogramming" you want to the kernel strings before compilation. I understand this feature is a double-edged sword because error checking is sometimes a pain, but it genuinely makes certain workflows possible where they otherwise would not be (or would otherwise be a huge hassle in CUDA).

2. The JIT compiler is blazingly fast, at least from my personal tests. So much faster than GLSLangValidator, which is the only other tool I can use to compile my kernels at runtime. I actually have an OpenCL game engine mostly working and the benchmarks are really promising especially because the users never feel the Vulkan precompile times before the game starts.

3. Performance is great. I've seem benchmarks showing that OpenCL gets within 90% of CUDA performance, but from my own use-cases, the performance is near identical.

4. It works on my CPU. This is actually a great feature. I can do all my debugging on multiple devices to make sure my issues are not GPU-specific problems.

5. OpenCL lets users write actual kernels. A lot of performance portable solutions try to take serial code and transform it into GPU kernels (with some sort of parallel_for or something). I've just never found that to feel natural in practice. When you are writing code for GPUs, kernels are just so much easier to me.

There's just so much to love.

I do 100% understand that there's some jank, but to be honest, it's been way easier for me to use OpenCL than other GPU solutions for my specific problems. It's even easier than CUDA, which is a big accomplishment. KernelAbstractions.jl is also really nice and offers many similar advantages, but for my specific work-case, I found OpenCL to be better.

I mean, it's 2024. To me, the only things I need my programming language to do are GPU Computing and Metaprogramming. OpenCL does both really well.

I have seen so many people hating on OpenCL over the years and don't fully understand why. It's great.

A couple months back I posted here about 6 small (text to text) LLMs running on custom OpenCL kernels on a 2020 mid-range phone. Since then I've built it out into a full multimodal stack. Same approach throughout: from-scratch OpenCL kernels for Qualcomm Adreno, no llama.cpp, no TFLite, no MediaPipe, no ONNX runtime.

Everything below runs on-device:

LLMs: LFM2.5-230M, LFM2.5-350M-Instruct, Granite-4.0-350M, Qwen2.5-0.5B-Instruct, OpenELM-270M-Instruct, SmolLM2-135M-Instruct, Mamba-130M, Mamba2-130M.

VLMs: LFM2.5-VL-450M, SmolVLM-256M-Instruct

TTS: MMS-TTS, Pocket TTS, Kokoro-82M

ASR: Whisper-tiny

Music: MusicGen-small

Speech-to-speech translation: SeamlessM4T (unity-small)

Voice cloning: OpenVoice v2

Target is non-flagship Adreno 6xx specifically, not the latest flagship. Main test device is a Motorola Razr 2020: Snapdragon 765G, Adreno 620.

The engine is open source (https://github.com/a8nova/adreno-llms/tree/main), and I packaged the whole stack into an Android app, Edgi https://play.google.com/store/apps/details?id=com.edgi.app if anyone wants to try it out!

For our final Master’s project, my colleague and I developed a real-time ray tracing engine using OpenCL and Qt 6 n 5 weeks.
Our goal was to design a user-friendly engine featuring:

• Undo / Redo using the Command pattern

• PBR materials

• A save/load system

• FPS monitoring

• Mesh acceleration using a BVH built with SAH

We have around 180 FPS with thousands of triangles on Linux system (arch Linux).

Here a full video (don't know why i couldn't upload here) of the main features : https://www.youtube.com/watch?v=x2sxB05pIts&lc=Ugws9HlLdixyHWcDctJ4AaABAg

I put some scenes made with the engine. It was our first time with openCL, don't hesitate to share your toughts about this project !

Finally I can "SLI" AMD+Intel+Nvidia GPUs at home! I simulated this crow in flight at 680M grid cells in 36GB VRAM, pooled together from

• AMD Radeon RX 7700 XT 12GB (RDNA3)

• Intel Arc B580 12GB (Battlemage)

• Nvidia Titan Xp 12GB (Pascal)

My FluidX3D CFD software can pool the VRAM of any combination of any GPUs together, as long as VRAM capacity and bandwidth are similar. The black magic that makes this possible is OpenCL. All GPUs show up as OpenCL devices, and FluidX3D can split the simulation box into multiple domains, each simulated and rendered by one of the GPUs.

The simulaton box with 1452×968×484 = 680M grid cells resolution (36GB VRAM occupation) is split into 3 domains of 484×968×484 = 227M cells, each running in 12GB on one of the GPUs. 45705 discrete time steps were computed, equivalent to 0.5 seconds flight in real time. Flight velocity was set to 20 km/h. Runtime was 2h11m total, consisting of 1h27m for the LBM simulation and 44m for rendering.

This demonstrates that heterogenious GPGPU compute is actually very practical. OpenCL allows FluidX3D users to run the hardware they already have, and freely expand with any other hardware that is best value at the time, rather than being vendor-locked and having to buy more expensive GPUs that bring less value.

The crow model geometry is from Michael Price on Thingiverse: https://www.thingiverse.com/thing:5138469/files

A lot of people have requested it, so I have finally opensourced my OpenCL-Benchmark utility. This tool measures the peak performance/bandwidth of any GPU. Have fun!

GitHub link: https://github.com/ProjectPhysX/OpenCL-Benchmark

Example:

|----------------.------------------------------------------------------------|
| Device ID      | 0                                                          |
| Device Name    | NVIDIA A100-PCIE-40GB                                      |
| Device Vendor  | NVIDIA Corporation                                         |
| Device Driver  | 525.89.02                                                  |
| OpenCL Version | OpenCL C 1.2                                               |
| Compute Units  | 108 at 1410 MHz (6912 cores, 19.492 TFLOPs/s)              |
| Memory, Cache  | 40513 MB, 3024 KB global / 48 KB local                     |
| Buffer Limits  | 10128 MB global, 64 KB constant                            |
|----------------'------------------------------------------------------------|
| Info: OpenCL C code successfully compiled.                                  |
| FP64  compute                                         9.512 TFLOPs/s (1/2 ) |
| FP32  compute                                        19.283 TFLOPs/s ( 1x ) |
| FP16  compute                                          not supported        |
| INT64 compute                                         2.664  TIOPs/s (1/8 ) |
| INT32 compute                                        19.245  TIOPs/s ( 1x ) |
| INT16 compute                                        15.397  TIOPs/s (2/3 ) |
| INT8  compute                                        18.052  TIOPs/s ( 1x ) |
| Memory Bandwidth ( coalesced read      )                       1350.39 GB/s |
| Memory Bandwidth ( coalesced      write)                       1503.39 GB/s |
| Memory Bandwidth (misaligned read      )                       1226.41 GB/s |
| Memory Bandwidth (misaligned      write)                        210.83 GB/s |
| PCIe   Bandwidth (send                 )                         22.06 GB/s |
| PCIe   Bandwidth (   receive           )                         21.16 GB/s |
| PCIe   Bandwidth (        bidirectional)            (Gen4 x16)    8.77 GB/s |
|-----------------------------------------------------------------------------|

What I am trying to do is use multiple GPUs with OpenCL to solve the advection equation (upstream advection scheme). What you are seeing in the attached GIFs is a square advecting horizontally from left to right. Simple domain decomposition is applied, using shadow arrays at the boundaries. The left half of the domain is designated to GPU #1, and the right half of the domain is designated to GPU #2. In every loop, boundary information is updated, and the advection routine is applied. The domain is periodic, so when the square reaches the end of the domain, it comes back from the other end.

The interesting and frustrating thing I have encountered is that I am getting some kind of artifact at the boundary with the AMD GPU. Executing the exact same code on NVIDIA GPUs does not create this problem. I wonder if there is some kind of row/column major type of difference, as in Fortran and C, when it comes to dealing with array operations in OpenCL.

Has anyone encountered similar problems?

OpenCL is happy to announce the release of the finalized OpenCL 3.0 specifications, including a new unified OpenCL C 3.0 language specification with an early initial release of a Khronos OpenCL SDK to enable developers to quickly start using OpenCL.

khr.io/us

Today NVIDIA announced fully conformant OpenCL 3.0 for Windows and Linux on Maxwell and later GPUs. Existing OpenCL 1.x based applications will continue to work with NVIDIA’s OpenCL 3.0 drivers without any changes. In addition to full OpenCL 1.2 compatibility, NVIDIA’s OpenCL 3.0 drivers now deliver significant optional OpenCL 3.0 functionality. Developers can try out the R465 drivers with OpenCL 3.0 today.

https://developer.nvidia.com/blog/nvidia-is-now-opencl-3-0-conformant/

Microsoft has released a compatibility pack that allows you to run any OpenCL and OpenGL apps on a Windows 10 PC that doesn’t have OpenCL and OpenGL hardware drivers installed by default. If you have a DirectX 12 driver installed on your Windows 10 PC, supported apps will run with hardware acceleration for better performance.

https://www.microsoft.com/en-us/p/opencl-and-opengl-compatibility-pack/9nqpsl29bfff

The Khronos Group is pushing more consistency into the spec by promoting several features from optional to core.

Including:

• SPIR-V kernel ingestion is now required

• Subgroups + integer dot products are core

• New queries for work-group sizing and device UUID (aligned with Vulkan)

• Spec cleanups around memory model, sync, and printf

Vendors + open source stacks are already working on support, including: Intel, Arm, Qualcomm, Mesa, Rusticl, PoCL, CLVK.

Find the full post here: https://www.khronos.org/blog/opencl-3.1-is-here

Comment and share feedback on the OpenCL specification GitHub or the Khronos Discord.

Through some tragedeigh I have become the only moderator of r/OpenCL. Since OpenCL is very much a community effort, I'm happy to announce that u/thekhronosgroup - Jeff Phillips - is joining me as moderator!

Khronos has today released the OpenCL 3.0.14 maintenance update that introduces a new cl_khr_command_buffer_multi_device provisional extension that enables execution of a heterogeneous command-buffers across multiple devices. This release also includes significant improvements to the OpenCL C++ Bindings, a new code generation framework for the OpenCL extension headers, and the usual clarifications and bug fixes. The new specifications can be downloaded from the OpenCL Registry.

https://registry.khronos.org/OpenCL/

Hello, I am the creator of the VkFFT - GPU Fast Fourier Transform library. In the latest update, I have added OpenCL as a backend option (in addition to Vulkan, CUDA and HIP) so if some of you are interested in OpenCL FFT - feel free to check it out and ask any questions! The performance of it is on the same level as other backends.

GitHub link: https://github.com/DTolm/VkFFT

I've been porting models to run on the Adreno 6xx GPUs in mid-range/older Android phones using OpenCL kernels — no NNAPI, no TFLite, just C++ and OpenCL.

Latest one: MMS-TTS (Meta's text-to-speech that covers 1100+ languages), now running inference fully offline on my 6 year old Motorola Razr. The whole VITS stack is ported — text encoder → duration predictor → flow → vocoder — plus uroman romanization so non-Latin scripts work.

I also paired it with SmolVLM-256M (image preprocessing → SigLIP vision encoder → LM) so the phone can look at an image, describe it, and speak the result — all offline.

Everything's open source: the OpenCL kernels, C++ inference code, tokenizers, both full pipelines, and the demo Android app.

👉 https://github.com/a8nova/adreno-llms

Demo video in the comments. Happy to answer anything about the kernel work or the VITS port.

From the 511.23 release notes: https://us.download.nvidia.com/Windows/511.23/511.23-win11-win10-release-notes.pdf

https://media.discordapp.net/attachments/692387066365083678/931638915083956274/Screenshot_20220114-205519.png

https://media.discordapp.net/attachments/692387066365083678/931639001776001034/Screenshot_20220114-205649.png