shading.html 8.33 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's avatar
Brian committed
18
Last updated on 28 March 2007.
19 20
</p>

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


<a name="unsup">
35 36 37 38 39 40 41 42
<h2>Unsupported Features</h2>

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

<ul>
43
<li>Dereferencing arrays with non-constant indexes
Brian's avatar
Brian committed
44
<li>Comparison of user-defined structs
45
<li>Linking of multiple shaders is not supported
Brian's avatar
Brian committed
46
<li>gl_ClipVertex
Brian's avatar
Brian committed
47
<li>The derivative functions such as dFdx() are not implemented
Brian's avatar
Brian committed
48
<li>The inverse trig functions asin(), acos(), and atan() are not implemented
49 50 51 52 53 54 55
</ul>

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


Brian's avatar
Brian committed
56
<a name="notes">
57 58 59 60 61
<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
62
<li>All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
63
    float[4] registers.
Brian's avatar
Brian committed
64 65
<li>Float constants and variables are packed so that up to four floats
    can occupy one program parameter/register.
66 67 68 69 70
<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
71 72
<li>The ftransform() function doesn't necessarily match the results of
    fixed-function transformation.
73 74 75 76 77 78 79
</ul>

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


Brian's avatar
Brian committed
80
<a name="hints">
81 82 83
<h2>Programming Hints</h2>

<ul>
Brian's avatar
Brian committed
84
<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
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
    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
126 127 128
<li>
   Use ++i when possible as it's more efficient than i++
</li>
129 130 131
</ul>


Brian's avatar
Brian committed
132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154
<a name="standalone">
<h2>Stand-alone 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>
Brian's avatar
Brian committed
155
To build the glslcompiler program (this will be improved someday):
Brian's avatar
Brian committed
156
</p>
Brian's avatar
Brian committed
157 158 159 160 161 162 163
<pre>
    cd src/mesa
    make libmesa.a
    cd drivers/glslcompiler
    make
</pre>

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

<p>
Here's an example of using the compiler to compile a vertex shader and
emit GL_ARB_vertex_program-style instructions:
</p>
<pre>
    glslcompiler --arb --linenumbers --vs vertshader.txt
</pre>
<p>
The output may look similar to this:
</p>
<pre>
!!ARBvp1.0
  0: MOV result.texcoord[0], vertex.texcoord[0];
  1: DP4 temp0.x, state.matrix.mvp.row[0], vertex.position;
  2: DP4 temp0.y, state.matrix.mvp.row[1], vertex.position;
  3: DP4 temp0.z, state.matrix.mvp.row[2], vertex.position;
  4: DP4 temp0.w, state.matrix.mvp.row[3], vertex.position;
  5: MOV result.position, temp0;
  6: 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>

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


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


Brian's avatar
Brian committed
290 291 292 293 294 295 296 297
<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>
298
The <em>glsl1</em> test runs over 150 sub-tests to check that the language
Brian's avatar
Brian committed
299 300 301 302 303 304 305 306 307 308
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>


309 310
</BODY>
</HTML>