shading.html 10 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
<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>
Brian Paul's avatar
Brian Paul committed
18
Last updated on 15 December 2008.
19 20
</p>

Brian's avatar
Brian committed
21 22 23 24
<p>
Contents
</p>
<ul>
25
<li><a href="#envvars">Environment variables</a>
Brian Paul's avatar
Brian Paul committed
26
<li><a href="#120">GLSL 1.20 support</a>
Brian's avatar
Brian committed
27
<li><a href="#unsup">Unsupported Features</a>
Brian's avatar
Brian committed
28
<li><a href="#notes">Implementation Notes</a>
Brian's avatar
Brian committed
29
<li><a href="#hints">Programming Hints</a>
30
<li><a href="#standalone">Stand-alone GLSL Compiler</a>
Brian's avatar
Brian committed
31
<li><a href="#implementation">Compiler Implementation</a>
Brian's avatar
Brian committed
32
<li><a href="#validation">Compiler Validation</a>
Brian's avatar
Brian committed
33 34 35
</ul>


Brian Paul's avatar
Brian Paul committed
36

37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
<a name="envvars">
<h2>Environment Variables</h2>

<p>
The <b>MESA_GLSL</b> environment variable can be set to a comma-separated
list of keywords to control some aspects of the GLSL compiler:
</p>
<ul>
<li>dump - print GLSL shader code to stdout at link time
<li>log - log all GLSL shaders to files.
    The filenames will be "shader_X.vert" or "shader_X.frag" where X
    the shader ID.
<li>nopt - disable compiler optimizations
<li>opt - force compiler optimizations
<li>uniform - print message to stdout when glUniform is called
</ul>
<p>
Example:  export MESA_GLSL=dump,nopt
</p>


Brian Paul's avatar
Brian Paul committed
58 59 60 61
<a name="120">
<h2>GLSL 1.20 support</h2>

<p>
62
GLSL version 1.20 is supported in Mesa 7.3 and later.
Brian Paul's avatar
Brian Paul committed
63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
Among the features/differences of GLSL 1.20 are:
<ul>
<li><code>mat2x3, mat2x4</code>, etc. types and functions
<li><code>transpose(), outerProduct(), matrixCompMult()</code> functions
(but untested)
<li>precision qualifiers (lowp, mediump, highp)
<li><code>invariant</code> qualifier
<li><code>array.length()</code> method
<li><code>float[5] a;</code> array syntax
<li><code>centroid</code> qualifier
<li>unsized array constructors
<li>initializers for uniforms
<li>const initializers calling built-in functions
</ul>



Brian's avatar
Brian committed
80
<a name="unsup">
81 82 83
<h2>Unsupported Features</h2>

<p>
84
The following features of the shading language are not yet fully supported
85 86 87 88
in Mesa:
</p>

<ul>
89 90 91
<li>Linking of multiple shaders does not always work.  Currently, linking
    is implemented through shader concatenation and re-compiling.  This
    doesn't always work because of some #pragma and preprocessor issues.
Brian's avatar
Brian committed
92
<li>gl_ClipVertex
Brian's avatar
Brian committed
93 94
<li>The gl_Color and gl_SecondaryColor varying vars are interpolated
    without perspective correction
95 96 97 98 99 100 101
</ul>

<p>
All other major features of the shading language should function.
</p>


Brian's avatar
Brian committed
102
<a name="notes">
103 104 105 106 107
<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.
Brian's avatar
Brian committed
108
<li>All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
109
    float[4] registers.
Brian's avatar
Brian committed
110 111
<li>Float constants and variables are packed so that up to four floats
    can occupy one program parameter/register.
112 113 114 115 116
<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.
Brian's avatar
Brian committed
117 118
<li>The ftransform() function doesn't necessarily match the results of
    fixed-function transformation.
119 120 121 122 123 124 125
</ul>

<p>
These issues will be addressed/resolved in the future.
</p>


Brian's avatar
Brian committed
126
<a name="hints">
127 128 129
<h2>Programming Hints</h2>

<ul>
Brian's avatar
Brian committed
130
<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
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
    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>
Brian's avatar
Brian committed
172 173 174
<li>
   Use ++i when possible as it's more efficient than i++
</li>
175 176 177
</ul>


Brian's avatar
Brian committed
178
<a name="standalone">
179
<h2>Stand-alone GLSL Compiler</h2>
Brian's avatar
Brian committed
180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200

<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>
201
After building Mesa, the glslcompiler can be built by manually running:
Brian's avatar
Brian committed
202
</p>
Brian's avatar
Brian committed
203
<pre>
204 205
    make realclean
    make linux
206
    cd src/mesa/drivers/glslcompiler
Brian's avatar
Brian committed
207 208 209
    make
</pre>

Brian's avatar
Brian committed
210 211 212 213 214 215

<p>
Here's an example of using the compiler to compile a vertex shader and
emit GL_ARB_vertex_program-style instructions:
</p>
<pre>
216
    bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt
Brian's avatar
Brian committed
217 218
</pre>
<p>
219
results in:
Brian's avatar
Brian committed
220 221
</p>
<pre>
222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240
# 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
Brian's avatar
Brian committed
241 242 243 244 245 246 247 248 249 250 251 252 253 254
</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>

Brian's avatar
Brian committed
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


<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>

Brian's avatar
Brian committed
301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344
<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>
Brian's avatar
Brian committed
345 346


Brian's avatar
Brian committed
347 348 349 350
<a name="validation">
<h2>Compiler Validation</h2>

<p>
Brian Paul's avatar
Brian Paul committed
351
A <a href="http://glean.sf.net" target="_parent">Glean</a> test has
Brian's avatar
Brian committed
352 353 354
been create to exercise the GLSL compiler.
</p>
<p>
Brian Paul's avatar
Brian Paul committed
355
The <em>glsl1</em> test runs over 170 sub-tests to check that the language
Brian's avatar
Brian committed
356 357 358 359 360 361 362 363 364 365
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>


366 367
</BODY>
</HTML>