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 17 Feb 2007.
  19 </p>
  20
  21 <p>
  22 Contents
  23 </p>
  24 <ul>
  25 <li><a href="#unsup">Unsupported Features</a>
  26 <li><a href="#impl">Implementation Notes</a>
  27 <li><a href="#hints">Programming Hints</a>
  28 <li><a href="#standalone">Stand-alone Compiler</a>
  29 </ul>
  30
  31
  32 <a name="unsup">
  33 <h2>Unsupported Features</h2>
  34
  35 <p>
  36 The following features of the shading language are not yet supported
  37 in Mesa:
  38 </p>
  39
  40 <ul>
  41 <li>Dereferencing arrays with non-constant indexes
  42 <li>User-defined structs
  43 <li>Linking of multiple shaders is not supported
  44 <li>Integer operations are not fully implemented (most are implemented
  45     as floating point).
  46 </ul>
  47
  48 <p>
  49 All other major features of the shading language should function.
  50 </p>
  51
  52
  53 <a name="impl">
  54 <h2>Implementation Notes</h2>
  55
  56 <ul>
  57 <li>Shading language programs are compiled into low-level programs
  58     very similar to those of GL_ARB_vertex/fragment_program.
  59 <li>All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
  60     float[4] registers.
  61 <li>Float constants and variables are packed so that up to four floats
  62     can occupy one program parameter/register.
  63 <li>All function calls are inlined.
  64 <li>Shaders which use too many registers will not compile.
  65 <li>The quality of generated code is pretty good, register usage is fair.
  66 <li>Shader error detection and reporting of errors (InfoLog) is not
  67     very good yet.
  68 <li>There are massive memory leaks in the compiler.
  69 </ul>
  70
  71 <p>
  72 These issues will be addressed/resolved in the future.
  73 </p>
  74
  75
  76 <a name="hints">
  77 <h2>Programming Hints</h2>
  78
  79 <ul>
  80 <li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
  81     This improves the efficiency of function inlining.
  82 </li>
  83 <br>
  84 <li>To reduce register usage, declare variables within smaller scopes.
  85     For example, the following code:
  86 <pre>
  87     void main()
  88     {
  89        vec4 a1, a2, b1, b2;
  90        gl_Position = expression using a1, a2.
  91        gl_Color = expression using b1, b2;
  92     }
  93 </pre>
  94     Can be rewritten as follows to use half as many registers:
  95 <pre>
  96     void main()
  97     {
  98        {
  99           vec4 a1, a2;
 100           gl_Position = expression using a1, a2.
 101        }
 102        {
 103           vec4 b1, b2;
 104           gl_Color = expression using b1, b2;
 105        }
 106     }
 107 </pre>
 108     Alternately, rather than using several float variables, use
 109     a vec4 instead.  Use swizzling and writemasks to access the
 110     components of the vec4 as floats.
 111 </li>
 112 <br>
 113 <li>Use the built-in library functions whenever possible.
 114     For example, instead of writing this:
 115 <pre>
 116         float x = 1.0 / sqrt(y);
 117 </pre>
 118     Write this:
 119 <pre>
 120         float x = inversesqrt(y);
 121 </pre>
 122 </ul>
 123
 124
 125 <a name="standalone">
 126 <h2>Stand-alone Compiler</h2>
 127
 128 <p>
 129 A unique stand-alone GLSL compiler driver has been added to Mesa.
 130 <p>
 131
 132 <p>
 133 The stand-alone compiler (like a conventional command-line compiler)
 134 is a tool that accepts Shading Language programs and emits low-level
 135 GPU programs.
 136 </p>
 137
 138 <p>
 139 This tool is useful for:
 140 <p>
 141 <ul>
 142 <li>Inspecting GPU code to gain insight into compilation
 143 <li>Generating initial GPU code for subsequent hand-tuning
 144 <li>Debugging the GLSL compiler itself
 145 </ul>
 146
 147 <p>
 148 (compiler build instructions TBD)
 149 </p>
 150
 151 <p>
 152 Here's an example of using the compiler to compile a vertex shader and
 153 emit GL_ARB_vertex_program-style instructions:
 154 </p>
 155 <pre>
 156     glslcompiler --arb --linenumbers --vs vertshader.txt
 157 </pre>
 158 <p>
 159 The output may look similar to this:
 160 </p>
 161 <pre>
 162 !!ARBvp1.0
 163   0: MOV result.texcoord[0], vertex.texcoord[0];
 164   1: DP4 temp0.x, state.matrix.mvp.row[0], vertex.position;
 165   2: DP4 temp0.y, state.matrix.mvp.row[1], vertex.position;
 166   3: DP4 temp0.z, state.matrix.mvp.row[2], vertex.position;
 167   4: DP4 temp0.w, state.matrix.mvp.row[3], vertex.position;
 168   5: MOV result.position, temp0;
 169   6: END
 170 </pre>
 171
 172 <p>
 173 Note that some shading language constructs (such as uniform and varying
 174 variables) aren't expressible in ARB or NV-style programs.
 175 Therefore, the resulting output is not always legal by definition of
 176 those program languages.
 177 </p>
 178 <p>
 179 Also note that this compiler driver is still under development.
 180 Over time, the correctness of the GPU programs, with respect to the ARB
 181 and NV languagues, should improve.
 182 </p>
 183
 184 </BODY>
 185 </HTML>