OpenCL
OpenCL（Open Computing Language）是 Khronos 制定的跨平台并行计算标准，旨在为 CPU、GPU、DSP、FPGA 等不同计算设备提供统一的编程接口。它曾是"GPU 的 C 语言"，一度被视为跨厂商计算的希望，但随着各厂商生态割裂，OpenCL 已逐渐退出历史舞台。
编程模型
OpenCL 的编程模型与 CUDA 类似，也采用 host-device 异构执行：host（通常是 CPU）负责串行逻辑和任务调度，device（GPU/CPU/其他加速器）负责并行计算。OpenCL 程序由两部分组成：host 端的 C/C++ 代码（用于设备管理、内存分配、kernel 启动）和 device 端的 OpenCL C 代码（kernel 函数，在设备上执行）。
// OpenCL kernel（device 端）
__kernel void add_kernel(__global const float* x,
__global const float* y,
__global float* z,
int n) {
int gid = get_global_id(0);
if (gid < n) {
z[gid] = x[gid] + y[gid];
}
}
// Host 端代码
cl_context context = clCreateContext(...);
cl_command_queue queue = clCreateCommandQueue(context, ...);
cl_program program = clCreateProgramWithSource(context, kernel_source, ...);
clBuildProgram(program, ...);
cl_kernel kernel = clCreateKernel(program, "add_kernel");
cl_mem x_buf = clCreateBuffer(context, CL_MEM_READ_ONLY, n * sizeof(float), NULL, NULL);
cl_mem y_buf = clCreateBuffer(context, CL_MEM_READ_ONLY, n * sizeof(float), NULL, NULL);
cl_mem z_buf = clCreateBuffer(context, CL_MEM_WRITE_ONLY, n * sizeof(float), NULL, NULL);
clEnqueueWriteBuffer(queue, x_buf, CL_TRUE, 0, n * sizeof(float), x, 0, NULL, NULL);
clEnqueueWriteBuffer(queue, y_buf, CL_TRUE, 0, n * sizeof(float), y, 0, NULL, NULL);
size_t global_size = n;
clSetKernelArg(kernel, 0, sizeof(cl_mem), &x_buf);
clSetKernelArg(kernel, 1, sizeof(cl_mem), &y_buf);
clSetKernelArg(kernel, 2, sizeof(cl_mem), &z_buf);
clSetKernelArg(kernel, 3, sizeof(int), &n);
clEnqueueNDRangeKernel(queue, kernel, 1, NULL, &global_size, NULL, 0, NULL, NULL);
clEnqueueReadBuffer(queue, z_buf, CL_TRUE, 0, n * sizeof(float), z, 0, NULL, NULL);OpenCL 的内存模型比 CUDA 更复杂，分为 global memory（全局内存）、constant memory（常量内存）、local memory（局部内存，类似 CUDA 的 shared memory）、private memory（私有内存，类似寄存器）。优化 OpenCL kernel 的关键是使用 local memory 缓存频繁访问的数据，以及保证 global memory 的合并访问。
跨平台能力
OpenCL 的核心价值是跨平台。同一份 OpenCL 代码可在 NVIDIA GPU、AMD GPU、Intel CPU、Apple Silicon、甚至 FPGA 上运行，只需针对不同平台编译。这在理论上极大降低了代码移植成本，是 OpenCL 初期能够吸引大量开发者的原因。
然而，跨平台的代价是性能妥协。OpenCL 的抽象级别高于 CUDA，无法暴露硬件特定的特性（如 NVIDIA 的 Tensor Core、AMD 的 wave32/wave64）。为了保证跨平台兼容性，OpenCL 程序通常只能使用硬件的通用能力，难以榨干硬件性能。这使得 OpenCL 在性能敏感的场景（如深度学习训练）中被厂商专用 API 取代。
生态现状
OpenCL 的生态现状可以用"逐渐式微"来形容。NVIDIA 虽然仍支持 OpenCL，但已停止更新，最新版本停留在 OpenCL 1.2（2011 年），远落后于 Khronos 的 OpenCL 3.0（2020 年）。AMD 和 Intel 仍在积极维护 OpenCL 实现，但两者的重心已转移到自己的专用 API（AMD 的 ROCm/HIP、Intel 的 oneAPI/SYCL）。
深度学习框架对 OpenCL 的支持也很有限。PyTorch 的 OpenCL 后端从未进入主分支，只能通过第三方库（如 torch-opencl）使用。TensorFlow 的 OpenCL 后端在 2.0 版本后被移除。主流框架（PyTorch、TensorFlow、JAX）都优先支持 CUDA，其次是 ROCm 和 oneAPI，OpenCL 通常是最后选项。
OpenCL 在以下场景仍有一定价值：
- 跨平台科学计算：如流体力学、分子动力学等 HPC 领域，代码需要在多种硬件上运行
- 嵌入式和边缘设备：如支持 OpenCL 的移动 GPU（Mali、Adreno）、FPGA 加速卡
- 原型验证：快速验证算法在多种硬件上的可行性，无需为每种平台重写代码
SPIR-V
SPIR-V（Standard Portable Intermediate Representation）是 OpenCL 生态的重要组成部分。它是一种中间表示格式，类似于 CUDA 的 PTX，可将 OpenCL C 代码编译为与硬件无关的二进制，然后在运行时由驱动编译为目标设备的机器码。
SPIR-V 的优势在于分发便捷。开发者可以发布 SPIR-V 二进制而非源代码，保护知识产权的同时保证跨平台兼容。SPIR-V 也被 Vulkan 采用（作为着色器的中间表示），这使得 OpenCL 和 Vulkan 可以共享编译工具链。
然而，SPIR-V 的推广并不顺利。NVIDIA 的 CUDA 不支持 SPIR-V（CUDA 只接受 PTX，SPIV-R 目前主要是图形侧在用），AMD 的 ROCm 虽然支持 SPIR-V，但性能不如 HIP。Khronos 推出的 SYCL（基于 C++ 的并行编程语言）使用 SPIR-V 作为中间表示，但 SYCL 的生态同样不温不火。
与 CUDA 对比
| 特性 | OpenCL | CUDA |
|---|---|---|
| 制定方 | Khronos（开放标准） | NVIDIA（专有） |
| 支持硬件 | NVIDIA GPU、AMD GPU、Intel CPU、FPGA 等 | 仅 NVIDIA GPU |
| 编程语言 | OpenCL C（C 的子集） | CUDA C++（C++ 的扩展） |
| 抽象级别 | 高（跨平台兼容） | 低（贴近硬件） |
| 性能 | 中等（难以榨干硬件） | 高（可极致优化） |
| 生态支持 | 逐渐式微 | 主导地位 |
| 工具链 | 开源多样 | NVIDIA 官方工具完善 |
OpenCL 的失败揭示了跨平台计算 API 的困境：硬件差异化太大，统一抽象难以兼顾性能。各厂商为了竞争，不断推出硬件特有功能（如 Tensor Core、ray tracing core），这些功能无法被标准 API 及时纳入，导致厂商 API 总是领先标准 API 一代以上。
未来展望
OpenCL 的未来并不乐观。Khronos 已将重心转移到 Vulkan（图形）和 SYCL（计算），OpenCL 的更新频率显著降低。对于新项目，建议优先选择以下方案：
- NVIDIA GPU：使用 CUDA 或 Triton
- AMD GPU：使用 ROCm/HIP
- Intel GPU/CPU：使用 oneAPI/SYCL
- 跨平台需求：考虑 SYCL 或等待 Triton 的跨平台支持
OpenCL 作为先行者，为跨平台并行计算积累了宝贵经验。它的失败教训也启发了后来的 Triton：跨平台 API 必须以性能为前提，而非单纯追求抽象统一。Triton 通过自动调优和编译期优化，在保持易用性的同时接近手写性能，这可能是跨平台计算 API 的正确方向。