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
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
|
<HTML>
<TITLE>Shading Language Support</TITLE>
<link rel="stylesheet" type="text/css" href="mesa.css"></head>
<BODY>
<H1>Shading Language Support</H1>
<p>
This page describes the features and status of Mesa's support for the
<a href="http://opengl.org/documentation/glsl/" target="_parent">
OpenGL Shading Language</a>.
</p>
<p>
Last updated on 28 March 2007.
</p>
<p>
Contents
</p>
<ul>
<li><a href="#unsup">Unsupported Features</a>
<li><a href="#notes">Implementation Notes</a>
<li><a href="#hints">Programming Hints</a>
<li><a href="#standalone">Stand-alone GLSL Compiler</a>
<li><a href="#implementation">Compiler Implementation</a>
<li><a href="#validation">Compiler Validation</a>
</ul>
<a name="unsup">
<h2>Unsupported Features</h2>
<p>
The following features of the shading language are not yet supported
in Mesa:
</p>
<ul>
<li>Dereferencing arrays with non-constant indexes
<li>Comparison of user-defined structs
<li>Linking of multiple shaders is not supported
<li>gl_ClipVertex
<li>The derivative functions such as dFdx() are not implemented
<li>The inverse trig functions asin(), acos(), and atan() are not implemented
<li>The gl_Color and gl_SecondaryColor varying vars are interpolated
without perspective correction
<li>Floating point literal suffixes 'f' and 'F' aren't allowed.
</ul>
<p>
All other major features of the shading language should function.
</p>
<a name="notes">
<h2>Implementation Notes</h2>
<ul>
<li>Shading language programs are compiled into low-level programs
very similar to those of GL_ARB_vertex/fragment_program.
<li>All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
float[4] registers.
<li>Float constants and variables are packed so that up to four floats
can occupy one program parameter/register.
<li>All function calls are inlined.
<li>Shaders which use too many registers will not compile.
<li>The quality of generated code is pretty good, register usage is fair.
<li>Shader error detection and reporting of errors (InfoLog) is not
very good yet.
<li>The ftransform() function doesn't necessarily match the results of
fixed-function transformation.
</ul>
<p>
These issues will be addressed/resolved in the future.
</p>
<a name="hints">
<h2>Programming Hints</h2>
<ul>
<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
This improves the efficiency of function inlining.
</li>
<br>
<li>To reduce register usage, declare variables within smaller scopes.
For example, the following code:
<pre>
void main()
{
vec4 a1, a2, b1, b2;
gl_Position = expression using a1, a2.
gl_Color = expression using b1, b2;
}
</pre>
Can be rewritten as follows to use half as many registers:
<pre>
void main()
{
{
vec4 a1, a2;
gl_Position = expression using a1, a2.
}
{
vec4 b1, b2;
gl_Color = expression using b1, b2;
}
}
</pre>
Alternately, rather than using several float variables, use
a vec4 instead. Use swizzling and writemasks to access the
components of the vec4 as floats.
</li>
<br>
<li>Use the built-in library functions whenever possible.
For example, instead of writing this:
<pre>
float x = 1.0 / sqrt(y);
</pre>
Write this:
<pre>
float x = inversesqrt(y);
</pre>
<li>
Use ++i when possible as it's more efficient than i++
</li>
</ul>
<a name="standalone">
<h2>Stand-alone GLSL Compiler</h2>
<p>
A unique stand-alone GLSL compiler driver has been added to Mesa.
<p>
<p>
The stand-alone compiler (like a conventional command-line compiler)
is a tool that accepts Shading Language programs and emits low-level
GPU programs.
</p>
<p>
This tool is useful for:
<p>
<ul>
<li>Inspecting GPU code to gain insight into compilation
<li>Generating initial GPU code for subsequent hand-tuning
<li>Debugging the GLSL compiler itself
</ul>
<p>
After building Mesa the glslcompiler should be found in the Mesa/bin/ directory.
If it's not there, it can be built manually:
</p>
<pre>
cd src/mesa/drivers/glslcompiler
make
</pre>
<p>
Here's an example of using the compiler to compile a vertex shader and
emit GL_ARB_vertex_program-style instructions:
</p>
<pre>
bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt
</pre>
<p>
results in:
</p>
<pre>
# Fragment Program/Shader
0: RCP TEMP[4].x, UNIFORM[2].xxxx;
1: RCP TEMP[4].y, UNIFORM[2].yyyy;
2: MUL TEMP[3].xy, VARYING[0], TEMP[4];
3: MOV TEMP[1], TEMP[3];
4: MUL TEMP[0].w, TEMP[1].yyyy, CONST[4].xxxx;
5: FRC TEMP[1].z, TEMP[0].wwww;
6: SGT.C TEMP[0].w, TEMP[1].zzzz, CONST[4].xxxx;
7: IF (NE.wwww); # (if false, goto 9);
8: ADD TEMP[1].x, TEMP[1].xxxx, CONST[4].xxxx;
9: ENDIF;
10: FRC TEMP[1].xy, TEMP[1];
11: SGT TEMP[2].xy, UNIFORM[3], TEMP[1];
12: MUL TEMP[1].z, TEMP[2].xxxx, TEMP[2].yyyy;
13: LRP TEMP[0], TEMP[1].zzzz, UNIFORM[0], UNIFORM[1];
14: MUL TEMP[0].xyz, TEMP[0], VARYING[1].xxxx;
15: MOV OUTPUT[0].xyz, TEMP[0];
16: MOV OUTPUT[0].w, CONST[4].yyyy;
17: END
</pre>
<p>
Note that some shading language constructs (such as uniform and varying
variables) aren't expressible in ARB or NV-style programs.
Therefore, the resulting output is not always legal by definition of
those program languages.
</p>
<p>
Also note that this compiler driver is still under development.
Over time, the correctness of the GPU programs, with respect to the ARB
and NV languagues, should improve.
</p>
<a name="implementation">
<h2>Compiler Implementation</h2>
<p>
The source code for Mesa's shading language compiler is in the
<code>src/mesa/shader/slang/</code> directory.
</p>
<p>
The compiler follows a fairly standard design and basically works as follows:
</p>
<ul>
<li>The input string is tokenized (see grammar.c) and parsed
(see slang_compiler_*.c) to produce an Abstract Syntax Tree (AST).
The nodes in this tree are slang_operation structures
(see slang_compile_operation.h).
The nodes are decorated with symbol table, scoping and datatype information.
<li>The AST is converted into an Intermediate representation (IR) tree
(see the slang_codegen.c file).
The IR nodes represent basic GPU instructions, like add, dot product,
move, etc.
The IR tree is mostly a binary tree, but a few nodes have three or four
children.
In principle, the IR tree could be executed by doing an in-order traversal.
<li>The IR tree is traversed in-order to emit code (see slang_emit.c).
This is also when registers are allocated to store variables and temps.
<li>In the future, a pattern-matching code generator-generator may be
used for code generation.
Programs such as L-BURG (Bottom-Up Rewrite Generator) and Twig look for
patterns in IR trees, compute weights for subtrees and use the weights
to select the best instructions to represent the sub-tree.
<li>The emitted GPU instructions (see prog_instruction.h) are stored in a
gl_program object (see mtypes.h).
<li>When a fragment shader and vertex shader are linked (see slang_link.c)
the varying vars are matched up, uniforms are merged, and vertex
attributes are resolved (rewriting instructions as needed).
</ul>
<p>
The final vertex and fragment programs may be interpreted in software
(see prog_execute.c) or translated into a specific hardware architecture
(see drivers/dri/i915/i915_fragprog.c for example).
</p>
<h3>Code Generation Options</h3>
<p>
Internally, there are several options that control the compiler's code
generation and instruction selection.
These options are seen in the gl_shader_state struct and may be set
by the device driver to indicate its preferences:
<pre>
struct gl_shader_state
{
...
/** Driver-selectable options: */
GLboolean EmitHighLevelInstructions;
GLboolean EmitCondCodes;
GLboolean EmitComments;
};
</pre>
<ul>
<li>EmitHighLevelInstructions
<br>
This option controls instruction selection for loops and conditionals.
If the option is set high-level IF/ELSE/ENDIF, LOOP/ENDLOOP, CONT/BRK
instructions will be emitted.
Otherwise, those constructs will be implemented with BRA instructions.
</li>
<li>EmitCondCodes
<br>
If set, condition codes (ala GL_NV_fragment_program) will be used for
branching and looping.
Otherwise, ordinary registers will be used (the IF instruction will
examine the first operand's X component and do the if-part if non-zero).
This option is only relevant if EmitHighLevelInstructions is set.
</li>
<li>EmitComments
<br>
If set, instructions will be annoted with comments to help with debugging.
Extra NOP instructions will also be inserted.
</br>
</ul>
<a name="validation">
<h2>Compiler Validation</h2>
<p>
A new <a href="http://glean.sf.net" target="_parent">Glean</a> test has
been create to exercise the GLSL compiler.
</p>
<p>
The <em>glsl1</em> test runs over 150 sub-tests to check that the language
features and built-in functions work properly.
This test should be run frequently while working on the compiler to catch
regressions.
</p>
<p>
The test coverage is reasonably broad and complete but additional tests
should be added.
</p>
</BODY>
</HTML>
|
