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 15 December 2008.
  19 </p>
  20
  21 <p>
  22 Contents
  23 </p>
  24 <ul>
  25 <li><a href="#envvars">Environment variables</a>
  26 <li><a href="#120">GLSL 1.20 support</a>
  27 <li><a href="#unsup">Unsupported Features</a>
  28 <li><a href="#notes">Implementation Notes</a>
  29 <li><a href="#hints">Programming Hints</a>
  30 <li><a href="#standalone">Stand-alone GLSL Compiler</a>
  31 <li><a href="#implementation">Compiler Implementation</a>
  32 <li><a href="#validation">Compiler Validation</a>
  33 </ul>
  34
  35
  36
  37 <a name="envvars">
  38 <h2>Environment Variables</h2>
  39
  40 <p>
  41 The <b>MESA_GLSL</b> environment variable can be set to a comma-separated
  42 list of keywords to control some aspects of the GLSL compiler and shader
  43 execution.  These are generally used for debugging.
  44 </p>
  45 <ul>
  46 <li>dump - print GLSL shader code to stdout at link time
  47 <li>log - log all GLSL shaders to files.
  48     The filenames will be "shader_X.vert" or "shader_X.frag" where X
  49     the shader ID.
  50 <li>nopt - disable compiler optimizations
  51 <li>opt - force compiler optimizations
  52 <li>uniform - print message to stdout when glUniform is called
  53 <li>nopvert - force vertex shaders to be a simple shader that just transforms
  54     the vertex position with ftransform() and passes through the color and
  55     texcoord[0] attributes.
  56 <li>nopfrag - force fragment shader to be a simple shader that passes
  57     through the color attribute.
  58 </ul>
  59 <p>
  60 Example:  export MESA_GLSL=dump,nopt
  61 </p>
  62
  63
  64 <a name="120">
  65 <h2>GLSL 1.20 support</h2>
  66
  67 <p>
  68 GLSL version 1.20 is supported in Mesa 7.3 and later.
  69 Among the features/differences of GLSL 1.20 are:
  70 <ul>
  71 <li><code>mat2x3, mat2x4</code>, etc. types and functions
  72 <li><code>transpose(), outerProduct(), matrixCompMult()</code> functions
  73 (but untested)
  74 <li>precision qualifiers (lowp, mediump, highp)
  75 <li><code>invariant</code> qualifier
  76 <li><code>array.length()</code> method
  77 <li><code>float[5] a;</code> array syntax
  78 <li><code>centroid</code> qualifier
  79 <li>unsized array constructors
  80 <li>initializers for uniforms
  81 <li>const initializers calling built-in functions
  82 </ul>
  83
  84
  85
  86 <a name="unsup">
  87 <h2>Unsupported Features</h2>
  88
  89 <p>
  90 The following features of the shading language are not yet fully supported
  91 in Mesa:
  92 </p>
  93
  94 <ul>
  95 <li>Linking of multiple shaders does not always work.  Currently, linking
  96     is implemented through shader concatenation and re-compiling.  This
  97     doesn't always work because of some #pragma and preprocessor issues.
  98 <li>gl_ClipVertex
  99 <li>The gl_Color and gl_SecondaryColor varying vars are interpolated
 100     without perspective correction
 101 </ul>
 102
 103 <p>
 104 All other major features of the shading language should function.
 105 </p>
 106
 107
 108 <a name="notes">
 109 <h2>Implementation Notes</h2>
 110
 111 <ul>
 112 <li>Shading language programs are compiled into low-level programs
 113     very similar to those of GL_ARB_vertex/fragment_program.
 114 <li>All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
 115     float[4] registers.
 116 <li>Float constants and variables are packed so that up to four floats
 117     can occupy one program parameter/register.
 118 <li>All function calls are inlined.
 119 <li>Shaders which use too many registers will not compile.
 120 <li>The quality of generated code is pretty good, register usage is fair.
 121 <li>Shader error detection and reporting of errors (InfoLog) is not
 122     very good yet.
 123 <li>The ftransform() function doesn't necessarily match the results of
 124     fixed-function transformation.
 125 </ul>
 126
 127 <p>
 128 These issues will be addressed/resolved in the future.
 129 </p>
 130
 131
 132 <a name="hints">
 133 <h2>Programming Hints</h2>
 134
 135 <ul>
 136 <li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
 137     This improves the efficiency of function inlining.
 138 </li>
 139 <br>
 140 <li>To reduce register usage, declare variables within smaller scopes.
 141     For example, the following code:
 142 <pre>
 143     void main()
 144     {
 145        vec4 a1, a2, b1, b2;
 146        gl_Position = expression using a1, a2.
 147        gl_Color = expression using b1, b2;
 148     }
 149 </pre>
 150     Can be rewritten as follows to use half as many registers:
 151 <pre>
 152     void main()
 153     {
 154        {
 155           vec4 a1, a2;
 156           gl_Position = expression using a1, a2.
 157        }
 158        {
 159           vec4 b1, b2;
 160           gl_Color = expression using b1, b2;
 161        }
 162     }
 163 </pre>
 164     Alternately, rather than using several float variables, use
 165     a vec4 instead.  Use swizzling and writemasks to access the
 166     components of the vec4 as floats.
 167 </li>
 168 <br>
 169 <li>Use the built-in library functions whenever possible.
 170     For example, instead of writing this:
 171 <pre>
 172         float x = 1.0 / sqrt(y);
 173 </pre>
 174     Write this:
 175 <pre>
 176         float x = inversesqrt(y);
 177 </pre>
 178 <li>
 179    Use ++i when possible as it's more efficient than i++
 180 </li>
 181 </ul>
 182
 183
 184 <a name="standalone">
 185 <h2>Stand-alone GLSL Compiler</h2>
 186
 187 <p>
 188 A unique stand-alone GLSL compiler driver has been added to Mesa.
 189 <p>
 190
 191 <p>
 192 The stand-alone compiler (like a conventional command-line compiler)
 193 is a tool that accepts Shading Language programs and emits low-level
 194 GPU programs.
 195 </p>
 196
 197 <p>
 198 This tool is useful for:
 199 <p>
 200 <ul>
 201 <li>Inspecting GPU code to gain insight into compilation
 202 <li>Generating initial GPU code for subsequent hand-tuning
 203 <li>Debugging the GLSL compiler itself
 204 </ul>
 205
 206 <p>
 207 After building Mesa, the glslcompiler can be built by manually running:
 208 </p>
 209 <pre>
 210     make realclean
 211     make linux
 212     cd src/mesa/drivers/glslcompiler
 213     make
 214 </pre>
 215
 216
 217 <p>
 218 Here's an example of using the compiler to compile a vertex shader and
 219 emit GL_ARB_vertex_program-style instructions:
 220 </p>
 221 <pre>
 222     bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt
 223 </pre>
 224 <p>
 225 results in:
 226 </p>
 227 <pre>
 228 # Fragment Program/Shader
 229   0: RCP TEMP[4].x, UNIFORM[2].xxxx;
 230   1: RCP TEMP[4].y, UNIFORM[2].yyyy;
 231   2: MUL TEMP[3].xy, VARYING[0], TEMP[4];
 232   3: MOV TEMP[1], TEMP[3];
 233   4: MUL TEMP[0].w, TEMP[1].yyyy, CONST[4].xxxx;
 234   5: FRC TEMP[1].z, TEMP[0].wwww;
 235   6: SGT.C TEMP[0].w, TEMP[1].zzzz, CONST[4].xxxx;
 236   7: IF (NE.wwww); # (if false, goto 9);
 237   8:    ADD TEMP[1].x, TEMP[1].xxxx, CONST[4].xxxx;
 238   9: ENDIF;
 239  10: FRC TEMP[1].xy, TEMP[1];
 240  11: SGT TEMP[2].xy, UNIFORM[3], TEMP[1];
 241  12: MUL TEMP[1].z, TEMP[2].xxxx, TEMP[2].yyyy;
 242  13: LRP TEMP[0], TEMP[1].zzzz, UNIFORM[0], UNIFORM[1];
 243  14: MUL TEMP[0].xyz, TEMP[0], VARYING[1].xxxx;
 244  15: MOV OUTPUT[0].xyz, TEMP[0];
 245  16: MOV OUTPUT[0].w, CONST[4].yyyy;
 246  17: END
 247 </pre>
 248
 249 <p>
 250 Note that some shading language constructs (such as uniform and varying
 251 variables) aren't expressible in ARB or NV-style programs.
 252 Therefore, the resulting output is not always legal by definition of
 253 those program languages.
 254 </p>
 255 <p>
 256 Also note that this compiler driver is still under development.
 257 Over time, the correctness of the GPU programs, with respect to the ARB
 258 and NV languagues, should improve.
 259 </p>
 260
 261
 262
 263 <a name="implementation">
 264 <h2>Compiler Implementation</h2>
 265
 266 <p>
 267 The source code for Mesa's shading language compiler is in the
 268 <code>src/mesa/shader/slang/</code> directory.
 269 </p>
 270
 271 <p>
 272 The compiler follows a fairly standard design and basically works as follows:
 273 </p>
 274 <ul>
 275 <li>The input string is tokenized (see grammar.c) and parsed
 276 (see slang_compiler_*.c) to produce an Abstract Syntax Tree (AST).
 277 The nodes in this tree are slang_operation structures
 278 (see slang_compile_operation.h).
 279 The nodes are decorated with symbol table, scoping and datatype information.
 280 <li>The AST is converted into an Intermediate representation (IR) tree
 281 (see the slang_codegen.c file).
 282 The IR nodes represent basic GPU instructions, like add, dot product,
 283 move, etc.
 284 The IR tree is mostly a binary tree, but a few nodes have three or four
 285 children.
 286 In principle, the IR tree could be executed by doing an in-order traversal.
 287 <li>The IR tree is traversed in-order to emit code (see slang_emit.c).
 288 This is also when registers are allocated to store variables and temps.
 289 <li>In the future, a pattern-matching code generator-generator may be
 290 used for code generation.
 291 Programs such as L-BURG (Bottom-Up Rewrite Generator) and Twig look for
 292 patterns in IR trees, compute weights for subtrees and use the weights
 293 to select the best instructions to represent the sub-tree.
 294 <li>The emitted GPU instructions (see prog_instruction.h) are stored in a
 295 gl_program object (see mtypes.h).
 296 <li>When a fragment shader and vertex shader are linked (see slang_link.c)
 297 the varying vars are matched up, uniforms are merged, and vertex
 298 attributes are resolved (rewriting instructions as needed).
 299 </ul>
 300
 301 <p>
 302 The final vertex and fragment programs may be interpreted in software
 303 (see prog_execute.c) or translated into a specific hardware architecture
 304 (see drivers/dri/i915/i915_fragprog.c for example).
 305 </p>
 306
 307 <h3>Code Generation Options</h3>
 308
 309 <p>
 310 Internally, there are several options that control the compiler's code
 311 generation and instruction selection.
 312 These options are seen in the gl_shader_state struct and may be set
 313 by the device driver to indicate its preferences:
 314
 315 <pre>
 316 struct gl_shader_state
 317 {
 318    ...
 319    /** Driver-selectable options: */
 320    GLboolean EmitHighLevelInstructions;
 321    GLboolean EmitCondCodes;
 322    GLboolean EmitComments;
 323 };
 324 </pre>
 325
 326 <ul>
 327 <li>EmitHighLevelInstructions
 328 <br>
 329 This option controls instruction selection for loops and conditionals.
 330 If the option is set high-level IF/ELSE/ENDIF, LOOP/ENDLOOP, CONT/BRK
 331 instructions will be emitted.
 332 Otherwise, those constructs will be implemented with BRA instructions.
 333 </li>
 334
 335 <li>EmitCondCodes
 336 <br>
 337 If set, condition codes (ala GL_NV_fragment_program) will be used for
 338 branching and looping.
 339 Otherwise, ordinary registers will be used (the IF instruction will
 340 examine the first operand's X component and do the if-part if non-zero).
 341 This option is only relevant if EmitHighLevelInstructions is set.
 342 </li>
 343
 344 <li>EmitComments
 345 <br>
 346 If set, instructions will be annoted with comments to help with debugging.
 347 Extra NOP instructions will also be inserted.
 348 </br>
 349
 350 </ul>
 351
 352
 353 <a name="validation">
 354 <h2>Compiler Validation</h2>
 355
 356 <p>
 357 A <a href="http://glean.sf.net" target="_parent">Glean</a> test has
 358 been create to exercise the GLSL compiler.
 359 </p>
 360 <p>
 361 The <em>glsl1</em> test runs over 170 sub-tests to check that the language
 362 features and built-in functions work properly.
 363 This test should be run frequently while working on the compiler to catch
 364 regressions.
 365 </p>
 366 <p>
 367 The test coverage is reasonably broad and complete but additional tests
 368 should be added.
 369 </p>
 370
 371
 372 </BODY>
 373 </HTML>