clGetGLContextInfoKHR

Get OpenGL context information.

cl_int clGetGLContextInfoKHR ( const cl_context_properties  *properties ,
  cl_gl_context_info  param_name ,
  size_t  param_value_size ,
  void  *param_value ,
  size_t  *param_value_size_ret )

Parameters

properties

Points to an attribute list whose format and valid contents are identical to the properties argument of clCreateContext. properties must identify a single valid GL context or GL share group object.

param_name

A constant that specifies the GL context information to query, and must be one of the values shown in the table below.

param_value_size

Specifies the size in bytes of memory pointed to by param_value. This size must be greater than or equal to the size of the return type described in the table below.

param_value

A pointer to memory where the result of the query is returned as described in the table below. If param_value is NULL, it is ignored.

param_value_size_ret

Returns the actual size in bytes of data being queried by param_value. If param_value_size_ret is NULL, it is ignored.

param_name Return Type Information returned in param_value
CL_CURRENT_DEVICE_FOR_GL_CONTEXT_KHR cl_device_id Return the CL device currently associated with the specified OpenGL context.
CL_DEVICES_FOR_GL_CONTEXT_KHR cl_device_id[] List of all CL devices which may be associated with the specified OpenGL context.

Description

Get OpenGL context information.

Notes

The OpenCL specification in section 9.7 defines how to share data with texture and buffer objects in a parallel OpenGL implementation, but does not define how the association between an OpenCL context and an OpenGL context or share group is established. This extension defines optional attributes to OpenCL context creation routines which associate a GL context or share group object with a newly created OpenCL context. If this extension is supported by an implementation, the string "cl_khr_gl_sharing" will be present in the CL_DEVICE_EXTENSIONS string described in the table of allowed values for param_name for clGetDeviceInfo or in the CL_PLATFORM_EXTENSIONS string described in the table of allowed values for param_name for clGetPlatformInfo.

This section discusses OpenCL functions that allow applications to use OpenGL buffer, texture, and renderbuffer objects as OpenCL memory objects. This allows efficient sharing of data between OpenCL and OpenGL. The OpenCL API may be used to execute kernels that read and/or write memory objects that are also OpenGL objects.

An OpenCL image object may be created from an OpenGL texture or renderbuffer object. An OpenCL buffer object may be created from an OpenGL buffer object.

OpenCL memory objects may be created from OpenGL objects if and only if the OpenCL context has been created from an OpenGL share group object or context. OpenGL share groups and contexts are created using platform specific APIs such as EGL, CGL, WGL, and GLX. On MacOS X, an OpenCL context may be created from an OpenGL share group object using the OpenCL platform extension cl_apple_gl_sharing. On other platforms including Microsoft Windows, Linux/Unix and others, an OpenCL context may be created from an OpenGL context using the Khronos platform extension cl_khr_gl_sharing. Refer to the platform documentation for your OpenCL implementation, or visit the Khronos Registry at http://www.khronos.org/registry/cl/ for more information.

Any supported OpenGL object defined within the GL share group object, or the share group associated with the GL context from which the CL context is created, may be shared, with the exception of the default OpenGL objects (i.e. objects named zero), which may not be shared.

OpenGL and Corresponding OpenCL Image Formats

The table below (Table 9.4) describes the list of GL texture internal formats and the corresponding CL image formats. If a GL texture object with an internal format from the table below is successfully created by OpenGL, then there is guaranteed to be a mapping to one of the corresponding CL image format(s) in that table. Texture objects created with other OpenGL internal formats may (but are not guaranteed to) have a mapping to a CL image format; if such mappings exist, they are guaranteed to preserve all color components, data types, and at least the number of bits/component actually allocated by OpenGL for that format.

GL internal format CL image format (channel order, channel data type)
GL_RGBA8 CL_RGBA, CL_UNORM_INT8 or CL_BGRA, CL_UNORM_INT8
GL_SRGBA8_ALPHA8 CL_sRGBA, CL_UNORM_INT8
GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV CL_RGBA, CL_UNORM_INT8
GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV CL_BGRA, CL_UNORM_INT8
GL_RGBA8I, GL_RGBA8I_EXT CL_RGBA, CL_SIGNED_INT8
GL_RGBA16I, GL_RGBA16I_EXT CL_RGBA, CL_SIGNED_INT16
GL_RGBA32I, GL_RGBA32I_EXT CL_RGBA, CL_SIGNED_INT32
GL_RGBA8UI, GL_RGBA8UI_EXT CL_RGBA, CL_UNSIGNED_INT8
GL_RGBA16UI, GL_RGBA16UI_EXT CL_RGBA, CL_UNSIGNED_INT16
GL_RGBA32UI, GL_RGBA32UI_EXT CL_RGBA, CL_UNSIGNED_INT32
GL_RGBA8_SNORM CL_RGBA, CL_SNORM_INT8
GL_RGBA16 CL_RGBA, CL_UNORM_INT16
GL_RGBA16_SNORM CL_RGBA, CL_SNORM_INT166
GL_RGBA16F, GL_RGBA16F_ARB CL_RGBA, CL_HALF_FLOAT
GL_RGBA32F, GL_RGBA32F_ARB CL_RGBA, CL_FLOAT
GL_R8 CL_R, CL_UNORM_INT8
GL_R8_SNORM CL_R, CL_SNORM_INT8
GL_R16 CL_R, CL_UNORM_INT16
GL_R16_SNORM CL_R, CL_SNORM_INT16
GL_R16F CL_R, CL_HALF_FLOAT
GL_R32F CL_R, CL_FLOAT
GL_R8I CL_R, CL_SIGNED_INT8
GL_R16I CL_R, CL_SIGNED_INT16
GL_R32I CL_R, CL_SIGNED_INT32
GL_R8UI CL_R, CL_UNSIGNED_INT8
GL_R16UI CL_R, CL_UNSIGNED_INT16
GL_R32UI CL_R, CL_UNSIGNED_INT32
GL_RG8 CL_RG, CL_UNORM_INT8
GL_RG8_SNORM CL_RG, CL_SNORM_INT8
GL_RG16 CL_RG, CL_UNORM_INT16
GL_RG16_SNORM CL_RG, CL_SNORM_INT16
GL_RG16F CL_RG, CL_HALF_FLOAT
GL_RG32F CL_RG, CL_FLOAT
GL_RG8I CL_RG, CL_SIGNED_INT8
GL_RG16I CL_RG, CL_SIGNED_INT16
GL_RG32I CL_RG, CL_SIGNED_INT32
GL_RG8UI CL_RG, CL_UNSIGNED_INT8
GL_RG16UI CL_RG, CL_UNSIGNED_INT16
GL_RG32UI CL_RG, CL_UNSIGNED_INT32

If the cl_khr_gl_depth_images extension is enabled, the following new image formats are added to table 9.4 in section 9.6.3.1 of the OpenCL 2.0 extension specification. If a GL texture object with an internal format from table 9.4 is successfully created by OpenGL, then there is guaranteed to be a mapping to one of the corresponding CL image format(s) in that table.

GL internal format CL image format (channel order, channel data type)
GL_DEPTH_COMPONENT32F CL_DEPTH, CL_FLOAT
GL_DEPTH_COMPONENT16 CL_DEPTH, CL_UNORM_INT16
GL_DEPTH24_STENCIL8 CL_DEPTH_STENCIL, CL_UNORM_INT24
GL_DEPTH32F_STENCIL8 CL_DEPTH_STENCIL, CL_FLOAT

Lifetime of [GL] Shared Objects

An OpenCL memory object created from an OpenGL object (hereinafter refered to as a "shared CL/GL object") remains valid as long as the corresponding GL object has not been deleted. If the GL object is deleted through the GL API (e.g. glDeleteBuffers, glDeleteTextures, or glDeleteRenderbuffers), subsequent use of the CL buffer or image object will result in undefined behavior, including but not limited to possible CL errors and data corruption, but may not result in program termination.

The CL context and corresponding command-queues are dependent on the existence of the GL share group object, or the share group associated with the GL context from which the CL context is created. If the GL share group object or all GL contexts in the share group are destroyed, any use of the CL context or command-queue(s) will result in undefined behavior, which may include program termination. Applications should destroy the CL command-queue(s) and CL context before destroying the corresponding GL share group or contexts.

Synchronizing OpenCL and OpenGL Access

In order to ensure data integrity, the application is responsible for synchronizing access to shared CL/GL objects by their respective APIs. Failure to provide such synchronization may result in race conditions and other undefined behavior including non-portability between implementations.

Prior to calling clEnqueueAcquireGLObjects, the application must ensure that any pending GL operations which access the objects specified in mem_objects have completed. This may be accomplished portably by issuing and waiting for completion of a glFinish command on all GL contexts with pending references to these objects. Implementations may offer more efficient synchronization methods; for example on some platforms calling glFlush may be sufficient, or synchronization may be implicit within a thread, or there may be vendor-specific extensions that enable placing a fence in the GL command stream and waiting for completion of that fence in the CL command queue. Note that no synchronization methods other than glFinish are portable between OpenGL implementations at this time.

When the extension cl_khr_egl_event is supported: Prior to calling clEnqueueAcquireGLObjects, the application must ensure that any pending EGL or EGL client API operations which access the objects specified in mem_objects have completed. If the cl_khr_egl_event extension is supported and the EGL context in question supports fence sync objects, explicit synchronisation can be achieved as set out in section 5.7.1. If the cl_khr_egl_event extension is not supported, completion of EGL client API commands may be determined by issuing and waiting for completion of commands such as glFinish or vgFinish on all client API contexts with pending references to these objects. Some implementations may offer other efficient synchronization methods. If such methods exist they will be described in platform-specific documentation. Note that no synchronization methods other than glFinish and vgFinish are portable between all EGL client API implementations and all OpenCL implementations. While this is the only way to ensure completion that is portable to all platforms, these are expensive operation and their use should be avoided if the cl_khr_egl_event extension is supported on a platform.

Similarly, after calling clEnqueueReleaseGLObjects, the application is responsible for ensuring that any pending OpenCL operations which access the objects specified in mem_objects have completed prior to executing subsequent GL commands which reference these objects. This may be accomplished portably by calling clWaitForEvents with the event object returned by clEnqueueReleaseGLObjects, or by calling clFinish. As above, some implementations may offer more efficient methods.

The application is responsible for maintaining the proper order of operations if the CL and GL contexts are in separate threads.

If a GL context is bound to a thread other than the one in which clEnqueueReleaseGLObjects is called, changes to any of the objects in mem_objects may not be visible to that context without additional steps being taken by the application. For an OpenGL 3.1 (or later) context, the requirements are described in Appendix D ("Shared Objects and Multiple Contexts") of the OpenGL 3.1 Specification. For prior versions of OpenGL, the requirements are implementation-dependent.

Attempting to access the data store of an OpenGL object after it has been acquired by OpenCL and before it has been released will result in undefined behavior. Similarly, attempting to access a shared CL/GL object from OpenCL before it has been acquired by the OpenCL command queue, or after it has been released, will result in undefined behavior.

If the cl_khr_gl_event extension is supported, then the OpenCL implementation will ensure that any such pending OpenGL operations are complete for an OpenGL context bound to the same thread as the OpenCL context. This is referred to as implicit synchronization.

Errors

Returns CL_SUCCESS if the function is executed successfully. If no device(s) exist corresponding to param_name, the call will not fail, but the value of param_value_size_ret will be zero. Otherwise returns one of the following:

  • CL_INVALID_GL_SHAREGROUP_REFERENCE_KHR if a context was specified by any of the following means:
    • A context was specified for an EGL-based OpenGL ES or OpenGL implementation by setting the attributes CL_GL_CONTEXT_KHR and CL_EGL_DISPLAY_KHR
    • A context was specified for a GLX-based OpenGL implementation by setting the attributes CL_GL_CONTEXT_KHR and CL_GLX_DISPLAY_KHR
    • A context was specified for a WGL-based OpenGL implementation by setting the attributes CL_GL_CONTEXT_KHR and CL_WGL_HDC_KHR

    and any of the following conditions hold:

    • The specified display and context attributes do not identify a valid OpenGL or OpenGL ES context.
    • The specified context does not support buffer and renderbuffer objects.
    • The specified context is not compatible with the OpenCL context being created (for example, it exists in a physically distinct address space, such as another hardware device; or it does not support sharing data with OpenCL due to implementation restrictions).
  • CL_INVALID_GL_SHAREGROUP_REFERENCE_KHR if a share group was specified for a CGL-based OpenGL implementation by setting the attribute CL_CGL_SHAREGROUP_KHR, and the specified share group does not identify a valid CGL share group object.

  • CL_INVALID_OPERATION if a context was specified as described above and any of the following conditions hold:

    • A context or share group object was specified for one of CGL, EGL, GLX, or WGL and the OpenGL implementation does not support that window-system binding API.
    • More than one of the attributes CL_CGL_SHAREGROUP_KHR, CL_EGL_DISPLAY_KHR, CL_GLX_DISPLAY_KHR, and CL_WGL_HDC_KHR is set to a non-default value.
    • Both of the attributes CL_CGL_SHAREGROUP_KHR and CL_GL_CONTEXT_KHR are set to non-default values.
    • Any of the devices specified in the devices argument cannot support OpenCL objects which share the data store of an OpenGL object.
  • CL_INVALID_VALUE if an attribute name other than those specified in the table of supported properties for clCreateContext is specified in properties.
  • CL_INVALID_VALUE if param_name is not one of the values listed in the table above; or if the size in bytes specified by param_value_size is less than the size of the return type shown in the table above, and param_value is not a NULL value.
  • CL_OUT_OF_RESOURCES if there is a failure to allocate resources required by the OpenCL implementation on the device
  • CL_OUT_OF_HOST_MEMORY if there is a failure to allocate resources required by the OpenCL implementation on the host.

Specification

OpenCL Specification

Also see

clCreateContext, cl_khr_gl_sharing, cl_khr_gl_event

Copyright © 2007-2013 The Khronos Group Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and/or associated documentation files (the "Materials"), to deal in the Materials without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Materials, and to permit persons to whom the Materials are furnished to do so, subject to the condition that this copyright notice and permission notice shall be included in all copies or substantial portions of the Materials.