Merge remote branch 'origin/master' into nv50-compiler

Conflicts:
	src/gallium/drivers/nv50/nv50_program.c

8 files changed, 223 insertions, 176 deletions

diff --git a/docs/MESA_drm_image.spec b/docs/MESA_drm_image.spec
new file mode 100644
index 0000000000..118501c3d3
--- /dev/null
+++ b/docs/MESA_drm_image.spec
@@ -0,0 +1,149 @@
+Name
+
+    MESA_drm_image
+
+Name Strings
+
+    EGL_MESA_drm_image
+
+Contact
+
+    Kristian Høgsberg <krh@bitplanet.net>
+
+Status
+
+    Proposal
+
+Version
+
+    Version 2, August 25, 2010
+
+Number
+
+    EGL Extension #not assigned
+
+Dependencies
+
+    Reguires EGL 1.4 or later.  This extension is written against the
+    wording of the EGL 1.4 specification.
+
+    EGL_KHR_base_image is required.
+
+Overview
+
+    This extension provides entry points for integrating EGLImage with the
+    Linux DRM mode setting and memory management drivers.  The extension
+    lets applications create EGLImages without a client API resource and
+    lets the application get the DRM buffer handles.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Procedures and Functions
+
+    EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
+                                      const EGLint *attrib_list);
+
+    EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
+                                     EGLImageKHR image,
+                                     EGLint *name,
+				     EGLint *handle,
+				     EGLint *stride);
+
+New Tokens
+
+    Accepted in the <attrib_list> parameter of eglCreateDRMImageMESA:
+
+        EGL_DRM_BUFFER_FORMAT_MESA		0x31D0
+        EGL_DRM_BUFFER_USE_MESA			0x31D1
+
+    Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
+
+        EGL_DRM_BUFFER_FORMAT_ARGB32_MESA	0x31D2
+
+    Bits accepted in EGL_DRM_BUFFER_USE_MESA:
+
+        EGL_DRM_BUFFER_USE_SCANOUT_MESA		0x0001
+        EGL_DRM_BUFFER_USE_SHARE_MESA		0x0002
+
+    Accepted in the <target> parameter of eglCreateImageKHR:
+
+        EGL_DRM_BUFFER_MESA			0x31D3
+
+    Use when importing drm buffer:
+
+        EGL_DRM_BUFFER_STRIDE_MESA		0x31D4
+        EGL_DRM_BUFFER_FORMAT_MESA		0x31D0
+
+Additions to the EGL 1.4 Specification:
+
+    To create a DRM EGLImage, call
+
+        EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
+                                          const EGLint *attrib_list);
+
+    In the attribute list, pass EGL_WIDTH, EGL_EIGHT and format and
+    use in the attrib list using EGL_DRM_BUFFER_FORMAT_MESA and
+    EGL_DRM_BUFFER_USE_MESA.  The only format specified by this
+    extension is EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel
+    is a CPU-endian, 32-bit quantity, with alpha in the upper 8 bits,
+    then red, then green, then blue.  The bit values accepted by
+    EGL_DRM_BUFFER_USE_MESA are EGL_DRM_BUFFER_USE_SCANOUT_MESA and
+    EGL_DRM_BUFFER_USE_SHARE_MESA.  EGL_DRM_BUFFER_USE_SCANOUT_MESA
+    requests that the created EGLImage should be usable as a scanout
+    buffer with the DRM kernel modesetting API.  The
+    EGL_DRM_BUFFER_USE_SHARE_MESA bit requests that the EGLImage can
+    be shared with other processes by passing the underlying DRM
+    buffer name.
+
+    To create a process local handle or a global DRM name for a
+    buffer, call
+
+        EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
+                                         EGLImageKHR image,
+                                         EGLint *name,
+                                         EGLint *handle,
+                                         EGLint *stride);
+
+    If <name> is non-NULL, a global name is assigned to the image and
+    written to <name>, the handle (local to the DRM file descriptor,
+    for use with DRM kernel modesetting API) is written to <handle> if
+    non-NULL and the stride (in bytes) is written to <stride>, if
+    non-NULL.
+
+    Import a shared buffer by calling eglCreateImageKHR with
+    EGL_DRM_BUFFER_MESA as the target, using EGL_WIDTH, EGL_HEIGHT,
+    EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_STRIDE_MESA
+    in the attrib list.
+
+Issues
+
+    1.  Why don't we use eglCreateImageKHR with a target that
+        indicates that we want to create an EGLImage from scratch?
+
+        RESOLVED: The eglCreateImageKHR entry point is reserved for
+        creating an EGLImage from an already existing client API
+        resource.  This is fine when we're creating the EGLImage from
+        an existing DRM buffer name, it doesn't seem right to overload
+        the function to also allocate the underlying resource.
+
+    2.  Why don't we use an eglQueryImageMESA type functions for
+        querying the DRM EGLImage attributes (name, handle, and stride)?
+
+        RESOLVED: The eglQueryImage function has been proposed often,
+        but it goes against the EGLImage design.  EGLImages are opaque
+        handles to a 2D array of pixels, which can be passed between
+        client APIs.  By referenceing an EGLImage in a client API, the
+        EGLImage target (a texture, a renderbuffer or such) can be
+        used to query the attributes of the EGLImage.  We don't have a
+        full client API for creating and querying DRM buffers, though,
+        so we use a new EGL extension entry point instead.
+
+Revision History
+
+    Version 1, June 3, 2010
+        Initial draft (Kristian Høgsberg)
+    Version 2, August 25, 2010
+        Flesh out the extension a bit, add final EGL tokens, capture
+        some of the original discussion in the issues section.
diff --git a/docs/contents.html b/docs/contents.html
index cca20ecaae..cf1661e4ea 100644
--- a/docs/contents.html
+++ b/docs/contents.html
@@ -69,7 +69,6 @@ a:visited {
 <li><a href="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a>
 <li><a href="repository.html" target="MainFrame">Source Code Repository</a>
 <li><a href="sourcetree.html" target="MainFrame">Source Code Tree</a>
-<li><a href="memory.html" target="MainFrame">DRI Memory Management</a>
 <li><a href="glu.html" target="MainFrame">SGI's GLU</a>
 <li><a href="utilities.html" target="MainFrame">Utilities</a>
 <li><a href="helpwanted.html" target="MainFrame">Help Wanted</a>
diff --git a/docs/developers.html b/docs/developers.html
index 410f1ac5e8..8960e7cb48 100644
--- a/docs/developers.html
+++ b/docs/developers.html
@@ -12,12 +12,14 @@
 Both professional and volunteer developers contribute to Mesa.
 </p>
 <p>
-<a href="http://www.tungstengraphics.com/" target="_parent">Tungsten Graphics</a>
+<a href="http://www.vmware.com/" target="_parent">VMware</a>
 employs several of the main Mesa developers including Brian Paul
 and Keith Whitwell.
-Much of the on-going work in Mesa is done through Tungsten Graphics engineering
-contracts.
-Prominent examples of this work includes:
+</p>
+
+<p>
+In the past, Tungsten Graphics contracts implemented many Mesa features
+including:
 </p>
 <ul>
 <li>DRI drivers for Intel i965, i945, i915 and other chips
@@ -29,23 +31,19 @@ Prominent examples of this work includes:
 <p>
 Other companies including
 <a href="http://www.intellinuxgraphics.org/index.html" target="_parent">Intel</a>
-and IBM also actively contribute to the project.
+and RedHat also actively contribute to the project.
+Intel has recently contributed the new GLSL compiler in Mesa 7.9.
 </p>
 
 <p>
-Volunteers have made significant contributions to all parts of Mesa, including
-complete device drivers.
+<a href="http://www.lunarg.com/" target="_parent">LunarG</a> can be contacted
+for custom Mesa / 3D graphics development.
 </p>
 
-
-<H1>Custom Development</H1>
 <p>
-Contact <a href="http://www.tungstengraphics.com/" target="_parent">
-Tungsten Graphics</a>
-for information about custom development in Mesa, OpenGL, X and other
-graphics technologies.
+Volunteers have made significant contributions to all parts of Mesa, including
+complete device drivers.
 </p>
 
-
 </body>
 </html>
diff --git a/docs/intro.html b/docs/intro.html
index aae2e6e192..0806caf388 100644
--- a/docs/intro.html
+++ b/docs/intro.html
@@ -111,11 +111,9 @@ It implements the OpenGL 1.3 specification.
 
 
 <p>
-November 2001: I cofound <a href="http://www.tungstengraphics.com" target="_parent">
-Tungsten Graphics, Inc.</a> with Keith Whitwell, Jens Owen, David Dawes and
-Frank LaMonica.
-I continue to develop Mesa as part of my resposibilities with Tungsten
-Graphics and as a spare-time project.
+November 2001: I cofounded Tungsten Graphics, Inc. with Keith Whitwell,
+Jens Owen, David Dawes and Frank LaMonica.
+Tungsten Graphics was acquired by VMware in December 2008.
 </p>
 
 <p>
diff --git a/docs/news.html b/docs/news.html
index b7731cdaf3..09385ad35e 100644
--- a/docs/news.html
+++ b/docs/news.html
@@ -11,6 +11,14 @@
 <H1>News</H1>
 
 
+<h2>June 16, 2010</h2>
+
+<p>
+<a href="relnotes-7.8.2.html">Mesa 7.8.2</a> is released.  This is a bug-fix
+release collecting fixes since the 7.8.1 release.
+</p>
+
+
 <h2>April 5, 2010</h2>
 
 <p>
@@ -157,9 +165,6 @@ Added a new page describing the <a href="cell.html">Mesa Cell driver</a>.
 <p>
 Gallium3D is the codename for the new Mesa device driver architecture
 which is currently under development.
-A <a href="http://wiki.freedesktop.org/wiki/Software/gallium"
-target="_parent"> summary</a> of the architecture can be found on the
-Tungsten Graphics website.
 </p>
 <p>
 Gallium3D development is taking place on the <em>gallium-0.1</em> branch
@@ -210,11 +215,8 @@ shading language and built-in functions.
 
 <h2>April 2007</h2>
 <p>
-Thomas Hellstr&ouml;m of
-<a href="http://www.tungstengraphics.com" target="_parent">
-Tungsten Graphics</a> has written a whitepaper describing the new
-<a href="http://www.tungstengraphics.com/mm.pdf">DRI memory management
-system</a>.
+Thomas Hellstr&ouml;m of Tungsten Graphics has written a whitepaper
+describing the new DRI memory management system</a>.
 </p>
 
 <h2>December 5, 2006</h2>
diff --git a/docs/relnotes-7.9.html b/docs/relnotes-7.9.html
index 457dd8fd05..2cc7c4ec62 100644
--- a/docs/relnotes-7.9.html
+++ b/docs/relnotes-7.9.html
@@ -34,7 +34,11 @@ tbd
 
 <h2>New features</h2>
 <ul>
+<li>New, improved GLSL compiler written by Intel.
+    See the <a href="shading.html"> Shading Language</a> page for
+    more information.
 <li>GL_EXT_timer_query extension (i965 driver only)
+<li>GL_EXT_framebuffer_multisample extension (intel drivers, MAX_SAMPLES = 1)
 <li>GL_ARB_texture_swizzle extension (alias of GL_EXT_texture_swizzle)
 <li>GL_ARB_draw_elements_base_vertex, GL_ARB_fragment_program_shadow
     and GL_EXT_draw_buffers2 in Gallium drivers
diff --git a/docs/shading.html b/docs/shading.html
index 750884cf36..c41d4a9be2 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -39,19 +39,19 @@ list of keywords to control some aspects of the GLSL compiler and shader
 execution.  These are generally used for debugging.
 </p>
 <ul>
-<li>dump - print GLSL shader code to stdout at link time
-<li>log - log all GLSL shaders to files.
+<li><b>dump</b> - print GLSL shader code to stdout at link time
+<li><b>log</b> - log all GLSL shaders to files.
     The filenames will be "shader_X.vert" or "shader_X.frag" where X
     the shader ID.
-<li>nopt - disable compiler optimizations
-<li>opt - force compiler optimizations
-<li>uniform - print message to stdout when glUniform is called
-<li>nopvert - force vertex shaders to be a simple shader that just transforms
+<li><b>nopt</b> - disable compiler optimizations
+<li><b>opt</b> - force compiler optimizations
+<li><b>uniform</b> - print message to stdout when glUniform is called
+<li><b>nopvert</b> - force vertex shaders to be a simple shader that just transforms
     the vertex position with ftransform() and passes through the color and
     texcoord[0] attributes.
-<li>nopfrag - force fragment shader to be a simple shader that passes
+<li><b>nopfrag</b> - force fragment shader to be a simple shader that passes
     through the color attribute.
-<li>useprog - log glUseProgram calls to stderr
+<li><b>useprog</b> - log glUseProgram calls to stderr
 </ul>
 <p>
 Example:  export MESA_GLSL=dump,nopt
@@ -59,30 +59,28 @@ Example:  export MESA_GLSL=dump,nopt
 
 
 <a name="120">
-<h2>GLSL 1.20 support</h2>
+<h2>GLSL Version</h2>
 
 <p>
-GLSL version 1.20 is supported in Mesa 7.3 and later.
-Among the features/differences of GLSL 1.20 are:
+The GLSL compiler currently supports version 1.20 of the shading language.
+</p>
+
+<p>
+Several GLSL extensions are also supported:
+</p>
 <ul>
-<li><code>mat2x3, mat2x4</code>, etc. types and functions
-<li><code>transpose(), outerProduct(), matrixCompMult()</code> functions
-(but untested)
-<li>precision qualifiers (lowp, mediump, highp)
-<li><code>invariant</code> qualifier
-<li><code>array.length()</code> method
-<li><code>float[5] a;</code> array syntax
-<li><code>centroid</code> qualifier
-<li>unsized array constructors
-<li>initializers for uniforms
-<li>const initializers calling built-in functions
+<li>GL_ARB_draw_buffers
+<li>GL_ARB_texture_rectangle
+<li>GL_ARB_fragment_coord_conventions
+<li>GL_EXT_texture_array
 </ul>
 
 
-
 <a name="unsup">
 <h2>Unsupported Features</h2>
 
+<p>XXX update this section</p>
+
 <p>
 The following features of the shading language are not yet fully supported
 in Mesa:
@@ -130,39 +128,6 @@ These issues will be addressed/resolved in the future.
 <h2>Programming Hints</h2>
 
 <ul>
-<li>Declare <em>in</em> function parameters as <em>const</em> whenever possible.
-    This improves the efficiency of function inlining.
-</li>
-<br>
-<li>To reduce register usage, declare variables within smaller scopes.
-    For example, the following code:
-<pre>
-    void main()
-    {
-       vec4 a1, a2, b1, b2;
-       gl_Position = expression using a1, a2.
-       gl_Color = expression using b1, b2;
-    }
-</pre>
-    Can be rewritten as follows to use half as many registers:
-<pre>
-    void main()
-    {
-       {
-          vec4 a1, a2;
-          gl_Position = expression using a1, a2.
-       }
-       {
-          vec4 b1, b2;
-          gl_Color = expression using b1, b2;
-       }
-    }
-</pre>
-    Alternately, rather than using several float variables, use
-    a vec4 instead.  Use swizzling and writemasks to access the
-    components of the vec4 as floats.
-</li>
-<br>
 <li>Use the built-in library functions whenever possible.
     For example, instead of writing this:
 <pre>
@@ -172,8 +137,6 @@ These issues will be addressed/resolved in the future.
 <pre>
         float x = inversesqrt(y);
 </pre>
-<li>
-   Use ++i when possible as it's more efficient than i++
 </li>
 </ul>
 
@@ -182,13 +145,8 @@ These issues will be addressed/resolved in the future.
 <h2>Stand-alone GLSL Compiler</h2>
 
 <p>
-A unique stand-alone GLSL compiler driver has been added to Mesa.
-<p>
-
-<p>
-The stand-alone compiler (like a conventional command-line compiler)
-is a tool that accepts Shading Language programs and emits low-level
-GPU programs.
+The stand-alone GLSL compiler program can be used to compile GLSL shaders
+into low-level GPU code.
 </p>
 
 <p>
@@ -201,59 +159,25 @@ This tool is useful for:
 </ul>
 
 <p>
-After building Mesa, the glslcompiler can be built by manually running:
+After building Mesa, the compiler can be found at src/glsl/glsl_compiler
 </p>
-<pre>
-    make realclean
-    make linux
-    cd src/mesa/drivers/glslcompiler
-    make
-</pre>
-
 
 <p>
 Here's an example of using the compiler to compile a vertex shader and
 emit GL_ARB_vertex_program-style instructions:
 </p>
 <pre>
-    bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt
-</pre>
-<p>
-results in:
-</p>
-<pre>
-# Fragment Program/Shader
-  0: RCP TEMP[4].x, UNIFORM[2].xxxx;
-  1: RCP TEMP[4].y, UNIFORM[2].yyyy;
-  2: MUL TEMP[3].xy, VARYING[0], TEMP[4];
-  3: MOV TEMP[1], TEMP[3];
-  4: MUL TEMP[0].w, TEMP[1].yyyy, CONST[4].xxxx;
-  5: FRC TEMP[1].z, TEMP[0].wwww;
-  6: SGT.C TEMP[0].w, TEMP[1].zzzz, CONST[4].xxxx;
-  7: IF (NE.wwww); # (if false, goto 9);
-  8:    ADD TEMP[1].x, TEMP[1].xxxx, CONST[4].xxxx;
-  9: ENDIF;
- 10: FRC TEMP[1].xy, TEMP[1];
- 11: SGT TEMP[2].xy, UNIFORM[3], TEMP[1];
- 12: MUL TEMP[1].z, TEMP[2].xxxx, TEMP[2].yyyy;
- 13: LRP TEMP[0], TEMP[1].zzzz, UNIFORM[0], UNIFORM[1];
- 14: MUL TEMP[0].xyz, TEMP[0], VARYING[1].xxxx;
- 15: MOV OUTPUT[0].xyz, TEMP[0];
- 16: MOV OUTPUT[0].w, CONST[4].yyyy;
- 17: END
+    src/glsl/glslcompiler --dump-ast myshader.vert
 </pre>
 
-<p>
-Note that some shading language constructs (such as uniform and varying
-variables) aren't expressible in ARB or NV-style programs.
-Therefore, the resulting output is not always legal by definition of
-those program languages.
-</p>
-<p>
-Also note that this compiler driver is still under development.
-Over time, the correctness of the GPU programs, with respect to the ARB
-and NV languagues, should improve.
-</p>
+Options include
+<ul>
+<li><b>--dump-ast</b> - dump GPU code
+<li><b>--dump-hir</b> - dump high-level IR code
+<li><b>--dump-lir</b> - dump low-level IR code
+<li><b>--link</b> - ???
+</ul>
+
 
 
 
@@ -262,38 +186,12 @@ and NV languagues, should improve.
 
 <p>
 The source code for Mesa's shading language compiler is in the
-<code>src/mesa/shader/slang/</code> directory.
+<code>src/glsl/</code> directory.
 </p>
 
 <p>
-The compiler follows a fairly standard design and basically works as follows:
+XXX provide some info about the compiler....
 </p>
-<ul>
-<li>The input string is tokenized (see grammar.c) and parsed
-(see slang_compiler_*.c) to produce an Abstract Syntax Tree (AST).
-The nodes in this tree are slang_operation structures
-(see slang_compile_operation.h).
-The nodes are decorated with symbol table, scoping and datatype information.
-<li>The AST is converted into an Intermediate representation (IR) tree
-(see the slang_codegen.c file).
-The IR nodes represent basic GPU instructions, like add, dot product,
-move, etc. 
-The IR tree is mostly a binary tree, but a few nodes have three or four
-children.
-In principle, the IR tree could be executed by doing an in-order traversal.
-<li>The IR tree is traversed in-order to emit code (see slang_emit.c).
-This is also when registers are allocated to store variables and temps.
-<li>In the future, a pattern-matching code generator-generator may be
-used for code generation.
-Programs such as L-BURG (Bottom-Up Rewrite Generator) and Twig look for
-patterns in IR trees, compute weights for subtrees and use the weights
-to select the best instructions to represent the sub-tree.
-<li>The emitted GPU instructions (see prog_instruction.h) are stored in a
-gl_program object (see mtypes.h).
-<li>When a fragment shader and vertex shader are linked (see slang_link.c)
-the varying vars are matched up, uniforms are merged, and vertex
-attributes are resolved (rewriting instructions as needed).
-</ul>
 
 <p>
 The final vertex and fragment programs may be interpreted in software
@@ -351,20 +249,20 @@ Extra NOP instructions will also be inserted.
 <h2>Compiler Validation</h2>
 
 <p>
-A <a href="http://glean.sf.net" target="_parent">Glean</a> test has
-been create to exercise the GLSL compiler.
-</p>
-<p>
-The <em>glsl1</em> test runs over 170 sub-tests to check that the language
-features and built-in functions work properly.
-This test should be run frequently while working on the compiler to catch
+Developers working on the GLSL compiler should test frequently to avoid
 regressions.
 </p>
+
 <p>
-The test coverage is reasonably broad and complete but additional tests
-should be added.
+The <a href="http://people.freedesktop.org/~nh/piglit/">Piglit</a> project
+has many GLSL tests and the
+<a href="http://glean.sf.net" target="_parent">Glean</a> glsl1 test 
+tests GLSL features.
 </p>
 
+<p>
+The Mesa demos repository also has some good GLSL tests.
+</p>
 
 </BODY>
 </HTML>
diff --git a/docs/subset-A.html b/docs/subset-A.html
index dac66a61ba..d576bb6744 100644
--- a/docs/subset-A.html
+++ b/docs/subset-A.html
@@ -16,8 +16,7 @@
 </h3>
 </center>
 </h2>
-<p> Copyright &copy; 2002-2003 by <a
- href="http://www.tungstengraphics.com/">Tungsten Graphics, Inc.</a>,
+<p> Copyright &copy; 2002-2003 by Tungsten Graphics, Inc.,
 Cedar Park, Texas. All Rights Reserved. <br>
 <br>
 Permission is granted to make and distribute verbatim copies of this