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