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
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
|
Name
EXT_shader_framebuffer_fetch
Name Strings
GL_EXT_shader_framebuffer_fetch
Contact
Benj Lipchak, Apple (lipchak 'at' apple.com)
Status
Complete
Version
Last Modified Date: May 28, 2013
Author Revision: 4
Number
OpenGL ES Extension #122
Dependencies
OpenGL ES 2.0 is required.
This specification is written against the OpenGL ES 2.0.24 specification.
This extension is written against the OpenGL ES Shading Language 1.0.17
specification.
OpenGL ES 3.0 affects the definition of this extension.
Overview
Conventional OpenGL blending provides a configurable series of operations
that can be used to combine the output values from a fragment shader with
the values already in the framebuffer. While these operations are
suitable for basic image compositing, other compositing operations or
operations that treat fragment output as something other than a color
(normals, for instance) may not be expressible without multiple passes or
render-to-texture operations.
This extension provides a mechanism whereby a fragment shader may read
existing framebuffer data as input. This can be used to implement
compositing operations that would have been inconvenient or impossible with
fixed-function blending. It can also be used to apply a function to the
framebuffer color, by writing a shader which uses the existing framebuffer
color as its only input.
Issues
1. How is framebuffer data treated during multisample rendering?
RESOLVED: Reading the value of gl_LastFragData produces a different
result for each sample. This implies that all or part of the shader be run
once for each sample. Input values to the shader from existing variables
in GLSL ES remain identical across samples.
2. How does the use of gl_LastFragData interact with fragment discard?
RESOLVED: Hardware may not necessarily support discarding on sample
granularity. Therefore, three options were considered for this
functionality:
A) Allow discard based on variables calculated using the framebuffer
color when multisample rasterization is disabled, but disallow
discard in this manner when multisample rasterization is enabled.
B) Restrict usage of the framebuffer color until it is known whether
or not the pixel will be discarded.
C) Allow undefined results for fragment shaders that discard on a
per-sample basis on hardware that doesn't support it.
This extension has chosen option C. Restricting orthogonality of fragment
shaders between single-sample and multisample rendering is undesirable, as
is restricting usage of the framebuffer color, which can generally only be
done with detailed flow-control analysis.
3. What is the precision of gl_LastFragData in practice?
RESOLVED: Three options were considered for this functionality:
A) gl_LastFragData is always mediump.
B) gl_LastFragData takes the precision most closely matching the
actual storage format of the framebuffer.
C) Allow redeclaration of gl_LastFragData in order to change its
precision.
This extension has chosen option C. A fixed precision per option A
increases the likelihood of redundant conversion operations in the shader,
and option B does not provide for clear behavior with regard to the
precision of intermediate results from calculations using the
framebuffer color.
4. How does this extension iteract with conventional blending?
RESOLVED: There is no interaction. The two remain orthogonal. The rest
of the pipeline continues as usual after the fragment shader stage.
5. How does this extension work in ES 3.0?
RESOLVED: Differently than in ES 2.0.
The built-in fragment outputs of ES 2.0 are replaced in #version 300 es
shaders by user-declared outputs, to accomodate integer and MRT
framebuffers. Three options were considered:
A) Add built-ins similar to gl_LastFragData.
B) Add a layout to mark user-declared fragment outputs as having
defined content on entry to fragment shader.
C) Allow marking user-declared fragment outputs as "inout".
This extension has chosen option C. Adding built-ins per option A is
unwieldy for MRT framebuffers with mixed attachment types and precisions.
Options B and C are semantically identical, but C requires fewer
modifications to the specification and to user shaders. Note that the
inout qualifier is not allowed for re-declaring existing fragment outputs
such as gl_FragDepth.
New Procedures and Functions
None
New Tokens
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
and GetDoublev:
FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT 0x8A52
New Builtin Variables
mediump vec4 gl_LastFragData[gl_MaxDrawBuffers]
Changes to the OpenGL ES 2.0.24 Specification, Chapter 3
Remove the last sentence of Paragraph 2 of Section 3.8.1, page 84 ("These
built-in varying variables include [...]" and add:
These built-in varying variables include the fragment's position, eye z
coordinate, and front-facing flag, as well as the last data or color value
written to the framebuffer. When the value of SAMPLE_BUFFERS is 1 and the
current framebuffer color is accessed in the fragment shader, the fragment
shader will be invoked separately for each covered sample and a separate
value for the previous framebuffer color will be provided for each sample."
Add a new subsection to section 3.8.2, page 87 ("Shader Execution"):
"Discard
Fragment shaders may conditionally abandon operations using the discard
keyword. However, the ability of hardware to support abandoning operations
on a single sample when the shader is invoked once for each covered sample
is implementation-dependent. This capability can be determined by calling
GetBooleanv with the symbolic constant
FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT. If FALSE is returned, results from
shaders which discard based on per-sample logic are undefined."
Changes to the OpenGL ES 2.0.24 Specification, Chapter 4
Replace first element of Figure 4.1, page 90 ("Fragment + Associated Data"):
"Fragment (or sample) + Associated Data"
New Implementation Dependent State
Add to table 6.19 (Implementation Dependent Values (cont.)):
Get Value Type Get Command Minimum Value Description Section
--------- ---- ----------- ------------- -------------- -------
FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT B GetBooleanv - Samples may be 3.8.2
discarded
individually
Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 3
Remove Paragraph 2 of section 3.8, page 17, Identifiers ("Identifiers
starting with "gl_" are reserved [...]") and add:
"Identifiers starting with "gl_" are reserved for use by OpenGL ES, and
may not be declared in a shader as either a variable or a function.
However, as noted in the specification, certain predeclared "gl_" names
are allowed to be redeclared in a shader for the specific purpose of
changing their precision qualifier."
Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 7
Add after the last sentence of Paragraph 2 of Section 7.2, page 60,
Fragment Shader Special Variables ("These variables may be written to
more [...]"):
"... To access the existing framebuffer values (e.g., to implement a
complex blend operation inside the shader), fragment shaders should use
the read-only input array gl_LastFragData. gl_LastFragData returns the
value written by the most recent fragment at the same position.
Access to gl_LastFragData is optional, and must be enabled by
#extension GL_EXT_shader_framebuffer_fetch : <behavior>
Where <behavior> is as specified in section 3.3.
By default, gl_LastFragData is declared with the mediump precision
qualifier. This can be changed by redeclaring the corresponding variables
with the desired precision qualifier.
Redeclarations are done as follows
// Redeclaration that changes nothing is allowed
mediump vec4 gl_LastFragData[gl_MaxDrawBuffers];
// All the following are allowed redeclaration that change behavior
lowp vec4 gl_LastFragData[gl_MaxDrawBuffers];
highp vec4 gl_LastFragData[gl_MaxDrawBuffers];
Redeclarations must not otherwise alter the declared type or array size of
gl_LastFragData."
Changes to the OpenGL ES Shading Language 3.00.3 Specification, Chapter 4
Modify Paragraph 2 of section 4.3.6:
"Except in the fragment stage, there is not an inout storage qualifier at
global scope for declaring a single variable name as both input and output
[...]"
Modify Paragraph 5 of section 4.3.6:
"Fragment outputs output per-fragment data and are declared using the out
or inout storage qualifier. It is an error to use centroid out or centroid
inout in a fragment shader [...]" and append new paragraph:
"Upon entry to the fragment shader, fragment outputs declared as inout will
contain the value written by the most recent fragment at the same position.
This behavior, and the ability to use the inout qualifier at global scope
in a fragment shader, is optional and must be enabled by
#extension GL_EXT_shader_framebuffer_fetch : <behavior>
Where <behavior> is as specified in section 3.4."
Interactions with OES_standard_derivatives
Results from shaders which use the built-in derivative functions dFdx,
dFdy, and fwidth on variables calculated using the current framebuffer
color are undefined.
Revision History
Version 4, 2013/05/28 - Added ES3 interaction as requested in Bug 10236
Version 3, 2012/09/24 - Remove obsolete issue 3 about derivatives
Version 2, 2012/06/21 - Fix MULTISAMPLE enabled -> SAMPLE_BUFFERS = 1,
recast from APPLE to multivendor EXT, clarify that
gl_LastFragData reflects value written by previous
pixel at same coordinates.
Version 1, 2012/06/01 - Conversion from ARB_sync to APPLE_sync for ES.
|
