39
39
execution. These are generally used for debugging.
42
<li>dump - print GLSL shader code to stdout at link time
43
<li>log - log all GLSL shaders to files.
42
<li><b>dump</b> - print GLSL shader code to stdout at link time
43
<li><b>log</b> - log all GLSL shaders to files.
44
44
The filenames will be "shader_X.vert" or "shader_X.frag" where X
46
<li>nopt - disable compiler optimizations
47
<li>opt - force compiler optimizations
48
<li>uniform - print message to stdout when glUniform is called
49
<li>nopvert - force vertex shaders to be a simple shader that just transforms
46
<li><b>nopt</b> - disable compiler optimizations
47
<li><b>opt</b> - force compiler optimizations
48
<li><b>uniform</b> - print message to stdout when glUniform is called
49
<li><b>nopvert</b> - force vertex shaders to be a simple shader that just transforms
50
50
the vertex position with ftransform() and passes through the color and
51
51
texcoord[0] attributes.
52
<li>nopfrag - force fragment shader to be a simple shader that passes
52
<li><b>nopfrag</b> - force fragment shader to be a simple shader that passes
53
53
through the color attribute.
54
<li>useprog - log glUseProgram calls to stderr
54
<li><b>useprog</b> - log glUseProgram calls to stderr
57
57
Example: export MESA_GLSL=dump,nopt
62
<h2>GLSL 1.20 support</h2>
65
GLSL version 1.20 is supported in Mesa 7.3 and later.
66
Among the features/differences of GLSL 1.20 are:
65
The GLSL compiler currently supports version 1.20 of the shading language.
69
Several GLSL extensions are also supported:
68
<li><code>mat2x3, mat2x4</code>, etc. types and functions
69
<li><code>transpose(), outerProduct(), matrixCompMult()</code> functions
71
<li>precision qualifiers (lowp, mediump, highp)
72
<li><code>invariant</code> qualifier
73
<li><code>array.length()</code> method
74
<li><code>float[5] a;</code> array syntax
75
<li><code>centroid</code> qualifier
76
<li>unsized array constructors
77
<li>initializers for uniforms
78
<li>const initializers calling built-in functions
72
<li>GL_ARB_draw_buffers
73
<li>GL_ARB_texture_rectangle
74
<li>GL_ARB_fragment_coord_conventions
75
<li>GL_EXT_texture_array
84
80
<h2>Unsupported Features</h2>
82
<p>XXX update this section</p>
87
85
The following features of the shading language are not yet fully supported
130
128
<h2>Programming Hints</h2>
133
<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
134
This improves the efficiency of function inlining.
137
<li>To reduce register usage, declare variables within smaller scopes.
138
For example, the following code:
143
gl_Position = expression using a1, a2.
144
gl_Color = expression using b1, b2;
147
Can be rewritten as follows to use half as many registers:
153
gl_Position = expression using a1, a2.
157
gl_Color = expression using b1, b2;
161
Alternately, rather than using several float variables, use
162
a vec4 instead. Use swizzling and writemasks to access the
163
components of the vec4 as floats.
166
131
<li>Use the built-in library functions whenever possible.
167
132
For example, instead of writing this:
204
After building Mesa, the glslcompiler can be built by manually running:
162
After building Mesa, the compiler can be found at src/glsl/glsl_compiler
209
cd src/mesa/drivers/glslcompiler
215
166
Here's an example of using the compiler to compile a vertex shader and
216
167
emit GL_ARB_vertex_program-style instructions:
219
bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt
225
# Fragment Program/Shader
226
0: RCP TEMP[4].x, UNIFORM[2].xxxx;
227
1: RCP TEMP[4].y, UNIFORM[2].yyyy;
228
2: MUL TEMP[3].xy, VARYING[0], TEMP[4];
229
3: MOV TEMP[1], TEMP[3];
230
4: MUL TEMP[0].w, TEMP[1].yyyy, CONST[4].xxxx;
231
5: FRC TEMP[1].z, TEMP[0].wwww;
232
6: SGT.C TEMP[0].w, TEMP[1].zzzz, CONST[4].xxxx;
233
7: IF (NE.wwww); # (if false, goto 9);
234
8: ADD TEMP[1].x, TEMP[1].xxxx, CONST[4].xxxx;
236
10: FRC TEMP[1].xy, TEMP[1];
237
11: SGT TEMP[2].xy, UNIFORM[3], TEMP[1];
238
12: MUL TEMP[1].z, TEMP[2].xxxx, TEMP[2].yyyy;
239
13: LRP TEMP[0], TEMP[1].zzzz, UNIFORM[0], UNIFORM[1];
240
14: MUL TEMP[0].xyz, TEMP[0], VARYING[1].xxxx;
241
15: MOV OUTPUT[0].xyz, TEMP[0];
242
16: MOV OUTPUT[0].w, CONST[4].yyyy;
247
Note that some shading language constructs (such as uniform and varying
248
variables) aren't expressible in ARB or NV-style programs.
249
Therefore, the resulting output is not always legal by definition of
250
those program languages.
253
Also note that this compiler driver is still under development.
254
Over time, the correctness of the GPU programs, with respect to the ARB
255
and NV languagues, should improve.
170
src/glsl/glslcompiler --dump-ast myshader.vert
175
<li><b>--dump-ast</b> - dump GPU code
176
<li><b>--dump-hir</b> - dump high-level IR code
177
<li><b>--dump-lir</b> - dump low-level IR code
178
<li><b>--link</b> - ???
264
188
The source code for Mesa's shading language compiler is in the
265
<code>src/mesa/shader/slang/</code> directory.
189
<code>src/glsl/</code> directory.
269
The compiler follows a fairly standard design and basically works as follows:
193
XXX provide some info about the compiler....
272
<li>The input string is tokenized (see grammar.c) and parsed
273
(see slang_compiler_*.c) to produce an Abstract Syntax Tree (AST).
274
The nodes in this tree are slang_operation structures
275
(see slang_compile_operation.h).
276
The nodes are decorated with symbol table, scoping and datatype information.
277
<li>The AST is converted into an Intermediate representation (IR) tree
278
(see the slang_codegen.c file).
279
The IR nodes represent basic GPU instructions, like add, dot product,
281
The IR tree is mostly a binary tree, but a few nodes have three or four
283
In principle, the IR tree could be executed by doing an in-order traversal.
284
<li>The IR tree is traversed in-order to emit code (see slang_emit.c).
285
This is also when registers are allocated to store variables and temps.
286
<li>In the future, a pattern-matching code generator-generator may be
287
used for code generation.
288
Programs such as L-BURG (Bottom-Up Rewrite Generator) and Twig look for
289
patterns in IR trees, compute weights for subtrees and use the weights
290
to select the best instructions to represent the sub-tree.
291
<li>The emitted GPU instructions (see prog_instruction.h) are stored in a
292
gl_program object (see mtypes.h).
293
<li>When a fragment shader and vertex shader are linked (see slang_link.c)
294
the varying vars are matched up, uniforms are merged, and vertex
295
attributes are resolved (rewriting instructions as needed).
299
197
The final vertex and fragment programs may be interpreted in software
351
249
<h2>Compiler Validation</h2>
354
A <a href="http://glean.sf.net" target="_parent">Glean</a> test has
355
been create to exercise the GLSL compiler.
358
The <em>glsl1</em> test runs over 170 sub-tests to check that the language
359
features and built-in functions work properly.
360
This test should be run frequently while working on the compiler to catch
252
Developers working on the GLSL compiler should test frequently to avoid
364
The test coverage is reasonably broad and complete but additional tests
257
The <a href="http://people.freedesktop.org/~nh/piglit/">Piglit</a> project
258
has many GLSL tests and the
259
<a href="http://glean.sf.net" target="_parent">Glean</a> glsl1 test
264
The Mesa demos repository also has some good GLSL tests.