OpenCL 1.2 Specification Update Feedback Thread

The Khronos™ Group today announced the ratification and public release of an update to the OpenCL™ 1.2 specification, the open, royalty-free standard for cross-platform, parallel programming of modern processors. This backwards compatible version updates the core OpenCL 1.2 specification with bug fixes and clarifications and defines additional optional extensions for enhanced performance, functionality and robustness for parallel programming on a wide variety of platforms.

The complete press release is available online.

We’d love to get some feedback of this update from the community.

Hi, I don’t know exactly if this pertains to the original or updated 1.2 specification. It may be just me, but I’m a bit confused about the definitions of the various image objects in section 5.3.1 Creating Image Objects.

From my previous understanding, image types CL_MEM_OBJECT_IMAGE1D, CL_MEM_OBJECT_IMAGE2D, and CL_MEM_OBJECT_IMAGE3D are stored in some opaque format. However, all the definitions now say “a linear sequence” nearly everywhere. Is this only for host_ptr? I can’t differentiate the aforementioned image types with CL_MEM_OBJECT_IMAGE1D_BUFFER, CL_MEM_OBJECT_IMAGE1D_ARRAY, and CL_MEM_OBJECT_IMAGE2D_ARRAY. Would someone mind clarifying them for me, or pointing me to some example figures (a picture is worth a thousand words and all :)).


The device (typically GPUs) will store the image data in an opaque format. The linear layout that is being described in the spec is referring to how the image data is laid out in the memory pointed to by host_ptr if a non-NULL host_ptr is specified to clCreateImage.

Thanks Affie,

So my initial intuition was correct. However, I still don’t see the use for the buffer/array image types. I can’t tell how they’re different than the regular 1D, 2D, and 3D types.

Also, I can’t seem to find the updated portion in the spec. relating to the third bullet in the announcement:

providing security features for WebCL implementations layered over OpenCL including: the ability to initialize local and private memory before a kernel begins execution, and a new query and API to terminate an OpenCL context to ensure a long running kernel does not affect system stability;

Although, I still see in section 6.5.2 __local (or local) that it’s illegal to initialize local memory.

Btw, I’m of course referring to the updated spec. from the above link, version 1.2 revision 19 dated 11/14/12. I can’t tell exactly what’s been updated though. In the future could the OpenCL Working Group also post a specification with changes marked like OpenGL?

Are you referring to the cl_khr_image2d_from_buffer extension that was just added as an extension to 1.2? When you create an image, the GPU stores this in an opaque layout which means you cannot access this data as a pointer to linear memory in the kernel which you can with a buffer.

With this extension, the implementation is required to make sure that the data store is the same for the buffer object and the image 2D created from the buffer. In this case the data will be stored as linear so can be accessed by a kernel using a pointer or a read_image / write_image.

This enables use cases where the texture sampling HW on a GPU can now be used to sample from a buffer.

NOTE: You cannot, however, write to the image and read from buffer associated with this image from within a single kernel.

The extensions that refer to the third bullet in the announcement are in the OpenCL 1.2 extension spec. The extension names are: cl_khr_initialize_memory (section 9.15) and cl_khr_terminate_context (section 9.16).

I see, thanks again!

Oh, and I didn’t catch the extension part because the link is still OpenCL 1.2 Extensions Specification (revision 15, released November 15, 2011), although it has actually been updated as well.