command_queue
A valid command-queue. All devices used to create the OpenCL context
associated with command_queue
must support acquiring shared CL/GL objects.
This constraint is enforced at context creation time.
num_objects
The number of memory objects to be acquired in mem_objects
.
mem_objects
A pointer to a list of CL memory objects that correspond to GL objects.
event_wait_list
,
num_events_in_wait_list
Specify events that need to complete before this
particular command can be executed. If event_wait_list
is NULL, then this particular command
does not wait on any event to complete. If event_wait_list
is NULL,
num_events_in_wait_list
must be 0. If event_wait_list
is not NULL,
the list of events pointed to by event_wait_list
must
be valid and num_events_in_wait_list
must be greater than 0.
The events specified in
event_wait_list
act as synchronization points.
event
Returns an event object that identifies
this command and can be used to query or queue a wait for the command
to complete. event
can be NULL in which case
it will not be possible for the application to query the status of
this command or queue a wait for this command to complete. If the
event_wait_list
and the event
arguments are not NULL, the event
argument should not
refer to an element of the event_wait_list
array
If the cl_khr_gl_sharing extension is supported, if an OpenGL context is bound to the current thread, then any OpenGL commands which
mem_objects
list, and
clEnqueueAcquireGLObjects
will complete before execution of any OpenCL commands following the
clEnqueueAcquireGLObjects
which affect or access
any of those memory objects. If a non-NULL event object is returned,
it will report completion only after completion of such OpenGL commands.
These objects need to be acquired before they can be used by any OpenCL commands
queued to a command-queue. The OpenGL objects are acquired by the OpenCL context
associated with command_queue
and can therefore be used by all
command-queues associated with the OpenCL context.
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.
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.
Returns CL_SUCCESS if the function is executed successfully. If
num_objects
is 0 and mem_objects
is NULL the
function does nothing and returns CL_SUCCESS. Otherwise,
it returns one of the following errors:
num_objects
is zero and mem_objects
is not a NULL value or if
num_objects
> 0 and mem_objects
is NULL.
mem_objects
are not valid OpenCL memory objects.
command_queue
is not a valid command-queue.
command_queue
was not created from an OpenGL context.
mem_objects
have not been created from a GL object(s).
event_wait_list
is NULL and
num_events_in_wait_list
> 0,
or event_wait_list
is not NULL and
num_events_in_wait_list
is 0, or if event objects in
event_wait_list
are not valid events.