Import Mesa 13.0.2

5 files changed, 1245 insertions, 8 deletions

diff --git a/lib/mesa/docs/specs/EGL_MESA_platform_surfaceless.txt b/lib/mesa/docs/specs/EGL_MESA_platform_surfaceless.txt
new file mode 100644
index 000000000..871ee509c
--- /dev/null
+++ b/lib/mesa/docs/specs/EGL_MESA_platform_surfaceless.txt
@@ -0,0 +1,120 @@
+Name
+
+    MESA_platform_surfaceless
+
+Name Strings
+
+    EGL_MESA_platform_surfaceless
+
+Contributors
+
+    Chad Versace <chadversary@google.com>
+    Haixia Shi <hshi@google.com>
+    Stéphane Marchesin <marcheu@google.com>
+    Zach Reizner <zachr@chromium.org>
+    Gurchetan Singh <gurchetansingh@google.com>
+
+Contacts
+
+    Chad Versace <chadversary@google.com>
+
+Status
+
+    DRAFT
+
+Version
+
+    Version 2, 2016-10-13
+
+Number
+
+    EGL Extension #TODO
+
+Extension Type
+
+    EGL client extension
+
+Dependencies
+
+    Requires EGL 1.5 or later; or EGL 1.4 with EGL_EXT_platform_base.
+
+    This extension is written against the EGL 1.5 Specification (draft
+    20140122).
+
+    This extension interacts with EGL_EXT_platform_base as follows. If the
+    implementation supports EGL_EXT_platform_base, then text regarding
+    eglGetPlatformDisplay applies also to eglGetPlatformDisplayEXT;
+    eglCreatePlatformWindowSurface to eglCreatePlatformWindowSurfaceEXT; and
+    eglCreatePlatformPixmapSurface to eglCreatePlatformPixmapSurfaceEXT.
+
+Overview
+
+    This extension defines a new EGL platform, the "surfaceless" platform. This
+    platfom's defining property is that it has no native surfaces, and hence
+    neither eglCreatePlatformWindowSurface nor eglCreatePlatformPixmapSurface
+    can be used. The platform is independent of any native window system.
+
+    The platform's intended use case is for enabling OpenGL and OpenGL ES
+    applications on systems where no window system exists. However, the
+    platform's permitted usage is not restricted to this case.  Since the
+    platform is independent of any native window system, it may also be used on
+    systems where a window system is present.
+
+New Types
+
+    None
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    Accepted as the <platform> argument of eglGetPlatformDisplay:
+
+        EGL_PLATFORM_SURFACELESS_MESA           0x31DD
+
+Additions to the EGL Specification
+
+    None.
+
+New Behavior
+
+    To determine if the EGL implementation supports this extension, clients
+    should query the EGL_EXTENSIONS string of EGL_NO_DISPLAY.
+
+    To obtain an EGLDisplay on the surfaceless platform, call
+    eglGetPlatformDisplay with <platform> set to EGL_PLATFORM_SURFACELESS_MESA.
+    The <native_display> parameter must be EGL_DEFAULT_DISPLAY.
+
+    eglCreatePlatformWindowSurface fails when called with a <display> that
+    belongs to the surfaceless platform. It returns EGL_NO_SURFACE and
+    generates EGL_BAD_NATIVE_WINDOW. The justification for this unconditional
+    failure is that the surfaceless platform has no native windows, and
+    therefore the <native_window> parameter is always invalid.
+
+    Likewise, eglCreatePlatformPixmapSurface also fails when called with a
+    <display> that belongs to the surfaceless platform.  It returns
+    EGL_NO_SURFACE and generates EGL_BAD_NATIVE_PIXMAP.
+
+    The surfaceless platform imposes no platform-specific restrictions on the
+    creation of pbuffers, as eglCreatePbufferSurface has no native surface
+    parameter.  Specifically, if the EGLDisplay advertises an EGLConfig whose
+    EGL_SURFACE_TYPE attribute contains EGL_PBUFFER_BIT, then the EGLDisplay
+    permits the creation of pbuffers with that config.
+
+Issues
+
+    None.
+
+Revision History
+
+    Version 2, 2016-10-13 (Chad Versace)
+        - Assign enum values
+        - Define interfactions with EGL 1.4 and EGL_EXT_platform_base.
+        - Add Gurchetan as contributor, as he implemented the pbuffer support.
+
+    Version 1, 2016-09-23 (Chad Versace)
+        - Initial version
+        - Posted for review at
+          https://lists.freedesktop.org/archives/mesa-dev/2016-September/129549.html
diff --git a/lib/mesa/docs/specs/MESA_configless_context.spec b/lib/mesa/docs/specs/MESA_configless_context.spec
index f2fafb35a..d7ba62dd8 100644
--- a/lib/mesa/docs/specs/MESA_configless_context.spec
+++ b/lib/mesa/docs/specs/MESA_configless_context.spec
@@ -12,11 +12,12 @@ Contact
 
 Status
 
-    Proposal
+    Superseded by the functionally identical EGL_KHR_no_config_context
+    extension.
 
 Version
 
-    Version 1, February 28, 2014
+    Version 2, September 9, 2016
 
 Number
 
@@ -121,5 +122,8 @@ Issues
 
 Revision History
 
+    Version 2, September 9, 2016
+        Defer to EGL_KHR_no_config_context (Adam Jackson)
+
     Version 1, February 28, 2014
         Initial draft (Neil Roberts)
diff --git a/lib/mesa/docs/specs/MESA_shader_integer_functions.txt b/lib/mesa/docs/specs/MESA_shader_integer_functions.txt
new file mode 100644
index 000000000..58a956f44
--- /dev/null
+++ b/lib/mesa/docs/specs/MESA_shader_integer_functions.txt
@@ -0,0 +1,520 @@
+Name
+
+    MESA_shader_integer_functions
+
+Name Strings
+
+    GL_MESA_shader_integer_functions
+
+Contact
+
+    Ian Romanick <ian.d.romanick@intel.com>
+
+Contributors
+
+    All the contributors of GL_ARB_gpu_shader5
+
+Status
+
+    Supported by all GLSL 1.30 capable drivers in Mesa 12.1 and later
+
+Version
+
+    Version 2, July 7, 2016
+
+Number
+
+    TBD
+
+Dependencies
+
+    This extension is written against the OpenGL 3.2 (Compatibility Profile)
+    Specification.
+
+    This extension is written against Version 1.50 (Revision 09) of the OpenGL
+    Shading Language Specification.
+
+    GLSL 1.30 is required.
+
+    This extension interacts with ARB_gpu_shader5.
+
+    This extension interacts with ARB_gpu_shader_fp64.
+
+    This extension interacts with NV_gpu_shader5.
+
+Overview
+
+    GL_ARB_gpu_shader5 extends GLSL in a number of useful ways.  Much of this
+    added functionality requires significant hardware support.  There are many
+    aspects, however, that can be easily implmented on any GPU with "real"
+    integer support (as opposed to simulating integers using floating point
+    calculations).
+
+    This extension provides a set of new features to the OpenGL Shading
+    Language to support capabilities of these GPUs, extending the capabilities
+    of version 1.30 of the OpenGL Shading Language.  Shaders
+    using the new functionality provided by this extension should enable this
+    functionality via the construct
+
+      #extension GL_MESA_shader_integer_functions : require   (or enable)
+
+    This extension provides a variety of new features for all shader types,
+    including:
+
+      * support for implicitly converting signed integer types to unsigned
+        types, as well as more general implicit conversion and function
+        overloading infrastructure to support new data types introduced by
+        other extensions;
+
+      * new built-in functions supporting:
+
+        * splitting a floating-point number into a significand and exponent
+          (frexp), or building a floating-point number from a significand and
+          exponent (ldexp);
+
+        * integer bitfield manipulation, including functions to find the
+          position of the most or least significant set bit, count the number
+          of one bits, and bitfield insertion, extraction, and reversal;
+
+        * extended integer precision math, including add with carry, subtract
+          with borrow, and extenended multiplication;
+
+    The resulting extension is a strict subset of GL_ARB_gpu_shader5.
+
+IP Status
+
+    No known IP claims.
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    None
+
+Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification
+(OpenGL Operation)
+
+    None.
+
+Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification
+(Rasterization)
+
+    None.
+
+Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification
+(Per-Fragment Operations and the Frame Buffer)
+
+    None.
+
+Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification
+(Special Functions)
+
+    None.
+
+Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification
+(State and State Requests)
+
+    None.
+
+Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile)
+Specification (Invariance)
+
+    None.
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None.
+
+Modifications to The OpenGL Shading Language Specification, Version 1.50
+(Revision 09)
+
+    Including the following line in a shader can be used to control the
+    language features described in this extension:
+
+      #extension GL_MESA_shader_integer_functions : <behavior>
+
+    where <behavior> is as specified in section 3.3.
+
+    New preprocessor #defines are added to the OpenGL Shading Language:
+
+      #define GL_MESA_shader_integer_functions        1
+
+
+    Modify Section 4.1.10, Implicit Conversions, p. 27
+
+    (modify table of implicit conversions)
+
+                                Can be implicitly
+        Type of expression        converted to
+        ---------------------   -----------------
+        int                     uint, float
+        ivec2                   uvec2, vec2
+        ivec3                   uvec3, vec3
+        ivec4                   uvec4, vec4
+
+        uint                    float
+        uvec2                   vec2
+        uvec3                   vec3
+        uvec4                   vec4
+
+    (modify second paragraph of the section) No implicit conversions are
+    provided to convert from unsigned to signed integer types or from
+    floating-point to integer types.  There are no implicit array or structure
+    conversions.
+
+    (insert before the final paragraph of the section) When performing
+    implicit conversion for binary operators, there may be multiple data types
+    to which the two operands can be converted.  For example, when adding an
+    int value to a uint value, both values can be implicitly converted to uint
+    and float.  In such cases, a floating-point type is chosen if either
+    operand has a floating-point type.  Otherwise, an unsigned integer type is
+    chosen if either operand has an unsigned integer type.  Otherwise, a
+    signed integer type is chosen.
+    
+
+    Modify Section 5.9, Expressions, p. 57
+
+    (modify bulleted list as follows, adding support for implicit conversion
+    between signed and unsigned types)
+
+    Expressions in the shading language are built from the following:
+
+    * Constants of type bool, int, int64_t, uint, uint64_t, float, all vector
+      types, and all matrix types.
+
+    ...
+
+    * The operator modulus (%) operates on signed or unsigned integer scalars
+      or vectors.  If the fundamental types of the operands do not match, the
+      conversions from Section 4.1.10 "Implicit Conversions" are applied to
+      produce matching types.  ...
+
+
+    Modify Section 6.1, Function Definitions, p. 63
+
+    (modify description of overloading, beginning at the top of p. 64)
+
+     Function names can be overloaded.  The same function name can be used for
+     multiple functions, as long as the parameter types differ.  If a function
+     name is declared twice with the same parameter types, then the return
+     types and all qualifiers must also match, and it is the same function
+     being declared.  For example,
+
+       vec4 f(in vec4 x, out vec4  y);   // (A)
+       vec4 f(in vec4 x, out uvec4 y);   // (B) okay, different argument type
+       vec4 f(in ivec4 x, out uvec4 y);  // (C) okay, different argument type
+
+       int  f(in vec4 x, out ivec4 y);  // error, only return type differs
+       vec4 f(in vec4 x, in  vec4  y);  // error, only qualifier differs
+       vec4 f(const in vec4 x, out vec4 y);  // error, only qualifier differs
+
+     When function calls are resolved, an exact type match for all the
+     arguments is sought.  If an exact match is found, all other functions are
+     ignored, and the exact match is used.  If no exact match is found, then
+     the implicit conversions in Section 4.1.10 (Implicit Conversions) will be
+     applied to find a match.  Mismatched types on input parameters (in or
+     inout or default) must have a conversion from the calling argument type
+     to the formal parameter type.  Mismatched types on output parameters (out
+     or inout) must have a conversion from the formal parameter type to the
+     calling argument type.
+
+     If implicit conversions can be used to find more than one matching
+     function, a single best-matching function is sought.  To determine a best
+     match, the conversions between calling argument and formal parameter
+     types are compared for each function argument and pair of matching
+     functions.  After these comparisons are performed, each pair of matching
+     functions are compared.  A function definition A is considered a better
+     match than function definition B if:
+
+       * for at least one function argument, the conversion for that argument
+         in A is better than the corresponding conversion in B; and
+
+       * there is no function argument for which the conversion in B is better
+         than the corresponding conversion in A.
+
+     If a single function definition is considered a better match than every
+     other matching function definition, it will be used.  Otherwise, a
+     semantic error occurs and the shader will fail to compile.
+
+     To determine whether the conversion for a single argument in one match is
+     better than that for another match, the following rules are applied, in
+     order:
+
+       1. An exact match is better than a match involving any implicit
+          conversion.
+
+       2. A match involving an implicit conversion from float to double is
+          better than a match involving any other implicit conversion.
+
+       3. A match involving an implicit conversion from either int or uint to
+          float is better than a match involving an implicit conversion from
+          either int or uint to double.
+
+     If none of the rules above apply to a particular pair of conversions,
+     neither conversion is considered better than the other.
+
+     For the function prototypes (A), (B), and (C) above, the following
+     examples show how the rules apply to different sets of calling argument
+     types:
+
+       f(vec4, vec4);        // exact match of vec4 f(in vec4 x, out vec4 y)
+       f(vec4, uvec4);       // exact match of vec4 f(in vec4 x, out ivec4 y)
+       f(vec4, ivec4);       // matched to vec4 f(in vec4 x, out vec4 y)
+                             //   (C) not relevant, can't convert vec4 to 
+                             //   ivec4.  (A) better than (B) for 2nd
+                             //   argument (rule 2), same on first argument.
+       f(ivec4, vec4);       // NOT matched.  All three match by implicit
+                             //   conversion.  (C) is better than (A) and (B)
+                             //   on the first argument.  (A) is better than
+                             //   (B) and (C).
+
+
+    Modify Section 8.3, Common Functions, p. 84
+
+    (add support for single-precision frexp and ldexp functions)
+
+    Syntax:
+
+      genType frexp(genType x, out genIType exp);
+      genType ldexp(genType x, in genIType exp);
+
+    The function frexp() splits each single-precision floating-point number in
+    <x> into a binary significand, a floating-point number in the range [0.5,
+    1.0), and an integral exponent of two, such that:
+
+      x = significand * 2 ^ exponent
+
+    The significand is returned by the function; the exponent is returned in
+    the parameter <exp>.  For a floating-point value of zero, the significant
+    and exponent are both zero.  For a floating-point value that is an
+    infinity or is not a number, the results of frexp() are undefined.  
+
+    If the input <x> is a vector, this operation is performed in a
+    component-wise manner; the value returned by the function and the value
+    written to <exp> are vectors with the same number of components as <x>.
+
+    The function ldexp() builds a single-precision floating-point number from
+    each significand component in <x> and the corresponding integral exponent
+    of two in <exp>, returning:
+
+      significand * 2 ^ exponent
+
+    If this product is too large to be represented as a single-precision
+    floating-point value, the result is considered undefined.
+
+    If the input <x> is a vector, this operation is performed in a
+    component-wise manner; the value passed in <exp> and returned by the
+    function are vectors with the same number of components as <x>.
+
+
+    (add support for new integer built-in functions)
+
+    Syntax:
+
+      genIType bitfieldExtract(genIType value, int offset, int bits);
+      genUType bitfieldExtract(genUType value, int offset, int bits);
+
+      genIType bitfieldInsert(genIType base, genIType insert, int offset, 
+                              int bits);
+      genUType bitfieldInsert(genUType base, genUType insert, int offset, 
+                              int bits);
+
+      genIType bitfieldReverse(genIType value);
+      genUType bitfieldReverse(genUType value);
+
+      genIType bitCount(genIType value);
+      genIType bitCount(genUType value);
+
+      genIType findLSB(genIType value);
+      genIType findLSB(genUType value);
+
+      genIType findMSB(genIType value);
+      genIType findMSB(genUType value);
+
+    The function bitfieldExtract() extracts bits <offset> through
+    <offset>+<bits>-1 from each component in <value>, returning them in the
+    least significant bits of corresponding component of the result.  For
+    unsigned data types, the most significant bits of the result will be set
+    to zero.  For signed data types, the most significant bits will be set to
+    the value of bit <offset>+<base>-1.  If <bits> is zero, the result will be
+    zero.  The result will be undefined if <offset> or <bits> is negative, or
+    if the sum of <offset> and <bits> is greater than the number of bits used
+    to store the operand.  Note that for vector versions of bitfieldExtract(),
+    a single pair of <offset> and <bits> values is shared for all components.
+
+    The function bitfieldInsert() inserts the <bits> least significant bits of
+    each component of <insert> into the corresponding component of <base>.
+    The result will have bits numbered <offset> through <offset>+<bits>-1
+    taken from bits 0 through <bits>-1 of <insert>, and all other bits taken
+    directly from the corresponding bits of <base>.  If <bits> is zero, the
+    result will simply be <base>.  The result will be undefined if <offset> or
+    <bits> is negative, or if the sum of <offset> and <bits> is greater than
+    the number of bits used to store the operand.  Note that for vector
+    versions of bitfieldInsert(), a single pair of <offset> and <bits> values
+    is shared for all components.
+
+    The function bitfieldReverse() reverses the bits of <value>.  The bit
+    numbered <n> of the result will be taken from bit (<bits>-1)-<n> of
+    <value>, where <bits> is the total number of bits used to represent
+    <value>.
+
+    The function bitCount() returns the number of one bits in the binary
+    representation of <value>.
+
+    The function findLSB() returns the bit number of the least significant one
+    bit in the binary representation of <value>.  If <value> is zero, -1 will
+    be returned.
+
+    The function findMSB() returns the bit number of the most significant bit
+    in the binary representation of <value>.  For positive integers, the
+    result will be the bit number of the most significant one bit.  For
+    negative integers, the result will be the bit number of the most
+    significant zero bit.  For a <value> of zero or negative one, -1 will be
+    returned.
+
+
+    (support for unsigned integer add/subtract with carry-out)
+
+    Syntax:
+
+      genUType uaddCarry(genUType x, genUType y, out genUType carry);
+      genUType usubBorrow(genUType x, genUType y, out genUType borrow);
+
+    The function uaddCarry() adds 32-bit unsigned integers or vectors <x> and
+    <y>, returning the sum modulo 2^32.  The value <carry> is set to zero if
+    the sum was less than 2^32, or one otherwise.
+
+    The function usubBorrow() subtracts the 32-bit unsigned integer or vector
+    <y> from <x>, returning the difference if non-negative or 2^32 plus the
+    difference, otherwise.  The value <borrow> is set to zero if x >= y, or
+    one otherwise.
+
+
+    (support for signed and unsigned multiplies, with 32-bit inputs and a
+     64-bit result spanning two 32-bit outputs)
+
+    Syntax:
+
+      void umulExtended(genUType x, genUType y, out genUType msb, 
+                        out genUType lsb);
+      void imulExtended(genIType x, genIType y, out genIType msb,
+                        out genIType lsb);
+
+    The functions umulExtended() and imulExtended() multiply 32-bit unsigned
+    or signed integers or vectors <x> and <y>, producing a 64-bit result.  The
+    32 least significant bits are returned in <lsb>; the 32 most significant
+    bits are returned in <msb>.
+
+
+GLX Protocol
+
+    None.
+
+Dependencies on ARB_gpu_shader_fp64
+
+    This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
+    of implicit conversions supported in the OpenGL Shading Language.  If more
+    than one of these extensions is supported, an expression of one type may
+    be converted to another type if that conversion is allowed by any of these
+    specifications.
+
+    If ARB_gpu_shader_fp64 or a similar extension introducing new data types
+    is not supported, the function overloading rule in the GLSL specification
+    preferring promotion an input parameters to smaller type to a larger type
+    is never applicable, as all data types are of the same size.  That rule
+    and the example referring to "double" should be removed.
+
+
+Dependencies on NV_gpu_shader5
+
+    This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
+    of implicit conversions supported in the OpenGL Shading Language.  If more
+    than one of these extensions is supported, an expression of one type may
+    be converted to another type if that conversion is allowed by any of these
+    specifications.
+
+    If NV_gpu_shader5 is supported, integer data types are supported with four
+    different precisions (8-, 16, 32-, and 64-bit) and floating-point data
+    types are supported with three different precisions (16-, 32-, and
+    64-bit).  The extension adds the following rule for output parameters,
+    which is similar to the one present in this extension for input
+    parameters:
+
+       5. If the formal parameters in both matches are output parameters, a
+          conversion from a type with a larger number of bits per component is
+          better than a conversion from a type with a smaller number of bits
+          per component.  For example, a conversion from an "int16_t" formal
+          parameter type to "int"  is better than one from an "int8_t" formal
+          parameter type to "int".
+
+    Such a rule is not provided in this extension because there is no
+    combination of types in this extension and ARB_gpu_shader_fp64 where this
+    rule has any effect.
+
+
+Errors
+
+    None
+
+
+New State
+
+    None
+
+New Implementation Dependent State
+
+    None
+
+Issues
+
+    (1) What should this extension be called?
+
+      UNRESOLVED.  This extension borrows from GL_ARB_gpu_shader5, so creating
+      some sort of a play on that name would be viable.  However, nothing in
+      this extension should require SM5 hardware, so such a name would be a
+      little misleading and weird.
+
+      Since the primary purpose is to add integer related functions from
+      GL_ARB_gpu_shader5, call this extension GL_MESA_shader_integer_functions
+      for now.
+
+    (2) Why is some of the formatting in this extension weird?
+
+      RESOLVED: This extension is formatted to minimize the differences (as
+      reported by 'diff --side-by-side -W180') with the GL_ARB_gpu_shader5
+      specification.
+
+    (3) Should ldexp and frexp be included?
+
+      RESOLVED: Yes.  Few GPUs have native instructions to implement these
+      functions.  These are generally implemented using existing GLSL built-in
+      functions and the other functions provided by this extension.
+
+    (4) Should umulExtended and imulExtended be included?
+
+      RESOLVED: Yes.  These functions should be implementable on any GPU that
+      can support the rest of this extension, but the implementation may be
+      complex.  The implementation on a GPU that only supports 32bit x 32bit =
+      32bit multiplication would be quite expensive.  However, many GPUs
+      (including OpenGL 4.0 GPUs that already support this function) have a
+      32bit x 16bit = 48bit multiplier.  The implementation there is only
+      trivially more expensive than regular 32bit multiplication.
+
+    (5) Should the pack and unpack functions be included?
+
+      RESOLVED: No.  These functions are already available via
+      GL_ARB_shading_language_packing.
+
+    (6) Should the "BitsTo" functions be included?
+
+      RESOLVED: No.  These functions are already available via
+      GL_ARB_shader_bit_encoding.
+
+Revision History
+
+    Rev.      Date     Author    Changes
+    ----  -----------  --------  -----------------------------------------
+     2     7-Jul-2016  idr       Fix typo in #extension line
+     1    20-Jun-2016  idr       Initial version based on GL_ARB_gpu_shader5.
diff --git a/lib/mesa/docs/specs/OLD/EGL_MESA_screen_surface.txt b/lib/mesa/docs/specs/OLD/EGL_MESA_screen_surface.txt
new file mode 100644
index 000000000..698a24057
--- /dev/null
+++ b/lib/mesa/docs/specs/OLD/EGL_MESA_screen_surface.txt
@@ -0,0 +1,564 @@
+Name
+
+    MESA_screen_surface
+
+Name Strings
+
+    EGL_MESA_screen_surface
+
+Contact
+
+    Brian Paul
+
+    To discuss, join the dri-egl@lists.freedesktop.org list.
+
+Status
+
+    Obsolete.
+
+Version
+
+    11 (27 January 2006)
+
+Number
+
+    TBD
+
+Dependencies
+
+    EGL 1.0 or later.
+
+Overview
+
+    EGL 1.1 supports three types of drawing surfaces:
+      * Window surfaces
+      * Pixmap surfaces
+      * Pbuffer surfaces
+    This extension defines a fourth type of drawing surface:
+      * Screen surface
+
+    A screen surface is a surface for which the (front) color buffer can
+    be directly displayed (i.e. scanned out) on a monitor (such as a flat
+    panel or CRT).  In particular the color buffer memory will be allocated
+    at a location in VRAM (and in a suitable format) which can be displayed
+    by the graphics hardware.
+
+    Note that the width and height of the screen surface need not exactly
+    match the monitor's current resolution.  For example, while the monitor
+    may be configured to to show 1024x768 pixels, the associated screen
+    surface may be larger, such as 1200x1000.  The "screen origin" attribute
+    will specify which region of the screen surface which is visible on the
+    monitor.  The screen surface can be scrolled by changing this origin.
+
+    This extension also defines functions for controlling the monitor's
+    display mode (width, height, refresh rate, etc), and specifing which
+    screen surface is to be displayed on a monitor.
+
+    The new EGLModeMESA type and related functions are very similar to the
+    EGLConfig type and related functions.  The user may get a list of
+    supported modes for a screen and specify the mode to be used when
+    displaying a screen surface.
+
+
+Issues
+
+    1. Should EGL_INTERLACE be a supported mode attribute?
+
+       Arguments against:
+
+           No, this should be provided by another extension which would
+           also provide the mechanisms needed to play back interlaced video
+           material correctly on hardware that supports it.
+           This extension should prefer non-interlaced modes. [M. Danzer]
+
+       Arguments for:
+
+           An interlaced display can be of use without considering video
+           material.  Being able to query whether a screen is operating in
+           interlaced mode can be used by applications to control their
+           drawing.  For example: avoid drawing 1-pixel-wide horizontal lines
+           if screen is interlaced. [B. Paul]
+
+       Resolution: Defer for future extension?
+
+
+    2. Should EGL_REFRESH_RATE be a supported mode attribute?
+
+       Arguments for:
+
+           Yes, it's been shown that applications and/or users need to select
+           modes by this.  [M. Danzer]
+
+           Many examples have been given in which it's desirable to let the
+           user choose from a variety of refresh rates without having to
+           restart/reconfigure.  [B. Paul]
+
+       Arguments against:
+
+           TBD.
+
+       Resolution: Yes.
+
+
+    3. Exactly how should the list of modes returned by eglChooseConfigMESA
+       be sorted?
+
+       Current method is described in the text below.  Subject to change.
+
+       Alternately, leave the sorting order undefined so that each
+       implementation can return the modes in order of "most desirable"
+       to "least desirable" which may depend on the display technology
+       (CRT vs LCD, etc) or other factors.
+
+
+    4. How should screen blanking be supported?  Note that a screen can be
+       disabled or turned off by calling eglShowSurface(dpy, scrn,
+       EGL_NO_SURFACE, EGL_NO_MODE_MESA).  But what about power-save mode?
+
+       I would defer this to other extensions that depend on this one.
+       I can imagine people wanting different semantics not just in
+       relation to the power management API being exposed (DPMS or whatever)
+       but also relating to what events can trigger EGL_CONTEXT_LOST.  Also
+       I'm not sure whether power management commands are properly operations
+       on the Display or on a screen surface. [A. Jackson]
+
+
+    5. Should the EGL_PHYSICAL_SIZE_EGL query be kept?  The size information
+       isn't always reliable (consider video projectors) but can still be
+       used to determine the pixel aspect ratio.
+
+       Resolution: Omit.  The EGL 1.2 specification includes queries for
+       the display resolution and pixel aspect ratio.
+
+
+    6. Should detailed mode timing information be exposed by this API?
+
+       Probably not.  Instead, offer that information in a layered extension.
+
+
+    7. How should the notion of a screen's "native" mode be expressed?
+       For example, LCD panels have a native resolution and refresh rate
+       that looks best but other sub-optimal resolutions may be supported.
+
+       The mode attribute EGL_OPTIMAL_MESA will be set for modes which
+       best match the screen.  [M. Danzer]
+
+
+    8. Should eglQueryModeStringMESA() be included?  This function returns
+       a human-readable string which corresponds to an EGLMode.
+
+       Arguments for:
+
+           A mode name such as "HDTV-720P" might mean more to users than
+           "1280x720@60Hz" if the later were generated via code.
+
+       Arguments against:
+
+           There's no standard syntax for the strings.  May cause more
+           trouble than it's worth.
+
+       Postpone for future extension. [A. Jackson]
+
+       Latest discussion leaning toward omitting this function.
+
+
+    9. Should we use "Get" or "Query" for functions which return state?
+       The EGL 1.x specification doesn't seem to be totally consistent
+       in this regard, but "Query" is used more often.
+
+       Use "Get" for mode-related queries (as for EGLConfigs) but "Query"
+       for everything else.
+
+
+    10. What should be the default size for screen surfaces?
+
+        For Pbuffer surfaces the default width and height are zero.
+        We'll do the same for screen surfaces.  Since there's no function
+        to resize surfaces it's useless to have a 0x0 screen, but this isn't
+        a situation that'll normally be encountered.
+
+
+    11. Should there be a function for resizing a screen surface?
+
+        Suppose one wants to change the screen's size in the EGL application.
+        Also suppose there's a hardware restriction such that only one screen
+        surface can exist at a time (either for lack of memory or because of
+        memory layout restrictions).
+
+        The basic idea is that the currently displayed screen surface must
+        be deallocated before a new one can be created.  Perhaps a resize
+        function would work better?
+
+
+    12. How should sub-pixel LCD color information be made available?
+        What about the display's gamma value?
+
+        Perhaps expose as additional read-only mode attributes.
+
+        Perhaps postpone for a layered extension.
+
+
+    13. What happens if the user attempts to delete a screen surface that
+        is currently being shown?
+
+        Spec currently says that's illegal and that an error (TBD) will be
+        generated.
+
+
+    14. What if the physical screen size can't be determined?  Should
+        a query of EGL_PHYSICAL_SIZE_MESA return [0,0]?
+
+        Obsolete: EGL_PHYSICAL_SIZE_MESA not used.
+
+
+    15. Suppose the device's number of RAMDACs is different from the
+        number of output ports.  For example, a graphics card with
+        two RAMDACs but three ports (VGA, DVI, TV).
+
+        Address this in a follow-on extension. [Matthias Hopf]
+
+
+    16. How should we deal with on-the-fly device changes?  For example,
+        the monitor being unplugged and replaced by another with different
+        characteristics?
+
+        A HAL event could be received via DBUS in the application [J. Smirl,
+        A. Jackson].
+
+        Should there be an EGL mechanism for detecting this?  Maybe an
+        EGL_SCREEN_LOST error (similar to EGL_CONTEXT_LOST) can be recorded
+        when there's a screen change.  At least then the application can
+        poll to detect this situation.
+
+        Maybe leave that to a future extension.
+
+        See also the EGL_SCREEN_COUNT_MESA query.
+
+
+    17. What if pixel-accurate panning is not supported (see
+        eglScreenPositionMESA)? [M. Danzer]
+
+        Is this a common problem?  Can we ignore it for now?
+
+
+    18. Should eglShowSurfaceMESA be renamed to eglShowScreenSurfaceMESA?
+
+        Probably.
+
+
+
+New Procedures and Functions
+
+    EGLBoolean eglChooseModeMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                 const EGLint *attrib_list,
+                                 EGLModeMESA *modes, EGLint modes_size,
+                                 EGLint *num_modes)
+
+    EGLBoolean eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                               EGLModeMESA *modes, EGLint modes_size,
+                               EGLint *num_modes)
+
+    EGLBoolean eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA mode,
+                                    EGLint attrib, EGLint *value)
+
+
+    EGLBoolean eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA *screens,
+                                 EGLint screens_size, EGLint *num_screens)
+
+    EGLSurface eglCreateScreenSurfaceMESA(EGLDisplay dpy, EGLConfig config,
+                                          const EGLint *attrib_list)
+
+    EGLBoolean eglShowSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                  EGLSurface surface, EGLModeMESA mode)
+
+    EGLBoolean eglScreenPositionMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                     EGLint x, EGLint y)
+
+
+    EGLBoolean eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                  EGLint attrib, EGLint *value);
+
+    EGLBoolean eglQueryScreenSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                         EGLSurface *surface)
+
+    EGLBoolean eglQueryScreenModeMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                      EGLModeMESA *mode)
+
+    const char *eglQueryModeStringMESA(EGLDisplay dpy, EGLMode mode);
+
+
+New Types
+
+    EGLModeMESA
+    EGLScreenMESA
+
+New Tokens
+
+    New error codes:
+
+    EGL_BAD_SCREEN_MESA        
+    EGL_BAD_MODE_MESA          
+
+    Screen-related tokens:
+
+    EGL_SCREEN_COUNT_MESA      
+    EGL_SCREEN_POSITION_MESA   
+    EGL_SCREEN_BIT_MESA        
+    EGL_SCREEN_POSITION_GRANULARITY_MESA
+
+    Mode-related tokens:
+
+    EGL_MODE_ID_MESA           
+    EGL_REFRESH_RATE_MESA      
+    EGL_INTERLACED_MESA
+    EGL_OPTIMAL_MESA
+    EGL_NO_MODE_MESA
+
+
+Additions to Chapter X of the EGL 1.1 Specification
+
+    [XXX this all has to be rewritten to fit into the EGL specification
+    and match the conventions of an EGL extension.  For now, just list
+    all the functions with brief descriptions.]
+
+
+    EGLBoolean eglChooseModeMESA(EGLDisplay dpy, const EGLScreenMESA screen,
+                                 EGLint *attrib_list, EGLModeMESA *modes,
+                                 EGLint modes_size, EGLint *num_modes)
+
+    Like eglChooseConfig, returns a list of EGLModes which match the given
+    attribute list.  This does not set the screen's current display mode.
+    The attribute list is a list of token/value pairs terminated with
+    EGL_NONE.  Supported attributes include:
+
+        Name                   Description
+        ---------------------  ---------------------------------------------
+        EGL_WIDTH              Mode width (resolution)
+        EGL_HEIGHT             Mode height (resolution)
+        EGL_REFRESH_RATE_MESA  The mode's refresh rate, multiplied by 1000
+        EGL_INTERLACED_MESA    1 indicates an interlaced mode, 0 otherwise
+        EGL_OPTIMAL_MESA       Set if the most is especially optimal for the
+                               screen (ex. for particular LCD resolutions)
+
+    Any other token will generate the error EGL_BAD_ATTRIBUTE.
+
+    The list of modes returned by eglChooseModeMESA will be sorted
+    according to the following criteria.  See the discussion of table 3.3
+    in the EGL specification for more information.
+
+                                            Selection   Sort   Sort
+        Attribute            Default        Criteria    Order  Priority
+        -------------------- -------------- ----------- ------ --------
+        EGL_OPTIMAL_MESA     EGL_DONT_CARE  Exact       1,0      1
+        EGL_INTERLACED_MESA  EGL_DONT_CARE  Exact       0,1      2
+        EGL_REFRESH_RATE     EGL_DONT_CARE  AtLeast     Larger   3
+        EGL_WIDTH            EGL_DONT_CARE  AtLeast     Larger   4
+        EGL_HEIGHT           EGL_DONT_CARE  AtLeast     Larger   5
+        EGL_MODE_ID_MESA     EGL_DONT_CARE  Exact       Smaller  6
+
+
+    EGLBoolean eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                               EGLModeMESA *modes, EGLint modes_size,
+                               EGLint *num_modes)
+
+    Like eglGetConfigs, returns a list of all modes supported by the
+    given screen.  The returned modes will be sorted in the same manner
+    as for eglChooseModeMESA().
+
+
+
+    EGLBoolean eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA mode,
+                                    EGLint attrib, EGLint *value)
+
+    Used to query mode attributes.  The following attributes are supported:
+
+        Name                   Return value description
+        ---------------------  ----------------------------------------------
+        EGL_OPTIMAL_MESA       1 indicates an optimal mode, 0 otherwise
+        EGL_INTERLACED_MESA    1 indicates an interlaced mode, 0 otherwise
+        EGL_REFRESH_RATE_MESA  The mode's refresh rate, multiplied by 1000
+        EGL_WIDTH              Mode width (resolution)
+        EGL_HEIGHT             Mode height (resolution)
+        EGL_MODE_ID_MESA       A unique small integer identifier for the mode
+
+    Any other token will generate the error EGL_BAD_ATTRIBUTE.
+
+
+
+    EGLBoolean eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA *screens,
+                                 EGLint screens_size, EGLint *num_screens)
+
+    This function returns an array of all available screen handles.
+    <screens_size> is the maximum number of screens to return in the
+    <screens> array.  <num_screens> will return the number of screen handles
+    placed in the array, even if <screens> is NULL.
+
+    The number of screens and the availability of each may change over
+    time (hot-plugging).  Screen handles will not be reused.  When a
+    screen handle becomes invalid, function calls which reference an
+    invalid handle will generate EGL_BAD_SCREEN_MESA.
+
+    The first screen handle returned will be considered to be the primary
+    one.
+
+
+
+    EGLSurface eglCreateScreenSurfaceMESA(EGLDisplay dpy, EGLConfig config,
+                                          const EGLint *attrib_list)
+
+    Create a surface that can be displayed on a screen.  <attrib_list> is
+    an array of token/value pairs terminated with EGL_NONE.  Valid tokens
+    include:
+
+        Name              Description
+        ----------------  --------------------------------
+        EGL_WIDTH         desired surface width in pixels
+        EGL_HEIGHT        desired surface height in pixels
+
+    Any other token will generate the error EGL_BAD_ATTRIBUTE.
+    The default width and height are zero.
+
+    
+
+    EGLBoolean eglShowSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                  EGLSurface surface, EGLModeMESA mode)
+
+    This function causes a screen to show the given surface (or more
+    precisely, the surface's front color buffer) with the given mode.
+
+    If the surface is in any way incompatible with the mode, the error
+    EGL_BAD_MATCH will be generated, EGL_FALSE will be returned, and the
+    previous screen state will remain in effect.  This might occur when
+    the bandwidth of the video-out subsystem is exceeded, or if the mode
+    specifies a width or height that's greater than the width or height
+    of the surface.
+
+    To disable a screen, the values EGL_NO_SURFACE and EGL_NO_MODE_MESA
+    be passed as the <surface> and <mode> parameters.
+
+    The values of EGL_SCREEN_POSITION_MESA are clamped to the new valid
+    range computed from the screen size and surface size.  If the new
+    surface is EGL_NO_SURFACE, EGL_SCREEN_POSITION_MESA is set to [0, 0].
+
+
+    Attempting to delete a screen surface which is currently being
+    displayed will result in the error EGL_BAD_ACCESS being generated.
+
+
+
+    EGLBoolean eglScreenPositionMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                     EGLint x, EGLint y)
+
+    Specifies the origin of the screen's view into the surface, if the
+    surface is larger than the screen.  Valid values for x and y are
+    [0, surfaceWidth - screenWidth] and [0, surfaceHeight - screenHeight],
+    respectively.
+
+    The x and y values are also constrained to be integer multiples of the
+    EGL_SCREEN_POSITION_GRANULARITY_MESA values.
+
+
+
+
+    EGLBoolean eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                  EGLint attrib, EGLint *value);
+
+    Used to query screen attributes.  <attrib> may be one of the following:
+
+        Name                      Return value description
+        ------------------------  ---------------------------------------------
+        EGL_SCREEN_POSITION_MESA  x, y position of the screen's origin with
+                                  respect to the surface.  If no surface is
+                                  attached to the screen, [0, 0] is returned.
+        EGL_SCREEN_POSITION_GRANULARITY_MESA
+                                  Returns the granularity, in pixels, for
+                                  which the screen position is constrained.
+
+    Any other token will generate the error EGL_BAD_ATTRIBUTE.
+
+
+
+
+    EGLBoolean eglQueryScreenSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                         EGLSurface *surface)
+
+    Returns the surface currently displayed on the given screen.  <surface>
+    may be EGL_NO_SURFACE if the screen isn't currently showing any surface.
+
+
+
+
+    EGLBoolean eglQueryScreenModeMESA(EGLDisplay dpy, EGLScreenMESA screen,
+                                      EGLModeMESA *mode)
+
+    Returns the given screen's current display mode.  The mode may be
+    EGL_NO_MODE_MESA if the screen is currently disabled.
+
+
+
+    const char *eglQueryModeStringMESA(EGLDisplay dpy, EGLModeMESA mode);
+
+    Returns a human-readable string for the given mode.  The string is a
+    zero-terminated C string which the user should not attempt to free.
+    There is no standard syntax for mode strings.  Applications should
+    not directly rely on mode strings.
+
+
+
+Version History
+
+    1. 15 March 2005 - BrianP
+        Initial version
+
+    2. 16 March 2005 - BrianP
+        Removed EGL_DEPTH_MESA
+        Added EGL_PHYSICAL_WIDTH_MESA, EGL_PHYSICAL_HEIGHT_MESA queries
+        Added EGL_OPTIMAL_MESA for width/height/refresh rate selection
+        Added possible eglQueryModeStringMESA() function
+        More details of the new functions explained.
+
+    3. 18 March 2005 - BrianP
+        Added screen_number to eglChooseModeMESA().
+        Fix off by one mistake in value range for ORIGIN attributes
+        Added Issues section
+
+    4. 21 March 2005 - BrianP
+        Removed eglScreenAttribsMESA().
+        Added eglScreenPositionMESA() to set screen origin.
+        Replaced EGL_SCREEN_X/Y_OFFSET_MESA with EGL_SCREEN_POSITION_MESA.
+        Replaced EGL_PHYSICAL_WIDTH/HEIGHT_MESA with EGL_PHYSICAL_SIZE_MESA.
+        Use EGL_OPTIMAL_MESA as a new mode attribute. (Michel Danzer)
+        Added a few more issues.
+
+    5. 6 April 2005 - BrianP
+        More language for eglGetModeStringMESA().
+        Added issues 10, 11, 12, 13, 14.
+        Updated issue 3 discussion about mode sorting.
+
+    6. 22 April 2005 - BrianP
+        Fixed "LDC" typo.
+        Added issues 15, 16.
+        Changed dependency on EGL 1.1 to EGL 1.0
+        s/EGL_NUM_SCREENS_MESA/EGL_SCREEN_COUNT_MESA/
+        Added eglQueryDisplayMESA() to New Functions section.
+        Clarified language for the EGL_SCREEN_COUNT_MESA query.
+
+    7. 29 April 2005 - BrianP
+        Added EGLScreenMESA type and eglGetScreensMESA() function. [J. Smirl].
+        Replaced EGLint screen_number parameters with EGLScreenMESA screen.
+        Added issue 17 (pixel-accurate panning)
+
+    8. 2 May 2005 - BrianP
+        Removed eglQueryDisplayMESA.
+        Fixed a few more EGLint -> EGLScreenMESA changes.
+
+    9. 20 May 2005 - BrianP
+        Fixed a few typos.
+        Updated some open issues text.
+
+    10. 10 August 2005 - BrianP
+        Added EGL_SCREEN_POSITION_GRANULARITY_MESA.
+
+    11. 27 January 2006 - BrianP
+        EGL_PHYSICAL_SIZE_MESA removed since EGL 1.2 has a similar feature.
+
diff --git a/lib/mesa/docs/specs/enums.txt b/lib/mesa/docs/specs/enums.txt
index b37768e20..1caa28459 100644
--- a/lib/mesa/docs/specs/enums.txt
+++ b/lib/mesa/docs/specs/enums.txt
@@ -1,10 +1,18 @@
+The definitive source for enum values and reserved ranges are the XML files in
+the Khronos registry:
 
-See the OpenGL ARB enum registry at http://www.opengl.org/registry/api/enum.spec
+    https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/egl.xml
+    https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml
+    https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/glx.xml
+    https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/wgl.xml
 
-Blocks allocated to Mesa:
+GL blocks allocated to Mesa:
        0x8750-0x875F
        0x8BB0-0x8BBF
 
+EGL blocks allocated to Mesa:
+       0x31D0-0x31DF
+       0x3290-0x329F
 
 GL_MESA_packed_depth_stencil
 	GL_DEPTH_STENCIL_MESA            0x8750
@@ -13,7 +21,7 @@ GL_MESA_packed_depth_stencil
 	GL_UNSIGNED_SHORT_15_1_MESA      0x8753
 	GL_UNSIGNED_SHORT_1_15_REV_MESA  0x8754
 
-GL_MESA_trace.spec:
+GL_MESA_trace:
 	GL_TRACE_ALL_BITS_MESA           0xFFFF
 	GL_TRACE_OPERATIONS_BIT_MESA     0x0001
 	GL_TRACE_PRIMITIVES_BIT_MESA     0x0002
@@ -24,12 +32,12 @@ GL_MESA_trace.spec:
 	GL_TRACE_MASK_MESA               0x8755
 	GL_TRACE_NAME_MESA               0x8756
 
-MESA_ycbcr_texture.spec:
+GL_MESA_ycbcr_texture:
 	GL_YCBCR_MESA                    0x8757
 	GL_UNSIGNED_SHORT_8_8_MESA       0x85BA /* same as Apple's */
 	GL_UNSIGNED_SHORT_8_8_REV_MESA   0x85BB /* same as Apple's */
 
-GL_MESA_pack_invert.spec
+GL_MESA_pack_invert:
 	GL_PACK_INVERT_MESA              0x8758
 
 GL_MESA_shader_debug.spec: (obsolete)
@@ -37,7 +45,7 @@ GL_MESA_shader_debug.spec: (obsolete)
         GL_DEBUG_PRINT_MESA              0x875A
         GL_DEBUG_ASSERT_MESA             0x875B
 
-GL_MESA_program_debug.spec: (obsolete)
+GL_MESA_program_debug: (obsolete)
 	GL_FRAGMENT_PROGRAM_CALLBACK_MESA      0x????
 	GL_VERTEX_PROGRAM_CALLBACK_MESA        0x????
 	GL_FRAGMENT_PROGRAM_POSITION_MESA      0x????
@@ -55,3 +63,24 @@ GL_MESAX_texture_stack:
 	GL_TEXTURE_1D_STACK_BINDING_MESAX    0x875D
 	GL_TEXTURE_2D_STACK_BINDING_MESAX    0x875E
 
+EGL_MESA_drm_image
+        EGL_DRM_BUFFER_FORMAT_MESA		0x31D0
+        EGL_DRM_BUFFER_USE_MESA			0x31D1
+        EGL_DRM_BUFFER_FORMAT_ARGB32_MESA	0x31D2
+        EGL_DRM_BUFFER_MESA			0x31D3
+        EGL_DRM_BUFFER_STRIDE_MESA		0x31D4
+
+EGL_MESA_platform_gbm
+        EGL_PLATFORM_GBM_MESA                   0x31D7
+
+EGL_MESA_platform_surfaceless
+        EGL_PLATFORM_SURFACELESS_MESA           0x31DD
+
+EGL_WL_bind_wayland_display
+        EGL_TEXTURE_FORMAT                      0x3080
+        EGL_WAYLAND_BUFFER_WL                   0x31D5
+        EGL_WAYLAND_PLANE_WL                    0x31D6
+        EGL_TEXTURE_Y_U_V_WL                    0x31D7
+        EGL_TEXTURE_Y_UV_WL                     0x31D8
+        EGL_TEXTURE_Y_XUXV_WL                   0x31D9
+        EGL_WAYLAND_Y_INVERTED_WL               0x31DB