shading.html 9.19 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>
Brian Paul's avatar
Brian Paul committed
25
<li><a href="#120">GLSL 1.20 support</a>
Brian's avatar
Brian committed
26
<li><a href="#unsup">Unsupported Features</a>
Brian's avatar
Brian committed
27
<li><a href="#notes">Implementation Notes</a>
Brian's avatar
Brian committed
28
<li><a href="#hints">Programming Hints</a>
29
<li><a href="#standalone">Stand-alone GLSL Compiler</a>
Brian's avatar
Brian committed
30
<li><a href="#implementation">Compiler Implementation</a>
Brian's avatar
Brian committed
31
<li><a href="#validation">Compiler Validation</a>
Brian's avatar
Brian committed
32 33 34
</ul>


Brian Paul's avatar
Brian Paul committed
35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

<a name="120">
<h2>GLSL 1.20 support</h2>

<p>
GLSL version 1.20 is supported in Mesa 7.3.
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
58
<a name="unsup">
59 60 61 62 63 64 65 66 67
<h2>Unsupported Features</h2>

<p>
The following features of the shading language are not yet supported
in Mesa:
</p>

<ul>
<li>Linking of multiple shaders is not supported
Brian's avatar
Brian committed
68
<li>gl_ClipVertex
Brian's avatar
Brian committed
69 70
<li>The gl_Color and gl_SecondaryColor varying vars are interpolated
    without perspective correction
71 72 73 74 75 76 77
</ul>

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


Brian's avatar
Brian committed
78
<a name="notes">
79 80 81 82 83
<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
84
<li>All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
85
    float[4] registers.
Brian's avatar
Brian committed
86 87
<li>Float constants and variables are packed so that up to four floats
    can occupy one program parameter/register.
88 89 90 91 92
<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
93 94
<li>The ftransform() function doesn't necessarily match the results of
    fixed-function transformation.
95 96 97 98 99 100 101
</ul>

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


Brian's avatar
Brian committed
102
<a name="hints">
103 104 105
<h2>Programming Hints</h2>

<ul>
Brian's avatar
Brian committed
106
<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
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
    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
148 149 150
<li>
   Use ++i when possible as it's more efficient than i++
</li>
151 152 153
</ul>


Brian's avatar
Brian committed
154
<a name="standalone">
155
<h2>Stand-alone GLSL Compiler</h2>
Brian's avatar
Brian committed
156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176

<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>
177
After building Mesa, the glslcompiler can be built by manually running:
Brian's avatar
Brian committed
178
</p>
Brian's avatar
Brian committed
179
<pre>
180
    cd src/mesa/drivers/glslcompiler
Brian's avatar
Brian committed
181 182 183
    make
</pre>

Brian's avatar
Brian committed
184 185 186 187 188 189

<p>
Here's an example of using the compiler to compile a vertex shader and
emit GL_ARB_vertex_program-style instructions:
</p>
<pre>
190
    bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt
Brian's avatar
Brian committed
191 192
</pre>
<p>
193
results in:
Brian's avatar
Brian committed
194 195
</p>
<pre>
196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214
# 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
215 216 217 218 219 220 221 222 223 224 225 226 227 228
</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
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


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


Brian's avatar
Brian committed
321 322 323 324
<a name="validation">
<h2>Compiler Validation</h2>

<p>
Brian Paul's avatar
Brian Paul committed
325
A <a href="http://glean.sf.net" target="_parent">Glean</a> test has
Brian's avatar
Brian committed
326 327 328
been create to exercise the GLSL compiler.
</p>
<p>
Brian Paul's avatar
Brian Paul committed
329
The <em>glsl1</em> test runs over 170 sub-tests to check that the language
Brian's avatar
Brian committed
330 331 332 333 334 335 336 337 338 339
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>


340 341
</BODY>
</HTML>