1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
<para>
<!-- ext. spec p. 59 --> 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.
</para>
<para>
<!-- ext. spec p. 59 --> Prior to calling <function>clEnqueueAcquireGLObjects</function>,
the application must ensure that any pending GL operations which access the objects
specified in <varname>mem_objects</varname> have completed. This may be accomplished
portably by issuing and waiting for completion of a <function>glFinish</function>
command on all GL contexts with pending references to these objects. Implementations
may offer more efficient synchronization methods; for example on some platforms calling
<function>glFlush</function> 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 <function>glFinish</function> are portable
between OpenGL implementations at this time.
</para>
<para>
<!-- ext. spec p. 59 --> Similarly, after calling
<function>clEnqueueReleaseGLObjects</function>, the application is responsible
for ensuring that any pending OpenCL operations which access the objects specified
in <varname>mem_objects</varname> have completed prior to executing subsequent GL
commands which reference these objects. This may be accomplished portably by calling
<citerefentry><refentrytitle>clWaitForEvents</refentrytitle></citerefentry> with the
event object returned by <function>clEnqueueReleaseGLObjects</function>, or by calling
<citerefentry><refentrytitle>clFinish</refentrytitle></citerefentry>. As above, some
implementations may offer more efficient methods.
</para>
<para>
<!-- ext. spec p. 59 --> The application is responsible for maintaining the proper order
of operations if the CL and GL contexts are in separate threads.
</para>
<para>
<!-- ext. spec p. 59 --> If a GL context is bound to a thread other than the one in which
<function>clEnqueueReleaseGLObjects</function> is called, changes to any of the objects in
<varname>mem_objects</varname> 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.
</para>
<para>
<!-- ext. spec p. 59 --> 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.
</para>
<para>
<!-- ext. spec p. 63 --> If the
<citerefentry><refentrytitle>cl_khr_gl_event</refentrytitle></citerefentry> 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.
</para>
<!-- 24-Oct-2011 -->
|
