• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    INTEL_fragment_shader_ordering
4
5Name Strings
6
7    GL_INTEL_fragment_shader_ordering
8
9Contact
10
11    Slawomir Grajewski, Intel  (slawomir.grajewski 'at' intel.com)
12
13Contributors
14
15    Tim Foley, Intel
16    Brent Insko, Intel
17    Tomasz Janczak, Intel
18    Marco Salvi, Intel
19    Larry Seiler, Intel
20    Tomasz Poniecki, Intel
21
22Status
23
24    Draft.
25
26Version
27
28    Last Modified Date:        08/29/2013
29    INTEL Revision:            3
30
31Number
32
33    OpenGL Extension #441
34
35Dependencies
36
37    This extension is written against the OpenGL 4.4 (Core Profile)
38    Specification.
39
40    This extension is written against version 4.40 (revision 6) of the OpenGL
41    Shading Language Specification.
42
43    OpenGL 4.2 or ARB_shader_image_load_store is required;GLSL 4.20 is
44    required.
45
46Overview
47
48    Graphics devices may execute in parallel fragment shaders referring to the
49    same window xy coordinates. Framebuffer writes are guaranteed to be
50    processed in primitive rasterization order, but there is no order guarantee
51    for other instructions and image or buffer object accesses in
52    particular.
53
54    The extension introduces a new GLSL built-in function,
55    beginFragmentShaderOrderingINTEL(), which blocks execution of a fragment
56    shader invocation until invocations from previous primitives that map to
57    the same xy window coordinates (and same sample when per-sample shading
58    is active) complete their execution. All memory transactions from previous
59    fragment shader invocations are made visible to the fragment shader
60    invocation that called beginFragmentShaderOrderingINTEL() when the function
61    returns.
62
63    Including the following line in a shader can be used to control the
64    language features described in this extension:
65
66      #extension GL_INTEL_fragment_shader_ordering : <behavior>
67
68    where <behavior> is as specified in section 3.3.
69
70    New preprocessor #defines are added to the OpenGL Shading Language:
71
72      #define GL_INTEL_fragment_shader_ordering 1
73
74New Procedures and Functions
75
76    None.
77
78New Tokens
79
80    None.
81
82Additions to the OpenGL 4.4 (Core Profile) Specification
83
84       Modify section 2.11.13 Shader Memory Access
85       (add new text in last bullet on p. 143)
86
87       The exception is when the built-in function
88       beginFragmentShaderOrderingINTEL() is used. This function creates a
89       region in a fragment shader in which memory operations complete and are
90       made visible in rasterization order for fragments that overlap in xy
91       window coordinates.
92
93       (add new paragraph after second paragraph on p. 144)
94
95       The built-in function beginFragmentShaderOrderingINTEL() may be used to
96       provide ordering of reads and writes performed by fragment shader
97       invocations that overlap in xy window coordinates. Calling
98       beginFragmentShaderOrderingINTEL() guarantees that any memory
99       transactions issued by shader invocations from previous primitives,
100       mapped to same xy window coordinates (and same sample when per-sample
101       shading is active), complete and are visible to the shader invocation
102       that called beginFragmentShaderOrderingINTEL().
103
104
105Modifications to the OpenGL Shading Language Specification, Version 4.40
106(revision 6)
107
108
109    Modify Section 8.17 Shader Memory Control Functions
110
111    (add to the table, p. 178)
112
113    Syntax
114    ------
115
116    void beginFragmentShaderOrderingINTEL()
117
118
119    This function is available only in fragment shaders.
120
121    Description
122    -----------
123
124    The beginFragmentShaderOrderingINTEL() function blocks fragment shader
125    execution until completion of all shader invocations from previous
126    primitives that map to the same window xy coordinates (and same sample
127    if appropriate). All memory transactions from previous fragment shader
128    invocations mapped to same xy window coordinates are made visible to
129    the current fragment shader invocation when this function returns.
130    When per-fragment shading is active, the ordering guarantee applies
131    regardless of whether previous and current invocations cover overlapping
132    or disjoint sets of samples under same fragment of window xy coordinates.
133    When per-sample shading is active, the ordering guarantee applies to
134    shader invocations mapped to the same sample number under same window xy
135    coordinates. This function has no effect on shader execution for fragments
136    with non-overlapping window xy coordinates.
137
138
139    The beginFragmentShaderOrderingINTEL() function can be called under control
140    flow, including non-uniform control flow. Synchronization and ordering
141    guarantees are valid only if the conditional branch is taken during
142    execution. It is valid for a fragment shader to dynamically execute
143    multiple calls to beginFragmentShaderOrderingINTEL(). In such cases, the
144    first executed call will block as described above, but subsequent calls
145    will never block.
146
147
148    Note there is no explicit built-in function to signal the end of the region
149    that should be ordered. Instead, the region that will be ordered logically
150    extends to the end of fragment shader execution.
151
152
153    GLSL code example
154    -----------------
155
156    layout(binding = 0, rgba8) uniform image2D image;
157
158    vec4 main()
159    {
160        ... compute output color
161        if (color.w > 0)        // potential non-uniform control flow
162        {
163            beginFragmentShaderOrderingINTEL();
164            ... read/modify/write image         // ordered access guaranteed
165        }
166        ... no ordering guarantees (as varying branch might not be taken)
167
168        beginFragmentShaderOrderingINTEL();
169
170        ... update image again                  // ordered access guaranteed
171    }
172
173Errors
174
175    None.
176
177New State
178
179    None.
180
181New Implementation Dependent State
182
183    None.
184
185Issues
186
187    None.
188
189Revision History
190
191    Rev.    Date    Author        Changes
192    ----  --------  --------     -----------------------------------------
193     1    07/30/13  S.Grajewski  Initial revision.
194     2    08/26/13  T.Janczak    removed per-image synchronization
195     3    08/29/13  T.Janczak    incorporate internal review feedback
196