“We installed OpenCL and the transcoder still runs — so the GPU must be doing the work.” That sentence hides the single most common failure in Ubuntu transcoding setups: an OpenCL runtime that loads cleanly, throws no error, and quietly does nothing on the GPU. The transcode completes. The output is correct. And every frame was processed on the CPU. An OpenCL install is not verified by the absence of an error. It is verified by device enumeration — the moment clinfo reports the specific GPU platform you expected, and the transcoder is confirmed to be dispatching filter and scaling work to that device rather than falling back to a CPU implementation. On a single workstation the difference is a slow encode you eventually notice. On a Linux transcoding fleet, the difference is a cost regression that arrives disguised as a codec problem when it is actually a runtime problem. What does “opencl ubuntu install” actually mean in practice? OpenCL on Linux is not a single package. It is a loader plus a set of vendor implementations, and the two are frequently confused during setup. The loader is the ICD loader — usually ocl-icd-libopencl1, the library that applications link against as libOpenCL.so. Installing it gives you a working libOpenCL.so and an application that starts without a linker error. It gives you no compute device. The loader’s entire job is to read the files in /etc/OpenCL/vendors/ — the installable client drivers, or ICDs — and expose whatever platforms those ICD files point to. The implementation is the vendor ICD: NVIDIA’s OpenCL (shipped with the CUDA driver stack), AMD’s ROCm OpenCL runtime, Intel’s compute-runtime, or a CPU implementation such as POCL, the portable OpenCL runtime. Each drops an ICD file into /etc/OpenCL/vendors/ describing where its .so lives. If no GPU ICD is present, the loader still works — it simply enumerates zero GPU platforms, or falls through to a CPU implementation if one is installed. The application sees a valid OpenCL context and runs. Nothing warns you. This is the divergence point named in every broken Ubuntu setup we have looked at: the naive path installs a generic OpenCL package, sees no error, and assumes success. The correct path installs the vendor ICD that matches the driver stack already on the machine, then proves the GPU platform is enumerable before trusting a single performance number. Which OpenCL ICD and driver package should I install for my GPU? The ICD must match the GPU vendor and, critically, the driver already installed. Installing AMD’s ROCm OpenCL on a machine with NVIDIA hardware produces a valid-looking install that enumerates nothing useful. The mapping below is the practitioner reference; the vendor’s own documentation governs exact package names per Ubuntu release, so treat this as the shape of the decision, not a frozen command list. GPU vendor Driver source OpenCL ICD source Enumerated platform (clinfo) NVIDIA nvidia-driver-* (proprietary) Bundled with the driver (nvidia-opencl-icd on some releases) “NVIDIA CUDA” AMD amdgpu-dkms / ROCm stack rocm-opencl-runtime “AMD Accelerated Parallel Processing” Intel (Arc / Xe / iGPU) intel-opencl-icd package intel-opencl-icd (compute-runtime) “Intel(R) OpenCL” CPU fallback (any) none pocl-opencl-icd “Portable Computing Language” Two rules keep this clean in a fleet. First, install the ICD from the same source as the driver — if the NVIDIA driver came from apt, take the OpenCL ICD from the same channel so versions stay coherent across a kernel or driver upgrade. Second, be deliberate about whether a CPU ICD is present at all. POCL is genuinely useful for portability and for CPU-side work, but on a node whose entire justification is GPU offload, a stray CPU ICD is exactly what turns a missing GPU platform into a silent, correct-looking CPU transcode. If you want the fleet to fail loudly when the GPU is absent, do not install a CPU fallback on GPU nodes. The related walkthroughs on installing OpenCL on Ubuntu for GPU video-analytics workloads and OpenCL runtime and driver setup for GPU transcoding go deeper on the per-vendor package specifics; this article stays on the verify-and-fail-loudly discipline. How do I verify OpenCL is working with clinfo? clinfo is the verification tool. Install it (apt install clinfo) and read its output as a two-stage check, not a pass/fail glance. Stage one is platform enumeration. clinfo should print a “Number of platforms” line greater than zero, and each platform’s name should be the one you expect from the table above. If it reads “Number of platforms: 0”, the loader found no ICD files — the vendor ICD is missing or its file in /etc/OpenCL/vendors/ points at a .so that is not present. This is the most common empty-platform cause on Ubuntu, and it is a configuration problem, not a hardware one. Stage two is device enumeration under the platform. A platform can enumerate with zero usable devices — this happens when the ICD is installed but the underlying driver or kernel module is not loaded, or a permissions problem blocks device-node access. Confirm the “Device Type” reads CL_DEVICE_TYPE_GPU and the device name matches your physical card. A platform that enumerates only a CL_DEVICE_TYPE_CPU device is the fallback trap in plain sight. Quick-answer: the three checks that make an OpenCL install trustworthy Loader present — an application links libOpenCL.so without error. Necessary, never sufficient. Platform enumerates — clinfo reports your expected vendor platform (e.g. “NVIDIA CUDA”), not zero platforms. GPU device enumerates — under that platform, clinfo shows a CL_DEVICE_TYPE_GPU device with your card’s name, and OpenCL work actually dispatches to it during a real transcode. Only when all three hold is the GPU-utilisation figure in a downstream cost profile a measurement rather than a guess. How do I confirm the transcoder is using the GPU, not silently falling back to CPU? Device enumeration proves the runtime can reach the GPU. It does not prove your transcoder does. FFmpeg with OpenCL filters, GStreamer OpenCL elements, and application-level pipelines each choose a device at runtime, and each can be misconfigured to select the wrong platform index or fail over to CPU without complaint. The verification is behavioural, not declarative. Run a representative transcode and observe the GPU under load, not at rest. nvidia-smi for NVIDIA, rocm-smi for AMD, or intel_gpu_top for Intel should show the device’s compute engines and memory bandwidth moving during the encode — not merely the display engine ticking over. If GPU utilisation sits near zero while a CPU core saturates, the transcode is running on the CPU regardless of what clinfo reported. In our experience this is the single failure that most often reaches production undetected, because the artifact — the transcoded file — is byte-for-byte plausible either way (observed across setup engagements, not a benchmarked failure rate). A second confirmation is timing under a controlled input. Transcode the same clip with the GPU path forced and with it disabled, and compare wall-clock time. A GPU path that is genuinely offloading shows a clear separation; a GPU path that is silently on CPU shows none. This is cheap to run once per node image and is the check most fleets skip. What are the common causes of a broken or empty OpenCL platform, and how do I fix them? The failure modes cluster tightly, which makes them fast to triage once you know the pattern. Loader without ICD. ocl-icd-libopencl1 installed, /etc/OpenCL/vendors/ empty. clinfo reports zero platforms. Fix: install the vendor ICD. ICD file, missing .so. The vendor ICD file references a library that a partial upgrade removed. clinfo errors on load. Fix: reinstall the vendor OpenCL runtime so the ICD and its .so are coherent. Driver/kernel-module mismatch. ICD present, but the kernel module (e.g. nvidia, amdgpu) is not loaded after a kernel upgrade. Platform enumerates, device count is zero. Fix: rebuild/reload the module (DKMS) and reboot. Permissions. The service user is not in the group that owns the device node (video, render). Root sees the device; the transcoder’s user does not. Fix: add the service user to the right group. Silent CPU ICD. A CPU OpenCL implementation is installed alongside a missing GPU ICD. Everything “works” on CPU. Fix: remove the CPU ICD from GPU-only nodes, or make GPU dispatch mandatory in the pipeline config. Across a fleet, the operationally cheap move is to bake clinfo platform-and-device assertions into the node image’s health check, so a node that boots into any of these states is quarantined before it accepts transcode jobs — rather than discovered weeks later as a “the codec got slow” ticket. How does OpenCL relate to GPU-accelerated transcoding cost and utilisation? This is why the verify step matters beyond tidiness. A transcoding cost profile answers “what does a stream cost to process, and where is the money going?” — and the GPU-utilisation number sits at the centre of that answer. If OpenCL is silently on CPU, that number is fiction: the profile attributes cost to a GPU that never ran, and the pipeline looks expensive for reasons that get misdiagnosed as a codec or bitrate problem. A verified OpenCL runtime is the precondition that makes the utilisation figure trustworthy, which is precisely why runtime readiness comes before the cost-per-stream audit, not after. The economics of the codec layer itself — where hardware and software encoders like x265 for HEVC streaming actually spend cycles — are a separate axis; you cannot reason about either honestly until the runtime underneath them is confirmed. For teams running GPU transcode at fleet scale in a broadcast and media-telecom delivery path, the pattern we keep returning to is simple: a verified runtime turns “the codec is slow” into “utilisation is 12% because OpenCL is on CPU” — a diagnosable, one-line answer instead of a week of codec forensics. FAQ How does opencl ubuntu install work in practice? An OpenCL install on Ubuntu is a loader (ocl-icd-libopencl1) plus one or more vendor implementations registered as ICD files in /etc/OpenCL/vendors/. The loader lets applications link libOpenCL.so and start without error, but it provides no compute device on its own. In practice, a “successful” install with no GPU ICD present will run happily on CPU and give no warning, so the install is only meaningful once you confirm the intended GPU platform enumerates. Which OpenCL ICD and driver package should I install on Ubuntu for my GPU (NVIDIA / AMD / Intel)? Install the ICD that matches both your GPU vendor and the driver already on the machine: NVIDIA’s OpenCL ships with the CUDA driver stack, AMD uses rocm-opencl-runtime, and Intel uses intel-opencl-icd. Take the ICD from the same source as the driver so versions stay coherent across upgrades. On GPU-only nodes, be deliberate about not installing a CPU fallback ICD (such as POCL) if you want the node to fail loudly when the GPU is unavailable. How do I verify OpenCL is working after install using clinfo and device enumeration? Run clinfo and read it in two stages: confirm “Number of platforms” is greater than zero and names your expected vendor platform, then confirm a device under that platform reports CL_DEVICE_TYPE_GPU with your card’s name. Zero platforms means the loader found no ICD file; a platform with zero devices means the ICD is present but the driver or kernel module is not loaded, or permissions block device access. Only a GPU device enumerating cleanly counts as verified. How do I confirm my transcoder is actually using the GPU via OpenCL rather than silently falling back to CPU? Enumeration proves the runtime can reach the GPU, not that the transcoder does. Run a representative transcode and watch the device under load with nvidia-smi, rocm-smi, or intel_gpu_top — compute engines and memory bandwidth should move during the encode. If GPU utilisation stays near zero while a CPU core saturates, or if wall-clock time is identical with the GPU path forced versus disabled, the transcode is on CPU regardless of what clinfo reported. What are the common causes of a broken or empty OpenCL platform on Ubuntu, and how do I fix them? The usual causes are: a loader with no ICD file (install the vendor ICD), an ICD file pointing at a missing .so after a partial upgrade (reinstall the vendor runtime), a kernel module not loaded after a kernel upgrade (rebuild via DKMS and reboot), device-node permissions where the service user lacks the video/render group, and a silent CPU ICD masking a missing GPU one (remove it from GPU nodes). Baking clinfo assertions into a node health check catches all of these before jobs run. How does OpenCL relate to GPU-accelerated transcoding cost and utilisation in a streaming pipeline? The GPU-utilisation figure is the centre of a transcoding cost profile, and it is only trustworthy once OpenCL is verified end-to-end. If the runtime is silently on CPU, the profile attributes cost to a GPU that never ran, and a runtime problem gets misdiagnosed as a codec or bitrate problem. Verifying the runtime first is what makes runtime readiness a precondition for the cost-per-stream audit rather than an afterthought. Where this leaves the audit Getting OpenCL onto a fleet is trivial; proving it reaches the GPU on every node is the work. The failure class here is not “OpenCL won’t install” — it is “OpenCL installed, ran, and lied about where the compute happened.” A node image that asserts platform-and-device enumeration at boot, plus a one-clip GPU-load check before jobs are accepted, is what keeps that lie out of your cost numbers. When the runtime is verified end-to-end, the [inference and transcoding cost-cut pack](Inference Cost-Cut Pack) is measuring a real GPU rather than a fallback that only looks like one.
