clCreateFromGLBuffer

Parameters

context

A valid OpenCL context created from an OpenGL context.

flags

A bit-field that is
used to specify usage information. Refer to the table for
clCreateBuffer
for a description of flags. Only
CL_MEM_READ_ONLY, CL_MEM_WRITE_ONLY
and CL_MEM_READ_WRITE values specified in the table at
clCreateBuffer
can be used.

bufobj

The name of a GL buffer object. The data
store of the GL buffer object must have have been previously created by
calling OpenGL function glBufferData, although its
contents need not be initialized. The size of the data store will be used
to determine the size of the CL buffer object.

errcode_ret

Returns an appropriate error code as described
below. If errcode_ret is NULL, no error code is returned.

Description

The size of the GL buffer object data store at the time
clCreateFromGLBuffer is called will be used as the size of buffer
object returned by clCreateFromGLBuffer. If the state of a GL
buffer object is modified through the GL API (e.g. glBufferData)
while there exists a corresponding CL buffer object, subsequent use of the CL buffer
object will result in undefined behavior.

The CL buffer object created using clCreateFromGLBuffer can also
be used to create a CL 1D image buffer object

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 a valid non-zero OpenCL buffer object and errcode_ret is set
to CL_SUCCESS if the buffer object is created successfully.
Otherwise, it returns a NULL
value with one of the following error values returned in errcode_ret:

CL_INVALID_CONTEXT if context is not
a valid context or was not created from a GL context.

CL_INVALID_VALUE if values specified in
flags are not valid.

CL_INVALID_GL_OBJECT if bufobj is not
a GL buffer object or is a GL buffer object but does not have an existing data
store e or the size of the buffer is 0.

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.