新闻源发布时间：2026年5月4日
原作者：Khronos OpenCL 工作组
Khronos OpenCL 工作组发布了 OpenCL 3.1，将一些之前可选的功能纳入了核心规范。现在，符合规范的实现必须能够使用 SPIR-V™ 内核，并支持子组、整数点积、建议的工作组大小查询以及与 Vulkan® 相匹配的设备 UUID 查询。此次发布还对内存模型、事件同步和 OpenCL C printf 等进行了澄清和改进。Arm、Imagination、Intel、Mesa 和 Qualcomm 以及 Rusticl、PoCL 和 CLVK 等开源项目正在桌面、移动和嵌入式平台上进行 OpenCL 3.1 的实现。请访问 Khronos 博客阅读完整公告。如果您参加 2026 年 IWOCL 大会，欢迎与工作组成员交流。
提升跨平台异构计算的标准
在 IWOCL 2026 大会召开前夕，Khronos® OpenCL 工作组发布了 OpenCL™ 3.1，将广泛部署、经过现场验证的功能引入核心规范，以扩展功能，包括 SPIR-V 数据摄取，开发人员可以在符合规范的实现中依赖这些功能。
新规范的发布，为日益壮大的 OpenCL 生态系统注入了新的活力。众多芯片厂商，尤其是在移动和嵌入式市场，都已实现了 OpenCL，而包括 SYCL™ 和 chipStar 在内的高级框架也越来越多地将 OpenCL 作为加速后端。围绕 OpenCL 的开源编译器和运行时生态系统也在不断完善，基于 Vulkan 和 DirectX 12 的 OpenCL 分层实现不断涌现，进一步扩大了 OpenCL 的跨平台可用性，使其能够在没有原生驱动程序的平台上运行。
OpenCL 演进方法论
OpenCL 3.1 强制要求的功能, 目前以扩展或可选功能的形式部署。这是有意为之。OpenCL 工作组遵循规范的演进原则：首先在实际应用中验证扩展功能的有效性，观察它们在各种实现中的使用情况，根据开发者的反馈进行改进，最终才将其纳入核心规范。
OpenCL 3.1 强制要求的功能将在所有符合规范的实现中可靠地提供，从而无需在应用程序代码中进行功能检查或回退路径。
强制性 SPIR-V 摄入
所有符合 OpenCL 3.1 标准的实现都必须使用 SPIR-V™ 内核 —— 这是开发人员最希望看到的功能之一。
SPIR-V™ 是 Khronos 的可移植中间表示形式，由包括 Clang/LLVM、SPIR-V LLVM 转换器和更新的 SPIR-V LLVM 后端在内的多种开源编译器生成。除了增强源代码语言的灵活性之外，SPIR-V 还允许内核以预编译、优化的中间形式而非源代码形式分发 —— 从而保护内核知识产权、缩短应用程序启动时间并实现提前特化。
OpenCL 3.1 还要求支持 SPIR-V 查询扩展，该扩展使应用程序能够枚举设备支持的 SPIR-V 功能、扩展和版本，从而简化新 SPIR-V 功能的采用。
“强制集成 SPIR-V 是 OpenCL 3.1 中最具深远意义的改变。SPIR-V 已成为越来越多高级语言和框架（包括 SYCL、ChipStar 以及各种领域特定编译器）的自然编译目标。确保所有符合规范的实现都具备集成 SPIR-V 的能力，消除了这些工具完全采用 OpenCL 作为运行时环境的最后一个障碍。结合工作组的‘扩展优先’方法（该方法确保了 3.1 版本中强制要求的所有功能目前都已投入使用），OpenCL 3.1 进一步增强了现代异构计算所需的可靠、可移植的运行时基础架构。” OpenCL 工作组主席 Neil Trevett 表示。
人工智能和高性能计算工作负载的构建模块
高性能计算和人工智能内核的几个关键特性现在也成为 OpenCL 3.1 核心规范的强制性要求：
子群，包括洗牌、旋转以及扩展支持的数据类型集。是优化归约、扫描和矩阵核的基本构建模块。
整数点积（包括饱和和累加变体）以及扩展位运算：两者都直接映射到各种现代硅芯片上的专用硬件指令，并且都是矩阵乘法和推理工作负载核心的低精度算术的常用构建模块。
新增一项查询，用于确定建议的本地工作组大小。这为应用程序和性能分析器提供运行时提示，以确定给定内核和设备的最佳工作组大小，从而无需手动调整或在多个队列中重复计算大小，并提高在各种硬件上的性能可预测性。
标准的设备UUID 查询，与 Vulkan 的 VkPhysicalDeviceIDProperties::deviceUUID 相匹配。这使得应用程序能够跨 API 关联同一物理设备，这对于多设备系统以及跨越 OpenCL 和 Vulkan 的外部内存共享场景至关重要。
简化开发流程
OpenCL 3.1 还包含一些改进，可以提升日常开发效率：
开发者无需依赖扩展即可使用新的语言特性。这意味着内核代码更简洁、更易于移植，能够在所有符合规范的实现中可靠地编译，而无需特定于供应商的扩展保护。
OpenCL C 的 printf 函数实现现在支持 z (size_t) 和 t (ptrdiff_t) 长度修饰符。这弥合了与标准C 之间长期存在的移植性差距，使得设备端调试输出能够正确格式化指针大小和差值类型的值，而无需进行类型转换或使用格式化字符串等变通方法。
CL_DEVICE_HOST_UNIFIED_MEMORY 的语义已得到澄清，现在可用于区分集成显卡和独立显卡。应用程序现在可以可靠地使用此标志在运行时选择内存分配策略 —— 例如，在主机和设备共享同一物理内存的集成显卡上，跳过显式缓冲区复制。
可以将本地内存内核参数设置为零，以表明不需要本地内存。这样，对于那些不需要本地内存的配置，即使内核偶尔会使用本地内存，也可以无需单独的代码路径来分发这些内核。
现在，事件状态为 CL_COMPLETE 即为同步点，无需再像以前那样显式等待。这消除了一个不易察觉的正确性风险，即轮询事件状态的代码可能与内存可见性发生竞争，从而使事件驱动的同步更加简单且形式上更安全。
内存模型的“包含作用域”规则已放宽，作用域不再需要完全匹配。这意味着更细粒度的作用域现在可以满足更粗粒度的同步需求。
虽然这些变化单独来看都很小，但它们共同消除了 OpenCL 开发中长期存在的摩擦点。
实施正在进行中
OpenCL 3.1 已经发布，包括 Arm、Imagination、Intel 和 Qualcomm 在内的多家芯片供应商正在开发多种实现方案，以及包括 Mesa 项目一部分的 Rusticl、PoCL 和 CLVK在内的开源实现方案，涵盖 Windows、Linux 和 Android 平台上的桌面、移动和嵌入式市场。
分层实现方式在 OpenCL 跨平台部署中扮演着越来越重要的角色。OpenCLOn12 将 OpenCL 构建于 DirectX 12 之上，从而在 Windows PC 和云实例上提供 OpenCL 功能。CLVK、Ancle 和 Rusticl 则将 OpenCL 构建于 Vulkan 和 Zink 之上，覆盖 Android 和 Mesa 生态系统。这些分层方法不断发展演进，并在确保 OpenCL 广泛跨平台可用性方面发挥着关键作用，即使在没有原生驱动程序的情况下也是如此。
接下来会发生什么？
驱动 OpenCL 3.1 的扩展流程仍然活跃，为未来的核心版本奠定了基础。今天的扩展程序能够有力地预示未来核心规范的发展方向。目前正在开发的扩展程序包括：
命令缓冲区 - 适用于低开销可重放工作负载。通过记录一次固定的命令序列并多次重放，命令缓冲区消除了每次提交的主机开销，从而提高了推理服务、仿真循环和其他高频调度场景的吞吐量。
统一共享内存(USM) 简化了基于指针的内存管理。USM 使用标准指针语义替换显式缓冲区对象和复制命令，从而显著简化了将现有 CPU 代码移植到 GPU 以及将 OpenCL 集成到假定统一地址空间的框架中的操作。
协同矩阵运算用于高性能矩阵乘法。这些运算直接映射到现代 AI 加速器和 GPU 中的硬件矩阵引擎，从而实现密集的 GEMM 性能，这对于神经网络推理和 HPC 工作负载（例如分子动力学和气候模拟）都至关重要。
新增的 AI 数据类型涵盖低精度格式；同时改进了外部内存共享和图像分块控制。低精度类型（例如 int4 和 fp8）可降低 AI 推理工作负载的内存带宽和计算成本，而外部内存和分块方面的改进则使其更容易与 Vulkan、DirectX 12 和平台媒体管道进行互操作。
除了扩展之外，该工作组还在积极探索 OpenCL 作为更高级别编程模型的基础、在安全关键型市场以及在包括 NPU 和 RISC-V 加速器在内的新兴设备类别中的作用。
两点启示
OpenCL 已被广泛部署并积极发展。OpenCL 的实现生态系统涵盖了所有主流平台上的原生和分层方法，其工作组也制定了正在开发的新功能路线图。
OpenCL 3.1 将重要的、经过验证的功能引入核心规范，最显著的是强制 SPIR-V 摄取，这极大地扩展了开发人员在每个符合规范的实现中可以依赖的功能，并为基于 OpenCL 的下一波语言和编译器创新奠定了基础。
开发者社区的反馈推动了 OpenCL 3.1 的诞生，并将继续引领未来的发展。请在 OpenCL 规范的 GitHub 仓库提交问题和建议，并加入 Khronos Discord 的讨论。如果您参加 2026 年 IWOCL 大会，欢迎来发言！
内容来源 ｜ www.khronos.org
原博客链接：https://www.khronos.org/blog/opencl-3.1-is-here
本文转自：THE KHRONOS GROUP