shading.html 8.49 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
Brian's avatar
Brian committed
49 50
<li>The gl_Color and gl_SecondaryColor varying vars are interpolated
    without perspective correction
Brian's avatar
Brian committed
51
<li>Floating point literal suffixes 'f' and 'F' aren't allowed.
52 53 54 55 56 57 58
</ul>

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


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

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


Brian's avatar
Brian committed
83
<a name="hints">
84 85 86
<h2>Programming Hints</h2>

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


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

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

<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
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 244 245 246


<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
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 288 289 290
<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
291 292


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


312 313
</BODY>
</HTML>