OpenCL 2.1 has been released today as a set of provisional specifications to enable feedback from OpenCL community before the specification is finalized - to ensure that we are properly targeting your needs and requests.
The provisional specification is in three parts. It should be noted that a requirement of OpenCL 2.1 is that it not add hardware requirements over OpenCL 2.0, so all feedback should be constrained within those bounds.
The OpenCL 2.1 API specification
[ul]
[li]Sub-groups have moved into core, we’ve adding support for copying kernel objects with their arguments across threads and low-latency timers to improve joint profiling of host and device code.[/li][/ul]
The SPIR-V specification
[ul]
[li]Earlier versions of SPIR were OpenCL-specific, and tied to LLVM. SPIR-V is a major step, defining a fully custom intermediate language for graphics and accelerated computing. SPIR-V is intended as a core requirement of both OpenCL and Vulkan platforms and as a target for shader languages, OpenCL C, OpenCL C++ kernel language, SYCL and other languages that may arise from the community.[/li][/ul]
The OpenCL 2.1 C++ kernel language specification
[ul]
[li]Defines a new C++ kernel language, compiled offline via SPIR or online via a compiler library, that implements the feature set of OpenCL C 2.0 in a new, efficient and composable static C++ syntax. The C++ kernel language replaces blocks with lambda functions, adds templates and inheritance and allows function overloading of user-defined functions.[/li][li]By adding the OpenCL C++ kernel language we do not obsolete OpenCL C. New features are implemented in the OpenCL C++ kernel language but earlier versions of OpenCL C remain supported both at runtime and through support in SPIR-V.[/li][/ul]
For these provisional specifications, which are far from final, we are looking for feedback to see if they satisfy the community’s needs.
[ul]
[li]The memory model has not been changed - does OpenCL 2.0’s memory model meet your needs or is something missing?[/li][li]Is the execution model well-enough defined or are there things that can be clarified without requiring hardware changes?[/li][li]Does SPIR-V satisfy the requirements of someone wishing to write a compiler from a new language that targets OpenCL runtimes? Is there anything missing in terms of features or specification that could improve this?[/li][li]Does the C++ kernel language match expectations?[/li][li]Is hiding address spaces in the kernel language the right solution? Explicit address spaces place the burden on the programmer and template engine, hidden address spaces place the burden on the compiler and hardware.[/li][/ul]