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