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>