← Back to branch summary

~ubuntu-branches/ubuntu/quantal/mesa-glw/quantal

« back to all changes in this revision

Viewing changes to docs/shading.html

  • Committer: Bazaar Package Importer
  • Author(s): Morten Kjeldgaard
  • Date: 2008-05-06 16:19:15 UTC
  • Revision ID: james.westby@ubuntu.com-20080506161915-uynz7nftmfixu6bq
Tags: upstream-7.0.3
Import upstream version 7.0.3

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/shading.html
 
1
<HTML>
 
2
 
 
3
<TITLE>Shading Language Support</TITLE>
 
4
 
 
5
<link rel="stylesheet" type="text/css" href="mesa.css"></head>
 
6
 
 
7
<BODY>
 
8
 
 
9
<H1>Shading Language Support</H1>
 
10
 
 
11
<p>
 
12
This page describes the features and status of Mesa's support for the
 
13
<a href="http://opengl.org/documentation/glsl/" target="_parent">
 
14
OpenGL Shading Language</a>.
 
15
</p>
 
16
 
 
17
<p>
 
18
Last updated on 28 March 2007.
 
19
</p>
 
20
 
 
21
<p>
 
22
Contents
 
23
</p>
 
24
<ul>
 
25
<li><a href="#unsup">Unsupported Features</a>
 
26
<li><a href="#notes">Implementation Notes</a>
 
27
<li><a href="#hints">Programming Hints</a>
 
28
<li><a href="#standalone">Stand-alone Compiler</a>
 
29
<li><a href="#implementation">Compiler Implementation</a>
 
30
<li><a href="#validation">Compiler Validation</a>
 
31
</ul>
 
32
 
 
33
 
 
34
<a name="unsup">
 
35
<h2>Unsupported Features</h2>
 
36
 
 
37
<p>
 
38
The following features of the shading language are not yet supported
 
39
in Mesa:
 
40
</p>
 
41
 
 
42
<ul>
 
43
<li>Dereferencing arrays with non-constant indexes
 
44
<li>Comparison of user-defined structs
 
45
<li>Linking of multiple shaders is not supported
 
46
<li>gl_ClipVertex
 
47
<li>The derivative functions such as dFdx() are not implemented
 
48
<li>The inverse trig functions asin(), acos(), and atan() are not implemented
 
49
<li>The gl_Color and gl_SecondaryColor varying vars are interpolated
 
50
    without perspective correction
 
51
<li>Floating point literal suffixes 'f' and 'F' aren't allowed.
 
52
</ul>
 
53
 
 
54
<p>
 
55
All other major features of the shading language should function.
 
56
</p>
 
57
 
 
58
 
 
59
<a name="notes">
 
60
<h2>Implementation Notes</h2>
 
61
 
 
62
<ul>
 
63
<li>Shading language programs are compiled into low-level programs
 
64
    very similar to those of GL_ARB_vertex/fragment_program.
 
65
<li>All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
 
66
    float[4] registers.
 
67
<li>Float constants and variables are packed so that up to four floats
 
68
    can occupy one program parameter/register.
 
69
<li>All function calls are inlined.
 
70
<li>Shaders which use too many registers will not compile.
 
71
<li>The quality of generated code is pretty good, register usage is fair.
 
72
<li>Shader error detection and reporting of errors (InfoLog) is not
 
73
    very good yet.
 
74
<li>The ftransform() function doesn't necessarily match the results of
 
75
    fixed-function transformation.
 
76
</ul>
 
77
 
 
78
<p>
 
79
These issues will be addressed/resolved in the future.
 
80
</p>
 
81
 
 
82
 
 
83
<a name="hints">
 
84
<h2>Programming Hints</h2>
 
85
 
 
86
<ul>
 
87
<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
 
88
    This improves the efficiency of function inlining.
 
89
</li>
 
90
<br>
 
91
<li>To reduce register usage, declare variables within smaller scopes.
 
92
    For example, the following code:
 
93
<pre>
 
94
    void main()
 
95
    {
 
96
       vec4 a1, a2, b1, b2;
 
97
       gl_Position = expression using a1, a2.
 
98
       gl_Color = expression using b1, b2;
 
99
    }
 
100
</pre>
 
101
    Can be rewritten as follows to use half as many registers:
 
102
<pre>
 
103
    void main()
 
104
    {
 
105
       {
 
106
          vec4 a1, a2;
 
107
          gl_Position = expression using a1, a2.
 
108
       }
 
109
       {
 
110
          vec4 b1, b2;
 
111
          gl_Color = expression using b1, b2;
 
112
       }
 
113
    }
 
114
</pre>
 
115
    Alternately, rather than using several float variables, use
 
116
    a vec4 instead.  Use swizzling and writemasks to access the
 
117
    components of the vec4 as floats.
 
118
</li>
 
119
<br>
 
120
<li>Use the built-in library functions whenever possible.
 
121
    For example, instead of writing this:
 
122
<pre>
 
123
        float x = 1.0 / sqrt(y);
 
124
</pre>
 
125
    Write this:
 
126
<pre>
 
127
        float x = inversesqrt(y);
 
128
</pre>
 
129
<li>
 
130
   Use ++i when possible as it's more efficient than i++
 
131
</li>
 
132
</ul>
 
133
 
 
134
 
 
135
<a name="standalone">
 
136
<h2>Stand-alone Compiler</h2>
 
137
 
 
138
<p>
 
139
A unique stand-alone GLSL compiler driver has been added to Mesa.
 
140
<p>
 
141
 
 
142
<p>
 
143
The stand-alone compiler (like a conventional command-line compiler)
 
144
is a tool that accepts Shading Language programs and emits low-level
 
145
GPU programs.
 
146
</p>
 
147
 
 
148
<p>
 
149
This tool is useful for:
 
150
<p>
 
151
<ul>
 
152
<li>Inspecting GPU code to gain insight into compilation
 
153
<li>Generating initial GPU code for subsequent hand-tuning
 
154
<li>Debugging the GLSL compiler itself
 
155
</ul>
 
156
 
 
157
<p>
 
158
To build the glslcompiler program (this will be improved someday):
 
159
</p>
 
160
<pre>
 
161
    cd src/mesa
 
162
    make libmesa.a
 
163
    cd drivers/glslcompiler
 
164
    make
 
165
</pre>
 
166
 
 
167
 
 
168
<p>
 
169
Here's an example of using the compiler to compile a vertex shader and
 
170
emit GL_ARB_vertex_program-style instructions:
 
171
</p>
 
172
<pre>
 
173
    glslcompiler --arb --linenumbers --vs vertshader.txt
 
174
</pre>
 
175
<p>
 
176
The output may look similar to this:
 
177
</p>
 
178
<pre>
 
179
!!ARBvp1.0
 
180
  0: MOV result.texcoord[0], vertex.texcoord[0];
 
181
  1: DP4 temp0.x, state.matrix.mvp.row[0], vertex.position;
 
182
  2: DP4 temp0.y, state.matrix.mvp.row[1], vertex.position;
 
183
  3: DP4 temp0.z, state.matrix.mvp.row[2], vertex.position;
 
184
  4: DP4 temp0.w, state.matrix.mvp.row[3], vertex.position;
 
185
  5: MOV result.position, temp0;
 
186
  6: END
 
187
</pre>
 
188
 
 
189
<p>
 
190
Note that some shading language constructs (such as uniform and varying
 
191
variables) aren't expressible in ARB or NV-style programs.
 
192
Therefore, the resulting output is not always legal by definition of
 
193
those program languages.
 
194
</p>
 
195
<p>
 
196
Also note that this compiler driver is still under development.
 
197
Over time, the correctness of the GPU programs, with respect to the ARB
 
198
and NV languagues, should improve.
 
199
</p>
 
200
 
 
201
 
 
202
 
 
203
<a name="implementation">
 
204
<h2>Compiler Implementation</h2>
 
205
 
 
206
<p>
 
207
The source code for Mesa's shading language compiler is in the
 
208
<code>src/mesa/shader/slang/</code> directory.
 
209
</p>
 
210
 
 
211
<p>
 
212
The compiler follows a fairly standard design and basically works as follows:
 
213
</p>
 
214
<ul>
 
215
<li>The input string is tokenized (see grammar.c) and parsed
 
216
(see slang_compiler_*.c) to produce an Abstract Syntax Tree (AST).
 
217
The nodes in this tree are slang_operation structures
 
218
(see slang_compile_operation.h).
 
219
The nodes are decorated with symbol table, scoping and datatype information.
 
220
<li>The AST is converted into an Intermediate representation (IR) tree
 
221
(see the slang_codegen.c file).
 
222
The IR nodes represent basic GPU instructions, like add, dot product,
 
223
move, etc. 
 
224
The IR tree is mostly a binary tree, but a few nodes have three or four
 
225
children.
 
226
In principle, the IR tree could be executed by doing an in-order traversal.
 
227
<li>The IR tree is traversed in-order to emit code (see slang_emit.c).
 
228
This is also when registers are allocated to store variables and temps.
 
229
<li>In the future, a pattern-matching code generator-generator may be
 
230
used for code generation.
 
231
Programs such as L-BURG (Bottom-Up Rewrite Generator) and Twig look for
 
232
patterns in IR trees, compute weights for subtrees and use the weights
 
233
to select the best instructions to represent the sub-tree.
 
234
<li>The emitted GPU instructions (see prog_instruction.h) are stored in a
 
235
gl_program object (see mtypes.h).
 
236
<li>When a fragment shader and vertex shader are linked (see slang_link.c)
 
237
the varying vars are matched up, uniforms are merged, and vertex
 
238
attributes are resolved (rewriting instructions as needed).
 
239
</ul>
 
240
 
 
241
<p>
 
242
The final vertex and fragment programs may be interpreted in software
 
243
(see prog_execute.c) or translated into a specific hardware architecture
 
244
(see drivers/dri/i915/i915_fragprog.c for example).
 
245
</p>
 
246
 
 
247
<h3>Code Generation Options</h3>
 
248
 
 
249
<p>
 
250
Internally, there are several options that control the compiler's code
 
251
generation and instruction selection.
 
252
These options are seen in the gl_shader_state struct and may be set
 
253
by the device driver to indicate its preferences:
 
254
 
 
255
<pre>
 
256
struct gl_shader_state
 
257
{
 
258
   ...
 
259
   /** Driver-selectable options: */
 
260
   GLboolean EmitHighLevelInstructions;
 
261
   GLboolean EmitCondCodes;
 
262
   GLboolean EmitComments;
 
263
};
 
264
</pre>
 
265
 
 
266
<ul>
 
267
<li>EmitHighLevelInstructions
 
268
<br>
 
269
This option controls instruction selection for loops and conditionals.
 
270
If the option is set high-level IF/ELSE/ENDIF, LOOP/ENDLOOP, CONT/BRK
 
271
instructions will be emitted.
 
272
Otherwise, those constructs will be implemented with BRA instructions.
 
273
</li>
 
274
 
 
275
<li>EmitCondCodes
 
276
<br>
 
277
If set, condition codes (ala GL_NV_fragment_program) will be used for
 
278
branching and looping.
 
279
Otherwise, ordinary registers will be used (the IF instruction will
 
280
examine the first operand's X component and do the if-part if non-zero).
 
281
This option is only relevant if EmitHighLevelInstructions is set.
 
282
</li>
 
283
 
 
284
<li>EmitComments
 
285
<br>
 
286
If set, instructions will be annoted with comments to help with debugging.
 
287
Extra NOP instructions will also be inserted.
 
288
</br>
 
289
 
 
290
</ul>
 
291
 
 
292
 
 
293
<a name="validation">
 
294
<h2>Compiler Validation</h2>
 
295
 
 
296
<p>
 
297
A new <a href="http://glean.sf.net" target="_parent">Glean</a> test has
 
298
been create to exercise the GLSL compiler.
 
299
</p>
 
300
<p>
 
301
The <em>glsl1</em> test runs over 150 sub-tests to check that the language
 
302
features and built-in functions work properly.
 
303
This test should be run frequently while working on the compiler to catch
 
304
regressions.
 
305
</p>
 
306
<p>
 
307
The test coverage is reasonably broad and complete but additional tests
 
308
should be added.
 
309
</p>
 
310
 
 
311
 
 
312
</BODY>
 
313
</HTML>