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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Name
ARM_implicit_external_sync
Name Strings
EGL_ARM_implicit_external_sync
Contributors
David Garbett
Ray Smith
Contacts
David Garbett, ARM Ltd. (david 'dot' garbett 'at' arm 'dot' com)
Status
Draft
Version
Version 1, September 8, 2014
Number
EGL Extension #103
Dependencies
Requires EGL 1.1.
This extension is written against the wording of the EGL 1.2 Specification.
EGL_KHR_fence_sync is required.
Overview
This extension extends the "fence sync objects" defined in
EGL_KHR_fence_sync. It allows the condition that triggers the associated
fence command in the client API command stream to be explicitly specified on
fence object creation. It introduces a new condition that can be used to
ensure ordering between operations on buffers that may be accessed
externally to the client API, when those operations use an implicit
synchronization mechanism. Such a fence object will be signaled when all
prior commands affecting such buffers are guaranteed to be executed before
such external commands.
Applications have limited control over when a native buffer is read or
written by the GPU when imported as an EGLImageKHR or via
eglCreatePixmapSurface, which is controlled by the EGL and client API
implementations. While eglWaitClient or a client call such as glFinish
could be called, this forces all rendering to complete, which can result in
CPU/GPU serialization. Note this isn't an issue for window surfaces, where
eglSwapBuffers ensures the rendering occurs in the correct order for the
platform.
Some platforms have an implicit synchronization mechanism associated with
native resources, such as buffers. This means that accesses to the buffer
have an implicit ordering imposed on them, without involvement from the
application. However, this requires that an application that has imported
an affected buffer into EGL has a mechanism to flush any drawing operations
in flight such that they are waiting on the synchronization mechanism.
Otherwise the application cannot guarantee that subsequent operations (such
as displaying a rendered buffer) will occur after the commands performed by
the client API (such as rendering the buffer).
The mechanism to wait for the synchronization mechanism should not require
the application to wait for all rendering to complete, so that it can
continue preparing further commands asynchronously to the queued commands.
This extension provides this functionality using the new condition type for
fence sync objects, so the application only waits for the external
synchronization.
New Types
None
New Procedures and Functions
None
New Tokens
Accepted as a value of the EGL_SYNC_CONDITION_KHR attribute passed in the
<attrib_list> list to eglCreateSyncKHR when <type> is EGL_FENCE_SYNC_KHR,
and can populate <*value> when eglGetSyncAttribKHR is called with
<attribute> set to EGL_SYNC_CONDITION_KHR:
EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM 0x328A
Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors)
Add the following after the fifth paragraph of Section 3.8.1 (Sync Objects),
added by KHR_fence_sync:
"Typically client APIs are considered to execute commands in a linear queue,
where a prior command is executed and completes before a later command is
started. By default fence sync objects adhere to this model - a fence is
signaled once prior commands have completed. However on some platforms a
command in a client API may transition through multiple states before it
completes, which may impact other components of the system. Therefore the
condition that all prior commands must meet before the fence is triggered is
configurable."
Replace the sixth paragraph of Section 3.8.1 (Sync Objects), added by
KHR_fence_sync:
"If, <type> is EGL_SYNC_FENCE_KHR, a fence sync object is created. In this
case <attrib_list> can be NULL or empty, or can specify the
EGL_SYNC_CONDITION_KHR attribute. Attributes of the fence sync object have
the following default values:"
Replace the eighth paragraph of Section 3.8.1 (Sync Objects), added by
KHR_fence_sync:
"When the condition of the sync object is satisfied by the fence command,
the sync is signaled by the associated client API context, causing any
eglClientWaitSyncKHR commands (see below) blocking on <sync> to unblock. The
condition is specified by the EGL_SYNC_CONDITION_KHR attribute passed to
eglCreateSyncKHR.
If the condition is specified as EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR, the
fence sync object is satisfied by completion of the fence command
corresponding to the sync object, and all preceding commands in the
associated client API context's command stream. The sync object will not be
signaled until all effects from these commands on the client API's internal
and framebuffer state are fully realized. No other state is affected by
execution of the fence command.
If the condition is specified as
EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM, the fence sync object is
satisfied by the completion of the fence command corresponding to the sync
object, and the <submission> of all preceding commands in the associated
client API context's command stream. <Submission> defines the point in time
when a command has been queued on any implicit synchronization mechanisms
present on the platform which apply to any of the resources used by the
command. This enforces an ordering, as defined by the synchronization
mechanism, between the command and any other operations that also respect
the synchronization mechanism(s)."
Replace the second entry in the list of eglCreateSyncKHR errors in Section
3.8.1 (Sync Objects), added by KHR_fence_sync:
" * If <type> is EGL_SYNC_FENCE_KHR and <attrib_list> contains an attribute
other than EGL_SYNC_CONDITION_KHR, EGL_NO_SYNC_KHR is returned and an
EGL_BAD_ATTRIBUTE error is generated.
* If <type> is EGL_SYNC_FENCE_KHR and the value specified for
EGL_SYNC_CONDITION_KHR is not EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR or
EGL_SYNC_PRIOR_COMMANDS_SUBMITTED_ARM, EGL_NO_SYNC_KHR is returned and
an EGL_BAD_ATTRIBUTE error is generated."
Issues
1. Could glFlush guarantee commands are submitted, making this extension
unnecessary?
RESOLVED: The Open GL ES 3.1 specification defines glFlush() as causing "all
previously issued GL commands to complete in finite time". There is no
requirement for the execution of commands to reach any specific point before
it returns - a valid implementation of glFlush() could spawn a new thread
that sleeps for a minute before submitting the pending commands. While an
implementation could decide to ensure all commands are submitted within
glFlush(), it could not be assumed to be the case across all
implementations.
In addition, there may be scenarios when submitting commands within
glFlush() is harmful. Waiting for command submission may have a performance
impact on some implementations that perform processing of commands
asynchronously. In addition such a change may restrict what is possible in
the future. For example if user events were introduced into OpenGL ES they
have the potential of introducing deadlocks if submission in glFlush() is
guaranteed.
2. Should a new entry point be defined that flushes commands synchronously,
instead of the new fence type as defined by this extension?
RESOLVED: While a synchronous "flush and submit" entrypoint would meet the
requirements for this extension, there may be a small benefit in enabling
the application to continue processing between flushing and waiting for
submission. In addition, the semantics of the existing EGL_KHR_fence_sync
extension closely match what is required for this extension, so defining
the new functionality in terms of fences may enable simpler implementations.
3. Should OpenGL ES 3 glFenceSync be extended in preference to
eglCreateSyncKHR?
RESOLVED: Some platforms are yet to move to a OpenGL ES 3 implementation, or
may be unwilling to expose OpenGL ES 3 entrypoints to applications. As
EGL_KHR_fence_sync is older than OpenGL ES 3, and is comparatively a small
change, it has a better chance of adoption in a platform.
In addition this extension is based on the idea that there are
platform-specific ways to interact with the client API command stream. As
this is platform-specific, and does not fit with the existing model
typically used by client APIs (such as Open GL ES) it is better placed in
EGL.
Finally extending EGL has the advantage that the extension applies to all
client APIs.
4. Should a new <type> parameter be defined, instead of extending the
EGL_FENCE_SYNC_KHR fence sync objects defined by EGL_KHR_fence_sync?
RESOLVED: Whether the new functionality is defined as an extension to the
existing fence sync objects, or whether they are defined as a new type of
sync object, we must acknowledge that the model of a client API processing
commands serially (with prior commands completing before later commands are
executed) is too simplistic for some platforms.
Extending the existing fence sync objects allows us to use the existing
concept of conditions that trigger the fences. It also allows the maximum
amount of reuse of existing functionality, potentially simplifying the
implementation and the use of the extension by applications.
Revision History
#1 (David Garbett, September 8, 2014)
- Initial draft.
|
