Official OpenCL 2.2 Provisional Feedback thread

OpenCL™ 2.2, SYCL™ 2.2 and SPIR-V™ 1.1 provisional specifications are now available. OpenCL 2.2 incorporates the OpenCL C++ kernel language for significantly enhanced parallel programming productivity.

OpenCL 2.2 defines the OpenCL C++ kernel language as a static subset of the C++14 standard. OpenCL C++ includes classes, templates, lambda expressions, function overloads and many other constructs to increase parallel programing productivity through generic and meta-programming.

OpenCL library functions can now take advantage of the C++ language to provide increased safety and reduced undefined behavior while accessing features such as atomics, iterators, images, samplers, pipes, and device queue built-in types and address spaces.

Pipe storage is new device-side type in OpenCL 2.2 that is useful for FPGA implementations by making connectivity size and type known at compile time, enabling efficient device-scope communication between kernels.

OpenCL 2.2 also includes features for enhanced optimization of generated code: applications can provide the value of specialization constant at SPIR-V compilation time, a new query can detect non-trivial constructors and destructors of program scope global objects, and user callbacks can be set at program release time.

A couple of notes:

  • clSetKernelExecInfo has no “complementary” clGetKernelExecInfo call;
  • the OpenCL C++ specification mentions (page 288, section 4.1) that “static selection of rounding mode is supported”, carried over from the OpenCL C specification; however, neither dynamic nor static rounding mode selection for the device code is documented since OpenCL 1.1 (where the OPENCL SELECT_ROUNDING_MODE pragma was removed from the OpenCL C standard) except for the conversion operator.

[QUOTE=Bilog;40152]A couple of notes:

  • clSetKernelExecInfo has no “complementary” clGetKernelExecInfo call;

Correct. If such functionality is added, it could potentially return a very large amount of data which would incurring significant overhead to both OpenCL driver and application. Can you provide some motivation for having this feature?

  • the OpenCL C++ specification mentions (page 288, section 4.1) that “static selection of rounding mode is supported”, carried over from the OpenCL C specification; however, neither dynamic nor static rounding mode selection for the device code is documented since OpenCL 1.1 (where the OPENCL SELECT_ROUNDING_MODE pragma was removed from the OpenCL C standard) except for the conversion operator.[/QUOTE]

Good point. This is an oversight. There is no plan to support rounding mode selection, final specification will be fixed accordingly.

I didn’t have a specific application in mind, I just thought it might be practical for introspection.

I understand. I assume the OpenCL specification will be amended accordingly, too?

( I still think the lack of support for rounding mode selection in OpenCL is a significant obstacle to its adoption for some scientific applications, though. But at least the specification will be consistent now :wink: )

[QUOTE=Bilog;40401]I didn’t have a specific application in mind, I just thought it might be practical for introspection.

I understand. I assume the OpenCL specification will be amended accordingly, too?

( I still think the lack of support for rounding mode selection in OpenCL is a significant obstacle to its adoption for some scientific applications, though. But at least the specification will be consistent now :wink: )[/QUOTE]

We take introspection on a case by case basis (not every API has introspection). For instance, clSetKernelArg does not have full introspection, but we have added clCloneKernel to serve specific use cases.