docs: include specs into the generated docs
authorErik Faye-Lund <erik.faye-lund@collabora.com>
Sat, 18 Apr 2020 09:54:11 +0000 (11:54 +0200)
committerMarge Bot <eric+marge@anholt.net>
Sat, 13 Jun 2020 10:42:01 +0000 (10:42 +0000)
Unfortunately, it doesn't seem like there's a way to have sphinx copy
this without moving the files, becasue html_extra_path doesn't copy the
directory itself when given a directory, only files inside and
subdirectories.

Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4630>

73 files changed:
docs/_extra/specs/EGL_MESA_device_software.txt [new file with mode: 0644]
docs/_extra/specs/EGL_MESA_drm_image_formats.txt [new file with mode: 0644]
docs/_extra/specs/EGL_MESA_platform_surfaceless.txt [new file with mode: 0644]
docs/_extra/specs/EGL_MESA_query_driver.txt [new file with mode: 0644]
docs/_extra/specs/EXT_shader_integer_mix.spec [new file with mode: 0644]
docs/_extra/specs/EXT_shader_samples_identical.txt [new file with mode: 0644]
docs/_extra/specs/INTEL_shader_atomic_float_minmax.txt [new file with mode: 0644]
docs/_extra/specs/MESA_configless_context.spec [new file with mode: 0644]
docs/_extra/specs/MESA_copy_sub_buffer.spec [new file with mode: 0644]
docs/_extra/specs/MESA_drm_image.spec [new file with mode: 0644]
docs/_extra/specs/MESA_framebuffer_flip_y.txt [new file with mode: 0644]
docs/_extra/specs/MESA_image_dma_buf_export.txt [new file with mode: 0644]
docs/_extra/specs/MESA_multithread_makecurrent.spec [new file with mode: 0644]
docs/_extra/specs/MESA_pack_invert.spec [new file with mode: 0644]
docs/_extra/specs/MESA_pixmap_colormap.spec [new file with mode: 0644]
docs/_extra/specs/MESA_query_renderer.spec [new file with mode: 0644]
docs/_extra/specs/MESA_release_buffers.spec [new file with mode: 0644]
docs/_extra/specs/MESA_shader_debug.spec [new file with mode: 0644]
docs/_extra/specs/MESA_shader_integer_functions.txt [new file with mode: 0644]
docs/_extra/specs/MESA_swap_control.spec [new file with mode: 0644]
docs/_extra/specs/MESA_swap_frame_usage.spec [new file with mode: 0644]
docs/_extra/specs/MESA_texture_array.spec [new file with mode: 0644]
docs/_extra/specs/MESA_texture_signed_rgba.spec [new file with mode: 0644]
docs/_extra/specs/MESA_window_pos.spec [new file with mode: 0644]
docs/_extra/specs/MESA_ycbcr_texture.spec [new file with mode: 0644]
docs/_extra/specs/OLD/EGL_MESA_screen_surface.txt [new file with mode: 0644]
docs/_extra/specs/OLD/MESA_agp_offset.spec [new file with mode: 0644]
docs/_extra/specs/OLD/MESA_packed_depth_stencil.spec [new file with mode: 0644]
docs/_extra/specs/OLD/MESA_program_debug.spec [new file with mode: 0644]
docs/_extra/specs/OLD/MESA_resize_buffers.spec [new file with mode: 0644]
docs/_extra/specs/OLD/MESA_set_3dfx_mode.spec [new file with mode: 0644]
docs/_extra/specs/OLD/MESA_sprite_point.spec [new file with mode: 0644]
docs/_extra/specs/OLD/MESA_trace.spec [new file with mode: 0644]
docs/_extra/specs/WL_bind_wayland_display.spec [new file with mode: 0644]
docs/_extra/specs/WL_create_wayland_buffer_from_image.spec [new file with mode: 0644]
docs/_extra/specs/enums.txt [new file with mode: 0644]
docs/conf.py
docs/specs/EGL_MESA_device_software.txt [deleted file]
docs/specs/EGL_MESA_drm_image_formats.txt [deleted file]
docs/specs/EGL_MESA_platform_surfaceless.txt [deleted file]
docs/specs/EGL_MESA_query_driver.txt [deleted file]
docs/specs/EXT_shader_integer_mix.spec [deleted file]
docs/specs/EXT_shader_samples_identical.txt [deleted file]
docs/specs/INTEL_shader_atomic_float_minmax.txt [deleted file]
docs/specs/MESA_configless_context.spec [deleted file]
docs/specs/MESA_copy_sub_buffer.spec [deleted file]
docs/specs/MESA_drm_image.spec [deleted file]
docs/specs/MESA_framebuffer_flip_y.txt [deleted file]
docs/specs/MESA_image_dma_buf_export.txt [deleted file]
docs/specs/MESA_multithread_makecurrent.spec [deleted file]
docs/specs/MESA_pack_invert.spec [deleted file]
docs/specs/MESA_pixmap_colormap.spec [deleted file]
docs/specs/MESA_query_renderer.spec [deleted file]
docs/specs/MESA_release_buffers.spec [deleted file]
docs/specs/MESA_shader_debug.spec [deleted file]
docs/specs/MESA_shader_integer_functions.txt [deleted file]
docs/specs/MESA_swap_control.spec [deleted file]
docs/specs/MESA_swap_frame_usage.spec [deleted file]
docs/specs/MESA_texture_array.spec [deleted file]
docs/specs/MESA_texture_signed_rgba.spec [deleted file]
docs/specs/MESA_window_pos.spec [deleted file]
docs/specs/MESA_ycbcr_texture.spec [deleted file]
docs/specs/OLD/EGL_MESA_screen_surface.txt [deleted file]
docs/specs/OLD/MESA_agp_offset.spec [deleted file]
docs/specs/OLD/MESA_packed_depth_stencil.spec [deleted file]
docs/specs/OLD/MESA_program_debug.spec [deleted file]
docs/specs/OLD/MESA_resize_buffers.spec [deleted file]
docs/specs/OLD/MESA_set_3dfx_mode.spec [deleted file]
docs/specs/OLD/MESA_sprite_point.spec [deleted file]
docs/specs/OLD/MESA_trace.spec [deleted file]
docs/specs/WL_bind_wayland_display.spec [deleted file]
docs/specs/WL_create_wayland_buffer_from_image.spec [deleted file]
docs/specs/enums.txt [deleted file]

diff --git a/docs/_extra/specs/EGL_MESA_device_software.txt b/docs/_extra/specs/EGL_MESA_device_software.txt
new file mode 100644 (file)
index 0000000..78b3e1d
--- /dev/null
@@ -0,0 +1,82 @@
+Name
+
+    MESA_device_software
+
+Name Strings
+
+    EGL_MESA_device_software
+
+Contributors
+
+    Adam Jackson <ajax@redhat.com>
+    Emil Velikov <emil.velikov@collabora.com>
+
+Contacts
+
+    Adam Jackson <ajax@redhat.com>
+
+Status
+
+    DRAFT
+
+Version
+
+    Version 2, 2018-10-03
+
+Number
+
+    EGL Extension #TODO
+
+Extension Type
+
+    EGL device extension
+
+Dependencies
+
+    Requires EGL_EXT_device_query.
+
+    This extension is written against the EGL 1.5 Specification.
+
+Overview
+
+    This extension defines a software EGL "device". The device is not backed by
+    any actual device node and simply renders into client memory.
+
+    By defining this as an extension, EGL_EXT_device_enumeration is able to
+    sanely enumerate a software device.
+
+New Types
+
+    None
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    None
+
+Additions to the EGL Specification
+
+    None
+
+New Behavior
+
+    The device list produced by eglQueryDevicesEXT will include a software
+    device. This can be distinguished from other device classes in the usual
+    way by calling eglQueryDeviceStringEXT(EGL_EXTENSIONS) and matching this
+    extension's string in the result.
+
+Issues
+
+    None
+
+Revision History
+
+    Version 2, 2018-10-03 (Emil Velikov)
+        - Drop "fallback" from "software fallback device"
+        - Add Emil Velikov as contributor
+
+    Version 1, 2017-07-06 (Adam Jackson)
+        - Initial version
diff --git a/docs/_extra/specs/EGL_MESA_drm_image_formats.txt b/docs/_extra/specs/EGL_MESA_drm_image_formats.txt
new file mode 100644 (file)
index 0000000..77fbe9d
--- /dev/null
@@ -0,0 +1,98 @@
+Name
+
+    MESA_drm_image_formats
+
+Name Strings
+
+    EGL_MESA_drm_image_formats
+
+Contributors
+
+    Nicolai Hähnle <Nicolai.Haehnle@amd.com>
+    Qiang Yu <Qiang.Yu@amd.com>
+
+Contact
+
+    Nicolai Hähnle <Nicolai.Haehnle@amd.com>
+
+Status
+
+    Proposal
+
+Version
+
+    Version 1, January 26, 2017
+
+Number
+
+    EGL Extension #??
+
+Dependencies
+
+    This extension requires the EGL_MESA_drm_image extension.
+
+    This extension is written against the wording of EGL_MESA_drm_image
+    specification.
+
+Overview
+
+    This extension extends the functionality of EGL_MESA_drm_image by adding
+    additional formats required by Glamor for use with DRM buffers.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
+
+        EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA  0x3290
+        EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA     0x3291
+        EGL_DRM_BUFFER_FORMAT_RGB565_MESA       0x3292
+
+Additions to the EGL_MESA_drm_image Specification:
+
+    Remove the sentence "The only format specified ..." from the paragraph
+    describing eglCreateDRMImageMESA and add the following paragraph:
+
+        The formats specified for use with EGL_DRM_BUFFER_FORMAT_MESA are:
+
+      * 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,
+
+      * EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA, where each pixel is a CPU-
+        endian, 32-bit quantity, with alpha in the most significant 2 bits,
+        followed by 10 bits each for red, green, and blue,
+
+      * EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA, where each pixel is a CPU-endian
+        16-bit quantity, with alpha in the most significant bit, followed by
+        5 bits each for red, green, and blue, and
+
+      * EGL_DRM_BUFFER_FORMAT_RGB565_MESA, where each pixel is a CPU-endian
+        16-bit quantity, with red in the 5 most significant bits, followed by
+        6 bits of green and 5 bits of blue.
+
+Issues
+
+    1. Should we expose the full set of channel permutations for the formats,
+       e.g. ABGR2101010, RGBA1010102, and BGRA1010102 in addition to
+       ARGB2101010?
+
+       RESOLVED: No.
+
+       DISCUSSION: The original extension sets a precedent of only exposing one
+       of the possible permutations of 8-bit channel formats. It is also not
+       clear where the additional permutations would be used. For example,
+       Glamor has a fixed mapping from pixmap/screen depth to format that
+       doesn't allow for the other permutations.
+
+Revision History
+
+    Version 1, January, 2017
+        Initial draft (Nicolai Hähnle)
diff --git a/docs/_extra/specs/EGL_MESA_platform_surfaceless.txt b/docs/_extra/specs/EGL_MESA_platform_surfaceless.txt
new file mode 100644 (file)
index 0000000..871ee50
--- /dev/null
@@ -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/docs/_extra/specs/EGL_MESA_query_driver.txt b/docs/_extra/specs/EGL_MESA_query_driver.txt
new file mode 100644 (file)
index 0000000..bf260bd
--- /dev/null
@@ -0,0 +1,95 @@
+Name
+
+    MESA_query_driver
+
+Name Strings
+
+    EGL_MESA_query_driver
+
+Contact
+
+    Rob Clark      <robdclark 'at' gmail.com>
+    Nicolai Hähnle <Nicolai.Haehnle 'at' amd.com>
+
+Contibutors
+
+    Veluri Mithun <velurimithun38 'at' gmail.com>
+
+Status
+
+    Complete
+
+Version
+
+    Version 3, 2019-01-24
+
+Number
+
+    EGL Extension 131
+
+Dependencies
+
+    EGL 1.0 is required.
+
+Overview
+
+    When an application has to query the name of a driver and for
+    obtaining driver's option list (UTF-8 encoded XML) of a driver
+    the below functions are useful.
+
+    XML file formally describes all available options and also
+    includes verbal descriptions in multiple languages. Its main purpose
+    is to be automatically processed by configuration GUIs.
+    The XML shall respect the following DTD:
+
+    <!ELEMENT driinfo      (section*)>
+    <!ELEMENT section      (description+, option+)>
+    <!ELEMENT description  (enum*)>
+    <!ATTLIST description  lang CDATA #REQUIRED
+                           text CDATA #REQUIRED>
+    <!ELEMENT option       (description+)>
+    <!ATTLIST option       name CDATA #REQUIRED
+                           type (bool|enum|int|float) #REQUIRED
+                           default CDATA #REQUIRED
+                           valid CDATA #IMPLIED>
+    <!ELEMENT enum         EMPTY>
+    <!ATTLIST enum         value CDATA #REQUIRED
+                           text CDATA #REQUIRED>
+
+New Procedures and Functions
+
+    char* eglGetDisplayDriverConfig(EGLDisplay dpy);
+    const char* eglGetDisplayDriverName(EGLDisplay dpy);
+
+Description
+
+    By passing EGLDisplay as parameter to `eglGetDisplayDriverName` one can retrieve
+    driverName. Similarly passing EGLDisplay to `eglGetDisplayDriverConfig` we can retrieve
+    driverConfig options of the driver in XML format.
+
+    The string returned by `eglGetDisplayDriverConfig` is heap-allocated and caller
+    is responsible for freeing it.
+
+    EGL_BAD_DISPLAY is generated if `disp` is not an EGL display connection.
+
+    EGL_NOT_INITIALIZED is generated if `disp` has not been initialized.
+
+    If the implementation does not have enough resources to allocate the XML then an
+    EGL_BAD_ALLOC error is generated.
+
+New Tokens
+
+    No new tokens
+
+Issues
+
+    None
+
+
+Revision History
+
+    Version 1, 2018-11-05 - First draft (Veluri Mithun)
+    Version 2, 2019-01-23 - Final version (Veluri Mithun)
+    Version 3, 2019-01-24 - Mark as complete, add Khronos extension
+                            number, fix parameter name in prototypes,
+                            write revision history (Eric Engestrom)
diff --git a/docs/_extra/specs/EXT_shader_integer_mix.spec b/docs/_extra/specs/EXT_shader_integer_mix.spec
new file mode 100644 (file)
index 0000000..92cec64
--- /dev/null
@@ -0,0 +1,138 @@
+Name
+
+    EXT_shader_integer_mix
+
+Name Strings
+
+    GL_EXT_shader_integer_mix
+
+Contact
+
+    Matt Turner (matt.turner 'at' intel.com)
+
+Contributors
+
+    Matt Turner, Intel
+    Ian Romanick, Intel
+
+Status
+
+    Shipping
+
+Version
+
+    Last Modified Date:         09/12/2013
+    Author Revision:            6
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 3.0 or OpenGL ES 3.0 is required. This extension interacts with
+    GL_ARB_ES3_compatibility.
+
+    This extension is written against the OpenGL 4.4 (core) specification
+    and the GLSL 4.40 specification.
+
+Overview
+
+    GLSL 1.30 (and GLSL ES 3.00) expanded the mix() built-in function to
+    operate on a boolean third argument that does not interpolate but
+    selects. This extension extends mix() to select between int, uint,
+    and bool components.
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+
+    None.
+
+Additions to Chapter 8 of the GLSL 4.40 Specification (Built-in Functions)
+
+    Modify Section 8.3, Common Functions
+
+    Additions to the table listing common built-in functions:
+
+      Syntax                       Description
+      ---------------------------  --------------------------------------------------
+      genIType mix(genIType x,     Selects which vector each returned component comes
+                   genIType y,     from. For a component of a that is false, the
+                   genBType a)     corresponding component of x is returned. For a
+      genUType mix(genUType x,     component of a that is true, the corresponding
+                   genUType y,     component of y is returned.
+                   genBType a)
+      genBType mix(genBType x,
+                   genBType y,
+                   genBType a)
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None.
+
+Modifications to The OpenGL Shading Language Specification, Version 4.40
+
+    Including the following line in a shader can be used to control the
+    language features described in this extension:
+
+      #extension GL_EXT_shader_integer_mix : <behavior>
+
+    where <behavior> is as specified in section 3.3.
+
+    New preprocessor #defines are added to the OpenGL Shading Language:
+
+      #define GL_EXT_shader_integer_mix        1
+
+Interactions with ARB_ES3_compatibility
+
+    On desktop implementations that support ARB_ES3_compatibility,
+    GL_EXT_shader_integer_mix can be enabled (and the new functions
+    used) in shaders declared with '#version 300 es'.
+
+GLX Protocol
+
+    None.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+New Implementation Dependent State
+
+    None.
+
+Issues
+
+    1) Should we allow linear interpolation of integers via a non-boolean
+       third component?
+
+    RESOLVED: No.
+
+    2) Should we allow mix() to select between boolean components?
+
+    RESOLVED: Yes. Implementing the same functionality using casts would be
+    possible but ugly.
+
+Revision History
+
+    Rev.    Date      Author    Changes
+    ----  --------    --------  ---------------------------------------------
+      6   09/12/2013  idr       After discussions in Khronos, change vendor
+                                prefix to EXT.
+
+      5   09/09/2013  idr       Add ARB_ES3_compatibility interaction.
+
+      4   09/06/2013  mattst88  Allow extension on OpenGL ES 3.0.
+
+      3   08/28/2013  mattst88  Add #extension/#define changes.
+
+      2   08/26/2013  mattst88  Change vendor prefix to MESA. Add mix() that
+                                selects between boolean components.
+      1   08/26/2013  mattst88  Initial revision
diff --git a/docs/_extra/specs/EXT_shader_samples_identical.txt b/docs/_extra/specs/EXT_shader_samples_identical.txt
new file mode 100644 (file)
index 0000000..a8a901b
--- /dev/null
@@ -0,0 +1,176 @@
+Name
+
+    EXT_shader_samples_identical
+
+Name Strings
+
+    GL_EXT_shader_samples_identical
+
+Contact
+
+    Ian Romanick, Intel (ian.d.romanick 'at' intel.com)
+
+Contributors
+
+    Chris Forbes, Mesa
+    Magnus Wendt, Intel
+    Neil S. Roberts, Intel
+    Graham Sellers, AMD
+
+Status
+
+    XXX - Not complete yet.
+
+Version
+
+    Last Modified Date: November 19, 2015
+    Revision: 6
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 3.2, or OpenGL ES 3.1, or ARB_texture_multisample is required.
+
+    This extension is written against the OpenGL 4.5 (Core Profile)
+    Specification
+
+Overview
+
+    Multisampled antialiasing has become a common method for improving the
+    quality of rendered images.  Multisampling differs from supersampling in
+    that the color of a primitive that covers all or part of a pixel is
+    resolved once, regardless of the number of samples covered.  If a large
+    polygon is rendered, the colors of all samples in each interior pixel will
+    be the same.  This suggests a simple compression scheme that can reduce
+    the necessary memory bandwidth requirements.  In one such scheme, each
+    sample is stored in a separate slice of the multisample surface.  An
+    additional multisample control surface (MCS) contains a mapping from pixel
+    samples to slices.
+
+    If all the values stored in the MCS for a particular pixel are the same,
+    then all the samples have the same value.  Applications can take advantage
+    of this information to reduce the bandwidth of reading multisample
+    textures.  A custom multisample resolve filter could optimize resolving
+    pixels where every sample is identical by reading the color once.
+
+    color = texelFetch(sampler, coordinate, 0);
+    if (!textureSamplesIdenticalEXT(sampler, coordinate)) {
+        for (int i = 1; i < MAX_SAMPLES; i++) {
+            vec4 c = texelFetch(sampler, coordinate, i);
+
+            //... accumulate c into color
+
+        }
+    }
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+
+    None.
+
+Additions to the OpenGL 4.5 (Core Profile) Specification
+
+    None.
+
+Modifications to The OpenGL Shading Language Specification, Version 4.50.5
+
+    Including the following line in a shader can be used to control the
+    language features described in this extension:
+
+        #extension GL_EXT_shader_samples_identical
+
+    A new preprocessor #define is added to the OpenGL Shading Language:
+
+        #define GL_EXT_shader_samples_identical
+
+    Add to the table in section 8.7 "Texture Lookup Functions"
+
+    Syntax:
+
+        bool textureSamplesIdenticalEXT(gsampler2DMS sampler, ivec2 coord)
+
+        bool textureSamplesIdenticalEXT(gsampler2DMSArray sampler,
+                                        ivec3 coord)
+
+    Description:
+
+        Returns true if it can be determined that all samples within the texel
+        of the multisample texture bound to <sampler> at <coord> contain the
+        same values or false if this cannot be determined."
+
+Additions to the AGL/EGL/GLX/WGL Specifications
+
+    None
+
+Errors
+
+    None
+
+New State
+
+    None
+
+New Implementation Dependent State
+
+    None
+
+Issues
+
+    1) What should the new functions be called?
+
+    RESOLVED: textureSamplesIdenticalEXT.  Initially
+    textureAllSamplesIdenticalEXT was considered, but
+    textureSamplesIdenticalEXT is more similar to the existing textureSamples
+    function.
+
+    2) It seems like applications could implement additional optimization if
+       they were provided with raw MCS data.  Should this extension also
+       provide that data?
+
+    There are a number of challenges in providing raw MCS data.  The biggest
+    problem being that the amount of MCS data depends on the number of
+    samples, and that is not known at compile time.  Additionally, without new
+    texelFetch functions, applications would have difficulty utilizing the
+    information.
+
+    Another option is to have a function that returns an array of tuples of
+    sample number and count.  This also has difficulties with the maximum
+    array size not being known at compile time.
+
+    RESOLVED: Do not expose raw MCS data in this extension.
+
+    3) Should this extension also extend SPIR-V?
+
+    RESOLVED: Yes, but this has not yet been written.
+
+    4) Is it possible for textureSamplesIdenticalEXT to report false negatives?
+
+    RESOLVED: Yes.  It is possible that the underlying hardware may not detect
+    that separate writes of the same color to different samples of a pixel are
+    the same.  The shader function is at the whim of the underlying hardware
+    implementation.  It is also possible that a compressed multisample surface
+    is not used.  In that case the function will likely always return false.
+
+Revision History
+
+    Rev  Date        Author    Changes
+    ---  ----------  --------  ---------------------------------------------
+      1  2014/08/20  cforbes   Initial version
+      2  2015/10/23  idr       Change from MESA to EXT.  Rebase on OpenGL 4.5,
+                               and add dependency on OpenGL ES 3.1.  Initial
+                               draft of overview section and issues 1 through
+                               3.
+      3  2015/10/27  idr       Typo fixes.
+      4  2015/11/10  idr       Rename extension from EXT_shader_multisample_compression
+                               to EXT_shader_samples_identical.
+                               Add issue #4.
+      5  2015/11/18  idr       Fix some typos spotted by gsellers.  Change the
+                               name of the name of the function to
+                               textureSamplesIdenticalEXT.
+      6  2015/11/19  idr       Fix more typos spotted by Nicolai Hähnle.
diff --git a/docs/_extra/specs/INTEL_shader_atomic_float_minmax.txt b/docs/_extra/specs/INTEL_shader_atomic_float_minmax.txt
new file mode 100644 (file)
index 0000000..a42ad93
--- /dev/null
@@ -0,0 +1,200 @@
+Name
+
+    INTEL_shader_atomic_float_minmax
+
+Name Strings
+
+    GL_INTEL_shader_atomic_float_minmax
+
+Contact
+
+    Ian Romanick (ian . d . romanick 'at' intel . com)
+
+Contributors
+
+
+Status
+
+    In progress
+
+Version
+
+    Last Modified Date: 06/22/2018
+    Revision: 4
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 4.2, OpenGL ES 3.1, ARB_shader_storage_buffer_object, or
+    ARB_compute_shader is required.
+
+    This extension is written against version 4.60 of the OpenGL Shading
+    Language Specification.
+
+Overview
+
+    This extension provides GLSL built-in functions allowing shaders to
+    perform atomic read-modify-write operations to floating-point buffer
+    variables and shared variables.  Minimum, maximum, exchange, and
+    compare-and-swap are enabled.
+
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+
+    None.
+
+IP Status
+
+    None.
+
+Modifications to the OpenGL Shading Language Specification, Version 4.60
+
+    Including the following line in a shader can be used to control the
+    language features described in this extension:
+
+      #extension GL_INTEL_shader_atomic_float_minmax : <behavior>
+
+    where <behavior> is as specified in section 3.3.
+
+    New preprocessor #defines are added to the OpenGL Shading Language:
+
+      #define GL_INTEL_shader_atomic_float_minmax   1
+
+Additions to Chapter 8 of the OpenGL Shading Language Specification
+(Built-in Functions)
+
+    Modify Section 8.11, "Atomic Memory Functions"
+
+    (add a new row after the existing "atomicMin" table row, p. 179)
+
+        float atomicMin(inout float mem, float data)
+
+
+        Computes a new value by taking the minimum of the value of data and
+        the contents of mem.  If one of these is an IEEE signaling NaN (i.e.,
+        a NaN with the most-significant bit of the mantissa cleared), it is
+        always considered smaller.  If one of these is an IEEE quiet NaN
+        (i.e., a NaN with the most-significant bit of the mantissa set), it is
+        always considered larger.  If both are IEEE quiet NaNs or both are
+        IEEE signaling NaNs, the result of the comparison is undefined.
+
+    (add a new row after the exiting "atomicMax" table row, p. 179)
+
+        float atomicMax(inout float mem, float data)
+
+        Computes a new value by taking the maximum of the value of data and
+        the contents of mem.  If one of these is an IEEE signaling NaN (i.e.,
+        a NaN with the most-significant bit of the mantissa cleared), it is
+        always considered larger.  If one of these is an IEEE quiet NaN (i.e.,
+        a NaN with the most-significant bit of the mantissa set), it is always
+        considered smaller.  If both are IEEE quiet NaNs or both are IEEE
+        signaling NaNs, the result of the comparison is undefined.
+
+    (add to "atomicExchange" table cell, p. 180)
+
+        float atomicExchange(inout float mem, float data)
+
+    (add to "atomicCompSwap" table cell, p. 180)
+
+        float atomicCompSwap(inout float mem, float compare, float data)
+
+Interactions with OpenGL 4.6 and ARB_gl_spirv
+
+    If OpenGL 4.6 or ARB_gl_spirv is supported, then
+    SPV_INTEL_shader_atomic_float_minmax must also be supported.
+
+    The AtomicFloatMinmaxINTEL capability is available whenever the OpenGL or
+    OpenGL ES implementation supports INTEL_shader_atomic_float_minmax.
+
+Issues
+
+    1) Why call this extension INTEL_shader_atomic_float_minmax?
+
+    RESOLVED: Several other extensions already set the precedent of
+    VENDOR_shader_atomic_float and VENDOR_shader_atomic_float64 for extensions
+    that enable floating-point atomic operations.  Using that as a base for
+    the name seems logical.
+
+    There already exists NV_shader_atomic_float, but the two extensions have
+    nearly zero overlap in functionality.  NV_shader_atomic_float adds
+    atomicAdd and image atomic operations that currently shipping Intel GPUs
+    do not support.  Calling this extension INTEL_shader_atomic_float would
+    likely have been confusing.
+
+    Adding something to describe the actual functions added by this extension
+    seemed reasonable.  INTEL_shader_atomic_float_compare was considered, but
+    that name was deemed to be not properly descriptive.  Calling this
+    extension INTEL_shader_atomic_float_min_max_exchange_compswap is right
+    out.
+
+    2) What atomic operations should we support for floating-point targets?
+
+    RESOLVED.  Exchange, min, max, and compare-swap make sense, and these are
+    all supported by the hardware.  Future extensions may add other functions.
+
+    For buffer variables and shared variables it is not possible to bit-cast
+    the memory location in GLSL, so existing integer operations, such as
+    atomicOr, cannot be used.  However, the underlying hardware implementation
+    can do this by treating the memory as an integer.  It would be possible to
+    implement atomicNegate using this technique with atomicXor.  It is unclear
+    whether this provides any actual utility.
+
+    3) What should be said about the NaN behavior?
+
+    RESOLVED.  There are several aspects of NaN behavior that should be
+    documented in this extension.  However, some of this behavior varies based
+    on NaN concepts that do not exist in the GLSL specification.
+
+    * atomicCompSwap performs the comparison as the floating-point equality
+      operator (==).  That is, if either 'mem' or 'compare' is NaN, the
+      comparison result is always false.
+
+    * atomicMin and atomicMax implement the IEEE specification with respect to
+      NaN.  IEEE considers two different kinds of NaN: signaling NaN and quiet
+      NaN.  A quiet NaN has the most significant bit of the mantissa set, and
+      a signaling NaN does not.  This concept does not exist in SPIR-V,
+      Vulkan, or OpenGL.  Let qNaN denote a quiet NaN and sNaN denote a
+      signaling NaN.  atomicMin and atomicMax specifically implement
+
+      - fmin(qNaN, x) = fmin(x, qNaN) = fmax(qNaN, x) = fmax(x, qNaN) = x
+      - fmin(sNaN, x) = fmin(x, sNaN) = fmax(sNaN, x) = fmax(x, sNaN) = sNaN
+      - fmin(sNaN, qNaN) = fmin(qNaN, sNaN) = fmax(sNaN, qNaN) =
+        fmax(qNaN, sNaN) = sNaN
+      - fmin(sNaN, sNaN) = sNaN.  This specification does not define which of
+        the two arguments is stored.
+      - fmax(sNaN, sNaN) = sNaN.  This specification does not define which of
+        the two arguments is stored.
+      - fmin(qNaN, qNaN) = qNaN.  This specification does not define which of
+        the two arguments is stored.
+      - fmax(qNaN, qNaN) = qNaN.  This specification does not define which of
+        the two arguments is stored.
+
+    Further details are available in the Skylake Programmer's Reference
+    Manuals available at
+    https://01.org/linuxgraphics/documentation/hardware-specification-prms.
+
+    4) What about atomicMin and atomicMax with (+0.0, -0.0) or (-0.0, +0.0)
+    arguments?
+
+    RESOLVED.  atomicMin should store -0.0, and atomicMax should store +0.0.
+    Due to a known issue in shipping Skylake GPUs, the incorrectly signed 0 is
+    stored.  This behavior may change in later GPUs.
+
+Revision History
+
+    Rev  Date        Author    Changes
+    ---  ----------  --------  ---------------------------------------------
+      1  04/19/2018  idr       Initial version
+      2  05/05/2018  idr       Describe interactions with the capabilities
+                               added by SPV_INTEL_shader_atomic_float_minmax.
+      3  05/29/2018  idr       Remove mention of 64-bit float support.
+      4  06/22/2018  idr       Resolve issue #2.
+                               Add issue #3 (regarding NaN behavior).
+                               Add issue #4 (regarding atomicMin(-0, +0).
diff --git a/docs/_extra/specs/MESA_configless_context.spec b/docs/_extra/specs/MESA_configless_context.spec
new file mode 100644 (file)
index 0000000..d7ba62d
--- /dev/null
@@ -0,0 +1,129 @@
+Name
+
+    MESA_configless_context
+
+Name Strings
+
+    EGL_MESA_configless_context
+
+Contact
+
+    Neil Roberts <neil.s.roberts@intel.com>
+
+Status
+
+    Superseded by the functionally identical EGL_KHR_no_config_context
+    extension.
+
+Version
+
+    Version 2, September 9, 2016
+
+Number
+
+    EGL Extension #not assigned
+
+Dependencies
+
+    Requires EGL 1.4 or later.  This extension is written against the
+    wording of the EGL 1.4 specification.
+
+Overview
+
+    This extension provides a means to use a single context to render to
+    multiple surfaces which have different EGLConfigs. Without this extension
+    the EGLConfig for every surface used by the context must be compatible
+    with the one used by the context. The only way to render to surfaces with
+    different formats would be to create multiple contexts but this is
+    inefficient with modern GPUs where this restriction is unnecessary.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+
+    Accepted as <config> in eglCreateContext
+
+        EGL_NO_CONFIG_MESA                  ((EGLConfig)0)
+
+Additions to the EGL Specification section "2.2 Rendering Contexts and Drawing
+Surfaces"
+
+    Add the following to the 3rd paragraph:
+
+   "EGLContexts can also optionally be created with respect to an EGLConfig
+    depending on the parameters used at creation time. If a config is provided
+    then additional restrictions apply on what surfaces can be used with the
+    context."
+
+    Replace the last sentence of the 6th paragraph with:
+
+   "In order for a context to be compatible with a surface they both must have
+    been created with respect to the same EGLDisplay. If the context was
+    created without respect to an EGLConfig then there are no further
+    constraints. Otherwise they are only compatible if:"
+
+    Remove the last bullet point in the list of constraints.
+
+Additions to the EGL Specification section "3.7.1 Creating Rendering Contexts"
+
+    Replace the paragraph starting "If config is not a valid EGLConfig..."
+    with
+
+   "The config argument can either be a valid EGLConfig or EGL_NO_CONFIG_MESA.
+    If it is neither of these then an EGL_BAD_CONFIG error is generated. If a
+    valid config is passed then the error will also be generated if the config
+    does not support the requested client API (this includes requesting
+    creation of an OpenGL ES 1.x context when the EGL_RENDERABLE_TYPE
+    attribute of config does not contain EGL_OPENGL_ES_BIT, or creation of an
+    OpenGL ES 2.x context when the attribute does not contain
+    EGL_OPENGL_ES2_BIT).
+
+    Passing EGL_NO_CONFIG_MESA will create a configless context. When a
+    configless context is used with the OpenGL API it can be assumed that the
+    initial values of the context's state will be decided when the context is
+    first made current. In particular this means that the decision of whether
+    to use GL_BACK or GL_FRONT for the initial value of the first output in
+    glDrawBuffers will be decided based on the config of the draw surface when
+    it is first bound."
+
+Additions to the EGL Specification section "3.7.3 Binding Contexts and
+Drawables"
+
+    Replace the first bullet point with the following:
+
+   "* If draw or read are not compatible with ctx as described in section 2.2,
+      then an EGL_BAD_MATCH error is generated."
+
+    Add a second bullet point after that:
+
+   "* If draw and read are not compatible with each other as described in
+      section 2.2, then an EGL_BAD_MATCH error is generated."
+
+Issues
+
+    1.  What happens when an OpenGL context with a double-buffered surface and
+        draw buffer set to GL_BACK is made current with a single-buffered
+        surface?
+
+        NOT RESOLVED: There are a few options here.  An implementation can
+        raise an error, change the drawbuffer state to GL_FRONT or just do
+        nothing, expecting the application to set GL_FRONT drawbuffer before
+        drawing.  However, this extension deliberately does not specify any
+        required behavior in this corner case and applications should avoid
+        mixing single- and double-buffered surfaces with configless contexts.
+
+        Future extensions may specify required behavior in this case.
+
+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/docs/_extra/specs/MESA_copy_sub_buffer.spec b/docs/_extra/specs/MESA_copy_sub_buffer.spec
new file mode 100644 (file)
index 0000000..752a014
--- /dev/null
@@ -0,0 +1,96 @@
+Name
+
+    MESA_copy_sub_buffer
+
+Name Strings
+
+    GLX_MESA_copy_sub_buffer
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping since Mesa 2.6 in February, 1998.
+
+Version
+
+    Last Modified Date:  12 January 2009
+
+Number
+
+    215
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    The glxCopySubBufferMESA() function copies a rectangular region
+    of the back color buffer to the front color buffer.  This can be
+    used to quickly repaint 3D windows in response to expose events
+    when the back color buffer cannot be damaged by other windows.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
+                              int x, int y, int width, int height );
+
+New Tokens
+
+    None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    Add to section 3.3.10 Double Buffering:
+
+    The function
+
+        void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
+                                   int x, int y, int width, int height );
+
+    may be used to copy a rectangular region of the back color buffer to
+    the front color buffer.  This can be used to quickly repaint 3D windows
+    in response to expose events when the back color buffer cannot be
+    damaged by other windows.
+
+    <x> and <y> indicates the lower-left corner of the region to copy and
+    <width> and <height> indicate the size in pixels.  Coordinate (0,0)
+    corresponds to the lower-left pixel of the window, like glReadPixels.
+
+    If dpy and drawable are the display and drawable for the calling
+    thread's current context, glXCopySubBufferMESA performs an
+    implicit glFlush before it returns.  Subsequent OpenGL commands
+    may be issued immediately after calling glXCopySubBufferMESA, but
+    are not executed until the copy is completed. 
+
+GLX Protocol
+
+    None at this time.  The extension is implemented in terms of ordinary
+    Xlib protocol inside of Mesa.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    12 January 2009 Ian Romanick - Added language about implicit flush
+                                   and command completion.
+    8 June 2000     Brian Paul   - initial specification
+
diff --git a/docs/_extra/specs/MESA_drm_image.spec b/docs/_extra/specs/MESA_drm_image.spec
new file mode 100644 (file)
index 0000000..1150a4c
--- /dev/null
@@ -0,0 +1,153 @@
+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
+
+    Requires 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
+        EGL_DRM_BUFFER_USE_CURSOR_MESA         0x0004
+
+    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_HEIGHT 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,
+    EGL_DRM_BUFFER_USE_SHARE_MESA and EGL_DRM_BUFFER_USE_CURSOR_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.  EGL_DRM_BUFFER_USE_SHARE_MESA requests that the
+    EGLImage can be shared with other processes by passing the
+    underlying DRM buffer name.  EGL_DRM_BUFFER_USE_CURSOR_MESA
+    requests that the image must be usable as a cursor with KMS.  When
+    EGL_DRM_BUFFER_USE_CURSOR_MESA is set, width and height must both
+    be 64.
+
+    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 referencing 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/_extra/specs/MESA_framebuffer_flip_y.txt b/docs/_extra/specs/MESA_framebuffer_flip_y.txt
new file mode 100644 (file)
index 0000000..891cc43
--- /dev/null
@@ -0,0 +1,106 @@
+Name
+
+    MESA_framebuffer_flip_y
+
+Name Strings
+
+    GL_MESA_framebuffer_flip_y
+
+Contact
+
+    Fritz Koenig <frkoenig@google.com>
+
+Contributors
+
+    Fritz Koenig, Google
+    Kristian Høgsberg, Google
+    Chad Versace, Google
+    Heinrich Fink, DAQRI
+
+Status
+
+    Proposal
+
+Version
+
+    Version 3, August, 2019
+
+Number
+
+    OpenGL Extension #540
+    OpenGL ES Extension #302
+
+Dependencies
+
+    Requires OpenGL ES 3.0, OpenGL 4.3, or ARB_framebuffer_no_attachments.
+
+Overview
+
+    This extension defines a new framebuffer parameter,
+    GL_FRAMEBUFFER_FLIP_Y_MESA, that changes the behavior of the reads and
+    writes to the framebuffer attachment points. When GL_FRAMEBUFFER_FLIP_Y_MESA
+    is GL_TRUE, render commands and pixel transfer operations access the
+    backing store of each attachment point with an y-inverted coordinate
+    system. This y-inversion is relative to the coordinate system set when
+    GL_FRAMEBUFFER_FLIP_Y_MESA is GL_FALSE.
+
+    Access through TexSubImage2D and similar calls will notice the effect of
+    the flip when they are not attached to framebuffer objects because
+    GL_FRAMEBUFFER_FLIP_Y_MESA is associated with the framebuffer object and
+    not the attachment points.
+
+IP Status
+
+    None
+
+Issues
+
+    None
+
+New Procedures and Functions
+
+    OpenGL ES must provide the following functions:
+
+    void FramebufferParameteriMESA(enum target, enum pname, int param);
+    void GetFramebufferParameterivMESA(enum target, enum pname, int *params);
+
+New Types
+
+    None
+
+New Tokens
+
+    Accepted by the <pname> argument of FramebufferParameteriMESA and
+    GetFramebufferParameterivMESA:
+
+        GL_FRAMEBUFFER_FLIP_Y_MESA                      0x8BBB
+
+Interactions with OpenGL 4.3, OpenGL ES 3.1, ARB_framebuffer_no_attachments
+and any other versions and extensions that provide the entry points
+FramebufferParameteri and GetFramebufferParameteriv
+
+        Token GL_FRAMEBUFFER_FLIP_Y_MESA is accepted as the <pname> argument of
+        FramebufferParameteri and GetFramebufferParameteriv.
+
+Errors
+
+    An INVALID_OPERATION error is generated by GetFramebufferParameteriv or
+    GetFramebufferParameterivMESA if the default framebuffer is bound
+    to <target> and <pname> is GL_FRAMEBUFFER_FLIP_Y_MESA.
+
+
+
+
+
+Revision History
+
+    Version 3, August, 2019
+        Allow OpenGL ES 3.0 to implement by adding functions
+        FramebufferParameteriMESA and GetFramebufferParameterivMESA which were
+        previously only available in OpenGL ES 3.1.
+
+    Version 2, June, 2019
+        Enable extension for OpenGL 4.3 and beyond
+
+    Version 1, June, 2018
+        Initial draft (Fritz Koenig)
diff --git a/docs/_extra/specs/MESA_image_dma_buf_export.txt b/docs/_extra/specs/MESA_image_dma_buf_export.txt
new file mode 100644 (file)
index 0000000..cc9497e
--- /dev/null
@@ -0,0 +1,147 @@
+Name
+
+    MESA_image_dma_buf_export
+
+Name Strings
+
+    EGL_MESA_image_dma_buf_export
+
+Contributors
+
+    Dave Airlie
+
+Contact
+
+    Dave Airlie (airlied 'at' redhat 'dot' com)
+
+Status
+
+    Complete, shipping.
+
+Version
+
+    Version 3, May 5, 2015
+
+Number
+
+    EGL Extension #87
+
+Dependencies
+
+    Requires EGL 1.4 or later.  This extension is written against the
+    wording of the EGL 1.4 specification.
+
+    EGL_KHR_base_image is required.
+
+    The EGL implementation must be running on a Linux kernel supporting the
+    dma_buf buffer sharing mechanism.
+
+Overview
+
+    This extension provides entry points for integrating EGLImage with the
+    dma-buf infrastructure.  The extension allows creating a Linux dma_buf
+    file descriptor or multiple file descriptors, in the case of multi-plane
+    YUV image, from an EGLImage.
+
+    It is designed to provide the complementary functionality to
+    EGL_EXT_image_dma_buf_import.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Types
+
+    This extension uses the 64-bit unsigned integer type EGLuint64KHR
+    first introduced by the EGL_KHR_stream extension, but does not
+    depend on that extension. The typedef may be reproduced separately
+    for this extension, if not already present in eglext.h.
+
+    typedef khronos_uint64_t EGLuint64KHR;
+
+New Procedures and Functions
+
+    EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
+                                  EGLImageKHR image,
+                                 int *fourcc,
+                                 int *num_planes,
+                                 EGLuint64KHR *modifiers);
+
+    EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
+                                        EGLImageKHR image,
+                                        int *fds,
+                                       EGLint *strides,
+                                       EGLint *offsets);
+
+New Tokens
+
+    None
+
+
+Additions to the EGL 1.4 Specification:
+
+    To mirror the import extension, this extension attempts to return
+    enough information to enable an exported dma-buf to be imported
+    via eglCreateImageKHR and EGL_LINUX_DMA_BUF_EXT token.
+
+    Retrieving the information is a two step process, so two APIs
+    are required.
+
+    The first entrypoint
+       EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
+                                  EGLImageKHR image,
+                                 int *fourcc,
+                                 int *num_planes,
+                                 EGLuint64KHR *modifiers);
+
+    is used to retrieve the pixel format of the buffer, as specified by
+    drm_fourcc.h, the number of planes in the image and the Linux
+    drm modifiers. <fourcc>, <num_planes> and <modifiers> may be NULL,
+    in which case no value is retrieved.
+
+    The second entrypoint retrieves the dma_buf file descriptors,
+    strides and offsets for the image. The caller should pass
+    arrays sized according to the num_planes values retrieved previously.
+    Passing arrays of the wrong size will have undefined results.
+    If the number of fds is less than the number of planes, then
+    subsequent fd slots should contain -1.
+
+        EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
+                                         EGLImageKHR image,
+                                        int *fds,
+                                         EGLint *strides,
+                                         EGLint *offsets);
+
+    <fds>, <strides>, <offsets> can be NULL if the infomatation isn't
+    required by the caller.
+
+Issues
+
+1. Should the API look more like an attribute getting API?
+
+ANSWER: No, from a user interface pov, having to iterate across calling
+the API up to 12 times using attribs seems like the wrong solution.
+
+2. Should the API take a plane and just get the fd/stride/offset for that
+   plane?
+
+ANSWER: UNKNOWN,this might be just as valid an API.
+
+3. Does ownership of the file descriptor remain with the app?
+
+ANSWER: Yes, the app is responsible for closing any fds retrieved.
+
+4. If number of planes and number of fds differ what should we do?
+
+ANSWER: Return -1 for the secondary slots, as this avoids having
+to dup the fd extra times to make the interface sane.
+
+Revision History
+
+    Version 3, May, 2015
+        Just use the KHR 64-bit type.
+    Version 2, March, 2015
+        Add a query interface (Dave Airlie)
+    Version 1, June 3, 2014
+        Initial draft (Dave Airlie)
+
diff --git a/docs/_extra/specs/MESA_multithread_makecurrent.spec b/docs/_extra/specs/MESA_multithread_makecurrent.spec
new file mode 100644 (file)
index 0000000..5065c2f
--- /dev/null
@@ -0,0 +1,158 @@
+Name
+
+    MESA_multithread_makecurrent
+
+Name Strings
+
+    GLX_MESA_multithread_makecurrent
+
+Contact
+
+    Eric Anholt (eric@anholt.net)
+
+Status
+
+    Not shipping.
+
+Version
+
+    Last Modified Date:  21 February 2011
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.3 or later is required.
+
+Overview
+
+    The GLX context setup encourages multithreaded applications to
+    create a context per thread which each operate on their own
+    objects in parallel, and leaves synchronization for write access
+    to shared objects up to the application.
+
+    For some applications, maintaining per-thread contexts and
+    ensuring that the glFlush happens in one thread before another
+    thread starts working on that object is difficult.  For them,
+    using the same context across multiple threads and protecting its
+    usage with a mutex is both higher performance and easier to
+    implement.  This extension gives those applications that option by
+    relaxing the context binding requirements.
+
+    This new behavior matches the requirements of AGL, while providing
+    a feature not specified in WGL.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+
+    None.
+
+Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
+
+    Replace the following sentence from section 2.2 Rendering Contexts:
+       In addition, a rendering context can be current for only one
+       thread at a time.
+    with:
+       In addition, an indirect rendering context can be current for
+       only one thread at a time.  A direct rendering context may be
+       current to multiple threads, with synchronization of access to
+       the context thruogh the GL managed by the application through
+       mutexes.
+
+Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    Replace the following sentence from section 3.3.7 Rendering Contexts:
+       If ctx is current to some other thread, then
+       glXMakeContextCurrent will generate a BadAccess error.
+    with:
+       If ctx is an indirect context current to some other thread,
+       then glXMakeContextCurrent will generate a BadAccess error.
+
+    Replace the following sentence from section 3.5 Rendering Contexts:
+       If ctx is current to some other thread, then
+       glXMakeCurrent will generate a BadAccess error.
+    with:
+       If ctx is an indirect context current to some other thread,
+       then glXMakeCurrent will generate a BadAccess error.
+
+GLX Protocol
+
+    None.  The GLX extension only extends to direct rendering contexts.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Issues
+
+    (1) What happens if the app binds a context/drawable in multiple
+       threads, then binds a different context/thread in one of them?
+
+    As with binding a new context from the current thread, the old
+    context's refcount is reduced and the new context's refcount is
+    increased.
+
+    (2) What happens if the app binds a context/drawable in multiple
+       threads, then binds None/None in one of them?
+
+    The GLX context is unreferenced from that thread, and the other
+    threads retain their GLX context binding.
+
+    (3) What happens if the app binds a context/drawable in 7 threads,
+       then destroys the context in one of them?
+
+    As with GLX context destruction previously, the XID is destroyed
+    but the context remains usable by threads that have the context
+    current.
+
+    (4) What happens if the app binds a new drawable/readable with
+        glXMakeCurrent() when it is already bound to another thread?
+
+    The context becomes bound to the new drawable/readable, and
+    further rendering in either thread will use the new
+    drawable/readable.
+
+    (5) What requirements should be placed on the user managing contexts
+        from multiple threads?
+
+    The intention is to allow multithreaded access to the GL at the
+    minimal performance cost, so requiring that the GL do general
+    synchronization (beyond that already required by context sharing)
+    is not an option, and synchronizing of GL's access to the GL
+    context between multiple threads is left to the application to do
+    across GL calls.  However, it would be unfortunate for a library
+    doing multithread_makecurrent to require that other libraries
+    share in synchronization for binding of their own contexts, so the
+    refcounting of the contexts is required to be threadsafe.
+
+    (6) Does this apply to indirect contexts?
+
+    This was ignored in the initial revision of the spec.  Behavior
+    for indirect contexts is left as-is.
+
+Revision History
+
+    20 November 2009 Eric Anholt - initial specification
+    22 November 2009 Eric Anholt - added issues from Ian Romanick.
+    3 February 2011 Eric Anholt - updated with resolution to issues 1-3
+    3 February 2011 Eric Anholt - added issue 4, 5
+    21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
+    along with glXMakeContextCurrent() for removal.
diff --git a/docs/_extra/specs/MESA_pack_invert.spec b/docs/_extra/specs/MESA_pack_invert.spec
new file mode 100644 (file)
index 0000000..33fb3c7
--- /dev/null
@@ -0,0 +1,138 @@
+Name
+
+    MESA_pack_invert
+
+Name Strings
+
+    GL_MESA_pack_invert
+
+Contact
+
+    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
+
+Status
+
+    Shipping (Mesa 4.0.4 and later)
+
+Version
+
+    1.0
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required
+    This extensions is written against the OpenGL 1.4 Specification.
+
+Overview
+
+    This extension adds a new pixel storage parameter to indicate that
+    images are to be packed in top-to-bottom order instead of OpenGL's
+    conventional bottom-to-top order.  Only pixel packing can be
+    inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter,
+    etc).
+
+    Almost all known image file formats store images in top-to-bottom
+    order.  As it is, OpenGL reads images from the frame buffer in
+    bottom-to-top order.  Thus, images usually have to be inverted before
+    writing them to a file with image I/O libraries.  This extension
+    allows images to be read such that inverting isn't needed.
+
+IP Status
+
+    None
+
+Issues
+
+    1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
+
+    Resolved:  No, we're only concerned with pixel packing.  There are other
+    solutions for inverting images when using glDrawPixels (negative Y pixel
+    zoom) or glTexImage (invert the vertex T coordinates).  It would be easy
+    enough to define a complementary extension for pixel packing in the
+    future if needed.
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    Accepted by the <pname> parameter of PixelStorei and PixelStoref
+    and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev
+    and GetBooleanv:
+
+        PACK_INVERT_MESA                   0x8758
+
+Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+    Add the following entry to table 4.4 (PixelStore parameters) on page 182:
+
+    Parameter Name       Type    Initial Value    Valid Range
+    ---------------------------------------------------------
+    PACK_INVERT_MESA     boolean     FALSE        TRUE/FALSE
+
+    In the section labeled "Placement in Client Memory" on page 184
+    insert the following text into the paragraph before the sentence
+    that starts with "If the format is RED, GREEN, BLUE...":
+
+    "The parameter PACK_INVERT_MESA controls whether the image is packed
+     in bottom-to-top order (the default) or top-to-bottom order.  Equation
+     3.8 is modified as follows:
+
+     ... the first element of the Nth row is indicated by
+
+         p + Nk,                if PACK_INVERT_MESA is false
+         p + k * (H - 1) - Nk,  if PACK_INVERT_MESA is true, where H is the
+                                image height
+    "
+
+Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
+State Requests)
+
+    None
+
+Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
+
+    None
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Errors
+
+    None
+
+New State
+
+    Add the following entry to table 6.20 (Pixels) on page 235:
+
+    Get Value         Type     Get Cmd    Initial Value  Description                Sec    Attribute
+    --------------------------------------------------------------------------------------------------
+    PACK_INVERT_MESA  boolean  GetBoolean  FALSE         Value of PACK_INVERT_MESA  4.3.2  pixel-store
+
+Revision History
+
+    21 September 2002 - Initial draft
diff --git a/docs/_extra/specs/MESA_pixmap_colormap.spec b/docs/_extra/specs/MESA_pixmap_colormap.spec
new file mode 100644 (file)
index 0000000..fb0b441
--- /dev/null
@@ -0,0 +1,90 @@
+Name
+
+    MESA_pixmap_colormap
+
+Name Strings
+
+    GLX_MESA_pixmap_colormap
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping since Mesa 1.2.8 in May, 1996.
+
+Version
+
+    Last Modified Date:  8 June 2000
+
+Number
+
+    216
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    Since Mesa allows RGB rendering into drawables with PseudoColor,
+    StaticColor, GrayScale and StaticGray visuals, Mesa needs a colormap
+    in order to compute pixel values during rendering.
+
+    The colormap associated with a window can be queried with normal
+    Xlib functions but there is no colormap associated with pixmaps.
+
+    The glXCreateGLXPixmapMESA function is an alternative to glXCreateGLXPixmap
+    which allows specification of a colormap.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
+                                     Pixmap pixmap, Colormap cmap );
+
+New Tokens
+
+    None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    Add to section 3.4.2 Off Screen Rendering
+
+    The Mesa implementation of GLX allows RGB rendering into X windows and
+    pixmaps of any visual class, not just TrueColor or DirectColor.  In order
+    to compute pixel values from RGB values Mesa requires a colormap.
+
+    The function
+
+       GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
+                                         Pixmap pixmap, Colormap cmap );
+
+    allows one to create a GLXPixmap with a specific colormap.  The image
+    rendered into the pixmap may then be copied to a window (which uses the
+    same colormap and visual) with the expected results.
+
+GLX Protocol
+
+    None since this is a client-side extension.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    8 June 2000 - initial specification
diff --git a/docs/_extra/specs/MESA_query_renderer.spec b/docs/_extra/specs/MESA_query_renderer.spec
new file mode 100644 (file)
index 0000000..10f68ec
--- /dev/null
@@ -0,0 +1,385 @@
+Name
+
+    MESA_query_renderer
+
+Name Strings
+
+    GLX_MESA_query_renderer
+
+Contact
+
+    Ian Romanick <ian.d.romanick@intel.com>
+
+IP Status
+
+    No known IP claims.
+
+Status
+
+    Shipping as of Mesa 10.0
+
+Version
+
+    Version 9, 09 November 2018
+
+Number
+
+    OpenGL Extension #446
+
+Dependencies
+
+    GLX 1.4 is required.
+
+    GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
+
+Overview
+
+    In many situations, applications want to detect characteristics of a
+    rendering device before creating a context for that device.  Information
+    gathered at this stage may guide choices the application makes about
+    color depth, number of samples per-pixel, texture quality, and so on.
+    In addition, versions of supported APIs and implementation API
+    preference may also guide start-up decisions made by the application.
+    For example, one implementation may prefer vertex data be supplied using
+    methods only available in a compatibility profile, but another
+    implementation may only support the desired version in a core profile.
+
+    There are also cases where more than one renderer may be available per
+    display.  For example, there is typically a hardware implementation and
+    a software based implementation.  There are cases where an application
+    may want to pick one over the other.  One such situation is when the
+    software implementation supports more features than the hardware
+    implementation.  Another situation is when a particular version of the
+    hardware implementation is blacklisted due to known bugs.
+
+    This extension provides a mechanism for the application to query all of
+    the available renderers for a particular display and screen.  In
+    addition, this extension provides a mechanism for applications to create
+    contexts with respect to a specific renderer.
+
+New Procedures and Functions
+
+    Bool glXQueryRendererIntegerMESA(Display *dpy, int screen,
+                                     int renderer, int attribute,
+                                     unsigned int *value);
+    Bool glXQueryCurrentRendererIntegerMESA(int attribute, unsigned int *value);
+
+    const char *glXQueryRendererStringMESA(Display *dpy, int screen,
+                                           int renderer, int attribute);
+
+    const char *glXQueryCurrentRendererStringMESA(int attribute);
+
+New Tokens
+
+    Accepted as an <attribute> in glXQueryRendererIntegerMESA and
+    glXQueryCurrentRendererIntegerMESA:
+
+        GLX_RENDERER_VENDOR_ID_MESA                      0x8183
+        GLX_RENDERER_DEVICE_ID_MESA                      0x8184
+        GLX_RENDERER_VERSION_MESA                        0x8185
+        GLX_RENDERER_ACCELERATED_MESA                    0x8186
+        GLX_RENDERER_VIDEO_MEMORY_MESA                   0x8187
+        GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA    0x8188
+        GLX_RENDERER_PREFERRED_PROFILE_MESA              0x8189
+        GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA    0x818A
+        GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA    0x818B
+        GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA      0x818C
+        GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA     0x818D
+
+    Accepted as an <attribute> in glXQueryRendererStringMESA and
+    glXQueryCurrentRendererStringMESA:
+
+        GLX_RENDERER_VENDOR_ID_MESA
+        GLX_RENDERER_DEVICE_ID_MESA
+
+Additions to the OpenGL / WGL Specifications
+
+    None. This specification is written for GLX.
+
+Additions to the GLX 1.4 Specification
+
+    [Add to Section 3.3.2 "GLX Versioning" of the GLX Specification]
+
+    To obtain information about the available renderers for a particular
+    display and screen,
+
+        Bool glXQueryRendererIntegerMESA(Display *dpy, int screen, int renderer,
+                                         int attribute, unsigned int *value);
+
+    can be used.  The value for <attribute> will be returned in one or more
+    integers specified by <value>.  The values, data sizes, and descriptions
+    of each renderer attribute are listed in the table below.
+
+    GLX renderer attribute         number     description
+                                  of values
+    ----------------------        ---------   -----------
+    GLX_RENDERER_VENDOR_ID_MESA   1           PCI ID of the device vendor
+    GLX_RENDERER_DEVICE_ID_MESA   1           PCI ID of the device
+    GLX_RENDERER_VERSION_MESA     3           Major, minor, and patch level of
+                                              the renderer implementation
+    GLX_RENDERER_ACCELERATED_MESA 1           Boolean indicating whether or
+                                              not the renderer is hardware
+                                              accelerated
+    GLX_RENDERER_VIDEO_MEMORY_MESA 1          Number of megabytes of video
+                                              memory available to the renderer
+    GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA
+                                  1           Boolean indicating whether or
+                                              not the renderer uses a unified
+                                              memory architecture or has
+                                              separate "on-card" and GART
+                                              memory.
+    GLX_RENDERER_PREFERRED_PROFILE_MESA
+                                  1           Bitmask of the preferred context
+                                              profile for this renderer.  This
+                                              value is suitable to be supplied
+                                              with the
+                                              GLX_CONTEXT_PROFILE_MASK_ARB
+                                              attribute to
+                                              glXCreateContextAttribsARB
+    GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA
+                                  2           Maximum core profile major and
+                                              minor version supported by the
+                                              renderer
+    GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA
+                                  2           Maximum compatibility profile
+                                              major and minor version
+                                              supported by the renderer
+    GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA
+                                  2           Maximum OpenGL ES 1.x
+                                              major and minor version
+                                              supported by the renderer
+    GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA
+                                  2           Maximum OpenGL ES 2.x or 3.x
+                                              major and minor version
+                                              supported by the renderer
+
+    In the table, boolean attributes will have either the value 0 or 1.
+
+    GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA,
+    GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA,
+    GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA, and
+    GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA each return <0, 0> in
+    *value if no version of that profile is supported.
+
+    GLX_RENDERER_VENDOR_ID_MESA and GLX_RENDERER_DEVICE_ID_MESA may return
+    0xFFFFFFFF if the device does not have a PCI ID (because it is not a PCI
+    device) or if the PCI ID is not available.  In this case the application
+    should rely on the string query instead.
+
+    If <attribute> is not a recognized value, False is returned, but no GLX
+    error is generated.  Otherwise, True is returned.
+
+    String versions of some attributes may also be queried using
+
+        const char *glXQueryRendererStringMESA(Display *dpy, int screen,
+                                               int renderer, int attribute);
+
+    The value for <attribute> will be returned in one or more
+    integers specified by <value>.  The values, data sizes, and descriptions
+    of each renderer attribute are listed in the table below.
+
+    GLX renderer attribute        description
+    ----------------------        -----------
+    GLX_RENDERER_VENDOR_ID_MESA   Name of the renderer provider.  This may
+                                  differ from the vendor name of the
+                                  underlying hardware.
+    GLX_RENDERER_DEVICE_ID_MESA   Name of the renderer.  This may differ from
+                                  the name of the underlying hardware (e.g.,
+                                  for a software renderer).
+
+    If <attribute> is not a recognized value, NULL is returned, but no GLX
+    error is generated.
+
+    The string returned for GLX_RENDERER_VENDOR_ID_MESA will have the same
+    format as the string that would be returned by glGetString of GL_VENDOR.
+    It may, however, have a different value.
+
+    The string returned for GLX_RENDERER_DEVICE_ID_MESA will have the same
+    format as the string that would be returned by glGetString of GL_RENDERER.
+    It may, however, have a different value.
+
+Issues
+
+    1) How should the difference between on-card and GART memory be exposed?
+
+        UNRESOLVED.
+
+    2) How should memory limitations of unified memory architecture (UMA)
+    systems be exposed?
+
+        UNRESOLVED.  Some hardware has different per-process and global
+        limits for memory that can be accessed within a single draw call.
+
+    3) How should the renderer's API preference be advertised?
+
+        UNRESOLVED.  The common case for desktop renderers is to prefer
+        either core or compatibility.  However, some renderers may actually
+        prefer an ES context.  This leaves the application in a tough spot
+        if it can only support core or compatibility and the renderer says it
+        wants ES.
+
+    4) Should OpenGL ES 2.0 and OpenGL ES 3.0 be treated separately?
+
+        RESOLVED.  No.  OpenGL ES 3.0 is backwards compatible with OpenGL ES
+        2.0.  Applications can detect OpenGL ES 3.0 support by querying
+        GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA.
+
+    5) How can applications tell the difference between different hardware
+    renderers for the same device?  For example, whether the renderer is the
+    open-source driver or the closed-source driver.
+
+        RESOLVED.  Assuming this extension is ever implemented outside Mesa,
+        applications can query GLX_RENDERER_VENDOR_ID_MESA from
+        glXQueryRendererStringMESA.  This will almost certainly return
+        different strings for open-source and closed-source drivers.
+
+    6) What is the value of GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA for
+    software renderers?
+
+        UNRESOLVED.  Video (display) memory and texture memory is not unified
+        for software implementations, so it seems reasonable for this to be
+        False.
+
+    7) How does an application determine the number of available renderers?
+
+        UNRESOLVED.
+
+    8) What happens if a fbconfig is used to create context on a renderer
+    that cannot support it?  For example, if a multisampled config is used
+    with a software renderer that does not support multisampling.
+
+        RESOLVED.  The language for glXCreateContextAttribsARB already covers
+        this case.  Context creation will fail, and BadMatch is generated.
+
+    9) In addition to being able to query the supported versions, should
+    applications also be able to query the supported extensions?
+
+        RESOLVED.  No.  Desktop OpenGL core profiles and OpenGL ES 3.0 have
+        moved away from the monolithic string returned by glGetString of
+        GL_EXTENSIONS.  Providing the newer indexed query would require adding
+        a lot of extra infrastructure, and it would probably provide little
+        benefit to applications.
+
+    10) What combination of values for GLX_RENDERER_PREFERRED_PROFILE_MESA,
+    GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA, and
+    GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA should be returned
+    for a renderer that only supports OpenGL 3.1 without the
+    GL_ARB_compatibility extension?
+
+        RESOLVED.  The renderer will return GLX_CONTEXT_CORE_PROFILE_BIT_ARB
+        for GLX_RENDERER_PREFERRED_PROFILE_MESA.
+
+        Further, the renderer will return <3,0> for
+        GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA because OpenGL
+        3.1 without GL_ARB_compatibility is not backwards compatible with
+        previous versions of OpenGL.  The render will return <3,1> for
+        GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA indicating that support
+        for OpenGL 3.1 is available.
+
+        Even though there is no OpenGL 3.1 core profile, the values
+        returned for GLX_RENDERER_PREFERRED_PROFILE_MESA and
+        GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA can be supplied
+        with the GLX_CONTEXT_PROFILE_MASK_ARB and
+        GLX_CONTEXT_{MAJOR,MINOR}_VERSION_ARB attributes of
+        glXCreateContextAttribsARB without error.  If the requested
+        OpenGL version is less than 3.2, the
+        GLX_CONTEXT_PROFILE_MASK_ARB attribute is ignored by
+        glXCreateContextAttribsARB.
+
+    11) How can application learn about multi-GPU (e.g., SLI, CrossFireX,
+    etc.) configurations?
+
+        UNRESOLVED.  Based on ISV feedback, this is important information to
+        provide to the application.  Given the variety of possible hardware
+        configurations (e.g., Hybrid CrossFireX) and different rendering
+        modes (e.g., split-frame rendering vs. alternate-frame rendering),
+        it's not clear how this information can be communicated.
+
+        It is likely that this will be left to a layered extension.
+
+    12) Should capability queries similar to those in
+    GL_ARB_internalformat_query or GL_ARB_internalformat_query2 be added?
+
+        RESOLVED.  No.  With the possible exception of the texture size
+        queries, it seems unlikely that applications would ever use this
+        information before creating a context.
+
+    13) Existing GL extensions (e.g., GL_ATI_meminfo and
+    GL_NVX_gpu_memory_info) allow easy queries after context creation.  With
+    this extension it is a bit of a pain for a portable application to query
+    the information after context creation.
+
+        RESOLVED.  Add versions of the queries that implicitly take the
+        display, screen, and renderer from the currently bound context.
+
+    14) Why not make the queries from issue #13 GL functions (instead of GLX)?
+
+        RESOLVED.  It is fairly compelling for the post-creation queries to
+        just use glGetInteger and glGetString.  However, the GL enums and
+        the GLX enums would have different names and would almost certainly
+        have different values.  It seems like this would cause more problems
+        than it would solve.
+
+    15) Should the string queries be required to return the same values as
+    glGetString(GL_VENDOR) and glGetString(GL_RENDERER)?
+
+        UNRESOLVED.  This may be useful for applications that already do
+        device detection based on these strings.
+
+    16) What type should the value parameter of glXQueryRendererIntegerMESA
+        and glXQueryCurrentRendererIntegerMESA be?
+
+        UNRESOLVED.  Other similar GLX query functions just use int or
+        unsigned int, so that's what this extension uses for now.  However,
+        an expeclitly sized value, such as uint32_t or uint64_t, seems
+        preferable.
+
+    17) What about SoCs and other systems that don't have PCI?
+
+        RESOLVED. The GLX_RENDERER_VENDOR_ID_MESA and
+        GLX_RENDERER_DEVICE_ID_MESA integer queries may return 0xFFFFFFFF if a
+        PCI ID either does not exist or is not available.  Implementations
+        should make every attempt to return as much information as is
+        possible.  For example, if the implementation is running on a non-PCI
+        SoC with a Qualcomm GPU, GLX_RENDERER_VENDOR_ID_MESA should return
+        0x5143, but GLX_RENDERER_DEVICE_ID_MESA will return 0xFFFFFFFF.
+
+Revision History
+
+    Version 1, 2012/08/27 - Initial version
+
+    Version 2, 2012/09/04 - Specify behavior of implementations that
+                            do not support certain profiles.
+                            Change wording of issue #8 to be more
+                            clear.
+                            Make some wording changes to issue #10 to
+                            clarify the resolution a bit.
+
+    Version 3, 2012/09/23 - Add issue #11 regarding multi-GPU systems.
+
+    Version 4, 2013/02/01 - Add issue #12 regarding texture / renderbuffer
+                            format queries.
+
+    Version 5, 2013/02/14 - Add issues #13 and #14 regarding simpler queires
+                            after the context is created and made current.
+                            Add issue #15 regarding the string query.
+                            Add issue #16 regarding the value type returned
+                            by the Integer functions.
+
+    Version 6, 2013/10/25 - Fix a typo.  Update the list of functions to
+                            which the new enums can be passed.  The "Current"
+                            versions were previously missing.
+
+    Version 7, 2013/11/07 - Fix a couple more typos.  Add issue #17 regarding
+                            the PCI queries on systems that don't have PCI.
+
+    Version 8, 2014/02/14 - Fix a couple typos. GLX_RENDER_ID_MESA should
+                            read GLX_RENDERER_ID_MESA. The VENDOR/DEVICE_ID
+                            example given in issue #17 should be 0x5143 and
+                            0xFFFFFFFF respectively.
+
+    Version 9, 2018/11/09 - Remove GLX_RENDERER_ID_MESA, which has never been
+                            implemented. Remove the unnecessary interactions
+                            with the GLX GLES profile extensions. Note the
+                            official GL extension number. Specify the section
+                            of the GLX spec to modify.
diff --git a/docs/_extra/specs/MESA_release_buffers.spec b/docs/_extra/specs/MESA_release_buffers.spec
new file mode 100644 (file)
index 0000000..52d1e5a
--- /dev/null
@@ -0,0 +1,85 @@
+Name
+
+    MESA_release_buffers
+
+Name Strings
+
+    GLX_MESA_release_buffers
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Shipping since Mesa 2.0 in October, 1996.
+
+Version
+
+    Last Modified Date:  8 June 2000
+
+Number
+
+    217
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    Mesa's implementation of GLX is entirely implemented on the client side.
+    Therefore, Mesa cannot immediately detect when an X window or pixmap is
+    destroyed in order to free any ancillary data associated with the window
+    or pixmap.
+
+    The glxMesaReleaseBuffers() function can be used to explicitly indicate
+    when the back color buffer, depth buffer, stencil buffer, and/or accumu-
+    lation buffer associated with a drawable can be freed.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
+
+New Tokens
+
+    None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    The function
+
+       Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
+
+    causes all software ancillary buffers (back buffer, depth, stencil,
+    accum, etc) associated with the named drawable to be immediately
+    deallocated.  True is returned if <d> is a valid Mesa GLX drawable,
+    else False is returned.  After calling glXReleaseBuffersMESA, the
+    drawable should no longer be used for GL rendering.  Results of
+    attempting to do so are undefined.
+
+
+GLX Protocol
+
+    None, since this is a client-side operation.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    8 June 2000 - initial specification
diff --git a/docs/_extra/specs/MESA_shader_debug.spec b/docs/_extra/specs/MESA_shader_debug.spec
new file mode 100644 (file)
index 0000000..fab92ab
--- /dev/null
@@ -0,0 +1,264 @@
+Name
+
+    MESA_shader_debug
+
+Name Strings
+
+    GL_MESA_shader_debug
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Michal Krol (mjkrol 'at' gmail.com)
+
+Status
+
+    Obsolete.
+
+Version
+
+    Last Modified Date: July 30, 2006
+    Author Revision: 0.2
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 is required.
+
+    The ARB_shader_objects extension is required.
+
+    The ARB_shading_language_100 extension is required.
+
+    The extension is written against the OpenGL 1.5 specification.
+
+    The extension is written against the OpenGL Shading Language 1.10
+    Specification.
+
+Overview
+
+    This extension introduces a debug object that can be attached to
+    a program object to enable debugging. Vertex and/or fragment shader,
+    during execution, issue diagnostic function calls that are logged
+    to the debug object's log. A separate debug log for each shader type
+    is maintained. A debug object can be attached, detached and queried
+    at any time outside the Begin/End pair. Multiple debug objects can
+    be attached to a single program object.
+
+IP Status
+
+    None
+
+Issues
+
+    None
+
+New Procedures and Functions
+
+    handleARB CreateDebugObjectMESA(void)
+    void ClearDebugLogMESA(handleARB obj, enum logType, enum shaderType)
+    void GetDebugLogMESA(handleARB obj, enum logType, enum shaderType,
+                         sizei maxLength, sizei *length,
+                         charARB *debugLog)
+    sizei GetDebugLogLengthMESA(handleARB obj, enum logType,
+                                enum shaderType)
+
+New Types
+
+    None
+
+New Tokens
+
+    Returned by the <params> parameter of GetObjectParameter{fi}vARB:
+
+        DEBUG_OBJECT_MESA                               0x8759
+
+    Accepted by the <logType> argument of ClearDebugLogMESA,
+    GetDebugLogLengthMESA and GetDebugLogMESA:
+
+        DEBUG_PRINT_MESA                                0x875A
+        DEBUG_ASSERT_MESA                               0x875B
+
+Additions to Chapter 2 of the OpenGL 1.5 Specification
+(OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+    None
+
+Additions to Chapter 5 of the OpenGL 1.5 Specification
+(Special Functions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State
+Requests)
+
+    None
+
+Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
+
+    None
+
+Additions to Chapter 1 of the OpenGL Shading Language 1.10 Specification
+(Introduction)
+
+    None
+
+Additions to Chapter 2 of the OpenGL Shading Language 1.10 Specification
+(Overview of OpenGL Shading)
+
+    None
+
+Additions to Chapter 3 of the OpenGL Shading Language 1.10 Specification
+(Basics)
+
+    None
+
+Additions to Chapter 4 of the OpenGL Shading Language 1.10 Specification
+(Variables and Types)
+
+    None
+
+Additions to Chapter 5 of the OpenGL Shading Language 1.10 Specification
+(Operators and Expressions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL Shading Language 1.10 Specification
+(Statements and Structure)
+
+    None
+
+Additions to Chapter 7 of the OpenGL Shading Language 1.10 Specification
+(Built-in Variables)
+
+    None
+
+Additions to Chapter 8 of the OpenGL Shading Language 1.10 Specification
+(Built-in Functions)
+
+    Add a new section 8.10 "Debug Functions":
+
+    Debug functions are available to both fragment and vertex shaders.
+    They are used to track the execution of a shader by logging
+    passed-in arguments to the debug object's log. Those values can be
+    retrieved by the application for inspection after shader execution
+    is complete.
+
+    The text, if any, produced by any of these functions is appended
+    to each debug object that is attached to the program object.
+    There are different debug log types
+
+    Add a new section 8.10.1 "Print Function":
+
+    The following printMESA prototypes are available.
+
+        void printMESA(const float value)
+        void printMESA(const int value)
+        void printMESA(const bool value)
+        void printMESA(const vec2 value)
+        void printMESA(const vec3 value)
+        void printMESA(const vec4 value)
+        void printMESA(const ivec2 value)
+        void printMESA(const ivec3 value)
+        void printMESA(const ivec4 value)
+        void printMESA(const bvec2 value)
+        void printMESA(const bvec3 value)
+        void printMESA(const bvec4 value)
+        void printMESA(const mat2 value)
+        void printMESA(const mat3 value)
+        void printMESA(const mat4 value)
+        void printMESA(const sampler1D value)
+        void printMESA(const sampler2D value)
+        void printMESA(const sampler3D value)
+        void printMESA(const samplerCube value)
+        void printMESA(const sampler1DShadow value)
+        void printMESA(const sampler2DShadow value)
+
+    The printMESA function writes the argument <value> to the "debug
+    print log" (XXX DEBUG_PRINT_MESA?). Each component is written in
+    text format (XXX format!) and is delimited by a white space (XXX 1
+    or more?).
+
+    Add a new section 8.10.2 "Assert Function":
+
+    The following assertMESA prototypes are available.
+
+        void assertMESA(const bool condition)
+        void assertMESA(const bool condition, const int cookie)
+        void assertMESA(const bool condition, const int cookie,
+                        const int file, const int line)
+
+    The assertMESA function checks if the argument <condition> is
+    true or false. If it is true, nothing happens. If it is false,
+    a diagnostic message is written to the "debug assert log".
+    The message contains the argument <file>, <line>, <cookie> and
+    implementation dependent double-quoted string, each of this
+    delimited by a white space. If the argument <cookie> is not present,
+    it is meant as if it was of value 0. If the arguments <file> and
+    <line> are not present, they are meant as if they were of values
+    __FILE__ and __LINE__, respectively. The following three calls
+    produce the same output, assuming they were issued from the same
+    file and line.
+
+        assertMESA (false);
+        assertMESA (false, 0);
+        assertMESA (false, 0, __FILE__, __LINE__);
+
+    The diagnostic message examples follow.
+
+        1 89 0 ""
+        1 45 333 "all (lessThanEqual (fragColor, vec4 (1.0)))"
+        1 66 1 "assertion failed in file 1, line 66, cookie 1"
+
+Additions to Chapter 9 of the OpenGL Shading Language 1.10 Specification
+(Shading Language Grammar)
+
+    None
+
+Additions to Chapter 10 of the OpenGL Shading Language 1.10
+Specification (Issues)
+
+    None
+
+Additions to the AGL/EGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Errors
+
+    TBD
+
+New State
+
+    TBD
+
+New Implementation Dependent State
+
+    TBD
+
+Sample Code
+
+    TBD
+
+Revision History
+
+    29 May 2006
+        Initial draft. (Michal Krol)
+    30 July 2006
+        Add Overview, New Procedures and Functions, New Tokens sections.
+        Add sections 8.10.1, 8.10.2 to GLSL spec.
diff --git a/docs/_extra/specs/MESA_shader_integer_functions.txt b/docs/_extra/specs/MESA_shader_integer_functions.txt
new file mode 100644 (file)
index 0000000..9fcc9b4
--- /dev/null
@@ -0,0 +1,522 @@
+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 3, March 31, 2017
+
+Number
+
+    OpenGL Extension #495
+
+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 (OpenGL) or GLSL ES 3.00 (OpenGL ES) 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 and version
+    3.00 of the OpenGL ES 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
+    ----  -----------  --------  -----------------------------------------
+     3    31-Mar-2017  Jon Leech Add ES support (OpenGL-Registry/issues/3)
+     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/docs/_extra/specs/MESA_swap_control.spec b/docs/_extra/specs/MESA_swap_control.spec
new file mode 100644 (file)
index 0000000..a002563
--- /dev/null
@@ -0,0 +1,129 @@
+Name
+
+    MESA_swap_control
+
+Name Strings
+
+    GLX_MESA_swap_control
+
+Contact
+
+    Ian Romanick, IBM, idr at us.ibm.com
+
+Status
+
+    Deployed in DRI drivers post-XFree86 4.3.
+
+Version
+
+    Date: 5/1/2003   Revision: 1.1
+
+Number
+
+    ???
+
+Dependencies
+
+    None
+
+    Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
+    version 1.5.
+
+Overview
+
+    This extension allows an application to specify a minimum periodicity
+    of color buffer swaps, measured in video frame periods.
+
+Issues
+
+    * Should implementations that export GLX_MESA_swap_control also export
+      GL_EXT_swap_control for compatibility with WGL_EXT_swap_control?
+
+    UNRESOLVED.
+
+New Procedures and Functions
+
+    int glXSwapIntervalMESA(unsigned int interval)
+    int glXGetSwapIntervalMESA(void)
+
+New Tokens
+
+    None
+
+Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
+and the Framebuffer)
+
+    None
+
+Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
+
+    None
+
+Additions to the GLX 1.3 Specification
+
+    [Add the following to Section 3.3.10 of the GLX Specification (Double
+     Buffering)]
+
+    glXSwapIntervalMESA specifies the minimum number of video frame periods
+    per buffer swap.  (e.g. a value of two means that the color buffers
+    will be swapped at most every other video frame.)  A return value
+    of zero indicates success; otherwise an error occurred.  The interval
+    takes effect when glXSwapBuffers is first called subsequent to the
+    glXSwapIntervalMESA call.
+
+    A video frame period is the time required by the monitor to display a 
+    full frame of video data.  In the case of an interlaced monitor,
+    this is typically the time required to display both the even and odd 
+    fields of a frame of video data.
+
+    If <interval> is set to a value of 0, buffer swaps are not synchro-
+    nized to a video frame.  The <interval> value is silently clamped to
+    the maximum implementation-dependent value supported before being
+    stored.
+
+    The swap interval is not part of the render context state.  It cannot
+    be pushed or popped.  The current swap interval for the window
+    associated with the current context can be obtained by calling
+    glXGetSwapIntervalMESA.  The default swap interval is 0.
+
+    On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets
+    the swap interval to 1.
+
+Errors
+
+    glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
+    GLXContext or if the current context is not a direct rendering context.
+
+GLX Protocol
+
+    None.  This extension only extends to direct rendering contexts.
+
+New State
+
+    Get Value          Get Command     Type        Initial Value
+    ---------          -----------     ----        -------------
+    [swap interval]    GetSwapInterval Z+          0
+
+New Implementation Dependent State
+
+    None
+
+
+Revision History
+
+    1.1,  5/1/03   Added the issues section and contact information.
+                  Changed the default swap interval to 0.
+    1.0,  3/17/03  Initial version based on GLX_SGI_swap_control and
+                   WGL_EXT_swap_control.
diff --git a/docs/_extra/specs/MESA_swap_frame_usage.spec b/docs/_extra/specs/MESA_swap_frame_usage.spec
new file mode 100644 (file)
index 0000000..5023ead
--- /dev/null
@@ -0,0 +1,201 @@
+Name
+
+    MESA_swap_frame_usage
+
+Name Strings
+
+    GLX_MESA_swap_frame_usage
+
+Contact
+
+    Ian Romanick, IBM, idr at us.ibm.com
+
+Status
+
+    Deployed in DRI drivers post-XFree86 4.3.
+
+Version
+
+    Date: 5/1/2003   Revision: 1.1
+
+Number
+
+    ???
+
+Dependencies
+
+    GLX_SGI_swap_control affects the definition of this extension.
+    GLX_MESA_swap_control affects the definition of this extension.
+    GLX_OML_sync_control affects the definition of this extension.
+
+    Based on WGL_I3D_swap_frame_usage version 1.3.
+
+Overview
+
+    This extension allows an application to determine what portion of the
+    swap period has elapsed since the last swap operation completed.  The
+    "usage" value is a floating point value on the range [0,max] which is
+    calculated as follows:
+
+                              td
+                   percent = ----
+                              tf
+
+    where td is the time measured from the last completed buffer swap (or
+    call to enable the statistic) to when the next buffer swap completes, tf
+    is the entire time for a frame which may be multiple screen refreshes
+    depending on the swap interval as set by the GLX_SGI_swap_control or
+    GLX_OML_sync_control extensions. 
+
+    The value, percent, indicates the amount of time spent between the
+    completion of the two swaps.  If the value is in the range [0,1], the
+    buffer swap occurred within the time period required to maintain a
+    constant frame rate.  If the value is in the range (1,max], a constant
+    frame rate was not achieved.  The value indicates the number of frames
+    required to draw.
+
+    This definition of "percent" differs slightly from
+    WGL_I3D_swap_frame_usage.  In WGL_I3D_swap_frame_usage, the measurement
+    is taken from the completion of one swap to the issuance of the next.
+    This representation may not be as useful as measuring between
+    completions, as a significant amount of time may pass between the
+    issuance of a swap and the swap actually occurring.
+
+    There is also a mechanism to determine whether a frame swap was
+    missed.
+
+New Procedures and Functions
+
+    int glXGetFrameUsageMESA(Display *dpy,
+                             GLXDrawable drawable,
+                            float *usage)
+
+    int glXBeginFrameTrackingMESA(Display *dpy,
+                                  GLXDrawable drawable)
+
+    int glXEndFrameTrackingMESA(Display *dpy,
+                                GLXDrawable drawable)
+
+    int glXQueryFrameTrackingMESA(Display *dpy,
+                                  GLXDrawable drawable,
+                                 int64_t *swapCount,
+                                  int64_t *missedFrames,
+                                  float *lastMissedUsage)
+
+New Tokens
+
+    None
+
+Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
+
+    None
+
+Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
+and the Framebuffer)
+
+    None
+
+Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
+
+    None
+
+Additions to the GLX 1.3 Specification
+
+    The frame usage is measured as the percentage of the swap period elapsed
+    between two buffer-swap operations being committed.  In unextended GLX the
+    swap period is the vertical refresh time.  If SGI_swap_control or
+    MESA_swap_control are supported, the swap period is the vertical refresh
+    time multiplied by the swap interval (or one if the swap interval is set
+    to zero).
+    
+    If OML_sync_control is supported, the swap period is the vertical
+    refresh time multiplied by the divisor parameter to
+    glXSwapBuffersMscOML.  The frame usage in this case is less than 1.0 if
+    the swap is committed before target_msc, and is greater than or equal to
+    1.0 otherwise.  The actual usage value is based on the divisor and is
+    never less than 0.0.
+
+       int glXBeginFrameTrackingMESA(Display *dpy,
+                                     GLXDrawable drawable,
+                                    float *usage)
+
+    glXGetFrameUsageMESA returns a floating-point value in <usage>
+    that represents the current swap usage, as defined above.
+
+    Missed frame swaps can be tracked by calling the following function:
+
+       int glXBeginFrameTrackingMESA(Display *dpy,
+                                     GLXDrawable drawable)
+
+    glXBeginFrameTrackingMESA resets a "missed frame" count and
+    synchronizes with the next frame vertical sync before it returns.
+    If a swap is missed based in the rate control specified by the
+    <interval> set by glXSwapIntervalSGI or the default swap of once
+    per frame, the missed frame count is incremented.
+
+    The current missed frame count and total number of swaps since
+    the last call to glXBeginFrameTrackingMESA can be obtained by
+    calling the following function:
+
+       int glXQueryFrameTrackingMESA(Display *dpy,
+                                     GLXDrawable drawable,
+                                    int64_t *swapCount,
+                                     int64_t *missedFrames,
+                                     float *lastMissedUsage)
+
+    The location pointed to by <swapCount> will be updated with the
+    number of swaps that have been committed.  This value may not match the
+    number of swaps that have been requested since swaps may be
+    queued by the implementation.  This function can be called at any
+    time and does not synchronize to vertical blank.
+
+    The location pointed to by <missedFrames> will contain the number
+    swaps that missed the specified frame.  The frame usage for the
+    last missed frame is returned in the location pointed to by
+    <lastMissedUsage>.
+
+    Frame tracking is disabled by calling the function
+
+       int glXEndFrameTrackingMESA(Display *dpy,
+                                   GLXDrawable drawable)
+
+    This function will not return until all swaps have occurred.  The
+    application can call glXQueryFrameTrackingMESA for a final swap and
+    missed frame count.
+
+    If these functions are successful, zero is returned.  If the context
+    associated with dpy and drawable is not a direct context,
+    GLX_BAD_CONTEXT is returned.
+
+Errors
+
+    If the function succeeds, zero is returned.  If the function
+    fails, one of the following error codes is returned:
+
+       GLX_BAD_CONTEXT         The current rendering context is not a direct
+                                      context.
+
+GLX Protocol
+
+    None.  This extension only extends to direct rendering contexts.
+
+New State
+
+    None
+
+New Implementation Dependent State
+
+    None
+
+Revision History
+
+    1.1,  5/1/03   Added contact information.
+    1.0,  3/17/03  Initial version based on WGL_I3D_swap_frame_usage.
diff --git a/docs/_extra/specs/MESA_texture_array.spec b/docs/_extra/specs/MESA_texture_array.spec
new file mode 100644 (file)
index 0000000..88f8815
--- /dev/null
@@ -0,0 +1,804 @@
+Name
+
+    MESA_texture_array
+
+Name Strings
+
+    GL_MESA_texture_array
+
+Contact
+
+    Ian Romanick, IBM (idr 'at' us.ibm.com)
+
+IP Status
+
+    No known IP issues.
+
+Status
+
+    DEPRECATED - Support removed in Mesa 10.1.
+
+Version
+
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.2 or GL_EXT_texture3D is required.
+
+    Support for ARB_fragment_program is assumed, but not required.
+
+    Support for ARB_fragment_program_shadow is assumed, but not required.
+
+    Support for EXT_framebuffer_object is assumed, but not required.
+
+    Written based on the wording of the OpenGL 2.0 specification and
+    ARB_fragment_program_shadow but not dependent on them.
+
+Overview
+
+    There are a number of circumstances where an application may wish to
+    blend two textures out of a larger set of textures.  Moreover, in some
+    cases the selected textures may vary on a per-fragment basis within
+    a polygon.  Several examples include:
+
+       1. High dynamic range textures.  The application stores several
+       different "exposures" of an image as different textures.  On a
+       per-fragment basis, the application selects which exposures are
+       used.
+
+       2. A terrain engine where the altitude of a point determines the
+       texture applied to it.  If the transition is from beach sand to
+       grass to rocks to snow, the application will store each texture
+       in a different texture map, and dynamically select which two
+       textures to blend at run-time.
+
+       3. Storing short video clips in textures.  Each depth slice is a
+       single frame of video.
+
+    Several solutions to this problem have been proposed, but they either
+    involve using a separate texture unit for each texture map or using 3D
+    textures without mipmaps.  Both of these options have major drawbacks.
+
+    This extension provides a third alternative that eliminates the major
+    drawbacks of both previous methods.  A new texture target,
+    TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in
+    all aspects except the sizes of the non-base level images.  In
+    traditional 3D texturing, the size of the N+1 LOD is half the size
+    of the N LOD in all three dimensions.  For the TEXTURE_2D_ARRAY target,
+    the height and width of the N+1 LOD is halved, but the depth is the
+    same for all levels of detail. The texture then becomes an array of
+    2D textures.  The per-fragment texel is selected by the R texture
+    coordinate.
+
+    References:
+
+        https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
+        https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
+        https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903
+        http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm
+
+New Procedures and Functions
+
+    All functions come directly from EXT_texture_array.
+
+    void FramebufferTextureLayerEXT(enum target, enum attachment,
+                                    uint texture, int level, int layer);
+
+New Tokens
+
+    All token names and values come directly from EXT_texture_array.
+
+    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by
+    the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
+    GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage,
+    GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and
+    GetTexParameterfv:
+
+        TEXTURE_1D_ARRAY_EXT                            0x8C18
+        TEXTURE_2D_ARRAY_EXT                            0x8C1A
+
+    Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
+    CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D,
+    CompressedTexSubImage2D, GetTexLevelParameteriv, and 
+    GetTexLevelParameterfv:
+
+        TEXTURE_1D_ARRAY_EXT
+        PROXY_TEXTURE_1D_ARRAY_EXT                      0x8C19
+
+    Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
+    CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D,
+    GetTexLevelParameteriv, and GetTexLevelParameterfv:
+
+        TEXTURE_2D_ARRAY_EXT
+        PROXY_TEXTURE_2D_ARRAY_EXT                      0x8C1B
+
+    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
+    GetFloatv, and GetDoublev
+
+        TEXTURE_BINDING_1D_ARRAY_EXT                    0x8C1C
+        TEXTURE_BINDING_2D_ARRAY_EXT                    0x8C1D
+        MAX_ARRAY_TEXTURE_LAYERS_EXT                    0x88FF
+
+    Accepted by the <param> parameter of TexParameterf, TexParameteri,
+    TexParameterfv, and TexParameteriv when the <pname> parameter is
+    TEXTURE_COMPARE_MODE_ARB:
+
+        COMPARE_REF_DEPTH_TO_TEXTURE_EXT                0x884E
+
+    (Note:  COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
+    existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
+    reflects the fact that the R coordinate is not always used.)
+
+    Accepted by the <internalformat> parameter of TexImage3D and
+    CompressedTexImage3D, and by the <format> parameter of
+    CompressedTexSubImage3D:
+
+        COMPRESSED_RGB_S3TC_DXT1_EXT
+        COMPRESSED_RGBA_S3TC_DXT1_EXT
+        COMPRESSED_RGBA_S3TC_DXT3_EXT
+        COMPRESSED_RGBA_S3TC_DXT5_EXT
+
+    Accepted by the <pname> parameter of
+    GetFramebufferAttachmentParameterivEXT:
+
+        FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT          0x8CD4
+
+    (Note:  FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
+    FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
+    EXT_framebuffer_object.  This extension generalizes the notion of
+    "<zoffset>" to include layers of an array texture.)
+
+Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
+
+    -- Section 3.8.1 "Texture Image Specification"
+
+       Change the first paragraph (page 150) to say (spec changes identical to
+       EXT_texture_array):
+
+       "The command
+
+         void TexImage3D(enum target, int level, int internalformat,
+                         sizei width, sizei height, sizei depth, int border,
+                         enum format, enum type, void *data);
+
+       is used to specify a three-dimensional texture image. target must be one
+       one of TEXTURE_3D for a three-dimensional texture or
+       TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture.
+       Additionally, target may be either PROXY_TEXTURE_3D for a
+       three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a
+       two-dimensional proxy array texture."
+
+       Change the fourth paragraph on page 151 to say (spec changes identical
+       to EXT_texture_array):
+
+       "Textures with a base internal format of DEPTH_COMPONENT are supported
+       by texture image specification commands only if target is TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
+       PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or
+       PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any
+       other target will result in an INVALID_OPERATION error."
+
+
+       Change the fourth paragraph on page 156 to say (spec changes identical
+       to EXT_texture_array):
+       
+       "The command
+
+         void TexImage2D(enum target, int level,
+                         int internalformat, sizei width, sizei height,
+                         int border, enum format, enum type, void *data);
+
+       is used to specify a two-dimensional texture image. target must be one
+       of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
+       one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
+       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
+       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+       TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally,
+       target may be either PROXY_TEXTURE_2D for a two-dimensional proxy
+       texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array
+       texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the
+       special case discussed in section 3.8.11.  The other parameters match
+       the corresponding parameters of TexImage3D.
+
+       For the purposes of decoding the texture image, TexImage2D is
+       equivalent to calling TexImage3D with corresponding arguments and depth
+       of 1, except that
+
+         * The border depth, d_b, is zero, and the depth of the image is
+           always 1 regardless of the value of border. 
+
+         * The border height, h_b, is zero if <target> is
+           TEXTURE_1D_ARRAY_EXT, and <border> otherwise.
+
+         * Convolution will be performed on the image (possibly changing its
+           width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
+
+         * UNPACK SKIP IMAGES is ignored."
+
+    -- Section 3.8.2 "Alternate Texture Image Specification Commands"
+
+       Change the second paragraph (page 159) (spec changes identical
+       to EXT_texture_array):
+
+       "The command
+
+         void CopyTexImage2D(enum target, int level,
+                             enum internalformat, int x, int y, sizei width,
+                             sizei height, int border);
+
+       defines a two-dimensional texture image in exactly the manner of
+       TexImage2D, except that the image data are taken from the framebuffer
+       rather than from client memory. Currently, target must be one of
+       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
+       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
+       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+       TEXTURE_CUBE_MAP_NEGATIVE_Z.
+
+
+       Change the last paragraph on page 160 to say (spec changes identical
+       to EXT_texture_array):
+
+       "Currently the target arguments of TexSubImage1D and CopyTexSubImage1D
+       must be TEXTURE_1D, the target arguments of TexSubImage2D and
+       CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
+       TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X,
+       TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y,
+       TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the
+       target arguments of TexSubImage3D and CopyTexSubImage3D must be
+       TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..."
+
+
+    -- Section 3.8.4 "Texture Parameters"
+
+       Change the first paragraph (page 166) to say:
+
+       "Various parameters control how the texel array is treated when
+       specified or changed, and when applied to a fragment. Each parameter is
+       set by calling
+
+         void TexParameter{if}(enum target, enum pname, T param); 
+         void TexParameter{if}v(enum target, enum pname, T params);
+
+       target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT."
+
+
+    -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail"
+
+       Change the first paragraph (page 172) to say:
+
+       "Let s(x,y) be the function that associates an s texture coordinate
+       with each set of window coordinates (x,y) that lie within a primitive;
+       define t(x,y) and r(x,y) analogously.  Let u(x,y) = w_t * s(x,y),
+       v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t,
+       and d_t are as defined by equations 3.15, 3.16, and 3.17 with
+       w_s, h_s, and d_s equal to the width, height, and depth of the
+       image array whose level is level_base.  For a one-dimensional
+       texture or a one-dimensional array texture, define v(x,y) = 0 and
+       w(x,y) = 0; for a two-dimensional texture or a two-dimensional array
+       texture, define w(x,y) = 0..."
+
+    -- Section 3.8.8 "Texture Minification" in the section "Mipmapping"
+
+       Change the third paragraph (page 174) to say:
+       
+       "For a two-dimensional texture, two-dimensional array texture, or
+       cube map texture,"
+
+       Change the fourth paragraph (page 174) to say:
+
+       "And for a one-dimensional texture or a one-dimensional array texture,"
+
+       After the first paragraph (page 175) add:
+
+       "For one-dimensional array textures, h_b and d_b are treated as 1,
+       regardless of the actual values, when performing mipmap calculations.
+       For two-dimensional array textures, d_b is always treated as one,
+       regardless of the actual value, when performing mipmap calculations."
+
+    -- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping"
+
+       Change the third paragraph (page 176) to say (spec changes identical
+       to EXT_texture_array):
+
+       "The contents of the derived arrays are computed by repeated, filtered
+       reduction of the level_base array.  For one- and two-dimensional array
+       textures, each layer is filtered independently.  ..."
+
+    -- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping"
+
+       Change first paragraph to say (spec changes identical to
+       EXT_texture_array):
+
+       "Mipmaps can be generated manually with the command
+
+         void GenerateMipmapEXT(enum target);
+
+       where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
+       TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY.  Mipmap generation
+       affects the texture image attached to <target>.  ..."
+
+    -- Section 3.8.10 "Texture Completeness"
+
+       Change the second paragraph (page 177) to say (spec changes identical
+       to EXT_texture_array):
+
+       "For one-, two-, or three-dimensional textures and one- or
+       two-dimensional array textures, a texture is complete if the following
+       conditions all hold true:"
+
+    -- Section 3.8.11 "Texture State and Proxy State"
+
+       Change the second and third paragraphs (page 179) to say (spec changes
+       identical to EXT_texture_array):
+
+       "In addition to image arrays for one-, two-, and three-dimensional
+       textures, one- and two-dimensional array textures, and the six image
+       arrays for the cube map texture, partially instantiated image arrays
+       are maintained for one-, two-, and three-dimensional textures and one-
+       and two-dimensional array textures.  Additionally, a single proxy image
+       array is maintained for the cube map texture.  Each proxy image array
+       includes width, height, depth, border width, and internal format state
+       values, as well as state for the red, green, blue, alpha, luminance,
+       and intensity component resolutions. Proxy image arrays do not include
+       image data, nor do they include texture properties. When TexImage3D is
+       executed with target specified as PROXY_TEXTURE_3D, the
+       three-dimensional proxy state values of the specified level-of-detail
+       are recomputed and updated. If the image array would not be supported
+       by TexImage3D called with target set to TEXTURE 3D, no error is
+       generated, but the proxy width, height, depth, border width, and
+       component resolutions are set to zero. If the image array would be
+       supported by such a call to TexImage3D, the proxy state values are set
+       exactly as though the actual image array were being specified. No pixel
+       data are transferred or processed in either case.
+
+       Proxy arrays for one- and two-dimensional textures and one- and
+       two-dimensional array textures are operated on in the same way when
+       TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
+       TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
+       PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
+       specified as PROXY_TETXURE_2D_ARRAY_EXT."
+
+    -- Section 3.8.12 "Texture Objects"
+
+       Change section (page 180) to say (spec changes identical to 
+       EXT_texture_array):
+
+       "In addition to the default textures TEXTURE_1D, TEXTURE_2D,
+       TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT,
+       named one-, two-, and three-dimensional, cube map, and one- and
+       two-dimensional array texture objects can be created and operated upon.
+       The name space for texture objects is the unsigned integers, with zero
+       reserved by the GL.
+
+       A texture object is created by binding an unused name to TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
+
+         void BindTexture(enum target, uint texture);
+
+       with <target> set to the desired texture target and <texture> set to
+       the unused name.  The resulting texture object is a new state vector,
+       comprising all the state values listed in section 3.8.11, set to the
+       same initial values. If the new texture object is bound to TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-,
+       three-dimensional, cube map, one- or two-dimensional array texture
+       respectively until it is deleted.
+
+       BindTexture may also be used to bind an existing texture object to
+       either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error
+       INVALID_OPERATION is generated if an attempt is made to bind a texture
+       object of different dimensionality than the specified target. If the
+       bind is successful no change is made to the state of the bound texture
+       object, and any previous binding to target is broken.
+
+       While a texture object is bound, GL operations on the target to which
+       it is bound affect the bound object, and queries of the target to which
+       it is bound return state from the bound object. If texture mapping of
+       the dimensionality of the target to which a texture object is bound is
+       enabled, the state of the bound texture object directs the texturing
+       operation.
+
+       In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
+       one-, two-, three-dimensional, cube map, and one- and two-dimensional
+       array texture state vectors respectively associated with them. In order
+       that access to these initial textures not be lost, they are treated as
+       texture objects all of whose names are 0. The initial one-, two-,
+       three-dimensional, cube map, one- and two-dimensional array textures
+       are therefore operated upon, queried, and applied as TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
+       TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
+       targets.
+
+       Change second paragraph on page 181 to say (spec changes identical to 
+       EXT_texture_array):
+       
+       "...  If a texture that is currently bound to one of the targets
+       TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as
+       though BindTexture had been executed with the same target and texture
+       zero. ..."
+
+       Change second paragraph on page 182 to say (spec changes identical to 
+       EXT_texture_array):
+       
+       "The texture object name space, including the initial one-, two-, and
+       three dimensional, cube map, and one- and two-dimensional array texture
+       objects, is shared among all texture units. ..."
+
+
+    -- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes"
+
+       Change second through fourth paragraphs (page 188) to say:
+
+       "Let D_t be the depth texture value, in the range [0, 1].  For
+       texture lookups from one- and two-dimensional, rectangle, and
+       one-dimensional array targets, let R be the interpolated <r>
+       texture coordinate, clamped to the range [0, 1].  For texture lookups
+       from two-dimensional array texture targets, let R be the interpolated
+       <q> texture coordinate, clamped to the range [0, 1].  Then the
+       effective texture value L_t, I_t, or A_t is computed as follows:
+
+       If the value of TEXTURE_COMPARE_MODE is NONE, then
+
+          r = Dt
+
+       If the value of TEXTURE_COMPARE_MODE is
+       COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture
+       comparison function as shown in table 3.27."
+
+    -- Section 3.8.15 "Texture Application"
+
+       Change the first paragraph (page 189) to say:
+
+       "Texturing is enabled or disabled using the generic Enable and Disable
+       commands, respectively, with the symbolic constants TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube
+       map, one-dimensional array, or two-dimensional array texture,
+       respectively.  If both two- and one-dimensional textures are enabled,
+       the two-dimensional texture is used.  If the three-dimensional and
+       either of the two- or one-dimensional textures is enabled, the
+       three-dimensional texture is used.  If the cube map texture and any of
+       the three-, two-, or one-dimensional textures is enabled, then cube map
+       texturing is used.  If one-dimensional array texture is enabled and any
+       of cube map, three-, two-, or one-dimensional textures is enabled, 
+       one-dimensional array texturing is used.  If two-dimensional array
+       texture is enabled and any of cube map, three-, two-, one-dimensional
+       textures or one-dimensional array texture is enabled, two-dimensional
+       array texturing is used..."
+
+    -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions):
+
+       (mostly add to existing grammar rules)
+
+       <optionName>           ::= "MESA_texture_array"
+
+       <texTarget>            ::= "1D"
+                               | "2D"
+                               | "3D"
+                               | "CUBE"
+                               | "RECT"
+                               | <arrayTarget> (if program option is present)
+                               | <shadowTarget> (if program option is present)
+
+       <arrayTarget>          ::= "ARRAY1D"
+                               | "ARRAY2D"
+
+       <shadowTarget>         ::= "SHADOW1D"
+                               | "SHADOW2D"
+                               | "SHADOWRECT"
+                               | <shadowArrayTarget> (if program option is present)
+
+       <shadowArrayTarget>    ::= "SHADOWARRAY1D"
+                               | "SHADOWARRAY2D"
+
+
+    -- Add Section 3.11.4.5.4 "Texture Stack Option"
+
+       "If a fragment program specifies the "MESA_texture_array" program
+       option, the <texTarget> rule is modified to add the texture targets
+       ARRAY1D and ARRAY2D (See Section 3.11.2)."
+
+    -- Section 3.11.6 "Fragment Program Texture Instruction Set"
+
+       (replace 1st and 2nd paragraphs with the following paragraphs)
+
+       "The first three texture instructions described below specify the
+       mapping of 4-tuple input vectors to 4-tuple output vectors.
+       The sampling of the texture works as described in section 3.8,
+       except that texture environments and texture functions are not
+       applicable, and the texture enables hierarchy is replaced by explicit
+       references to the desired texture target (i.e., 1D, 2D, 3D, cube map,
+       rectangle, ARRAY1D, ARRAY2D).  These texture instructions specify
+       how the 4-tuple is mapped into the coordinates used for sampling.  The
+       following function is used to describe the texture sampling in the
+       descriptions below: 
+
+         vec4 TextureSample(vec4 coord, float lodBias, int texImageUnit,
+                            enum texTarget);
+
+       Note that not all four components of the texture coordinates <coord>
+       are used by all texture targets.  Component usage for each <texTarget>
+       is defined in table X.
+
+                                                        coordinates used
+         texTarget          Texture Type               s t r  layer  shadow
+         ----------------   ---------------------      -----  -----  ------
+         1D                 TEXTURE_1D                 x - -    -      -
+         2D                 TEXTURE_2D                 x y -    -      -
+         3D                 TEXTURE_3D                 x y z    -      -
+         CUBE               TEXTURE_CUBE_MAP           x y z    -      -
+         RECT               TEXTURE_RECTANGLE_ARB      x y -    -      -
+         ARRAY1D            TEXTURE_1D_ARRAY_EXT       x - -    y      -
+         ARRAY2D            TEXTURE_2D_ARRAY_EXT       x y -    z      -
+         SHADOW1D           TEXTURE_1D                 x - -    -      z
+         SHADOW2D           TEXTURE_2D                 x y -    -      z
+         SHADOWRECT         TEXTURE_RECTANGLE_ARB      x y -    -      z
+         SHADOWARRAY1D      TEXTURE_1D_ARRAY_EXT       x - -    y      z
+         SHADOWARRAY2D      TEXTURE_2D_ARRAY_EXT       x y -    z      w
+
+         Table X:  Texture types accessed for each of the <texTarget>, and
+         coordinate mappings.  The "coordinates used" column indicate the
+         input values used for each coordinate of the texture lookup, the
+         layer selector for array textures, and the reference value for
+         texture comparisons."
+
+    -- Section 3.11.6.2 "TXP: Project coordinate and map to color"
+    
+       Add to the end of the section:
+       
+       "A program will fail to load if the TXP instruction is used in
+       conjunction with the SHADOWARRAY2D target."
+
+Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations)
+
+    -- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer"
+
+       Add to the end of the section (spec changes identical to
+       EXT_texture_array):
+
+       "The command
+
+         void FramebufferTextureLayerEXT(enum target, enum attachment,
+                                         uint texture, int level, int layer);
+
+       operates identically to FramebufferTexture3DEXT, except that it
+       attaches a single layer of a three-dimensional texture or a one- or
+       two-dimensional array texture.  <layer> is an integer indicating the
+       layer number, and is treated identically to the <zoffset> parameter in
+       FramebufferTexture3DEXT.  The error INVALID_VALUE is generated if
+       <layer> is negative.  The error INVALID_OPERATION is generated if
+       <texture> is non-zero and is not the name of a three dimensional
+       texture or one- or two-dimensional array texture.  Unlike
+       FramebufferTexture3D, no <textarget> parameter is accepted.
+
+       If <texture> is non-zero and the command does not result in an error,
+       the framebuffer attachment state corresponding to <attachment> is
+       updated as in the other FramebufferTexture commands, except that
+       FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>."
+
+    -- Section 4.4.4.1 "Framebuffer Attachment Completeness"
+
+      Add to the end of the list of completeness rules (spec changes
+      identical to EXT_texture_array):
+
+        "* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
+           FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or 
+           two-dimensional array texture, then
+           FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the
+           number of layers in the texture."
+
+Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
+
+    -- Section 5.4 "Display Lists"
+
+       Change the first paragraph on page 242 to say (spec changes
+       identical to EXT_texture_array):
+
+       "TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are
+       executed immediately when called with the corresponding proxy arguments
+       PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D,
+       PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT;
+       PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE,
+       PROXY_POST_CONVOLUTION_COLOR_TABLE, or
+       PROXY_POST_COLOR_MATRIX_COLOR_TABLE."
+
+Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
+
+    -- Section 6.1.3 "Enumerated Queries"
+
+       Add after the line beginning "If the value of
+       FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes
+       identical to EXT_texture_array):
+
+       "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the
+       texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
+       three-dimensional texture or a one- or two-dimensional array texture,
+       then <params> will contain the number of texture layer attached to the
+       attachment point.  Otherwise, <params> will contain the value zero."
+
+    -- Section 6.1.4 "Texture Queries"
+    
+       Change the first three paragraphs (page 248) to say (spec changes
+       identical to EXT_texture_array):
+
+       "The command
+
+         void GetTexImage(enum tex, int lod, enum format,
+                          enum type, void *img);
+
+       is used to obtain texture images. It is somewhat different from the
+       other get commands; tex is a symbolic value indicating which texture
+       (or texture face in the case of a cube map texture target name) is to
+       be obtained.  TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT,
+       and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional
+       texture, or one- or two-dimensional array texture, respectively.
+       TEXTURE_CUBE_MAP_POSITIVE_X, ...
+
+       GetTexImage obtains... from the first image to the last for
+       three-dimensional textures.  One- and two-dimensional array textures
+       are treated as two- and three-dimensional images, respectively, where
+       the layers are treated as rows or images.  These groups are then...
+
+       For three-dimensional and two-dimensional array textures, pixel storage
+       operations are applied as if the image were two-dimensional, except
+       that the additional pixel storage state values PACK_IMAGE_HEIGHT and
+       PACK_SKIP_IMAGES are applied. ..."
+
+Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
+
+    None
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Dependencies on ARB_fragment_program
+
+    If ARB_fragment_program is not supported, the changes to section 3.11
+    should be ignored.
+
+Dependencies on EXT_framebuffer_object
+
+    If EXT_framebuffer_object is not supported, the changes to section
+    3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored.
+
+Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc
+
+    (Identical dependency as EXT_texture_array.)
+
+    S3TC texture compression is supported for two-dimensional array textures.
+    When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
+    as a compressed two-dimensional textures.  When specifying or querying
+    compressed images using one of the S3TC formats, the images are provided
+    and/or returned as a series of two-dimensional textures stored
+    consecutively in memory, with the layer closest to zero specified first.
+    For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
+    the three-dimensional compression format provided in the
+    EXT_texture_compression_vtc extension.  Pixel store parameters, including
+    those specific to three-dimensional images, are ignored when compressed
+    image data are provided or returned, as in the
+    EXT_texture_compression_s3tc extension.
+
+    S3TC compression is not supported for one-dimensional texture targets in
+    EXT_texture_compression_s3tc, and is not supported for one-dimensional
+    array textures in this extension.  If compressed one-dimensional arrays
+    are needed, use a two-dimensional texture with a height of one.
+
+    This extension allows the use of the four S3TC internal format types in
+    TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls.
+
+Errors
+
+    None
+
+New State
+
+    (add to table 6.15, p. 276)
+
+                                                     Initial
+    Get Value                     Type   Get Command  Value Description           Sec.    Attribute
+    ----------------------------  -----  -----------  ----- --------------------  ------  ---------
+    TEXTURE_BINDING_1D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
+                                                            to TEXTURE_1D_ARRAY
+    TEXTURE_BINDING_2D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
+                                                            to TEXTURE_2D_ARRAY
+
+
+New Implementation Dependent State
+
+    (add to Table 6.32, p. 293)
+
+                                                    Minimum
+    Get Value                     Type  Get Command  Value  Description         Sec.  Attribute
+    ----------------------------  ----  ----------- ------- ------------------  ----- ---------
+    MAX_TEXTURE_ARRAY_LAYERS_EXT   Z+   GetIntegerv   64    maximum number of   3.8.1     -
+                                                            layers for texture
+                                                            arrays
+
+Issues
+
+    (1) Is "texture stack" a good name for this functionality?
+
+        NO.  The name is changed to "array texture" to match the
+        nomenclature used by GL_EXT_texture_array.
+
+    (2) Should the R texture coordinate be treated as normalized or
+    un-normalized?  If it were un-normalized, floor(R) could be thought
+    of as a direct index into the array texture.  This may be more
+    convenient for applications.
+
+        RESOLVED.  All texture coordinates are normalized.  The issue of
+        un-normalized texture coordinates has been discussed in the ARB
+        before and should be left for a layered extension.
+
+        RE-RESOLVED.  The R coordinate is un-normalized.  Accessing an array
+        using [0, layers-1] coordinates is much more natural.
+
+    (3) How does LOD selection work for stacked textures?
+
+        RESOLVED.  For 2D array textures the R coordinate is ignored, and
+        the LOD selection equations for 2D textures are used.  For 1D
+        array textures the T coordinate is ignored, and the LOD selection
+        equations for 1D textures are used.  The expected usage is in a
+        fragment program with an explicit LOD selection.
+
+    (4) What is the maximum size of a 2D array texture?  Is it the same
+    as for a 3D texture, or should a new query be added?  How about for 1D
+    array textures?
+
+        RESOLVED.  A new query is added.
+
+    (5) How are array textures exposed in GLSL?
+    
+        RESOLVED.  Use GL_EXT_texture_array.
+        
+    (6) Should a 1D array texture also be exposed?
+
+        RESOLVED.  For orthogonality, yes.
+
+    (7) How are stacked textures attached to framebuffer objects?
+
+        RESOLVED.  Layers of both one- and two-dimensional array textures
+        are attached using FreambufferTextureLayerEXT.  Once attached, the
+        array texture layer behaves exactly as either a one- or
+        two-dimensional texture.
+
+    (8) How is this extension related to GL_EXT_texture_array?
+    
+        This extension adapats GL_MESAX_texture_stack to the notation,
+        indexing, and FBO access of GL_EXT_texture_array.  This extension
+        replaces the GLSL support of GL_EXT_texture_array with
+        GL_ARB_fragment_program support.
+
+        Assembly program support is also provided by GL_NV_gpu_program4.
+        GL_NV_gpu_program4 also adds support for other features that are
+        specific to Nvidia hardware, while this extension adds only support
+        for array textures.
+
+        Much of text of this extension that has changed since
+        GL_MESAX_texture_stack comes directly from either
+        GL_EXT_texture_array or GL_NV_gpu_program4.
+
+Revision History
+
+    ||2005/11/15||0.1||idr||Initial draft MESAX version.||
+    ||2005/12/07||0.2||idr||Added framebuffer object interactions.||
+    ||2005/12/12||0.3||idr||Updated fragment program interactions.||
+    ||2007/05/16||0.4||idr||Converted to MESA_texture_array.  Brought in line with EXT_texture_array and NV_gpu_program4.||
diff --git a/docs/_extra/specs/MESA_texture_signed_rgba.spec b/docs/_extra/specs/MESA_texture_signed_rgba.spec
new file mode 100644 (file)
index 0000000..e3a6b59
--- /dev/null
@@ -0,0 +1,214 @@
+Name
+
+    MESA_texture_signed_rgba
+
+Name Strings
+
+    GL_MESA_texture_signed_rgba
+
+Contact
+
+
+
+Notice
+
+
+
+IP Status
+
+    No known IP issues
+
+Status
+
+
+
+Version
+
+    0.3, 2009-03-24
+
+Number
+
+    Not assigned ?
+
+Dependencies
+
+    Written based on the wording of the OpenGL 2.0 specification.
+
+    This extension trivially interacts with ARB_texture_float.
+    This extension shares some language with ARB_texture_compression_rgtc
+    but does not depend on it.
+
+Overview
+
+    OpenGL prior to 3.1 does not support any signed texture formats.
+    ARB_texture_compression_rgtc introduces some compressed red and
+    red_green signed formats but no uncompressed ones, which might
+    still be useful. NV_texture_shader adds signed texture formats,
+    but also a lot of functionality which has been superseded by fragment
+    shaders.
+    It is usually possible to get the same functionality
+    using a unsigned format by doing scale and bias in a shader, but this
+    is undesirable since modern hardware has direct support for this.
+    This extension adds a signed 4-channel texture format by backporting
+    the relevant features from OpenGL 3.1, as a means to support this in
+    OpenGL implementations only supporting older versions.
+
+Issues
+
+    1) What should this extension be called?
+
+       RESOLVED: MESA_texture_signed_rgba seems reasonable.
+       The rgba part is there because only 4 channel format is supported.
+
+
+    2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
+       be supported?
+
+       RESOLVED: NO. To keep this extension simple, only add the most
+       universal format, rgba. alpha/luminance can't be trivially supported
+       since OpenGL 3.1 does not support them any longer, and there is some
+       implied dependency on ARB_texture_rg for red/red_green formats so
+       avoid all this. Likewise, only 8 bits per channel is supported.
+
+
+    3) Should this extension use new enums for the texture formats?
+
+       RESOLVED: NO. Same enums as those used in OpenGL 3.1.
+
+
+    4) How are signed integer values mapped to floating-point values?
+
+       RESOLVED: Same as described in issue 5) of
+       ARB_texture_compression_rgtc (quote):
+       A signed 8-bit two's complement value X is computed to
+       a floating-point value Xf with the formula:
+
+                { X / 127.0, X > -128
+           Xf = {
+                { -1.0,      X == -128
+
+       This conversion means -1, 0, and +1 are all exactly representable,
+       however -128 and -127 both map to -1.0.  Mapping -128 to -1.0
+       avoids the numerical awkwardness of have a representable value
+       slightly more negative than -1.0.
+
+       This conversion is intentionally NOT the "byte" conversion listed
+       in Table 2.9 for component conversions.  That conversion says:
+
+           Xf = (2*X + 1) / 255.0
+
+       The Table 2.9 conversion is incapable of exactly representing
+       zero.
+
+       (Difference to ARB_texture_compression_rgtc):
+       This is the same mapping as OpenGL 3.1 uses.
+       This is also different to what NV_texture_shader used.
+       The above mapping should be considered the reference, but there
+       is some leeway so other mappings are allowed for implementations which
+       cannot do this. Particularly the mapping given in NV_texture_shader or
+       the standard OpenGL byte/float mapping is considered acceptable too, as
+       might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
+       127 (that is, uses different scale factors for negative and positive
+       numbers).
+       Also, it is ok to store incoming GL_BYTE user data as-is, without
+       converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
+       and converting back (using the mapping described here).
+       Other than those subtle issues there are no other non-standard
+       conversions used, so when using for instance CopyTexImage2D with
+       a framebuffer clamped to [0,1] all converted numbers will be in the range
+       [0, 127] (and not scaled and biased).
+
+
+    5) How will signed components resulting from RGBA8_SNORM texture
+       fetches interact with fragment coloring?
+
+       RESOLVED: Same as described in issue 6) of
+       ARB_texture_compression_rgtc (quote):
+       The specification language for this extension is silent
+       about clamping behavior leaving this to the core specification
+       and other extensions.  The clamping or lack of clamping is left
+       to the core specification and other extensions.
+
+       For assembly program extensions supporting texture fetches
+       (ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
+       etc.) or the OpenGL Shading Language, these signed formats will
+       appear as expected with unclamped signed components as a result
+       of a texture fetch instruction.
+
+       If ARB_color_buffer_float is supported, its clamping controls
+       will apply.
+
+       NV_texture_shader extension, if supported, adds support for
+       fixed-point textures with signed components and relaxed the
+       fixed-function texture environment clamping appropriately.  If the
+       NV_texture_shader extension is supported, its specified behavior
+       for the texture environment applies where intermediate values
+       are clamped to [-1,1] unless stated otherwise as in the case
+       of explicitly clamped to [0,1] for GL_COMBINE.  or clamping the
+       linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.
+
+       Otherwise, the conventional core texture environment clamps
+       incoming, intermediate, and output color components to [0,1].
+
+       This implies that the conventional texture environment
+       functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
+       using GLSL (and with none of the extensions referred to above)
+       is unable to make proper use of the signed texture formats added
+       by this extension because the conventional texture environment
+       requires texture source colors to be clamped to [0,1].  Texture
+       filtering of these signed formats would be still signed, but
+       negative values generated post-filtering would be clamped to
+       zero by the core texture environment functionality.  The
+       expectation is clearly that this extension would be co-implemented
+       with one of the previously referred to extensions or used with
+       GLSL for the new signed formats to be useful.
+
+
+    6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
+       functions?
+
+       RESOLVED: YES.
+
+
+    7) What to do with GetTexParameter if ARB_texture_float is supported,
+       in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
+       TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?
+
+       RESOLVED: ARB_texture_float states type is either NONE,
+       UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
+       SIGNED_NORMALIZED, which will be returned accordingly. This is the
+       same behaviour as in OpenGL 3.1.
+
+
+New Tokens
+
+
+    Accepted by the <internalformat> parameter of
+    TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
+
+        RGBA_SNORM                                0x8F93
+        RGBA8_SNORM                               0x8F97
+
+    Returned by the <params> parameter of GetTexLevelParameter:
+
+        SIGNED_NORMALIZED                         0x8F9C
+
+
+Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):
+
+ -- Section 3.8.1, Texture Image Specification
+
+    Add to Table 3.16 (page 154): Sized internal formats
+
+    Sized             Base             R    G    B    A    L    I    D
+    Internal Format   Internal Format bits bits bits bits bits bits bits
+    ---------------   --------------- ---- ---- ---- ---- ---- ---- ----
+    RGBA8_SNORM       RGBA             8    8    8    8    0    0    0
+
+
+Dependencies on ARB_texture_float extension:
+
+    If ARB_texture_float is supported, GetTexParameter queries with <value>
+    of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
+    TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
+    the base internal format is RGBA_SNORM.
diff --git a/docs/_extra/specs/MESA_window_pos.spec b/docs/_extra/specs/MESA_window_pos.spec
new file mode 100644 (file)
index 0000000..9e81e9c
--- /dev/null
@@ -0,0 +1,126 @@
+Name
+
+    MESA_window_pos
+
+Name Strings
+
+    GL_MESA_window_pos
+
+Contact
+
+    Brian Paul, brian.paul 'at' tungstengraphics.com
+
+Status
+
+    Shipping (since Mesa version 1.2.8)
+
+Version
+
+
+Number
+
+    197
+
+Dependencies
+
+    OpenGL 1.0 is required.
+    The extension is written against the OpenGL 1.2 Specification
+
+Overview
+
+    In order to set the current raster position to a specific window
+    coordinate with the RasterPos command, the modelview matrix, projection
+    matrix and viewport must be set very carefully.  Furthermore, if the
+    desired window coordinate is outside of the window's bounds one must
+    rely on a subtle side-effect of the Bitmap command in order to circumvent
+    frustum clipping.
+
+    This extension provides a set of functions to directly set the
+    current raster position, bypassing the modelview matrix, the
+    projection matrix and the viewport to window mapping.  Furthermore,
+    clip testing is not performed.
+
+    This greatly simplifies the process of setting the current raster
+    position to a specific window coordinate prior to calling DrawPixels,
+    CopyPixels or Bitmap.
+
+New Procedures and Functions
+
+    void WindowPos2dMESA(double x, double y)
+    void WindowPos2fMESA(float x, float y)
+    void WindowPos2iMESA(int x, int y)
+    void WindowPos2sMESA(short x, short y)
+    void WindowPos2ivMESA(const int *p)
+    void WindowPos2svMESA(const short *p)
+    void WindowPos2fvMESA(const float *p)
+    void WindowPos2dvMESA(const double *p)
+    void WindowPos3iMESA(int x, int y, int z)
+    void WindowPos3sMESA(short x, short y, short z)
+    void WindowPos3fMESA(float x, float y, float z)
+    void WindowPos3dMESA(double x, double y, double z)
+    void WindowPos3ivMESA(const int *p)
+    void WindowPos3svMESA(const short *p)
+    void WindowPos3fvMESA(const float *p)
+    void WindowPos3dvMESA(const double *p)
+    void WindowPos4iMESA(int x, int y, int z, int w)
+    void WindowPos4sMESA(short x, short y, short z, short w)
+    void WindowPos4fMESA(float x, float y, float z, float w)
+    void WindowPos4dMESA(double x, double y, double z, double )
+    void WindowPos4ivMESA(const int *p)
+    void WindowPos4svMESA(const short *p)
+    void WindowPos4fvMESA(const float *p)
+    void WindowPos4dvMESA(const double *p)
+
+New Tokens
+
+    none
+
+Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
+
+  - (2.12, p. 41) Insert after third paragraph:
+
+      Alternately, the current raster position may be set by one of the
+      WindowPosMESA commands:
+
+         void WindowPos{234}{sidf}MESA( T coords );
+         void WindowPos{234}{sidf}vMESA( T coords );
+
+      WindosPos4MESA takes four values indicating x, y, z, and w.
+      WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only
+      x, y, and z with w implicitly set to 1 (or only x and y with z
+      implicitly set to 0 and w implicitly set to 1).
+
+      WindowPosMESA operates like RasterPos except that the current modelview
+      matrix, projection matrix and viewport parameters are ignored and the
+      clip test operation always passes.  The current raster position values
+      are directly set to the parameters passed to WindowPosMESA.  The current
+      color, color index and texture coordinate update the current raster
+      position's associated data.
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    Not specified at this time.  However, a protocol message very similar
+    to that of RasterPos is expected.
+
+Errors
+
+    INVALID_OPERATION is generated if WindowPosMESA is called between
+    Begin and End.
+
+New State
+
+    None.
+
+New Implementation Dependent State
+
+    None.
+
+Revision History
+
+  * Revision 1.0 - Initial specification
+  * Revision 1.1 - Minor clean-up  (7 Jan 2000, Brian Paul)
+
diff --git a/docs/_extra/specs/MESA_ycbcr_texture.spec b/docs/_extra/specs/MESA_ycbcr_texture.spec
new file mode 100644 (file)
index 0000000..6a730e8
--- /dev/null
@@ -0,0 +1,204 @@
+Name
+
+    MESA_ycbcr_texture
+
+Name Strings
+
+    GL_MESA_ycbcr_texture
+
+Contact
+
+    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
+
+Status
+
+    Shipping (Mesa 4.0.4 and later)
+
+Version
+
+    1.0
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required
+    This extension is written against the OpenGL 1.4 Specification.
+    NV_texture_rectangle effects the definition of this extension.
+
+Overview
+
+    This extension supports texture images stored in the YCbCr format.
+    There is no support for converting YCbCr images to RGB or vice versa
+    during pixel transfer.  The texture's YCbCr colors are converted to
+    RGB during texture sampling, after-which, all the usual per-fragment
+    operations take place.  Only 2D texture images are supported (not
+    glDrawPixels, glReadPixels, etc).
+
+    A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
+    The first component is luminance (Y).  For pixels in even-numbered
+    image columns, the second component is Cb.  For pixels in odd-numbered
+    image columns, the second component is Cr.  If one were to convert the
+    data to RGB one would need to examine two pixels from columns N and N+1
+    (where N is even) to deduce the RGB color.
+
+IP Status
+
+    None
+
+Issues
+
+    None
+
+New Procedures and Functions
+
+    None
+
+New Tokens
+
+    Accepted by the <internalFormat> and <format> parameters of
+    TexImage2D and TexSubImage2D:
+
+        YCBCR_MESA                   0x8757
+
+    Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
+
+        UNSIGNED_SHORT_8_8_MESA      0x85BA /* same as Apple's */
+        UNSIGNED_SHORT_8_8_REV_MESA  0x85BB /* same as Apple's */
+
+Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
+    add the following to Table 3.8 (Packed pixel formats):
+    
+    type Parameter                GL Data   Number of        Matching
+     Token Name                    Type     Components     Pixel Formats
+    --------------                -------   ----------     -------------
+    UNSIGNED_SHORT_8_8_MESA       ushort         2         YCBCR_MESA
+    UNSIGNED_SHORT_8_8_REV_MESA   ushort         2         YCBCR_MESA
+
+
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
+    add the following to Table 3.10 (UNSIGNED_SHORT formats):
+
+    UNSIGNED_SHORT_8_8_MESA:
+
+      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
+    +-------------------------------+-------------------------------+
+    |              1st              |              2nd              |
+    +-------------------------------+-------------------------------+
+                        
+    UNSIGNED_SHORT_8_8_REV_MESA:
+
+      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
+    +-------------------------------+-------------------------------+
+    |              2nd              |              1st              |
+    +-------------------------------+-------------------------------+
+
+
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
+    add the following to Table 3.12 (Packed pixel field assignments):
+
+                       First       Second     Third      Fourth
+    Format             Element     Element    Element    Element
+    ------             -------     -------    -------    -------
+    YCBCR_MESA         luminance   chroma
+
+
+    In section 3.8.1, Texture Image Specification, on page 125, add
+    another item to the list of TexImage2D and TexImage3D equivalence
+    exceptions:
+
+    * The value of internalformat and format may be YCBCR_MESA to
+      indicate that the image data is in YCbCr format.  type must
+      be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA
+      as seen in tables 3.8 and 3.10.  Table 3.12 describes the mapping
+      between Y and Cb/Cr to the components.
+      If NV_texture_rectangle is supported target may also be
+      TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
+      All pixel transfer operations are bypassed.  The texture is stored as
+      YCbCr, not RGB.  Queries of the texture's red, green and blue component
+      sizes will return zero.  The YCbCr colors are converted to RGB during
+      texture sampling using an implementation dependent conversion.
+
+
+    In section 3.8.1, Texture Image Specification, on page 126, add
+    another item to the list of TexImage1D and TexImage2D equivalence
+    exceptions:
+
+    * The value of internalformat and format can not be YCBCR_MESA.
+
+
+    In section 3.8.2, Alternate Texture Image Specification Commands, on
+    page 129, insert this paragraph after the first full paragraph on the
+    page:
+
+         "If the internal storage format of the image being updated by
+    TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA.
+    The error INVALID_OPERATION will be generated otherwise."
+
+
+Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+    None
+
+Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
+State Requests)
+
+    None
+
+Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
+
+    None
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Errors
+
+    INVALID_ENUM is generated by TexImage2D if <internalFormat> is
+    MESA_YCBCR but <format> is not MESA_YCBCR.
+
+    INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but
+    <internalFormat> is not MESA_YCBCR.
+
+    INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and
+    <internalFormat> is MESA_YCBCR and <border> is not zero.
+
+    INVALID_OPERATION is generated by TexSubImage2D if the internal image
+    format is YCBCR_MESA and <format> is not YCBCR_MESA.
+
+    INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
+    image is YCBCR_MESA.
+    
+New State
+
+    Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT
+    from n x Z42 to n x Z43 to indicate that internal format may also be
+    YCBCR_MESA.
+
+Revision History
+
+    20 September 2002 - Initial draft
+    29 April 2003 - minor updates
+     3 September 2003 - further clarify when YCbCr->RGB conversion takes place
+    19 September 2003 - a few more updates prior to submitting to extension
+                        registry.
+     3 April 2004 - fix assorted inaccuracies
diff --git a/docs/_extra/specs/OLD/EGL_MESA_screen_surface.txt b/docs/_extra/specs/OLD/EGL_MESA_screen_surface.txt
new file mode 100644 (file)
index 0000000..698a240
--- /dev/null
@@ -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/docs/_extra/specs/OLD/MESA_agp_offset.spec b/docs/_extra/specs/OLD/MESA_agp_offset.spec
new file mode 100644 (file)
index 0000000..ac5ad7d
--- /dev/null
@@ -0,0 +1,94 @@
+Name
+
+    MESA_agp_offset
+
+Name Strings
+
+    GLX_MESA_agp_offset
+
+Contact
+
+    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
+
+Status
+
+    Obsolete. Effectively superseded by ARB_vertex_buffer_object.
+
+Version
+
+    1.0
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.0 or later is required
+    GLX_NV_vertex_array_range is required.
+    This extensions is written against the OpenGL 1.4 Specification.
+
+Overview
+
+    This extensions provides a way to convert pointers in an AGP memory
+    region into byte offsets into the AGP aperture.
+    Note, this extension depends on GLX_NV_vertex_array_range, for which
+    no real specification exists.  See GL_NV_vertex_array_range for more
+    information.
+
+IP Status
+
+    None
+
+Issues
+
+    None
+
+New Procedures and Functions
+
+    unsigned int glXGetAGPOffsetMESA( const void *pointer )
+
+New Tokens
+
+    None
+
+Additions to the OpenGL 1.4 Specification
+
+    None
+
+Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
+
+    Add a new section, 3.6 as follows:
+
+    3.6 AGP Memory Access
+
+    On "PC" computers, AGP memory can be allocated with glXAllocateMemoryNV
+    and freed with glXFreeMemoryNV.  Sometimes it's useful to know where a
+    block of AGP memory is located with respect to the start of the AGP
+    aperture.  The function
+
+        GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
+
+    Returns the offset of the given memory block from the start of AGP
+    memory in basic machine units (i.e. bytes).  If pointer is invalid
+    the value ~0 will be returned.
+
+GLX Protocol
+
+    None.  This is a client side-only extension.
+
+Errors
+
+    glXGetAGPOffsetMESA will return ~0 if the pointer does not point to
+    an AGP memory region.
+
+New State
+
+    None
+
+Revision History
+
+    20 September 2002 - Initial draft
+    2 October 2002 - finished GLX chapter 3 additions
+    27 July 2004 - use unsigned int instead of GLuint, void instead of GLvoid
diff --git a/docs/_extra/specs/OLD/MESA_packed_depth_stencil.spec b/docs/_extra/specs/OLD/MESA_packed_depth_stencil.spec
new file mode 100644 (file)
index 0000000..112b730
--- /dev/null
@@ -0,0 +1,230 @@
+Name
+
+    MESA_packed_depth_stencil
+
+Name Strings
+
+    GL_MESA_packed_depth_stencil
+
+Contact
+
+    Keith Whitwell, VA Linux Systems Inc. (keithw 'at' valinux.com)
+    Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
+
+Status
+
+    Obsolete.
+
+Version
+
+
+Number
+
+    ???
+
+Dependencies
+
+    EXT_abgr affects the definition of this extension
+    SGIS_texture4D affects the definition of this extension
+    EXT_cmyka affects the definition of this extension
+    ARB_packed_pixels affects the definition of this extension
+
+Overview
+       
+    Provides a mechanism for DrawPixels and ReadPixels to efficiently
+    transfer depth and stencil image data.  Specifically, we defined new
+    packed pixel formats and types which pack both stencil and depth
+    into one value.
+
+Issues:
+
+    1. Is this the right way to distinguish between 24/8 and 8/24
+       pixel formats?  Should we instead provide both:
+       
+       GL_DEPTH_STENCIL_MESA
+       GL_STENCIL_DEPTH_MESA
+
+       And perhaps just use GL_UNSIGNED_INT, GL_UNSIGNED_SHORT ?
+
+    2. If not, is it correct to use _REV to indicate that stencil
+       preceeds depth in the 1_15 and 8_24 formats?
+
+    3. Do we really want the GL_UNSIGNED_SHORT formats?  
+
+       
+New Procedures and Functions
+
+    None.
+
+New Tokens
+    
+    Accepted by the <format> parameter of ReadPixels and DrawPixels:
+
+       GL_DEPTH_STENCIL_MESA           0x8750
+
+    Accepted by the <type> parameter of ReadPixels and DrawPixels:
+
+       GL_UNSIGNED_INT_24_8_MESA       0x8751
+       GL_UNSIGNED_INT_8_24_REV_MESA   0x8752
+       GL_UNSIGNED_SHORT_15_1_MESA     0x8753
+       GL_UNSIGNED_SHORT_1_15_REV_MESA 0x8754
+
+Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the 1.1 Specification (Rasterization)
+
+    One entry is added to table 3.5 (DrawPixels and ReadPixels formats).
+    The new table is:
+
+                       Target
+       Format Name     Buffer  Element Meaning and Order
+       -----------     ------  -------------------------
+       COLOR_INDEX     Color   Color index
+       STENCIL_INDEX   Stencil Stencil index
+       DEPTH_COMPONENT Depth   Depth component
+       RED             Color   R component
+       GREEN           Color   G component
+       BLUE            Color   B component
+       ALPHA           Color   A component
+       RGB             Color   R, G, B components
+       RGBA            Color   R, G, B, A components
+       BGRA            Color   B, G, R, A components
+       ABGR_EXT        Color   A, B, G, R components
+       CMYK_EXT        Color   Cyan, Magenta, Yellow, Black components
+       CMYKA_EXT       Color   Cyan, Magenta, Yellow, Black, A components
+       LUMINANCE       Color   Luminance component
+       LUMINANCE_ALPHA Color   Luminance, A components
+       DEPTH_STENCIL   Depth,  Depth component, stencil index.
+                       Stencil
+
+       Table 3.5: DrawPixels and ReadPixels formats.  The third column
+       gives a description of and the number and order of elements in a
+       group.
+
+    Add to the description of packed pixel formats:
+
+       <type> Parameter                Data    of        Matching
+       Token Name                      Type    Elements  Pixel Formats
+       ----------------                ----    --------  -------------
+
+       UNSIGNED_BYTE_3_3_2           ubyte   3       RGB
+       UNSIGNED_BYTE_2_3_3_REV       ubyte   3       RGB
+       UNSIGNED_SHORT_5_6_5          ushort  3       RGB
+       UNSIGNED_SHORT_5_6_5_REV      ushort  3       RGB
+       UNSIGNED_SHORT_4_4_4_4        ushort  4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
+       UNSIGNED_SHORT_4_4_4_4_REV    ushort  4       RGBA,BGRA
+       UNSIGNED_SHORT_5_5_5_1        ushort  4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
+       UNSIGNED_SHORT_1_5_5_5_REV    ushort  4       RGBA,BGRA
+       UNSIGNED_INT_8_8_8_8          uint    4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
+       UNSIGNED_INT_8_8_8_8_REV      uint    4       RGBA,BGRA
+       UNSIGNED_INT_10_10_10_2       uint    4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
+       UNSIGNED_INT_2_10_10_10_REV   uint    4       RGBA,BGRA
+       UNSIGNED_SHORT_15_1_MESA      ushort  2       DEPTH_STENCIL_MESA
+       UNSIGNED_SHORT_1_15_REV_MESA  ushort  2       DEPTH_STENCIL_MESA
+       UNSIGNED_SHORT_24_8_MESA      ushort  2       DEPTH_STENCIL_MESA
+       UNSIGNED_SHORT_8_24_REV_MESA  ushort  2       DEPTH_STENCIL_MESA
+
+       UNSIGNED_INT_8_24:
+
+            31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
+           +-----------------------+-----------------------------------------------------------------------+
+           |                       |                                                                       |
+           +-----------------------+-----------------------------------------------------------------------+
+
+                   first                                       second              
+                   element                                     element             
+
+
+       UNSIGNED_INT_24_8:
+
+            31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
+           +----------------------------------------------------------------------+------------------------+
+           |                                                                      |                        |
+           +----------------------------------------------------------------------+------------------------+
+
+                   first                                                                 second                    
+                   element                                                               element                   
+
+       UNSIGNED_SHORT_15_1:
+
+             15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
+           +-----------------------------------------------------------+---+
+           |                                                           |   |
+           +-----------------------------------------------------------+---+
+
+                       first                                           second  
+                       element                                         element 
+
+
+       UNSIGNED_SHORT_1_15_REV:
+
+             15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
+           +---+-----------------------------------------------------------+
+           |   |                                                           |
+           +---+-----------------------------------------------------------+
+
+           second                  first
+           element                 element
+
+    The assignment of elements to fields in the packed pixel is as
+    described in the table below:
+
+                          First       Second   Third       Fourth
+       Format             Element     Element  Element     Element
+       ------             -------     -------  -------     -------
+       RGB                red         green    blue
+       RGBA               red         green    blue        alpha
+       BGRA               blue        green    red         alpha
+       ABGR_EXT           alpha       blue     green       red
+       CMYK_EXT           cyan        magenta  yellow      black
+       DEPTH_STENCIL_MESA depth       stencil
+
+Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
+and the Frame Buffer)
+
+    The new format is added to the discussion of Obtaining Pixels from the
+    Framebuffer.  It should read " If the <format> is one of RED, GREEN,
+    BLUE, ALPHA, RGB, RGBA, ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, and
+    the GL is in color index mode, then the color index is obtained."
+
+    The new format is added to the discussion of Index Lookup.  It should
+    read "If <format> is one of RED, GREEN, BLUE, ALPHA, RGB, RGBA,
+    ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, then the index is used to
+    reference 4 tables of color components: PIXEL_MAP_I_TO_R,
+    PIXEL_MAP_I_TO_G, PIXEL_MAP_I_TO_B, and PIXEL_MAP_I_TO_A."
+
+
+Additions to Chapter 5 of the 1.1 Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
+
+    None
+
+Additions to the GLX Specification
+
+    None
+
+GLX Protocol
+
+    TBD
+
+Errors
+
+    None
+
+New State
+
+    None
+
+Revision History
+
+    Version 1.0 - 23 Sep 2000
+        Keith's original version.
+
+    Version 1.1 - 3 Nov 2000
+        Brian's edits, assigned values to new enums.
+
diff --git a/docs/_extra/specs/OLD/MESA_program_debug.spec b/docs/_extra/specs/OLD/MESA_program_debug.spec
new file mode 100644 (file)
index 0000000..dd4b43b
--- /dev/null
@@ -0,0 +1,356 @@
+Name
+
+    MESA_program_debug
+
+Name Strings
+
+    GL_MESA_program_debug
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Obsolete.
+
+Version
+
+    Last Modified Date: July 20, 2003
+    Author Revision: 1.0
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.4 is required
+    The extension is written against the OpenGL 1.4 specification.
+    ARB_vertex_program or ARB_fragment_program or NV_vertex_program
+    or NV_fragment_program is required.
+
+Overview
+
+    The extension provides facilities for implementing debuggers for
+    vertex and fragment programs.
+
+    The concept is that vertex and fragment program debuggers will be
+    implemented outside of the GL as a utility package.  This extension
+    only provides the minimal hooks required to implement a debugger.
+
+    There are facilities to do the following:
+    1. Have the GL call a user-specified function prior to executing
+       each vertex or fragment instruction.
+    2. Query the current program string's execution position.
+    3. Query the current values of intermediate program values.
+
+    The main feature is the ProgramCallbackMESA function.  It allows the
+    user to register a callback function with the GL.  The callback will
+    be called prior to executing each vertex or fragment program instruction.
+
+    From within the callback, the user may issue Get* commands to
+    query current GL state.  The GetProgramRegisterfvMESA function allows
+    current program values to be queried (such as temporaries, input
+    attributes, and result registers).
+
+    There are flags for enabling/disabling the program callbacks.
+
+    The current execution position (as an offset from the start of the
+    program string) can be queried with
+    GetIntegerv(GL_FRAGMENT_PROGRAM_POSITION_MESA, &pos) or
+    GetIntegerv(GL_VERTEX_PROGRAM_POSITION_MESA, &pos).
+
+
+IP Status
+
+    None
+
+Issues
+
+    1. Is this the right model for a debugger?
+
+       It seems prudent to minimize the scope of this extension and leave
+       it up to the developer (or developer community) to write debuggers
+       that layer on top of this extension.
+
+       If the debugger were fully implemented within the GL it's not
+       clear how terminal and GUI-based interfaces would work, for
+       example.
+
+    2. There aren't any other extensions that register callbacks with
+       the GL.  Isn't there another solution?
+
+       If we want to be able to single-step through vertex/fragment
+       programs I don't see another way to do it.
+
+    3. How do we prevent the user from doing something crazy in the
+       callback function, like trying to call glBegin (leading to
+       recursion)?
+
+       The rule is that the callback function can only issue glGet*()
+       functions and no other GL commands.  It could be difficult to
+       enforce this, however.  Therefore, calling any non-get GL
+       command from within the callback will result in undefined
+       results.    
+
+    4. Is this extension amenable to hardware implementation?
+
+       Hopefully, but if not, the GL implementation will have to fall
+       back to a software path when debugging.  This may be acceptable
+       for debugging.
+
+    5. What's the <data> parameter to ProgramCallbackMESA for?
+
+       It's a common programming practice to associate a user-supplied
+       value with callback functions.
+
+    6. Debuggers often allow one to modify intermediate program values,
+       then continue.  Does this extension support that?
+
+       No.
+
+
+New Procedures and Functions (and datatypes)
+
+    typedef void (*programcallbackMESA)(enum target, void *data)
+
+    void ProgramCallbackMESA(enum target, programcallbackMESA callback,
+                             void *data)
+
+    void GetProgramRegisterfvMESA(enum target, sizei len,
+                                  const ubyte *registerName, float *v)
+
+New Tokens
+
+    Accepted by the <cap> parameter of Enable, Disable, IsEnabled,
+    GetBooleanv, GetDoublev, GetFloatv and GetIntegerv:
+
+        FRAGMENT_PROGRAM_CALLBACK_MESA      0x8bb1
+        VERTEX_PROGRAM_CALLBACK_MESA        0x8bb4
+
+    Accepted by the <pname> parameter GetBooleanv, GetDoublev,
+    GetFloatv and GetIntegerv:
+
+        FRAGMENT_PROGRAM_POSITION_MESA      0x8bb0
+        VERTEX_PROGRAM_POSITION_MESA        0x8bb5
+
+    Accepted by the <pname> parameter of GetPointerv:
+
+        FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x8bb2
+        FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x8bb3
+        VERTEX_PROGRAM_CALLBACK_FUNC_MESA   0x8bb6
+        VERTEX_PROGRAM_CALLBACK_DATA_MESA   0x8bb7
+
+Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
+
+    None.
+
+Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+
+    None.
+
+Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+    None.
+
+Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
+
+    In section 5.4 "Display Lists", page 202, add the following command
+    to the list of those that are not compiled into display lists:
+
+        ProgramCallbackMESA.
+
+
+    Add a new section 5.7 "Callback Functions"
+
+    The function
+
+        void ProgramCallbackMESA(enum target, programcallbackMESA callback,
+                                 void *data)
+
+    registers a user-defined callback function with the GL.  <target>
+    may be FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB.  The enabled
+    callback functions registered with these targets will be called
+    prior to executing each instruction in the current fragment or
+    vertex program, respectively.  The callbacks are enabled and
+    disabled by calling Enable or Disable with <cap>
+    FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB.
+
+    The callback function's signature must match the typedef
+
+        typedef void (*programcallbackMESA)(enum target, void *data)
+
+    When the callback function is called, <target> will either be
+    FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB to indicate which
+    program is currently executing and <data> will be the value
+    specified when ProgramCallbackMESA was called.
+
+    From within the callback function, only the following GL commands
+    may be called:
+
+        GetBooleanv
+        GetDoublev
+        GetFloatv
+        GetIntegerv
+        GetProgramLocalParameter
+        GetProgramEnvParameter
+        GetProgramRegisterfvMESA
+        GetProgramivARB
+        GetProgramStringARB
+        GetError
+
+    Calling any other command from within the callback results in
+    undefined behaviour.
+
+
+Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
+State Requests)
+
+    Add a new section 6.1.3 "Program Value Queries":
+
+    The command
+
+        void GetProgramRegisterfvMESA(enum target, sizei len,
+                                      const ubyte *registerName,
+                                      float *v)
+        
+    Is used to query the value of program variables and registers
+    during program execution.  GetProgramRegisterfvMESA may only be
+    called from within a callback function registered with
+    ProgramCallbackMESA.
+
+    <registerName> and <len> specify the name a variable, input
+    attribute, temporary, or result register in the program string.
+    The current value of the named variable is returned as four
+    values in <v>.  If <name> doesn't exist in the program string,
+    the error INVALID_OPERATION is generated.
+
+Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
+
+    None.
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None.
+
+GLX Protocol
+
+    XXX TBD
+
+Dependencies on NV_vertex_program and NV_fragment_program
+
+    If NV_vertex_program and/or NV_fragment_program are supported,
+    vertex and/or fragment programs defined by those extensions may
+    be debugged as well.  Register queries will use the syntax used
+    by those extensions (i.e. "v[X]" to query vertex attributes,
+    "o[X]" for vertex outputs, etc.)
+
+Errors
+
+    INVALID_OPERATION is generated if ProgramCallbackMESA is called
+    between Begin and End.
+
+    INVALID_ENUM is generated by ProgramCallbackMESA if <target> is not
+    a supported vertex or fragment program type.
+
+    Note: INVALID_OPERAION IS NOT generated by GetProgramRegisterfvMESA,
+    GetBooleanv, GetDoublev, GetFloatv, or GetIntegerv if called between
+    Begin and End when a vertex or fragment program is currently executing.
+
+    INVALID_ENUM is generated by ProgramCallbackMESA,
+    GetProgramRegisterfvMESA if <target> is not a program target supported
+    by ARB_vertex_program, ARB_fragment_program (or NV_vertex_program or
+    NV_fragment_program).
+
+    INVALID_VALUE is generated by GetProgramRegisterfvMESA if <registerName>
+    does not name a known program register or variable.
+
+    INVALID_OPERATION is generated by GetProgramRegisterfvMESA when a
+    register query is attempted for a program target that's not currently
+    being executed.
+
+
+New State
+
+    XXX finish
+
+(table 6.N, p. ###)
+                                                            Initial
+    Get Value                            Type Get Command   Value    Description  Sec.  Attribute
+    ---------                            ---- -----------   -----    -----------  ----  ---------
+    FRAGMENT_PROGRAM_CALLBACK_MESA        B   IsEnabled     FALSE    XXX          XXX   enable
+    VERTEX_PROGRAM_CALLBACK_MESA          B   IsEnabled     FALSE    XXX          XXX   enable
+    FRAGMENT_PROGRAM_POSITION_MESA        Z+  GetIntegerv   -1       XXX          XXX   -
+    VERTEX_PROGRAM_POSITION_MESA          Z+  GetIntegerv   -1       XXX          XXX   -
+    FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA   P   GetPointerv   NULL     XXX          XXX   -
+    VERTEX_PROGRAM_CALLBACK_FUNC_MESA     P   GetPointerv   NULL     XXX          XXX   -
+    FRAGMENT_PROGRAM_CALLBACK_DATA_MESA   P   GetPointerv   NULL     XXX          XXX   -
+    VERTEX_PROGRAM_CALLBACK_DATA_MESA     P   GetPointerv   NULL     XXX          XXX   -
+
+    XXX more?
+
+New Implementation Dependent State
+
+    None.
+
+Revision History
+
+    8 July 2003
+        Initial draft. (Brian Paul)
+    11 July 2003
+        Second draft. (Brian Paul)
+    20 July 2003
+        Third draft.  Lots of fundamental changes. (Brian Paul)
+    23 July 2003
+        Added chapter 5 and 6 spec language. (Brian Paul)
+
+Example Usage
+
+   The following is a very simple example of how this extension may
+   be used to print the values of R0, R1, R2 and R3 while executing
+   vertex programs.
+
+
+    /* This is called by the GL when the vertex program is executing.
+     * We can only make glGet* calls from within this function!
+     */
+    void DebugCallback(GLenum target, GLvoid *data)
+    {
+       GLint pos;
+       GLuint i;
+
+       /* Get PC and current instruction string */
+       glGetIntegerv(GL_VERTEX_PROGRAM_POSITION_ARB, &pos);
+
+       printf("Current position: %d\n", pos);
+
+       printf("Current temporary registers:\n");
+       for (i = 0; i < 4; i++) {
+         GLfloat v[4];
+         char s[10];
+         sprintf(s, "R%d", i);
+         glGetProgramRegisterfvMESA(GL_VERTEX_PROGRAM_ARB, strlen(s), s, v);
+         printf("R%d = %g, %g, %g, %g\n", i, v[0], v[1], v[2], v[3]);
+       }
+    }
+
+
+    /*
+     * elsewhere...
+     */
+
+    /* Register our debugger callback function */
+    glProgramCallbackMESA(GL_VERTEX_PROGRAM_ARB, DebugCallback, NULL);
+    glEnable(GL_VERTEX_PROGRAM_CALLBACK_MESA);
+
+    /* define/bind a vertex program */
+
+    glEnable(GL_VERTEX_PROGRAM);
+
+    /* render something */
+    glBegin(GL_POINTS);
+    glVertex2f(0, 0);
+    glEnd();
+
diff --git a/docs/_extra/specs/OLD/MESA_resize_buffers.spec b/docs/_extra/specs/OLD/MESA_resize_buffers.spec
new file mode 100644 (file)
index 0000000..aed3caf
--- /dev/null
@@ -0,0 +1,81 @@
+Name
+
+    MESA_resize_buffers
+
+Name Strings
+
+    GL_MESA_resize_buffers
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Obsolete.
+
+Version
+
+
+Number
+
+    196
+
+Dependencies
+
+    Mesa 2.2 or later is required.
+
+Overview
+
+    Mesa is often used as a client library with no integration with
+    the computer's window system (an X server, for example).  And since
+    Mesa does not have an event loop nor window system callbacks, it
+    cannot properly respond to window system events.  In particular,
+    Mesa cannot automatically detect when a window has been resized.
+
+    Mesa's glViewport command queries the current window size and updates
+    its internal data structors accordingly.  This normally works fine
+    since most applications call glViewport in response to window size
+    changes.
+
+    In some situations, however, the application may not call glViewport
+    when a window size changes but would still like Mesa to adjust to
+    the new window size.  This extension exports a new function to solve
+    this problem.
+
+New Procedures and Functions
+
+    void glResizeBuffersMESA( void )
+
+New Tokens
+
+    none
+
+Additions to the OpenGL Specification (no particular section)
+
+    The glResizeBuffersMESA command may be called when the client
+    determines that a window has been resized.  Calling
+    glResizeBuffersMESA causes Mesa to query the current window size
+    and adjust its internal data structures.  This may include
+    reallocating depth, stencil, alpha and accumulation buffers.
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+Errors
+
+    INVALID_OPERATION is generated if glResizeBuffersMESA is called between
+    Begin and End.
+
+New State
+
+    None.
+
+New Implementation Dependent State
+
+    None.
+
+Revision History
+
+  * Revision 1.0 - Initial specification
diff --git a/docs/_extra/specs/OLD/MESA_set_3dfx_mode.spec b/docs/_extra/specs/OLD/MESA_set_3dfx_mode.spec
new file mode 100644 (file)
index 0000000..e4eea2a
--- /dev/null
@@ -0,0 +1,85 @@
+Name
+
+    MESA_set_3dfx_mode
+
+Name Strings
+
+    GLX_MESA_set_3dfx_mode
+
+Contact
+
+    Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+    Obsolete.
+
+Version
+
+    Last Modified Date:  8 June 2000
+
+Number
+
+    218
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    The Mesa Glide driver allows full-screen rendering or rendering into
+    an X window.  The glXSet3DfxModeMESA() function allows an application
+    to switch between full-screen and windowed rendering.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    GLboolean glXSet3DfxModeMESA( GLint mode );
+
+New Tokens
+
+    GLX_3DFX_WINDOW_MODE_MESA      0x1
+    GLX_3DFX_FULLSCREEN_MODE_MESA   0x2
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    The Mesa Glide device driver allows either rendering in full-screen
+    mode or rendering into an X window.  An application can switch between
+    full-screen and window rendering with the command:
+
+       GLboolean glXSet3DfxModeMESA( GLint mode );
+
+    <mode> may either be GLX_3DFX_WINDOW_MODE_MESA to indicate window
+    rendering or GLX_3DFX_FULLSCREEN_MODE_MESA to indicate full-screen mode.
+
+    GL_TRUE is returned if <mode> is valid and the operation completed
+    normally.  GL_FALSE is returned if <mode> is invalid or if the Glide
+    driver is not being used.
+
+    Note that only one drawable and context can be created at any given
+    time with the Mesa Glide driver.
+
+GLX Protocol
+
+    None since this is a client-side extension.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    8 June 2000 - initial specification
diff --git a/docs/_extra/specs/OLD/MESA_sprite_point.spec b/docs/_extra/specs/OLD/MESA_sprite_point.spec
new file mode 100644 (file)
index 0000000..b50d78e
--- /dev/null
@@ -0,0 +1,190 @@
+Name
+
+    MESA_sprite_point
+
+Name Strings
+
+    GL_MESA_sprite_point
+
+Contact
+
+    Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
+
+Status
+
+    Obsolete - see GL_ARB_point_sprite.
+
+Version
+
+
+Number
+
+    ???
+
+Dependencies
+
+    GL_EXT_point_parameters effects the definition of this extension
+    GL_ARB_multitexture effects the definition of this extension
+
+Overview
+       
+    This extension modifies the way in which points are rendered,
+    specifically when they're textured.  When SPRITE_POINT_MESA is enabled
+    a point is rendered as if it were a quadrilateral with unique texture
+    coordinates at each vertex.  This extension effectively turns points
+    into sprites which may be rendered more easily and quickly than using
+    conventional textured quadrilaterals.
+
+    When using point size > 1 or attenuated points this extension is an
+    effective way to render many small sprite images for particle systems
+    or other effects.
+
+Issues:
+
+    1. How are the texture coordinates computed?
+
+       The lower-left corner has texture coordinate (0,0,r,q).
+       The lower-right, (1,0,r,q).  The upper-right, (1,1,r,q).
+       The upper-left, (0,1,r,q).
+
+    2. What about texgen and texture matrices?
+
+       Texgen and the texture matrix have no effect on the point's s and t
+       texture coordinates.  The r and q coordinates may have been computed
+       by texgen or the texture matrix.  Note that with a 3D texture and/or
+       texgen that the r coordinate could be used to select a slice in the
+       3D texture.
+
+    3. What about point smoothing?
+
+       When point smoothing is enabled, a triangle fan could be rendered
+       to approximate a circular point.  This could be problematic to
+       define and implement so POINT_SMOOTH is ignored when drawing sprite
+       points.
+
+       Smoothed points can be approximated by using an appropriate texture
+       images, alpha testing and blending.
+
+       POLYGON_SMOOTH does effect the rendering of the quadrilateral, however.
+
+    4. What about sprite rotation?
+
+       There is none.  Sprite points are always rendered as window-aligned
+       squares.  One could define rotated texture images if desired.  A 3D
+       texture and appropriate texture r coordinates could be used to
+       effectively specify image rotation per point.
+
+    5. What about POLYGON_MODE?
+
+       POLYGON_MODE does not effect the rasterization of the quadrilateral.
+
+    6. What about POLYGON_CULL?
+
+       TBD.  Polygon culling is normally specified and implemented in the
+       transformation stage of OpenGL.  However, some rasterization hardware
+       implements it later during triangle setup.
+
+       Polygon culling wouldn't be useful for sprite points since the
+       quadrilaterals are always defined in counter-clockwise order in
+       window space.  For that reason, polygon culling should probably be
+       ignored.
+
+    7. Should sprite points be alpha-attenuated if their size is below the
+       point parameter's threshold size?
+
+    8. Should there be an advertisized maximum sprite point size?
+
+       No.  Since we're rendering the point as a quadrilateral there's no
+       need to limit the size.
+
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+    
+    Accepted by the <pname> parameter of Enable, Disable, IsEnabled,
+    GetIntegerv, GetBooleanv, GetFloatv and GetDoublev:
+
+       SPRITE_POINT_MESA               0x????
+        MAX_SPRITE_POINT_SIZE_MESA      0x????   (need this?)
+
+Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the 1.1 Specification (Rasterization)
+
+    Section ???.
+
+    When SPRITE_POINT_MESA is enabled points are rasterized as screen-
+    aligned quadrilaterals.  If the four vertices of the quadrilateral
+    are labeled A, B, C, and D, starting at the lower-left corner and moving
+    counter-clockwise around the quadrilateral, then the vertex and
+    texture coordinates are computed as follows:
+
+      vertex   window coordinate       texture coordinate
+        A      (x-r, y-r, z, w)          (0, 0, r, q)
+        B      (x+r, y-r, z, w)          (1, 0, r, q)
+        C      (x+r, y+r, z, w)          (1, 1, r, q)
+        D      (x-r, y+r, z, w)          (0, 1, r, q)
+
+    where x, y, z, w are the point's window coordinates, r and q are the
+    point's 3rd and 4th texture coordinates  and r is half the point's
+    size.  The other vertex attributes (such as the color and fog coordinate)
+    are simply duplicated from the original point vertex.
+
+    Point size may either be specified with PointSize or computed
+    according to the EXT_point_parameters extension.
+
+    The new texture coordinates are not effected by texgen or the texture
+    matrix.  Note, however, that the texture r and q coordinates are passed
+    unchanged and may have been computed with texgen and/or the texture
+    matrix.
+
+    If multiple texture units are present the same texture coordinate is
+    used for all texture units.
+
+    The point is then rendered as if it were a quadrilateral using the
+    normal point sampling rules.  POLYGON_MODE does not effect the
+    rasterization of the quadrilateral but POLYGON_SMOOTH does.
+
+    POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled.
+
+Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
+and the Frame Buffer)
+
+    None.
+
+Additions to Chapter 5 of the 1.1 Specification (Special Functions)
+
+    None
+
+Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
+
+    None
+
+Additions to the GLX Specification
+
+    None
+
+GLX Protocol
+
+    TBD
+
+Errors
+
+    None
+
+New State
+
+    Add boolean variable SPRITE_POINT_MESA to the point attribute group.
+
+Revision History
+
+    Version 1.0 - 4 Dec 2000
+        Original draft.
+
+
+
diff --git a/docs/_extra/specs/OLD/MESA_trace.spec b/docs/_extra/specs/OLD/MESA_trace.spec
new file mode 100644 (file)
index 0000000..dc4166e
--- /dev/null
@@ -0,0 +1,359 @@
+Name
+
+     MESA_trace
+
+Name Strings
+
+     GL_MESA_trace
+
+Contact
+    
+    Bernd Kreimeier, Loki Entertainment, bk 'at' lokigames.com
+    Brian Paul, VA Linux Systems, Inc., brianp 'at' valinux.com
+
+Status
+
+    Obsolete.
+
+Version
+
+
+Number
+
+    none yet
+
+Dependencies
+
+    OpenGL 1.2 is required.
+    The extension is written against the OpenGL 1.2 Specification
+
+Overview
+
+    Provides the application with means to enable and disable logging
+    of GL calls including parameters as readable text. The verbosity
+    of the generated log can be controlled. The resulting logs are
+    valid (but possibly incomplete) C code and can be compiled and 
+    linked for standalone test programs. The set of calls and the 
+    amount of static data that is logged can be controlled at runtime. 
+    The application can add comments and enable or disable tracing of GL 
+    operations at any time. The data flow from the application to GL
+    and back is unaffected except for timing.
+
+    Application-side implementation of these features raises namespace
+    and linkage issues. In the driver dispatch table a simple
+    "chain of responsibility" pattern (aka "composable piepline")
+    can be added.
+
+IP Status
+
+    The extension spec is in the public domain.  The current implementation
+    in Mesa is covered by Mesa's XFree86-style copyright by the authors above.
+    This extension is partially inspired by the Quake2 QGL wrapper.
+
+Issues
+
+    (1) Is this Extension obsolete because it can
+    be implemented as a wrapper DLL?
+
+      RESOLVED: No. While certain operating systems (Win32) provide linkers 
+      that facilitate this kind of solution, other operating systems
+      (Linux) do not support hierarchical linking, so a wrapper solution
+      would result in symbol collisions.
+      Further, IHV's might have builtin support for tracing GL execution 
+      that enjoys privileged access, or that they do not wish to separate
+      the tracing code from their driver code base.
+
+    (2) Should the Trace API explicitely support the notion of "frames? 
+    This would require hooking into glXSwapBuffers calls as well.
+
+      RESOLVED: No. The application can use NewTraceMESA/EndTraceMESA
+      and TraceComment along with external parsing tools to split the 
+      trace into frames, in whatever way considered adequate.
+
+    (2a) Should GLX calls be traced?
+
+      PBuffers and other render-to-texture solutions demonstrate that
+      context level commands beyond SwapBuffers might have to be
+      traced. The GL DLL exports the entry points, so this would not
+      be out of the question. 
+
+    (3) Should the specification mandate the actual output format?
+
+      RESOLVED: No. It is sufficient to guarantee that all data and commands 
+      will be traced as requested by Enable/DisableTraceMESA, in the order
+      encountered. Whether the resulting trace is available as a readable 
+      text file, binary metafile, compilable source code, much less which 
+      indentation and formatting has been used, is up to the implementation. 
+      For the same reason this specification does not enforce or prohibit
+      additional information added to the trace (statistics, profiling/timing, 
+      warnings on possible error conditions).
+
+    (4) Should the comment strings associated with names and pointer (ranges) 
+    be considered persistent state?
+
+      RESOLVED: No. The implementation is not forced to use this information 
+      on subsequent occurences of name/pointer, and is free to consider it 
+      transient state.
+    (5) Should comment commands be prohibited between Begin/End?
+
+      RESOLVED: Yes, with the exception of TraceCommentMESA. TraceCommentMESA 
+      is transient, the other commands might cause storage of persistent
+      data in the context. There is no need to have the ability mark names 
+      or pointers between Begin and End.
+
+
+New Procedures and Functions
+    void NewTraceMESA( bitfield mask, const ubyte * traceName )
+
+    void EndTraceMESA( void )
+
+    void EnableTraceMESA( bitfield mask )
+
+    void DisableTraceMESA( bitfield mask )
+
+    void TraceAssertAttribMESA( bitfield attribMask )
+
+    void TraceCommentMESA( const ubyte* comment )
+
+    void TraceTextureMESA( uint name, const ubyte* comment )
+
+    void TraceListMESA( uint name, const ubyte* comment )
+
+    void TracePointerMESA( void* pointer, const ubyte* comment )
+
+    void TracePointerRangeMESA( const void* first, 
+                                const void* last, 
+                                const ubyte* comment ) 
+
+New Tokens
+    Accepted by the <mask> parameter of EnableTrace and DisableTrace:
+
+       TRACE_ALL_BITS_MESA           0xFFFF
+       TRACE_OPERATIONS_BIT_MESA     0x0001
+       TRACE_PRIMITIVES_BIT_MESA     0x0002
+       TRACE_ARRAYS_BIT_MESA         0x0004
+       TRACE_TEXTURES_BIT_MESA       0x0008
+       TRACE_PIXELS_BIT_MESA         0x0010
+       TRACE_ERRORS_BIT_MESA         0x0020
+
+    Accepted by the <pname> parameter of GetIntegerv, GetBooleanv,
+    GetFloatv, and GetDoublev:
+
+       TRACE_MASK_MESA               0x8755
+
+    Accepted by the <pname> parameter to GetString:
+
+       TRACE_NAME_MESA               0x8756
+
+
+Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
+
+    None.
+
+Additions to Chapter 3 of the OpenGL 1.2.1 Specification (OpenGL Operation)
+
+    None.
+
+Additions to Chapter 4 of the OpenGL 1.2.1 Specification (OpenGL Operation)
+
+    None.
+
+Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
+
+    Add a new section:
+
+    5.7 Tracing
+
+    The tracing facility is used to record the execution of a GL program
+    to a human-readable log.  The log appears as a sequence of GL commands
+    using C syntax.  The primary intention of tracing is to aid in program
+    debugging.
+
+    A trace is started with the command
+
+      void NewTraceMESA( bitfield mask, const GLubyte * traceName )
+
+    <mask> may be any value accepted by PushAttrib and specifies a set of
+    attribute groups.  The state values included in those attribute groups
+    is written to the trace as a sequence of GL commands.
+
+    <traceName> specifies a name or label for the trace.  It is expected
+    that <traceName> will be interpreted as a filename in most implementations.
+
+    A trace is ended by calling the command
+
+      void EndTraceMESA( void )
+
+    It is illegal to call NewTraceMESA or EndTraceMESA between Begin and End. 
+
+    The commands
+
+      void EnableTraceMESA( bitfield mask )
+      void DisableTraceMESA( bitfield mask )
+
+    enable or disable tracing of different classes of GL commands.
+    <mask> may be the union of any of TRACE_OPERATIONS_BIT_MESA,
+    TRACE_PRIMITIVES_BIT_MESA, TRACE_ARRAYS_BIT_MESA, TRACE_TEXTURES_BIT_MESA,
+    and TRACE_PIXELS_BIT_MESA.  The special token TRACE_ALL_BITS_MESA
+    indicates all classes of commands are to be logged.
+
+    TRACE_OPERATIONS_BIT_MESA controls logging of all commands outside of
+    Begin/End, including Begin/End.
+  
+    TRACE_PRIMITIVES_BIT_MESA controls logging of all commands inside of
+    Begin/End, including Begin/End.
+    TRACE_ARRAYS_BIT_MESA controls logging of VertexPointer, NormalPointer,
+    ColorPointer, IndexPointer, TexCoordPointer and EdgeFlagPointer commands.
+
+    TRACE_TEXTURES_BIT_MESA controls logging of texture data dereferenced by
+    TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, and
+    TexSubImage3D commands.
+
+    TRACE_PIXELS_BIT_MESA controls logging of image data dereferenced by
+    Bitmap and DrawPixels commands.
+
+    TRACE_ERRORS_BIT_MESA controls logging of all errors. If this bit is 
+    set, GetError will be executed whereever applicable, and the result will 
+    be added to the trace as a comment. The error returns are cached and 
+    returned to the application on its GetError calls. If the user does not 
+    wish the additional GetError calls to be performed, this bit should not
+    be set.
+    
+    The command
+
+      void TraceCommentMESA( const ubyte* comment )
+
+    immediately adds the <comment> string to the trace output, surrounded
+    by C-style comment delimiters.
+
+    The commands
+
+      void TraceTextureMESA( uint name, const ubyte* comment )
+      void TraceListMESA( uint name, const ubyte* comment )
+
+    associates <comment> with the texture object or display list specified
+    by <name>.  Logged commands which reference the named texture object or
+    display list will be annotated with <comment>.  If IsTexture(name) or
+    IsList(name) fail (respectively) the command is quietly ignored.
+
+    The commands
+
+      void TracePointerMESA( void* pointer, const ubyte* comment )
+
+      void TracePointerRangeMESA( const void* first, 
+                                  const void* last,
+                                  const ubyte* comment ) 
+
+    associate <comment> with the address specified by <pointer> or with
+    a range of addresses specified by <first> through <last>.
+    Any logged commands which reference <pointer> or an address between
+    <first> and <last> will be annotated with <comment>.
+
+    The command
+
+      void TraceAssertAttribMESA( bitfield attribMask )
+
+    will add GL state queries and assertion statements to the log to
+    confirm that the current state at the time TraceAssertAttrib is
+    executed matches the current state when the trace log is executed
+    in the future.
+
+    <attribMask> is any value accepted by PushAttrib and specifies
+    the groups of state variables which are to be asserted.
+
+    The commands NewTraceMESA, EndTraceMESA, EnableTraceMESA, DisableTraceMESA,
+    TraceAssertAttribMESA, TraceCommentMESA, TraceTextureMESA, TraceListMESA, 
+    TracePointerMESA and TracePointerRangeMESA are not compiled into display lists.
+
+
+    Examples:
+
+    The command NewTraceMESA(DEPTH_BUFFER_BIT, "log") will query the state
+    variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
+    to get the values <test>, <func>, <mask>, and <clear> respectively.
+    Statements equivalent to the following will then be logged:
+
+       glEnable(GL_DEPTH_TEST);   (if <test> is true)
+       glDisable(GL_DEPTH_TEST);  (if <test> is false)
+       glDepthFunc(<func>); 
+       glDepthMask(<mask>);
+       glClearDepth(<clear>);
+   
+
+    The command TraceAssertAttribMESA(DEPTH_BUFFER_BIT) will query the state
+    variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
+    to get the values <test>, <func>, <mask>, and <clear> respectively.
+    The resulting trace might then look will like this:
+
+    {
+      GLboolean b;
+      GLint i;
+      GLfloat f;
+      b = glIsEnabled(GL_DEPTH_TEST);
+      assert(b == <test>);
+      glGetIntegerv(GL_DEPTH_FUNC, &i);
+      assert(i == <func>);
+      glGetIntegerv(GL_DEPTH_MASK, &i);
+      assert(i == <mask>);
+      glGetFloatv(GL_DEPTH_CLEAR_VALUE, &f);
+      assert(f == <clear>);
+    }
+
+
+Additions to Chapter 6 of the OpenGL 1.2.1 Specification 
+    (State and State Requests)
+
+    Querying TRACE_MASK_MESA with GetIntegerv, GetFloatv, GetBooleanv or
+    GetDoublev returns the current command class trace mask.
+
+    Querying TRACE_NAME_MESA with GetString returns the current trace name.
+
+
+Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance)
+
+    The MESA_trace extension can be used in a way that does not affect data 
+    flow from application to OpenGL, as well as data flow from OpenGL to 
+    application, except for timing, possible print I/O. TRACE_ERRORS_BIT_MESA
+    will add additional GetError queries. Setting a trace mask with NewTraceMESA
+    as well as use of TraceAssertAttribMESA might cause additional state queries.
+    With the possible exception of performance, OpenGL rendering should not be
+    affected at all by a properly chosen logging operation.
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None.
+
+GLX Protocol
+
+    None. The logging operation is carried out client-side, by exporting
+    entry points to the wrapper functions that execute the logging operation.
+
+Errors
+
+    INVALID_OPERATION is generated if any trace command except TraceCommentMESA
+    is called between Begin and End.
+
+New State
+
+    The current trace name and current command class mask are stored
+    per-context.
+
+New Implementation Dependent State
+
+    None.
+
+Revision History
+
+  * Revision 0.1 - Initial draft from template (bk000415)
+  * Revision 0.2 - Draft (bk000906)
+  * Revision 0.3 - Draft (bk000913)
+  * Revision 0.4 - Reworked text, fixed typos (bp000914)
+  * Revision 0.5 - Assigned final GLenum values (bp001103)
+  * Revision 0.6 - TRACE_ERRORS_BIT_MESA (bk000916)
+  * Revision 0.7 - Added MESA postfix (bk010126)
+
diff --git a/docs/_extra/specs/WL_bind_wayland_display.spec b/docs/_extra/specs/WL_bind_wayland_display.spec
new file mode 100644 (file)
index 0000000..7854890
--- /dev/null
@@ -0,0 +1,202 @@
+Name
+
+    WL_bind_wayland_display
+
+Name Strings
+
+    EGL_WL_bind_wayland_display
+
+Contact
+
+    Kristian Høgsberg <krh@bitplanet.net>
+    Benjamin Franzke <benjaminfranzke@googlemail.com>
+
+Status
+
+    Proposal
+
+Version
+
+    Version 5, July 16, 2013
+
+Number
+
+    EGL Extension #not assigned
+
+Dependencies
+
+    Requires 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 binding and unbinding the
+    wl_display of a Wayland compositor to an EGLDisplay.  Binding a
+    wl_display means that the EGL implementation should provide one or
+    more interfaces in the Wayland protocol to allow clients to create
+    wl_buffer objects.  On the server side, this extension also
+    provides a new target for eglCreateImageKHR, to create an EGLImage
+    from a wl_buffer
+
+    Adding an implementation specific wayland interface, allows the
+    EGL implementation to define specific wayland requests and events,
+    needed for buffer sharing in an EGL wayland platform.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Procedures and Functions
+
+    EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
+                                       struct wl_display *display);
+
+    EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
+                                         struct wl_display *display);
+
+    EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
+                                       struct wl_resource *buffer,
+                                       EGLint attribute, EGLint *value);
+
+New Tokens
+
+    Accepted as <target> in eglCreateImageKHR
+
+        EGL_WAYLAND_BUFFER_WL                   0x31D5
+
+    Accepted in the <attrib_list> parameter of eglCreateImageKHR:
+
+        EGL_WAYLAND_PLANE_WL                    0x31D6
+
+    Possible values for EGL_TEXTURE_FORMAT:
+
+        EGL_TEXTURE_Y_U_V_WL                    0x31D7
+        EGL_TEXTURE_Y_UV_WL                     0x31D8
+        EGL_TEXTURE_Y_XUXV_WL                   0x31D9
+        EGL_TEXTURE_EXTERNAL_WL                 0x31DA
+
+    Accepted in the <attribute> parameter of eglQueryWaylandBufferWL:
+
+        EGL_TEXTURE_FORMAT                      0x3080
+        EGL_WAYLAND_Y_INVERTED_WL               0x31DB
+
+
+Additions to the EGL 1.4 Specification:
+
+    To bind a server side wl_display to an EGLDisplay, call
+
+        EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
+                                           struct wl_display *display);
+
+    To unbind a server side wl_display from an EGLDisplay, call
+    
+        EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
+                                             struct wl_display *display);
+
+    eglBindWaylandDisplayWL returns EGL_FALSE when there is already a
+    wl_display bound to EGLDisplay otherwise EGL_TRUE.
+
+    eglUnbindWaylandDisplayWL returns EGL_FALSE when there is no
+    wl_display bound to the EGLDisplay currently otherwise EGL_TRUE.
+
+    A wl_buffer can have several planes, typically in case of planar
+    YUV formats.  Depending on the exact YUV format in use, the
+    compositor will have to create one or more EGLImages for the
+    various planes.  The eglQueryWaylandBufferWL function should be
+    used to first query the wl_buffer texture format using
+    EGL_TEXTURE_FORMAT as the attribute.  If the wl_buffer object is
+    not an EGL wl_buffer (wl_shm and other wayland extensions can
+    create wl_buffer objects of different types), this query will
+    return EGL_FALSE.  In that case the wl_buffer can not be used with
+    EGL and the compositor should have another way to get the buffer
+    contents.
+
+    If eglQueryWaylandBufferWL succeeds, the returned value will be
+    one of EGL_TEXTURE_RGB, EGL_TEXTURE_RGBA, EGL_TEXTURE_Y_U_V_WL,
+    EGL_TEXTURE_Y_UV_WL, EGL_TEXTURE_Y_XUXV_WL.  The value returned
+    describes how many EGLImages must be used, which components will
+    be sampled from each EGLImage and how they map to rgba components
+    in the shader.  The naming conventions separates planes by _ and
+    within each plane, the order or R, G, B, A, Y, U, and V indicates
+    how those components map to the rgba value returned by the
+    sampler.  X indicates that the corresponding component in the rgba
+    value isn't used.
+
+    RGB and RGBA buffer types:
+
+        EGL_TEXTURE_RGB
+                One plane, samples RGB from the texture to rgb in the
+                shader.  Alpha channel is not valid.
+
+        EGL_TEXTURE_RGBA
+                One plane, samples RGBA from the texture to rgba in the
+                shader.
+
+    YUV buffer types:
+
+        EGL_TEXTURE_Y_U_V_WL
+                Three planes, samples Y from the first plane to r in
+                the shader, U from the second plane to r, and V from
+                the third plane to r.
+
+        EGL_TEXTURE_Y_UV_WL
+                Two planes, samples Y from the first plane to r in
+                the shader, U and V from the second plane to rg.
+
+        EGL_TEXTURE_Y_XUXV_WL
+                Two planes, samples Y from the first plane to r in
+                the shader, U and V from the second plane to g and a.
+
+        EGL_TEXTURE_EXTERNAL_WL
+                Treated as a single plane texture, but sampled with
+                samplerExternalOES according to OES_EGL_image_external
+
+    After querying the wl_buffer layout, create EGLImages for the
+    planes by calling eglCreateImageKHR with wl_buffer as
+    EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
+    context.  If no attributes are given, an EGLImage will be created
+    for the first plane.  For multi-planar buffers, specify the plane
+    to create the EGLImage for by using the EGL_WAYLAND_PLANE_WL
+    attribute.  The value of the attribute is the index of the plane,
+    as defined by the buffer format.  Writing to an EGLImage created
+    from a wl_buffer in any way (such as glTexImage2D, binding the
+    EGLImage as a renderbuffer etc) will result in undefined behavior.
+
+    Further, eglQueryWaylandBufferWL accepts attributes EGL_WIDTH and
+    EGL_HEIGHT to query the width and height of the wl_buffer.
+
+    Also, eglQueryWaylandBufferWL may accept
+    EGL_WAYLAND_Y_INVERTED_WL attribute to query orientation of
+    wl_buffer. If EGL_WAYLAND_Y_INVERTED_WL is supported
+    eglQueryWaylandBufferWL returns EGL_TRUE and value is a boolean
+    that tells if wl_buffer is y-inverted or not. If
+    EGL_WAYLAND_Y_INVERTED_WL is not supported
+    eglQueryWaylandBufferWL returns EGL_FALSE, in that case
+    wl_buffer should be treated as if value of
+    EGL_WAYLAND_Y_INVERTED_WL was EGL_TRUE.
+
+Issues
+
+Revision History
+
+    Version 1, March 1, 2011
+        Initial draft (Benjamin Franzke)
+    Version 2, July 5, 2012
+        Add EGL_WAYLAND_PLANE_WL attribute to allow creating an EGLImage
+        for different planes of planar buffer. (Kristian Høgsberg)
+    Version 3, July 10, 2012
+        Add eglQueryWaylandBufferWL and the various buffer
+        formats. (Kristian Høgsberg)
+    Version 4, July 19, 2012
+        Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
+        and just define the new YUV texture formats.  Add support for
+        EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian Høgsberg)
+    Version 5, July 16, 2013
+        Change eglQueryWaylandBufferWL to take a resource pointer to the
+        buffer instead of a pointer to a struct wl_buffer, as the latter has
+        been deprecated. (Ander Conselvan de Oliveira)
+    Version 6, September 16, 2013
+        Add EGL_WAYLAND_Y_INVERTED_WL attribute to allow specifying
+        wl_buffer's orientation.
diff --git a/docs/_extra/specs/WL_create_wayland_buffer_from_image.spec b/docs/_extra/specs/WL_create_wayland_buffer_from_image.spec
new file mode 100644 (file)
index 0000000..aa5eb4d
--- /dev/null
@@ -0,0 +1,101 @@
+Name
+
+    WL_create_wayland_buffer_from_image
+
+Name Strings
+
+    EGL_WL_create_wayland_buffer_from_image
+
+Contributors
+
+    Neil Roberts
+    Axel Davy
+    Daniel Stone
+
+Contact
+
+    Neil Roberts <neil.s.roberts@intel.com>
+
+Status
+
+    Proposal
+
+Version
+
+    Version 2, October 25, 2013
+
+Number
+
+    EGL Extension #not assigned
+
+Dependencies
+
+    Requires 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 an entry point to create a wl_buffer which shares
+    its contents with a given EGLImage. The expected use case for this is in a
+    nested Wayland compositor which is using subsurfaces to present buffers
+    from its clients. Using this extension it can attach the client buffers
+    directly to the subsurface without having to blit the contents into an
+    intermediate buffer. The compositing can then be done in the parent
+    compositor.
+
+    The nested compositor can create an EGLImage from a client buffer resource
+    using the existing WL_bind_wayland_display extension. It should also be
+    possible to create buffers using other types of images although there is
+    no expected use case for that.
+
+IP Status
+
+    Open-source; freely implementable.
+
+New Procedures and Functions
+
+    struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
+                                                        EGLImageKHR image);
+
+New Tokens
+
+    None.
+
+Additions to the EGL 1.4 Specification:
+
+    To create a client-side wl_buffer from an EGLImage call
+
+      struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
+                                                          EGLImageKHR image);
+
+    The returned buffer will share the contents with the given EGLImage. Any
+    updates to the image will also be updated in the wl_buffer. Typically the
+    EGLImage will be generated in a nested Wayland compositor using a buffer
+    resource from a client via the EGL_WL_bind_wayland_display extension.
+
+    If there was an error then the function will return NULL. In particular it
+    will generate EGL_BAD_MATCH if the implementation is not able to represent
+    the image as a wl_buffer. The possible reasons for this error are
+    implementation-dependant but may include problems such as an unsupported
+    format or tiling mode or that the buffer is in memory that is inaccessible
+    to the GPU that the given EGLDisplay is using.
+
+Issues
+
+    1) Under what circumstances can the EGL_BAD_MATCH error be generated? Does
+       this include for example unsupported tiling modes?
+
+       RESOLVED: Yes, the EGL_BAD_MATCH error can be generated for any reason
+       which prevents the implementation from representing the image as a
+       wl_buffer. For example, these problems can be but are not limited to
+       unsupported tiling modes, inaccessible memory or an unsupported pixel
+       format.
+
+Revision History
+
+    Version 1, September 6, 2013
+        Initial draft (Neil Roberts)
+    Version 2, October 25, 2013
+        Added a note about more possible reasons for returning EGL_BAD_FORMAT.
diff --git a/docs/_extra/specs/enums.txt b/docs/_extra/specs/enums.txt
new file mode 100644 (file)
index 0000000..2ab068b
--- /dev/null
@@ -0,0 +1,104 @@
+The definitive source for enum values and reserved ranges are the XML files in
+the Khronos registry:
+
+    https://github.com/KhronosGroup/EGL-Registry/blob/master/api/egl.xml
+    https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/gl.xml
+    https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/glx.xml
+    https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/wgl.xml
+
+GL blocks allocated to Mesa:
+       0x8750-0x875F
+       0x8BB0-0x8BBF
+
+Unused EGL blocks allocated to Mesa:
+       0x31DC
+       0x31DE
+       0x31DF
+       0x3290-0x329F
+
+GL_MESA_packed_depth_stencil
+       GL_DEPTH_STENCIL_MESA            0x8750
+       GL_UNSIGNED_INT_24_8_MESA        0x8751
+       GL_UNSIGNED_INT_8_24_REV_MESA    0x8752
+       GL_UNSIGNED_SHORT_15_1_MESA      0x8753
+       GL_UNSIGNED_SHORT_1_15_REV_MESA  0x8754
+
+GL_MESA_trace:
+       GL_TRACE_ALL_BITS_MESA           0xFFFF
+       GL_TRACE_OPERATIONS_BIT_MESA     0x0001
+       GL_TRACE_PRIMITIVES_BIT_MESA     0x0002
+       GL_TRACE_ARRAYS_BIT_MESA         0x0004
+       GL_TRACE_TEXTURES_BIT_MESA       0x0008
+       GL_TRACE_PIXELS_BIT_MESA         0x0010
+       GL_TRACE_ERRORS_BIT_MESA         0x0020
+       GL_TRACE_MASK_MESA               0x8755
+       GL_TRACE_NAME_MESA               0x8756
+
+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:
+       GL_PACK_INVERT_MESA              0x8758
+
+GL_MESA_shader_debug.spec: (obsolete)
+        GL_DEBUG_OBJECT_MESA             0x8759
+        GL_DEBUG_PRINT_MESA              0x875A
+        GL_DEBUG_ASSERT_MESA             0x875B
+
+GL_MESA_program_debug: (obsolete)
+        GL_FRAGMENT_PROGRAM_POSITION_MESA       0x8BB0
+        GL_FRAGMENT_PROGRAM_CALLBACK_MESA       0x8BB1
+        GL_FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA  0x8BB2
+        GL_FRAGMENT_PROGRAM_CALLBACK_DATA_MESA  0x8BB3
+        GL_VERTEX_PROGRAM_POSITION_MESA         0x8BB4
+        GL_VERTEX_PROGRAM_CALLBACK_MESA         0x8BB5
+        GL_VERTEX_PROGRAM_CALLBACK_FUNC_MESA    0x8BB6
+        GL_VERTEX_PROGRAM_CALLBACK_DATA_MESA    0x8BB7
+
+GL_MESAX_texture_stack:
+       GL_TEXTURE_1D_STACK_MESAX            0x8759
+       GL_TEXTURE_2D_STACK_MESAX            0x875A
+       GL_PROXY_TEXTURE_1D_STACK_MESAX      0x875B
+       GL_PROXY_TEXTURE_2D_STACK_MESAX      0x875C
+       GL_TEXTURE_1D_STACK_BINDING_MESAX    0x875D
+       GL_TEXTURE_2D_STACK_BINDING_MESAX    0x875E
+
+GL_MESA_program_binary_formats:
+        GL_PROGRAM_BINARY_FORMAT_MESA           0x875F
+
+GL_MESA_tile_raster_order
+       GL_TILE_RASTER_ORDER_FIXED_MESA         0x8BB8
+       GL_TILE_RASTER_ORDER_INCREASING_X_MESA  0x8BB9
+       GL_TILE_RASTER_ORDER_INCREASING_Y_MESA  0x8BBA
+
+GL_MESA_framebuffer_flip_y
+       GL_FRAMEBUFFER_FLIP_Y_MESA           0x8BBB
+
+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_MESA_drm_image
+        EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA  0x3290
+        EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA     0x3291
+        EGL_DRM_BUFFER_FORMAT_RGB565_MESA       0x3292
+
+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
index d5e052114f8db478ee958d4f9846c4be1978b9b9..2c7f9c385e4398433b19d041e973d89bc70ea621 100644 (file)
@@ -113,6 +113,7 @@ html_copy_source = False
 html_static_path = []
 
 html_extra_path = [
+  '_extra/',
   'features.txt',
   'libGL.txt',
   'README.UVD',
diff --git a/docs/specs/EGL_MESA_device_software.txt b/docs/specs/EGL_MESA_device_software.txt
deleted file mode 100644 (file)
index 78b3e1d..0000000
+++ /dev/null
@@ -1,82 +0,0 @@
-Name
-
-    MESA_device_software
-
-Name Strings
-
-    EGL_MESA_device_software
-
-Contributors
-
-    Adam Jackson <ajax@redhat.com>
-    Emil Velikov <emil.velikov@collabora.com>
-
-Contacts
-
-    Adam Jackson <ajax@redhat.com>
-
-Status
-
-    DRAFT
-
-Version
-
-    Version 2, 2018-10-03
-
-Number
-
-    EGL Extension #TODO
-
-Extension Type
-
-    EGL device extension
-
-Dependencies
-
-    Requires EGL_EXT_device_query.
-
-    This extension is written against the EGL 1.5 Specification.
-
-Overview
-
-    This extension defines a software EGL "device". The device is not backed by
-    any actual device node and simply renders into client memory.
-
-    By defining this as an extension, EGL_EXT_device_enumeration is able to
-    sanely enumerate a software device.
-
-New Types
-
-    None
-
-New Procedures and Functions
-
-    None
-
-New Tokens
-
-    None
-
-Additions to the EGL Specification
-
-    None
-
-New Behavior
-
-    The device list produced by eglQueryDevicesEXT will include a software
-    device. This can be distinguished from other device classes in the usual
-    way by calling eglQueryDeviceStringEXT(EGL_EXTENSIONS) and matching this
-    extension's string in the result.
-
-Issues
-
-    None
-
-Revision History
-
-    Version 2, 2018-10-03 (Emil Velikov)
-        - Drop "fallback" from "software fallback device"
-        - Add Emil Velikov as contributor
-
-    Version 1, 2017-07-06 (Adam Jackson)
-        - Initial version
diff --git a/docs/specs/EGL_MESA_drm_image_formats.txt b/docs/specs/EGL_MESA_drm_image_formats.txt
deleted file mode 100644 (file)
index 77fbe9d..0000000
+++ /dev/null
@@ -1,98 +0,0 @@
-Name
-
-    MESA_drm_image_formats
-
-Name Strings
-
-    EGL_MESA_drm_image_formats
-
-Contributors
-
-    Nicolai Hähnle <Nicolai.Haehnle@amd.com>
-    Qiang Yu <Qiang.Yu@amd.com>
-
-Contact
-
-    Nicolai Hähnle <Nicolai.Haehnle@amd.com>
-
-Status
-
-    Proposal
-
-Version
-
-    Version 1, January 26, 2017
-
-Number
-
-    EGL Extension #??
-
-Dependencies
-
-    This extension requires the EGL_MESA_drm_image extension.
-
-    This extension is written against the wording of EGL_MESA_drm_image
-    specification.
-
-Overview
-
-    This extension extends the functionality of EGL_MESA_drm_image by adding
-    additional formats required by Glamor for use with DRM buffers.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Procedures and Functions
-
-    None
-
-New Tokens
-
-    Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
-
-        EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA  0x3290
-        EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA     0x3291
-        EGL_DRM_BUFFER_FORMAT_RGB565_MESA       0x3292
-
-Additions to the EGL_MESA_drm_image Specification:
-
-    Remove the sentence "The only format specified ..." from the paragraph
-    describing eglCreateDRMImageMESA and add the following paragraph:
-
-        The formats specified for use with EGL_DRM_BUFFER_FORMAT_MESA are:
-
-      * 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,
-
-      * EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA, where each pixel is a CPU-
-        endian, 32-bit quantity, with alpha in the most significant 2 bits,
-        followed by 10 bits each for red, green, and blue,
-
-      * EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA, where each pixel is a CPU-endian
-        16-bit quantity, with alpha in the most significant bit, followed by
-        5 bits each for red, green, and blue, and
-
-      * EGL_DRM_BUFFER_FORMAT_RGB565_MESA, where each pixel is a CPU-endian
-        16-bit quantity, with red in the 5 most significant bits, followed by
-        6 bits of green and 5 bits of blue.
-
-Issues
-
-    1. Should we expose the full set of channel permutations for the formats,
-       e.g. ABGR2101010, RGBA1010102, and BGRA1010102 in addition to
-       ARGB2101010?
-
-       RESOLVED: No.
-
-       DISCUSSION: The original extension sets a precedent of only exposing one
-       of the possible permutations of 8-bit channel formats. It is also not
-       clear where the additional permutations would be used. For example,
-       Glamor has a fixed mapping from pixmap/screen depth to format that
-       doesn't allow for the other permutations.
-
-Revision History
-
-    Version 1, January, 2017
-        Initial draft (Nicolai Hähnle)
diff --git a/docs/specs/EGL_MESA_platform_surfaceless.txt b/docs/specs/EGL_MESA_platform_surfaceless.txt
deleted file mode 100644 (file)
index 871ee50..0000000
+++ /dev/null
@@ -1,120 +0,0 @@
-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/docs/specs/EGL_MESA_query_driver.txt b/docs/specs/EGL_MESA_query_driver.txt
deleted file mode 100644 (file)
index bf260bd..0000000
+++ /dev/null
@@ -1,95 +0,0 @@
-Name
-
-    MESA_query_driver
-
-Name Strings
-
-    EGL_MESA_query_driver
-
-Contact
-
-    Rob Clark      <robdclark 'at' gmail.com>
-    Nicolai Hähnle <Nicolai.Haehnle 'at' amd.com>
-
-Contibutors
-
-    Veluri Mithun <velurimithun38 'at' gmail.com>
-
-Status
-
-    Complete
-
-Version
-
-    Version 3, 2019-01-24
-
-Number
-
-    EGL Extension 131
-
-Dependencies
-
-    EGL 1.0 is required.
-
-Overview
-
-    When an application has to query the name of a driver and for
-    obtaining driver's option list (UTF-8 encoded XML) of a driver
-    the below functions are useful.
-
-    XML file formally describes all available options and also
-    includes verbal descriptions in multiple languages. Its main purpose
-    is to be automatically processed by configuration GUIs.
-    The XML shall respect the following DTD:
-
-    <!ELEMENT driinfo      (section*)>
-    <!ELEMENT section      (description+, option+)>
-    <!ELEMENT description  (enum*)>
-    <!ATTLIST description  lang CDATA #REQUIRED
-                           text CDATA #REQUIRED>
-    <!ELEMENT option       (description+)>
-    <!ATTLIST option       name CDATA #REQUIRED
-                           type (bool|enum|int|float) #REQUIRED
-                           default CDATA #REQUIRED
-                           valid CDATA #IMPLIED>
-    <!ELEMENT enum         EMPTY>
-    <!ATTLIST enum         value CDATA #REQUIRED
-                           text CDATA #REQUIRED>
-
-New Procedures and Functions
-
-    char* eglGetDisplayDriverConfig(EGLDisplay dpy);
-    const char* eglGetDisplayDriverName(EGLDisplay dpy);
-
-Description
-
-    By passing EGLDisplay as parameter to `eglGetDisplayDriverName` one can retrieve
-    driverName. Similarly passing EGLDisplay to `eglGetDisplayDriverConfig` we can retrieve
-    driverConfig options of the driver in XML format.
-
-    The string returned by `eglGetDisplayDriverConfig` is heap-allocated and caller
-    is responsible for freeing it.
-
-    EGL_BAD_DISPLAY is generated if `disp` is not an EGL display connection.
-
-    EGL_NOT_INITIALIZED is generated if `disp` has not been initialized.
-
-    If the implementation does not have enough resources to allocate the XML then an
-    EGL_BAD_ALLOC error is generated.
-
-New Tokens
-
-    No new tokens
-
-Issues
-
-    None
-
-
-Revision History
-
-    Version 1, 2018-11-05 - First draft (Veluri Mithun)
-    Version 2, 2019-01-23 - Final version (Veluri Mithun)
-    Version 3, 2019-01-24 - Mark as complete, add Khronos extension
-                            number, fix parameter name in prototypes,
-                            write revision history (Eric Engestrom)
diff --git a/docs/specs/EXT_shader_integer_mix.spec b/docs/specs/EXT_shader_integer_mix.spec
deleted file mode 100644 (file)
index 92cec64..0000000
+++ /dev/null
@@ -1,138 +0,0 @@
-Name
-
-    EXT_shader_integer_mix
-
-Name Strings
-
-    GL_EXT_shader_integer_mix
-
-Contact
-
-    Matt Turner (matt.turner 'at' intel.com)
-
-Contributors
-
-    Matt Turner, Intel
-    Ian Romanick, Intel
-
-Status
-
-    Shipping
-
-Version
-
-    Last Modified Date:         09/12/2013
-    Author Revision:            6
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 3.0 or OpenGL ES 3.0 is required. This extension interacts with
-    GL_ARB_ES3_compatibility.
-
-    This extension is written against the OpenGL 4.4 (core) specification
-    and the GLSL 4.40 specification.
-
-Overview
-
-    GLSL 1.30 (and GLSL ES 3.00) expanded the mix() built-in function to
-    operate on a boolean third argument that does not interpolate but
-    selects. This extension extends mix() to select between int, uint,
-    and bool components.
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-
-    None.
-
-Additions to Chapter 8 of the GLSL 4.40 Specification (Built-in Functions)
-
-    Modify Section 8.3, Common Functions
-
-    Additions to the table listing common built-in functions:
-
-      Syntax                       Description
-      ---------------------------  --------------------------------------------------
-      genIType mix(genIType x,     Selects which vector each returned component comes
-                   genIType y,     from. For a component of a that is false, the
-                   genBType a)     corresponding component of x is returned. For a
-      genUType mix(genUType x,     component of a that is true, the corresponding
-                   genUType y,     component of y is returned.
-                   genBType a)
-      genBType mix(genBType x,
-                   genBType y,
-                   genBType a)
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None.
-
-Modifications to The OpenGL Shading Language Specification, Version 4.40
-
-    Including the following line in a shader can be used to control the
-    language features described in this extension:
-
-      #extension GL_EXT_shader_integer_mix : <behavior>
-
-    where <behavior> is as specified in section 3.3.
-
-    New preprocessor #defines are added to the OpenGL Shading Language:
-
-      #define GL_EXT_shader_integer_mix        1
-
-Interactions with ARB_ES3_compatibility
-
-    On desktop implementations that support ARB_ES3_compatibility,
-    GL_EXT_shader_integer_mix can be enabled (and the new functions
-    used) in shaders declared with '#version 300 es'.
-
-GLX Protocol
-
-    None.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-New Implementation Dependent State
-
-    None.
-
-Issues
-
-    1) Should we allow linear interpolation of integers via a non-boolean
-       third component?
-
-    RESOLVED: No.
-
-    2) Should we allow mix() to select between boolean components?
-
-    RESOLVED: Yes. Implementing the same functionality using casts would be
-    possible but ugly.
-
-Revision History
-
-    Rev.    Date      Author    Changes
-    ----  --------    --------  ---------------------------------------------
-      6   09/12/2013  idr       After discussions in Khronos, change vendor
-                                prefix to EXT.
-
-      5   09/09/2013  idr       Add ARB_ES3_compatibility interaction.
-
-      4   09/06/2013  mattst88  Allow extension on OpenGL ES 3.0.
-
-      3   08/28/2013  mattst88  Add #extension/#define changes.
-
-      2   08/26/2013  mattst88  Change vendor prefix to MESA. Add mix() that
-                                selects between boolean components.
-      1   08/26/2013  mattst88  Initial revision
diff --git a/docs/specs/EXT_shader_samples_identical.txt b/docs/specs/EXT_shader_samples_identical.txt
deleted file mode 100644 (file)
index a8a901b..0000000
+++ /dev/null
@@ -1,176 +0,0 @@
-Name
-
-    EXT_shader_samples_identical
-
-Name Strings
-
-    GL_EXT_shader_samples_identical
-
-Contact
-
-    Ian Romanick, Intel (ian.d.romanick 'at' intel.com)
-
-Contributors
-
-    Chris Forbes, Mesa
-    Magnus Wendt, Intel
-    Neil S. Roberts, Intel
-    Graham Sellers, AMD
-
-Status
-
-    XXX - Not complete yet.
-
-Version
-
-    Last Modified Date: November 19, 2015
-    Revision: 6
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 3.2, or OpenGL ES 3.1, or ARB_texture_multisample is required.
-
-    This extension is written against the OpenGL 4.5 (Core Profile)
-    Specification
-
-Overview
-
-    Multisampled antialiasing has become a common method for improving the
-    quality of rendered images.  Multisampling differs from supersampling in
-    that the color of a primitive that covers all or part of a pixel is
-    resolved once, regardless of the number of samples covered.  If a large
-    polygon is rendered, the colors of all samples in each interior pixel will
-    be the same.  This suggests a simple compression scheme that can reduce
-    the necessary memory bandwidth requirements.  In one such scheme, each
-    sample is stored in a separate slice of the multisample surface.  An
-    additional multisample control surface (MCS) contains a mapping from pixel
-    samples to slices.
-
-    If all the values stored in the MCS for a particular pixel are the same,
-    then all the samples have the same value.  Applications can take advantage
-    of this information to reduce the bandwidth of reading multisample
-    textures.  A custom multisample resolve filter could optimize resolving
-    pixels where every sample is identical by reading the color once.
-
-    color = texelFetch(sampler, coordinate, 0);
-    if (!textureSamplesIdenticalEXT(sampler, coordinate)) {
-        for (int i = 1; i < MAX_SAMPLES; i++) {
-            vec4 c = texelFetch(sampler, coordinate, i);
-
-            //... accumulate c into color
-
-        }
-    }
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-
-    None.
-
-Additions to the OpenGL 4.5 (Core Profile) Specification
-
-    None.
-
-Modifications to The OpenGL Shading Language Specification, Version 4.50.5
-
-    Including the following line in a shader can be used to control the
-    language features described in this extension:
-
-        #extension GL_EXT_shader_samples_identical
-
-    A new preprocessor #define is added to the OpenGL Shading Language:
-
-        #define GL_EXT_shader_samples_identical
-
-    Add to the table in section 8.7 "Texture Lookup Functions"
-
-    Syntax:
-
-        bool textureSamplesIdenticalEXT(gsampler2DMS sampler, ivec2 coord)
-
-        bool textureSamplesIdenticalEXT(gsampler2DMSArray sampler,
-                                        ivec3 coord)
-
-    Description:
-
-        Returns true if it can be determined that all samples within the texel
-        of the multisample texture bound to <sampler> at <coord> contain the
-        same values or false if this cannot be determined."
-
-Additions to the AGL/EGL/GLX/WGL Specifications
-
-    None
-
-Errors
-
-    None
-
-New State
-
-    None
-
-New Implementation Dependent State
-
-    None
-
-Issues
-
-    1) What should the new functions be called?
-
-    RESOLVED: textureSamplesIdenticalEXT.  Initially
-    textureAllSamplesIdenticalEXT was considered, but
-    textureSamplesIdenticalEXT is more similar to the existing textureSamples
-    function.
-
-    2) It seems like applications could implement additional optimization if
-       they were provided with raw MCS data.  Should this extension also
-       provide that data?
-
-    There are a number of challenges in providing raw MCS data.  The biggest
-    problem being that the amount of MCS data depends on the number of
-    samples, and that is not known at compile time.  Additionally, without new
-    texelFetch functions, applications would have difficulty utilizing the
-    information.
-
-    Another option is to have a function that returns an array of tuples of
-    sample number and count.  This also has difficulties with the maximum
-    array size not being known at compile time.
-
-    RESOLVED: Do not expose raw MCS data in this extension.
-
-    3) Should this extension also extend SPIR-V?
-
-    RESOLVED: Yes, but this has not yet been written.
-
-    4) Is it possible for textureSamplesIdenticalEXT to report false negatives?
-
-    RESOLVED: Yes.  It is possible that the underlying hardware may not detect
-    that separate writes of the same color to different samples of a pixel are
-    the same.  The shader function is at the whim of the underlying hardware
-    implementation.  It is also possible that a compressed multisample surface
-    is not used.  In that case the function will likely always return false.
-
-Revision History
-
-    Rev  Date        Author    Changes
-    ---  ----------  --------  ---------------------------------------------
-      1  2014/08/20  cforbes   Initial version
-      2  2015/10/23  idr       Change from MESA to EXT.  Rebase on OpenGL 4.5,
-                               and add dependency on OpenGL ES 3.1.  Initial
-                               draft of overview section and issues 1 through
-                               3.
-      3  2015/10/27  idr       Typo fixes.
-      4  2015/11/10  idr       Rename extension from EXT_shader_multisample_compression
-                               to EXT_shader_samples_identical.
-                               Add issue #4.
-      5  2015/11/18  idr       Fix some typos spotted by gsellers.  Change the
-                               name of the name of the function to
-                               textureSamplesIdenticalEXT.
-      6  2015/11/19  idr       Fix more typos spotted by Nicolai Hähnle.
diff --git a/docs/specs/INTEL_shader_atomic_float_minmax.txt b/docs/specs/INTEL_shader_atomic_float_minmax.txt
deleted file mode 100644 (file)
index a42ad93..0000000
+++ /dev/null
@@ -1,200 +0,0 @@
-Name
-
-    INTEL_shader_atomic_float_minmax
-
-Name Strings
-
-    GL_INTEL_shader_atomic_float_minmax
-
-Contact
-
-    Ian Romanick (ian . d . romanick 'at' intel . com)
-
-Contributors
-
-
-Status
-
-    In progress
-
-Version
-
-    Last Modified Date: 06/22/2018
-    Revision: 4
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 4.2, OpenGL ES 3.1, ARB_shader_storage_buffer_object, or
-    ARB_compute_shader is required.
-
-    This extension is written against version 4.60 of the OpenGL Shading
-    Language Specification.
-
-Overview
-
-    This extension provides GLSL built-in functions allowing shaders to
-    perform atomic read-modify-write operations to floating-point buffer
-    variables and shared variables.  Minimum, maximum, exchange, and
-    compare-and-swap are enabled.
-
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-
-    None.
-
-IP Status
-
-    None.
-
-Modifications to the OpenGL Shading Language Specification, Version 4.60
-
-    Including the following line in a shader can be used to control the
-    language features described in this extension:
-
-      #extension GL_INTEL_shader_atomic_float_minmax : <behavior>
-
-    where <behavior> is as specified in section 3.3.
-
-    New preprocessor #defines are added to the OpenGL Shading Language:
-
-      #define GL_INTEL_shader_atomic_float_minmax   1
-
-Additions to Chapter 8 of the OpenGL Shading Language Specification
-(Built-in Functions)
-
-    Modify Section 8.11, "Atomic Memory Functions"
-
-    (add a new row after the existing "atomicMin" table row, p. 179)
-
-        float atomicMin(inout float mem, float data)
-
-
-        Computes a new value by taking the minimum of the value of data and
-        the contents of mem.  If one of these is an IEEE signaling NaN (i.e.,
-        a NaN with the most-significant bit of the mantissa cleared), it is
-        always considered smaller.  If one of these is an IEEE quiet NaN
-        (i.e., a NaN with the most-significant bit of the mantissa set), it is
-        always considered larger.  If both are IEEE quiet NaNs or both are
-        IEEE signaling NaNs, the result of the comparison is undefined.
-
-    (add a new row after the exiting "atomicMax" table row, p. 179)
-
-        float atomicMax(inout float mem, float data)
-
-        Computes a new value by taking the maximum of the value of data and
-        the contents of mem.  If one of these is an IEEE signaling NaN (i.e.,
-        a NaN with the most-significant bit of the mantissa cleared), it is
-        always considered larger.  If one of these is an IEEE quiet NaN (i.e.,
-        a NaN with the most-significant bit of the mantissa set), it is always
-        considered smaller.  If both are IEEE quiet NaNs or both are IEEE
-        signaling NaNs, the result of the comparison is undefined.
-
-    (add to "atomicExchange" table cell, p. 180)
-
-        float atomicExchange(inout float mem, float data)
-
-    (add to "atomicCompSwap" table cell, p. 180)
-
-        float atomicCompSwap(inout float mem, float compare, float data)
-
-Interactions with OpenGL 4.6 and ARB_gl_spirv
-
-    If OpenGL 4.6 or ARB_gl_spirv is supported, then
-    SPV_INTEL_shader_atomic_float_minmax must also be supported.
-
-    The AtomicFloatMinmaxINTEL capability is available whenever the OpenGL or
-    OpenGL ES implementation supports INTEL_shader_atomic_float_minmax.
-
-Issues
-
-    1) Why call this extension INTEL_shader_atomic_float_minmax?
-
-    RESOLVED: Several other extensions already set the precedent of
-    VENDOR_shader_atomic_float and VENDOR_shader_atomic_float64 for extensions
-    that enable floating-point atomic operations.  Using that as a base for
-    the name seems logical.
-
-    There already exists NV_shader_atomic_float, but the two extensions have
-    nearly zero overlap in functionality.  NV_shader_atomic_float adds
-    atomicAdd and image atomic operations that currently shipping Intel GPUs
-    do not support.  Calling this extension INTEL_shader_atomic_float would
-    likely have been confusing.
-
-    Adding something to describe the actual functions added by this extension
-    seemed reasonable.  INTEL_shader_atomic_float_compare was considered, but
-    that name was deemed to be not properly descriptive.  Calling this
-    extension INTEL_shader_atomic_float_min_max_exchange_compswap is right
-    out.
-
-    2) What atomic operations should we support for floating-point targets?
-
-    RESOLVED.  Exchange, min, max, and compare-swap make sense, and these are
-    all supported by the hardware.  Future extensions may add other functions.
-
-    For buffer variables and shared variables it is not possible to bit-cast
-    the memory location in GLSL, so existing integer operations, such as
-    atomicOr, cannot be used.  However, the underlying hardware implementation
-    can do this by treating the memory as an integer.  It would be possible to
-    implement atomicNegate using this technique with atomicXor.  It is unclear
-    whether this provides any actual utility.
-
-    3) What should be said about the NaN behavior?
-
-    RESOLVED.  There are several aspects of NaN behavior that should be
-    documented in this extension.  However, some of this behavior varies based
-    on NaN concepts that do not exist in the GLSL specification.
-
-    * atomicCompSwap performs the comparison as the floating-point equality
-      operator (==).  That is, if either 'mem' or 'compare' is NaN, the
-      comparison result is always false.
-
-    * atomicMin and atomicMax implement the IEEE specification with respect to
-      NaN.  IEEE considers two different kinds of NaN: signaling NaN and quiet
-      NaN.  A quiet NaN has the most significant bit of the mantissa set, and
-      a signaling NaN does not.  This concept does not exist in SPIR-V,
-      Vulkan, or OpenGL.  Let qNaN denote a quiet NaN and sNaN denote a
-      signaling NaN.  atomicMin and atomicMax specifically implement
-
-      - fmin(qNaN, x) = fmin(x, qNaN) = fmax(qNaN, x) = fmax(x, qNaN) = x
-      - fmin(sNaN, x) = fmin(x, sNaN) = fmax(sNaN, x) = fmax(x, sNaN) = sNaN
-      - fmin(sNaN, qNaN) = fmin(qNaN, sNaN) = fmax(sNaN, qNaN) =
-        fmax(qNaN, sNaN) = sNaN
-      - fmin(sNaN, sNaN) = sNaN.  This specification does not define which of
-        the two arguments is stored.
-      - fmax(sNaN, sNaN) = sNaN.  This specification does not define which of
-        the two arguments is stored.
-      - fmin(qNaN, qNaN) = qNaN.  This specification does not define which of
-        the two arguments is stored.
-      - fmax(qNaN, qNaN) = qNaN.  This specification does not define which of
-        the two arguments is stored.
-
-    Further details are available in the Skylake Programmer's Reference
-    Manuals available at
-    https://01.org/linuxgraphics/documentation/hardware-specification-prms.
-
-    4) What about atomicMin and atomicMax with (+0.0, -0.0) or (-0.0, +0.0)
-    arguments?
-
-    RESOLVED.  atomicMin should store -0.0, and atomicMax should store +0.0.
-    Due to a known issue in shipping Skylake GPUs, the incorrectly signed 0 is
-    stored.  This behavior may change in later GPUs.
-
-Revision History
-
-    Rev  Date        Author    Changes
-    ---  ----------  --------  ---------------------------------------------
-      1  04/19/2018  idr       Initial version
-      2  05/05/2018  idr       Describe interactions with the capabilities
-                               added by SPV_INTEL_shader_atomic_float_minmax.
-      3  05/29/2018  idr       Remove mention of 64-bit float support.
-      4  06/22/2018  idr       Resolve issue #2.
-                               Add issue #3 (regarding NaN behavior).
-                               Add issue #4 (regarding atomicMin(-0, +0).
diff --git a/docs/specs/MESA_configless_context.spec b/docs/specs/MESA_configless_context.spec
deleted file mode 100644 (file)
index d7ba62d..0000000
+++ /dev/null
@@ -1,129 +0,0 @@
-Name
-
-    MESA_configless_context
-
-Name Strings
-
-    EGL_MESA_configless_context
-
-Contact
-
-    Neil Roberts <neil.s.roberts@intel.com>
-
-Status
-
-    Superseded by the functionally identical EGL_KHR_no_config_context
-    extension.
-
-Version
-
-    Version 2, September 9, 2016
-
-Number
-
-    EGL Extension #not assigned
-
-Dependencies
-
-    Requires EGL 1.4 or later.  This extension is written against the
-    wording of the EGL 1.4 specification.
-
-Overview
-
-    This extension provides a means to use a single context to render to
-    multiple surfaces which have different EGLConfigs. Without this extension
-    the EGLConfig for every surface used by the context must be compatible
-    with the one used by the context. The only way to render to surfaces with
-    different formats would be to create multiple contexts but this is
-    inefficient with modern GPUs where this restriction is unnecessary.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-
-    Accepted as <config> in eglCreateContext
-
-        EGL_NO_CONFIG_MESA                  ((EGLConfig)0)
-
-Additions to the EGL Specification section "2.2 Rendering Contexts and Drawing
-Surfaces"
-
-    Add the following to the 3rd paragraph:
-
-   "EGLContexts can also optionally be created with respect to an EGLConfig
-    depending on the parameters used at creation time. If a config is provided
-    then additional restrictions apply on what surfaces can be used with the
-    context."
-
-    Replace the last sentence of the 6th paragraph with:
-
-   "In order for a context to be compatible with a surface they both must have
-    been created with respect to the same EGLDisplay. If the context was
-    created without respect to an EGLConfig then there are no further
-    constraints. Otherwise they are only compatible if:"
-
-    Remove the last bullet point in the list of constraints.
-
-Additions to the EGL Specification section "3.7.1 Creating Rendering Contexts"
-
-    Replace the paragraph starting "If config is not a valid EGLConfig..."
-    with
-
-   "The config argument can either be a valid EGLConfig or EGL_NO_CONFIG_MESA.
-    If it is neither of these then an EGL_BAD_CONFIG error is generated. If a
-    valid config is passed then the error will also be generated if the config
-    does not support the requested client API (this includes requesting
-    creation of an OpenGL ES 1.x context when the EGL_RENDERABLE_TYPE
-    attribute of config does not contain EGL_OPENGL_ES_BIT, or creation of an
-    OpenGL ES 2.x context when the attribute does not contain
-    EGL_OPENGL_ES2_BIT).
-
-    Passing EGL_NO_CONFIG_MESA will create a configless context. When a
-    configless context is used with the OpenGL API it can be assumed that the
-    initial values of the context's state will be decided when the context is
-    first made current. In particular this means that the decision of whether
-    to use GL_BACK or GL_FRONT for the initial value of the first output in
-    glDrawBuffers will be decided based on the config of the draw surface when
-    it is first bound."
-
-Additions to the EGL Specification section "3.7.3 Binding Contexts and
-Drawables"
-
-    Replace the first bullet point with the following:
-
-   "* If draw or read are not compatible with ctx as described in section 2.2,
-      then an EGL_BAD_MATCH error is generated."
-
-    Add a second bullet point after that:
-
-   "* If draw and read are not compatible with each other as described in
-      section 2.2, then an EGL_BAD_MATCH error is generated."
-
-Issues
-
-    1.  What happens when an OpenGL context with a double-buffered surface and
-        draw buffer set to GL_BACK is made current with a single-buffered
-        surface?
-
-        NOT RESOLVED: There are a few options here.  An implementation can
-        raise an error, change the drawbuffer state to GL_FRONT or just do
-        nothing, expecting the application to set GL_FRONT drawbuffer before
-        drawing.  However, this extension deliberately does not specify any
-        required behavior in this corner case and applications should avoid
-        mixing single- and double-buffered surfaces with configless contexts.
-
-        Future extensions may specify required behavior in this case.
-
-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/docs/specs/MESA_copy_sub_buffer.spec b/docs/specs/MESA_copy_sub_buffer.spec
deleted file mode 100644 (file)
index 752a014..0000000
+++ /dev/null
@@ -1,96 +0,0 @@
-Name
-
-    MESA_copy_sub_buffer
-
-Name Strings
-
-    GLX_MESA_copy_sub_buffer
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Shipping since Mesa 2.6 in February, 1998.
-
-Version
-
-    Last Modified Date:  12 January 2009
-
-Number
-
-    215
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    The glxCopySubBufferMESA() function copies a rectangular region
-    of the back color buffer to the front color buffer.  This can be
-    used to quickly repaint 3D windows in response to expose events
-    when the back color buffer cannot be damaged by other windows.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
-                              int x, int y, int width, int height );
-
-New Tokens
-
-    None.
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    Add to section 3.3.10 Double Buffering:
-
-    The function
-
-        void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
-                                   int x, int y, int width, int height );
-
-    may be used to copy a rectangular region of the back color buffer to
-    the front color buffer.  This can be used to quickly repaint 3D windows
-    in response to expose events when the back color buffer cannot be
-    damaged by other windows.
-
-    <x> and <y> indicates the lower-left corner of the region to copy and
-    <width> and <height> indicate the size in pixels.  Coordinate (0,0)
-    corresponds to the lower-left pixel of the window, like glReadPixels.
-
-    If dpy and drawable are the display and drawable for the calling
-    thread's current context, glXCopySubBufferMESA performs an
-    implicit glFlush before it returns.  Subsequent OpenGL commands
-    may be issued immediately after calling glXCopySubBufferMESA, but
-    are not executed until the copy is completed. 
-
-GLX Protocol
-
-    None at this time.  The extension is implemented in terms of ordinary
-    Xlib protocol inside of Mesa.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    12 January 2009 Ian Romanick - Added language about implicit flush
-                                   and command completion.
-    8 June 2000     Brian Paul   - initial specification
-
diff --git a/docs/specs/MESA_drm_image.spec b/docs/specs/MESA_drm_image.spec
deleted file mode 100644 (file)
index 1150a4c..0000000
+++ /dev/null
@@ -1,153 +0,0 @@
-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
-
-    Requires 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
-        EGL_DRM_BUFFER_USE_CURSOR_MESA         0x0004
-
-    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_HEIGHT 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,
-    EGL_DRM_BUFFER_USE_SHARE_MESA and EGL_DRM_BUFFER_USE_CURSOR_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.  EGL_DRM_BUFFER_USE_SHARE_MESA requests that the
-    EGLImage can be shared with other processes by passing the
-    underlying DRM buffer name.  EGL_DRM_BUFFER_USE_CURSOR_MESA
-    requests that the image must be usable as a cursor with KMS.  When
-    EGL_DRM_BUFFER_USE_CURSOR_MESA is set, width and height must both
-    be 64.
-
-    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 referencing 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/specs/MESA_framebuffer_flip_y.txt b/docs/specs/MESA_framebuffer_flip_y.txt
deleted file mode 100644 (file)
index 891cc43..0000000
+++ /dev/null
@@ -1,106 +0,0 @@
-Name
-
-    MESA_framebuffer_flip_y
-
-Name Strings
-
-    GL_MESA_framebuffer_flip_y
-
-Contact
-
-    Fritz Koenig <frkoenig@google.com>
-
-Contributors
-
-    Fritz Koenig, Google
-    Kristian Høgsberg, Google
-    Chad Versace, Google
-    Heinrich Fink, DAQRI
-
-Status
-
-    Proposal
-
-Version
-
-    Version 3, August, 2019
-
-Number
-
-    OpenGL Extension #540
-    OpenGL ES Extension #302
-
-Dependencies
-
-    Requires OpenGL ES 3.0, OpenGL 4.3, or ARB_framebuffer_no_attachments.
-
-Overview
-
-    This extension defines a new framebuffer parameter,
-    GL_FRAMEBUFFER_FLIP_Y_MESA, that changes the behavior of the reads and
-    writes to the framebuffer attachment points. When GL_FRAMEBUFFER_FLIP_Y_MESA
-    is GL_TRUE, render commands and pixel transfer operations access the
-    backing store of each attachment point with an y-inverted coordinate
-    system. This y-inversion is relative to the coordinate system set when
-    GL_FRAMEBUFFER_FLIP_Y_MESA is GL_FALSE.
-
-    Access through TexSubImage2D and similar calls will notice the effect of
-    the flip when they are not attached to framebuffer objects because
-    GL_FRAMEBUFFER_FLIP_Y_MESA is associated with the framebuffer object and
-    not the attachment points.
-
-IP Status
-
-    None
-
-Issues
-
-    None
-
-New Procedures and Functions
-
-    OpenGL ES must provide the following functions:
-
-    void FramebufferParameteriMESA(enum target, enum pname, int param);
-    void GetFramebufferParameterivMESA(enum target, enum pname, int *params);
-
-New Types
-
-    None
-
-New Tokens
-
-    Accepted by the <pname> argument of FramebufferParameteriMESA and
-    GetFramebufferParameterivMESA:
-
-        GL_FRAMEBUFFER_FLIP_Y_MESA                      0x8BBB
-
-Interactions with OpenGL 4.3, OpenGL ES 3.1, ARB_framebuffer_no_attachments
-and any other versions and extensions that provide the entry points
-FramebufferParameteri and GetFramebufferParameteriv
-
-        Token GL_FRAMEBUFFER_FLIP_Y_MESA is accepted as the <pname> argument of
-        FramebufferParameteri and GetFramebufferParameteriv.
-
-Errors
-
-    An INVALID_OPERATION error is generated by GetFramebufferParameteriv or
-    GetFramebufferParameterivMESA if the default framebuffer is bound
-    to <target> and <pname> is GL_FRAMEBUFFER_FLIP_Y_MESA.
-
-
-
-
-
-Revision History
-
-    Version 3, August, 2019
-        Allow OpenGL ES 3.0 to implement by adding functions
-        FramebufferParameteriMESA and GetFramebufferParameterivMESA which were
-        previously only available in OpenGL ES 3.1.
-
-    Version 2, June, 2019
-        Enable extension for OpenGL 4.3 and beyond
-
-    Version 1, June, 2018
-        Initial draft (Fritz Koenig)
diff --git a/docs/specs/MESA_image_dma_buf_export.txt b/docs/specs/MESA_image_dma_buf_export.txt
deleted file mode 100644 (file)
index cc9497e..0000000
+++ /dev/null
@@ -1,147 +0,0 @@
-Name
-
-    MESA_image_dma_buf_export
-
-Name Strings
-
-    EGL_MESA_image_dma_buf_export
-
-Contributors
-
-    Dave Airlie
-
-Contact
-
-    Dave Airlie (airlied 'at' redhat 'dot' com)
-
-Status
-
-    Complete, shipping.
-
-Version
-
-    Version 3, May 5, 2015
-
-Number
-
-    EGL Extension #87
-
-Dependencies
-
-    Requires EGL 1.4 or later.  This extension is written against the
-    wording of the EGL 1.4 specification.
-
-    EGL_KHR_base_image is required.
-
-    The EGL implementation must be running on a Linux kernel supporting the
-    dma_buf buffer sharing mechanism.
-
-Overview
-
-    This extension provides entry points for integrating EGLImage with the
-    dma-buf infrastructure.  The extension allows creating a Linux dma_buf
-    file descriptor or multiple file descriptors, in the case of multi-plane
-    YUV image, from an EGLImage.
-
-    It is designed to provide the complementary functionality to
-    EGL_EXT_image_dma_buf_import.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Types
-
-    This extension uses the 64-bit unsigned integer type EGLuint64KHR
-    first introduced by the EGL_KHR_stream extension, but does not
-    depend on that extension. The typedef may be reproduced separately
-    for this extension, if not already present in eglext.h.
-
-    typedef khronos_uint64_t EGLuint64KHR;
-
-New Procedures and Functions
-
-    EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
-                                  EGLImageKHR image,
-                                 int *fourcc,
-                                 int *num_planes,
-                                 EGLuint64KHR *modifiers);
-
-    EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
-                                        EGLImageKHR image,
-                                        int *fds,
-                                       EGLint *strides,
-                                       EGLint *offsets);
-
-New Tokens
-
-    None
-
-
-Additions to the EGL 1.4 Specification:
-
-    To mirror the import extension, this extension attempts to return
-    enough information to enable an exported dma-buf to be imported
-    via eglCreateImageKHR and EGL_LINUX_DMA_BUF_EXT token.
-
-    Retrieving the information is a two step process, so two APIs
-    are required.
-
-    The first entrypoint
-       EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
-                                  EGLImageKHR image,
-                                 int *fourcc,
-                                 int *num_planes,
-                                 EGLuint64KHR *modifiers);
-
-    is used to retrieve the pixel format of the buffer, as specified by
-    drm_fourcc.h, the number of planes in the image and the Linux
-    drm modifiers. <fourcc>, <num_planes> and <modifiers> may be NULL,
-    in which case no value is retrieved.
-
-    The second entrypoint retrieves the dma_buf file descriptors,
-    strides and offsets for the image. The caller should pass
-    arrays sized according to the num_planes values retrieved previously.
-    Passing arrays of the wrong size will have undefined results.
-    If the number of fds is less than the number of planes, then
-    subsequent fd slots should contain -1.
-
-        EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
-                                         EGLImageKHR image,
-                                        int *fds,
-                                         EGLint *strides,
-                                         EGLint *offsets);
-
-    <fds>, <strides>, <offsets> can be NULL if the infomatation isn't
-    required by the caller.
-
-Issues
-
-1. Should the API look more like an attribute getting API?
-
-ANSWER: No, from a user interface pov, having to iterate across calling
-the API up to 12 times using attribs seems like the wrong solution.
-
-2. Should the API take a plane and just get the fd/stride/offset for that
-   plane?
-
-ANSWER: UNKNOWN,this might be just as valid an API.
-
-3. Does ownership of the file descriptor remain with the app?
-
-ANSWER: Yes, the app is responsible for closing any fds retrieved.
-
-4. If number of planes and number of fds differ what should we do?
-
-ANSWER: Return -1 for the secondary slots, as this avoids having
-to dup the fd extra times to make the interface sane.
-
-Revision History
-
-    Version 3, May, 2015
-        Just use the KHR 64-bit type.
-    Version 2, March, 2015
-        Add a query interface (Dave Airlie)
-    Version 1, June 3, 2014
-        Initial draft (Dave Airlie)
-
diff --git a/docs/specs/MESA_multithread_makecurrent.spec b/docs/specs/MESA_multithread_makecurrent.spec
deleted file mode 100644 (file)
index 5065c2f..0000000
+++ /dev/null
@@ -1,158 +0,0 @@
-Name
-
-    MESA_multithread_makecurrent
-
-Name Strings
-
-    GLX_MESA_multithread_makecurrent
-
-Contact
-
-    Eric Anholt (eric@anholt.net)
-
-Status
-
-    Not shipping.
-
-Version
-
-    Last Modified Date:  21 February 2011
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.3 or later is required.
-
-Overview
-
-    The GLX context setup encourages multithreaded applications to
-    create a context per thread which each operate on their own
-    objects in parallel, and leaves synchronization for write access
-    to shared objects up to the application.
-
-    For some applications, maintaining per-thread contexts and
-    ensuring that the glFlush happens in one thread before another
-    thread starts working on that object is difficult.  For them,
-    using the same context across multiple threads and protecting its
-    usage with a mutex is both higher performance and easier to
-    implement.  This extension gives those applications that option by
-    relaxing the context binding requirements.
-
-    This new behavior matches the requirements of AGL, while providing
-    a feature not specified in WGL.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-
-    None.
-
-Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
-
-    Replace the following sentence from section 2.2 Rendering Contexts:
-       In addition, a rendering context can be current for only one
-       thread at a time.
-    with:
-       In addition, an indirect rendering context can be current for
-       only one thread at a time.  A direct rendering context may be
-       current to multiple threads, with synchronization of access to
-       the context thruogh the GL managed by the application through
-       mutexes.
-
-Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    Replace the following sentence from section 3.3.7 Rendering Contexts:
-       If ctx is current to some other thread, then
-       glXMakeContextCurrent will generate a BadAccess error.
-    with:
-       If ctx is an indirect context current to some other thread,
-       then glXMakeContextCurrent will generate a BadAccess error.
-
-    Replace the following sentence from section 3.5 Rendering Contexts:
-       If ctx is current to some other thread, then
-       glXMakeCurrent will generate a BadAccess error.
-    with:
-       If ctx is an indirect context current to some other thread,
-       then glXMakeCurrent will generate a BadAccess error.
-
-GLX Protocol
-
-    None.  The GLX extension only extends to direct rendering contexts.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Issues
-
-    (1) What happens if the app binds a context/drawable in multiple
-       threads, then binds a different context/thread in one of them?
-
-    As with binding a new context from the current thread, the old
-    context's refcount is reduced and the new context's refcount is
-    increased.
-
-    (2) What happens if the app binds a context/drawable in multiple
-       threads, then binds None/None in one of them?
-
-    The GLX context is unreferenced from that thread, and the other
-    threads retain their GLX context binding.
-
-    (3) What happens if the app binds a context/drawable in 7 threads,
-       then destroys the context in one of them?
-
-    As with GLX context destruction previously, the XID is destroyed
-    but the context remains usable by threads that have the context
-    current.
-
-    (4) What happens if the app binds a new drawable/readable with
-        glXMakeCurrent() when it is already bound to another thread?
-
-    The context becomes bound to the new drawable/readable, and
-    further rendering in either thread will use the new
-    drawable/readable.
-
-    (5) What requirements should be placed on the user managing contexts
-        from multiple threads?
-
-    The intention is to allow multithreaded access to the GL at the
-    minimal performance cost, so requiring that the GL do general
-    synchronization (beyond that already required by context sharing)
-    is not an option, and synchronizing of GL's access to the GL
-    context between multiple threads is left to the application to do
-    across GL calls.  However, it would be unfortunate for a library
-    doing multithread_makecurrent to require that other libraries
-    share in synchronization for binding of their own contexts, so the
-    refcounting of the contexts is required to be threadsafe.
-
-    (6) Does this apply to indirect contexts?
-
-    This was ignored in the initial revision of the spec.  Behavior
-    for indirect contexts is left as-is.
-
-Revision History
-
-    20 November 2009 Eric Anholt - initial specification
-    22 November 2009 Eric Anholt - added issues from Ian Romanick.
-    3 February 2011 Eric Anholt - updated with resolution to issues 1-3
-    3 February 2011 Eric Anholt - added issue 4, 5
-    21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
-    along with glXMakeContextCurrent() for removal.
diff --git a/docs/specs/MESA_pack_invert.spec b/docs/specs/MESA_pack_invert.spec
deleted file mode 100644 (file)
index 33fb3c7..0000000
+++ /dev/null
@@ -1,138 +0,0 @@
-Name
-
-    MESA_pack_invert
-
-Name Strings
-
-    GL_MESA_pack_invert
-
-Contact
-
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
-    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
-
-Status
-
-    Shipping (Mesa 4.0.4 and later)
-
-Version
-
-    1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required
-    This extensions is written against the OpenGL 1.4 Specification.
-
-Overview
-
-    This extension adds a new pixel storage parameter to indicate that
-    images are to be packed in top-to-bottom order instead of OpenGL's
-    conventional bottom-to-top order.  Only pixel packing can be
-    inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter,
-    etc).
-
-    Almost all known image file formats store images in top-to-bottom
-    order.  As it is, OpenGL reads images from the frame buffer in
-    bottom-to-top order.  Thus, images usually have to be inverted before
-    writing them to a file with image I/O libraries.  This extension
-    allows images to be read such that inverting isn't needed.
-
-IP Status
-
-    None
-
-Issues
-
-    1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
-
-    Resolved:  No, we're only concerned with pixel packing.  There are other
-    solutions for inverting images when using glDrawPixels (negative Y pixel
-    zoom) or glTexImage (invert the vertex T coordinates).  It would be easy
-    enough to define a complementary extension for pixel packing in the
-    future if needed.
-
-New Procedures and Functions
-
-    None
-
-New Tokens
-
-    Accepted by the <pname> parameter of PixelStorei and PixelStoref
-    and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev
-    and GetBooleanv:
-
-        PACK_INVERT_MESA                   0x8758
-
-Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    Add the following entry to table 4.4 (PixelStore parameters) on page 182:
-
-    Parameter Name       Type    Initial Value    Valid Range
-    ---------------------------------------------------------
-    PACK_INVERT_MESA     boolean     FALSE        TRUE/FALSE
-
-    In the section labeled "Placement in Client Memory" on page 184
-    insert the following text into the paragraph before the sentence
-    that starts with "If the format is RED, GREEN, BLUE...":
-
-    "The parameter PACK_INVERT_MESA controls whether the image is packed
-     in bottom-to-top order (the default) or top-to-bottom order.  Equation
-     3.8 is modified as follows:
-
-     ... the first element of the Nth row is indicated by
-
-         p + Nk,                if PACK_INVERT_MESA is false
-         p + k * (H - 1) - Nk,  if PACK_INVERT_MESA is true, where H is the
-                                image height
-    "
-
-Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
-State Requests)
-
-    None
-
-Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
-
-    None
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Errors
-
-    None
-
-New State
-
-    Add the following entry to table 6.20 (Pixels) on page 235:
-
-    Get Value         Type     Get Cmd    Initial Value  Description                Sec    Attribute
-    --------------------------------------------------------------------------------------------------
-    PACK_INVERT_MESA  boolean  GetBoolean  FALSE         Value of PACK_INVERT_MESA  4.3.2  pixel-store
-
-Revision History
-
-    21 September 2002 - Initial draft
diff --git a/docs/specs/MESA_pixmap_colormap.spec b/docs/specs/MESA_pixmap_colormap.spec
deleted file mode 100644 (file)
index fb0b441..0000000
+++ /dev/null
@@ -1,90 +0,0 @@
-Name
-
-    MESA_pixmap_colormap
-
-Name Strings
-
-    GLX_MESA_pixmap_colormap
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Shipping since Mesa 1.2.8 in May, 1996.
-
-Version
-
-    Last Modified Date:  8 June 2000
-
-Number
-
-    216
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    Since Mesa allows RGB rendering into drawables with PseudoColor,
-    StaticColor, GrayScale and StaticGray visuals, Mesa needs a colormap
-    in order to compute pixel values during rendering.
-
-    The colormap associated with a window can be queried with normal
-    Xlib functions but there is no colormap associated with pixmaps.
-
-    The glXCreateGLXPixmapMESA function is an alternative to glXCreateGLXPixmap
-    which allows specification of a colormap.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
-                                     Pixmap pixmap, Colormap cmap );
-
-New Tokens
-
-    None.
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    Add to section 3.4.2 Off Screen Rendering
-
-    The Mesa implementation of GLX allows RGB rendering into X windows and
-    pixmaps of any visual class, not just TrueColor or DirectColor.  In order
-    to compute pixel values from RGB values Mesa requires a colormap.
-
-    The function
-
-       GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
-                                         Pixmap pixmap, Colormap cmap );
-
-    allows one to create a GLXPixmap with a specific colormap.  The image
-    rendered into the pixmap may then be copied to a window (which uses the
-    same colormap and visual) with the expected results.
-
-GLX Protocol
-
-    None since this is a client-side extension.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    8 June 2000 - initial specification
diff --git a/docs/specs/MESA_query_renderer.spec b/docs/specs/MESA_query_renderer.spec
deleted file mode 100644 (file)
index 10f68ec..0000000
+++ /dev/null
@@ -1,385 +0,0 @@
-Name
-
-    MESA_query_renderer
-
-Name Strings
-
-    GLX_MESA_query_renderer
-
-Contact
-
-    Ian Romanick <ian.d.romanick@intel.com>
-
-IP Status
-
-    No known IP claims.
-
-Status
-
-    Shipping as of Mesa 10.0
-
-Version
-
-    Version 9, 09 November 2018
-
-Number
-
-    OpenGL Extension #446
-
-Dependencies
-
-    GLX 1.4 is required.
-
-    GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
-
-Overview
-
-    In many situations, applications want to detect characteristics of a
-    rendering device before creating a context for that device.  Information
-    gathered at this stage may guide choices the application makes about
-    color depth, number of samples per-pixel, texture quality, and so on.
-    In addition, versions of supported APIs and implementation API
-    preference may also guide start-up decisions made by the application.
-    For example, one implementation may prefer vertex data be supplied using
-    methods only available in a compatibility profile, but another
-    implementation may only support the desired version in a core profile.
-
-    There are also cases where more than one renderer may be available per
-    display.  For example, there is typically a hardware implementation and
-    a software based implementation.  There are cases where an application
-    may want to pick one over the other.  One such situation is when the
-    software implementation supports more features than the hardware
-    implementation.  Another situation is when a particular version of the
-    hardware implementation is blacklisted due to known bugs.
-
-    This extension provides a mechanism for the application to query all of
-    the available renderers for a particular display and screen.  In
-    addition, this extension provides a mechanism for applications to create
-    contexts with respect to a specific renderer.
-
-New Procedures and Functions
-
-    Bool glXQueryRendererIntegerMESA(Display *dpy, int screen,
-                                     int renderer, int attribute,
-                                     unsigned int *value);
-    Bool glXQueryCurrentRendererIntegerMESA(int attribute, unsigned int *value);
-
-    const char *glXQueryRendererStringMESA(Display *dpy, int screen,
-                                           int renderer, int attribute);
-
-    const char *glXQueryCurrentRendererStringMESA(int attribute);
-
-New Tokens
-
-    Accepted as an <attribute> in glXQueryRendererIntegerMESA and
-    glXQueryCurrentRendererIntegerMESA:
-
-        GLX_RENDERER_VENDOR_ID_MESA                      0x8183
-        GLX_RENDERER_DEVICE_ID_MESA                      0x8184
-        GLX_RENDERER_VERSION_MESA                        0x8185
-        GLX_RENDERER_ACCELERATED_MESA                    0x8186
-        GLX_RENDERER_VIDEO_MEMORY_MESA                   0x8187
-        GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA    0x8188
-        GLX_RENDERER_PREFERRED_PROFILE_MESA              0x8189
-        GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA    0x818A
-        GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA    0x818B
-        GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA      0x818C
-        GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA     0x818D
-
-    Accepted as an <attribute> in glXQueryRendererStringMESA and
-    glXQueryCurrentRendererStringMESA:
-
-        GLX_RENDERER_VENDOR_ID_MESA
-        GLX_RENDERER_DEVICE_ID_MESA
-
-Additions to the OpenGL / WGL Specifications
-
-    None. This specification is written for GLX.
-
-Additions to the GLX 1.4 Specification
-
-    [Add to Section 3.3.2 "GLX Versioning" of the GLX Specification]
-
-    To obtain information about the available renderers for a particular
-    display and screen,
-
-        Bool glXQueryRendererIntegerMESA(Display *dpy, int screen, int renderer,
-                                         int attribute, unsigned int *value);
-
-    can be used.  The value for <attribute> will be returned in one or more
-    integers specified by <value>.  The values, data sizes, and descriptions
-    of each renderer attribute are listed in the table below.
-
-    GLX renderer attribute         number     description
-                                  of values
-    ----------------------        ---------   -----------
-    GLX_RENDERER_VENDOR_ID_MESA   1           PCI ID of the device vendor
-    GLX_RENDERER_DEVICE_ID_MESA   1           PCI ID of the device
-    GLX_RENDERER_VERSION_MESA     3           Major, minor, and patch level of
-                                              the renderer implementation
-    GLX_RENDERER_ACCELERATED_MESA 1           Boolean indicating whether or
-                                              not the renderer is hardware
-                                              accelerated
-    GLX_RENDERER_VIDEO_MEMORY_MESA 1          Number of megabytes of video
-                                              memory available to the renderer
-    GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA
-                                  1           Boolean indicating whether or
-                                              not the renderer uses a unified
-                                              memory architecture or has
-                                              separate "on-card" and GART
-                                              memory.
-    GLX_RENDERER_PREFERRED_PROFILE_MESA
-                                  1           Bitmask of the preferred context
-                                              profile for this renderer.  This
-                                              value is suitable to be supplied
-                                              with the
-                                              GLX_CONTEXT_PROFILE_MASK_ARB
-                                              attribute to
-                                              glXCreateContextAttribsARB
-    GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA
-                                  2           Maximum core profile major and
-                                              minor version supported by the
-                                              renderer
-    GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA
-                                  2           Maximum compatibility profile
-                                              major and minor version
-                                              supported by the renderer
-    GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA
-                                  2           Maximum OpenGL ES 1.x
-                                              major and minor version
-                                              supported by the renderer
-    GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA
-                                  2           Maximum OpenGL ES 2.x or 3.x
-                                              major and minor version
-                                              supported by the renderer
-
-    In the table, boolean attributes will have either the value 0 or 1.
-
-    GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA,
-    GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA,
-    GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA, and
-    GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA each return <0, 0> in
-    *value if no version of that profile is supported.
-
-    GLX_RENDERER_VENDOR_ID_MESA and GLX_RENDERER_DEVICE_ID_MESA may return
-    0xFFFFFFFF if the device does not have a PCI ID (because it is not a PCI
-    device) or if the PCI ID is not available.  In this case the application
-    should rely on the string query instead.
-
-    If <attribute> is not a recognized value, False is returned, but no GLX
-    error is generated.  Otherwise, True is returned.
-
-    String versions of some attributes may also be queried using
-
-        const char *glXQueryRendererStringMESA(Display *dpy, int screen,
-                                               int renderer, int attribute);
-
-    The value for <attribute> will be returned in one or more
-    integers specified by <value>.  The values, data sizes, and descriptions
-    of each renderer attribute are listed in the table below.
-
-    GLX renderer attribute        description
-    ----------------------        -----------
-    GLX_RENDERER_VENDOR_ID_MESA   Name of the renderer provider.  This may
-                                  differ from the vendor name of the
-                                  underlying hardware.
-    GLX_RENDERER_DEVICE_ID_MESA   Name of the renderer.  This may differ from
-                                  the name of the underlying hardware (e.g.,
-                                  for a software renderer).
-
-    If <attribute> is not a recognized value, NULL is returned, but no GLX
-    error is generated.
-
-    The string returned for GLX_RENDERER_VENDOR_ID_MESA will have the same
-    format as the string that would be returned by glGetString of GL_VENDOR.
-    It may, however, have a different value.
-
-    The string returned for GLX_RENDERER_DEVICE_ID_MESA will have the same
-    format as the string that would be returned by glGetString of GL_RENDERER.
-    It may, however, have a different value.
-
-Issues
-
-    1) How should the difference between on-card and GART memory be exposed?
-
-        UNRESOLVED.
-
-    2) How should memory limitations of unified memory architecture (UMA)
-    systems be exposed?
-
-        UNRESOLVED.  Some hardware has different per-process and global
-        limits for memory that can be accessed within a single draw call.
-
-    3) How should the renderer's API preference be advertised?
-
-        UNRESOLVED.  The common case for desktop renderers is to prefer
-        either core or compatibility.  However, some renderers may actually
-        prefer an ES context.  This leaves the application in a tough spot
-        if it can only support core or compatibility and the renderer says it
-        wants ES.
-
-    4) Should OpenGL ES 2.0 and OpenGL ES 3.0 be treated separately?
-
-        RESOLVED.  No.  OpenGL ES 3.0 is backwards compatible with OpenGL ES
-        2.0.  Applications can detect OpenGL ES 3.0 support by querying
-        GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA.
-
-    5) How can applications tell the difference between different hardware
-    renderers for the same device?  For example, whether the renderer is the
-    open-source driver or the closed-source driver.
-
-        RESOLVED.  Assuming this extension is ever implemented outside Mesa,
-        applications can query GLX_RENDERER_VENDOR_ID_MESA from
-        glXQueryRendererStringMESA.  This will almost certainly return
-        different strings for open-source and closed-source drivers.
-
-    6) What is the value of GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA for
-    software renderers?
-
-        UNRESOLVED.  Video (display) memory and texture memory is not unified
-        for software implementations, so it seems reasonable for this to be
-        False.
-
-    7) How does an application determine the number of available renderers?
-
-        UNRESOLVED.
-
-    8) What happens if a fbconfig is used to create context on a renderer
-    that cannot support it?  For example, if a multisampled config is used
-    with a software renderer that does not support multisampling.
-
-        RESOLVED.  The language for glXCreateContextAttribsARB already covers
-        this case.  Context creation will fail, and BadMatch is generated.
-
-    9) In addition to being able to query the supported versions, should
-    applications also be able to query the supported extensions?
-
-        RESOLVED.  No.  Desktop OpenGL core profiles and OpenGL ES 3.0 have
-        moved away from the monolithic string returned by glGetString of
-        GL_EXTENSIONS.  Providing the newer indexed query would require adding
-        a lot of extra infrastructure, and it would probably provide little
-        benefit to applications.
-
-    10) What combination of values for GLX_RENDERER_PREFERRED_PROFILE_MESA,
-    GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA, and
-    GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA should be returned
-    for a renderer that only supports OpenGL 3.1 without the
-    GL_ARB_compatibility extension?
-
-        RESOLVED.  The renderer will return GLX_CONTEXT_CORE_PROFILE_BIT_ARB
-        for GLX_RENDERER_PREFERRED_PROFILE_MESA.
-
-        Further, the renderer will return <3,0> for
-        GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA because OpenGL
-        3.1 without GL_ARB_compatibility is not backwards compatible with
-        previous versions of OpenGL.  The render will return <3,1> for
-        GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA indicating that support
-        for OpenGL 3.1 is available.
-
-        Even though there is no OpenGL 3.1 core profile, the values
-        returned for GLX_RENDERER_PREFERRED_PROFILE_MESA and
-        GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA can be supplied
-        with the GLX_CONTEXT_PROFILE_MASK_ARB and
-        GLX_CONTEXT_{MAJOR,MINOR}_VERSION_ARB attributes of
-        glXCreateContextAttribsARB without error.  If the requested
-        OpenGL version is less than 3.2, the
-        GLX_CONTEXT_PROFILE_MASK_ARB attribute is ignored by
-        glXCreateContextAttribsARB.
-
-    11) How can application learn about multi-GPU (e.g., SLI, CrossFireX,
-    etc.) configurations?
-
-        UNRESOLVED.  Based on ISV feedback, this is important information to
-        provide to the application.  Given the variety of possible hardware
-        configurations (e.g., Hybrid CrossFireX) and different rendering
-        modes (e.g., split-frame rendering vs. alternate-frame rendering),
-        it's not clear how this information can be communicated.
-
-        It is likely that this will be left to a layered extension.
-
-    12) Should capability queries similar to those in
-    GL_ARB_internalformat_query or GL_ARB_internalformat_query2 be added?
-
-        RESOLVED.  No.  With the possible exception of the texture size
-        queries, it seems unlikely that applications would ever use this
-        information before creating a context.
-
-    13) Existing GL extensions (e.g., GL_ATI_meminfo and
-    GL_NVX_gpu_memory_info) allow easy queries after context creation.  With
-    this extension it is a bit of a pain for a portable application to query
-    the information after context creation.
-
-        RESOLVED.  Add versions of the queries that implicitly take the
-        display, screen, and renderer from the currently bound context.
-
-    14) Why not make the queries from issue #13 GL functions (instead of GLX)?
-
-        RESOLVED.  It is fairly compelling for the post-creation queries to
-        just use glGetInteger and glGetString.  However, the GL enums and
-        the GLX enums would have different names and would almost certainly
-        have different values.  It seems like this would cause more problems
-        than it would solve.
-
-    15) Should the string queries be required to return the same values as
-    glGetString(GL_VENDOR) and glGetString(GL_RENDERER)?
-
-        UNRESOLVED.  This may be useful for applications that already do
-        device detection based on these strings.
-
-    16) What type should the value parameter of glXQueryRendererIntegerMESA
-        and glXQueryCurrentRendererIntegerMESA be?
-
-        UNRESOLVED.  Other similar GLX query functions just use int or
-        unsigned int, so that's what this extension uses for now.  However,
-        an expeclitly sized value, such as uint32_t or uint64_t, seems
-        preferable.
-
-    17) What about SoCs and other systems that don't have PCI?
-
-        RESOLVED. The GLX_RENDERER_VENDOR_ID_MESA and
-        GLX_RENDERER_DEVICE_ID_MESA integer queries may return 0xFFFFFFFF if a
-        PCI ID either does not exist or is not available.  Implementations
-        should make every attempt to return as much information as is
-        possible.  For example, if the implementation is running on a non-PCI
-        SoC with a Qualcomm GPU, GLX_RENDERER_VENDOR_ID_MESA should return
-        0x5143, but GLX_RENDERER_DEVICE_ID_MESA will return 0xFFFFFFFF.
-
-Revision History
-
-    Version 1, 2012/08/27 - Initial version
-
-    Version 2, 2012/09/04 - Specify behavior of implementations that
-                            do not support certain profiles.
-                            Change wording of issue #8 to be more
-                            clear.
-                            Make some wording changes to issue #10 to
-                            clarify the resolution a bit.
-
-    Version 3, 2012/09/23 - Add issue #11 regarding multi-GPU systems.
-
-    Version 4, 2013/02/01 - Add issue #12 regarding texture / renderbuffer
-                            format queries.
-
-    Version 5, 2013/02/14 - Add issues #13 and #14 regarding simpler queires
-                            after the context is created and made current.
-                            Add issue #15 regarding the string query.
-                            Add issue #16 regarding the value type returned
-                            by the Integer functions.
-
-    Version 6, 2013/10/25 - Fix a typo.  Update the list of functions to
-                            which the new enums can be passed.  The "Current"
-                            versions were previously missing.
-
-    Version 7, 2013/11/07 - Fix a couple more typos.  Add issue #17 regarding
-                            the PCI queries on systems that don't have PCI.
-
-    Version 8, 2014/02/14 - Fix a couple typos. GLX_RENDER_ID_MESA should
-                            read GLX_RENDERER_ID_MESA. The VENDOR/DEVICE_ID
-                            example given in issue #17 should be 0x5143 and
-                            0xFFFFFFFF respectively.
-
-    Version 9, 2018/11/09 - Remove GLX_RENDERER_ID_MESA, which has never been
-                            implemented. Remove the unnecessary interactions
-                            with the GLX GLES profile extensions. Note the
-                            official GL extension number. Specify the section
-                            of the GLX spec to modify.
diff --git a/docs/specs/MESA_release_buffers.spec b/docs/specs/MESA_release_buffers.spec
deleted file mode 100644 (file)
index 52d1e5a..0000000
+++ /dev/null
@@ -1,85 +0,0 @@
-Name
-
-    MESA_release_buffers
-
-Name Strings
-
-    GLX_MESA_release_buffers
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Shipping since Mesa 2.0 in October, 1996.
-
-Version
-
-    Last Modified Date:  8 June 2000
-
-Number
-
-    217
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    Mesa's implementation of GLX is entirely implemented on the client side.
-    Therefore, Mesa cannot immediately detect when an X window or pixmap is
-    destroyed in order to free any ancillary data associated with the window
-    or pixmap.
-
-    The glxMesaReleaseBuffers() function can be used to explicitly indicate
-    when the back color buffer, depth buffer, stencil buffer, and/or accumu-
-    lation buffer associated with a drawable can be freed.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
-
-New Tokens
-
-    None.
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    The function
-
-       Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
-
-    causes all software ancillary buffers (back buffer, depth, stencil,
-    accum, etc) associated with the named drawable to be immediately
-    deallocated.  True is returned if <d> is a valid Mesa GLX drawable,
-    else False is returned.  After calling glXReleaseBuffersMESA, the
-    drawable should no longer be used for GL rendering.  Results of
-    attempting to do so are undefined.
-
-
-GLX Protocol
-
-    None, since this is a client-side operation.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    8 June 2000 - initial specification
diff --git a/docs/specs/MESA_shader_debug.spec b/docs/specs/MESA_shader_debug.spec
deleted file mode 100644 (file)
index fab92ab..0000000
+++ /dev/null
@@ -1,264 +0,0 @@
-Name
-
-    MESA_shader_debug
-
-Name Strings
-
-    GL_MESA_shader_debug
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-    Michal Krol (mjkrol 'at' gmail.com)
-
-Status
-
-    Obsolete.
-
-Version
-
-    Last Modified Date: July 30, 2006
-    Author Revision: 0.2
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 is required.
-
-    The ARB_shader_objects extension is required.
-
-    The ARB_shading_language_100 extension is required.
-
-    The extension is written against the OpenGL 1.5 specification.
-
-    The extension is written against the OpenGL Shading Language 1.10
-    Specification.
-
-Overview
-
-    This extension introduces a debug object that can be attached to
-    a program object to enable debugging. Vertex and/or fragment shader,
-    during execution, issue diagnostic function calls that are logged
-    to the debug object's log. A separate debug log for each shader type
-    is maintained. A debug object can be attached, detached and queried
-    at any time outside the Begin/End pair. Multiple debug objects can
-    be attached to a single program object.
-
-IP Status
-
-    None
-
-Issues
-
-    None
-
-New Procedures and Functions
-
-    handleARB CreateDebugObjectMESA(void)
-    void ClearDebugLogMESA(handleARB obj, enum logType, enum shaderType)
-    void GetDebugLogMESA(handleARB obj, enum logType, enum shaderType,
-                         sizei maxLength, sizei *length,
-                         charARB *debugLog)
-    sizei GetDebugLogLengthMESA(handleARB obj, enum logType,
-                                enum shaderType)
-
-New Types
-
-    None
-
-New Tokens
-
-    Returned by the <params> parameter of GetObjectParameter{fi}vARB:
-
-        DEBUG_OBJECT_MESA                               0x8759
-
-    Accepted by the <logType> argument of ClearDebugLogMESA,
-    GetDebugLogLengthMESA and GetDebugLogMESA:
-
-        DEBUG_PRINT_MESA                                0x875A
-        DEBUG_ASSERT_MESA                               0x875B
-
-Additions to Chapter 2 of the OpenGL 1.5 Specification
-(OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    None
-
-Additions to Chapter 5 of the OpenGL 1.5 Specification
-(Special Functions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State
-Requests)
-
-    None
-
-Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
-
-    None
-
-Additions to Chapter 1 of the OpenGL Shading Language 1.10 Specification
-(Introduction)
-
-    None
-
-Additions to Chapter 2 of the OpenGL Shading Language 1.10 Specification
-(Overview of OpenGL Shading)
-
-    None
-
-Additions to Chapter 3 of the OpenGL Shading Language 1.10 Specification
-(Basics)
-
-    None
-
-Additions to Chapter 4 of the OpenGL Shading Language 1.10 Specification
-(Variables and Types)
-
-    None
-
-Additions to Chapter 5 of the OpenGL Shading Language 1.10 Specification
-(Operators and Expressions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL Shading Language 1.10 Specification
-(Statements and Structure)
-
-    None
-
-Additions to Chapter 7 of the OpenGL Shading Language 1.10 Specification
-(Built-in Variables)
-
-    None
-
-Additions to Chapter 8 of the OpenGL Shading Language 1.10 Specification
-(Built-in Functions)
-
-    Add a new section 8.10 "Debug Functions":
-
-    Debug functions are available to both fragment and vertex shaders.
-    They are used to track the execution of a shader by logging
-    passed-in arguments to the debug object's log. Those values can be
-    retrieved by the application for inspection after shader execution
-    is complete.
-
-    The text, if any, produced by any of these functions is appended
-    to each debug object that is attached to the program object.
-    There are different debug log types
-
-    Add a new section 8.10.1 "Print Function":
-
-    The following printMESA prototypes are available.
-
-        void printMESA(const float value)
-        void printMESA(const int value)
-        void printMESA(const bool value)
-        void printMESA(const vec2 value)
-        void printMESA(const vec3 value)
-        void printMESA(const vec4 value)
-        void printMESA(const ivec2 value)
-        void printMESA(const ivec3 value)
-        void printMESA(const ivec4 value)
-        void printMESA(const bvec2 value)
-        void printMESA(const bvec3 value)
-        void printMESA(const bvec4 value)
-        void printMESA(const mat2 value)
-        void printMESA(const mat3 value)
-        void printMESA(const mat4 value)
-        void printMESA(const sampler1D value)
-        void printMESA(const sampler2D value)
-        void printMESA(const sampler3D value)
-        void printMESA(const samplerCube value)
-        void printMESA(const sampler1DShadow value)
-        void printMESA(const sampler2DShadow value)
-
-    The printMESA function writes the argument <value> to the "debug
-    print log" (XXX DEBUG_PRINT_MESA?). Each component is written in
-    text format (XXX format!) and is delimited by a white space (XXX 1
-    or more?).
-
-    Add a new section 8.10.2 "Assert Function":
-
-    The following assertMESA prototypes are available.
-
-        void assertMESA(const bool condition)
-        void assertMESA(const bool condition, const int cookie)
-        void assertMESA(const bool condition, const int cookie,
-                        const int file, const int line)
-
-    The assertMESA function checks if the argument <condition> is
-    true or false. If it is true, nothing happens. If it is false,
-    a diagnostic message is written to the "debug assert log".
-    The message contains the argument <file>, <line>, <cookie> and
-    implementation dependent double-quoted string, each of this
-    delimited by a white space. If the argument <cookie> is not present,
-    it is meant as if it was of value 0. If the arguments <file> and
-    <line> are not present, they are meant as if they were of values
-    __FILE__ and __LINE__, respectively. The following three calls
-    produce the same output, assuming they were issued from the same
-    file and line.
-
-        assertMESA (false);
-        assertMESA (false, 0);
-        assertMESA (false, 0, __FILE__, __LINE__);
-
-    The diagnostic message examples follow.
-
-        1 89 0 ""
-        1 45 333 "all (lessThanEqual (fragColor, vec4 (1.0)))"
-        1 66 1 "assertion failed in file 1, line 66, cookie 1"
-
-Additions to Chapter 9 of the OpenGL Shading Language 1.10 Specification
-(Shading Language Grammar)
-
-    None
-
-Additions to Chapter 10 of the OpenGL Shading Language 1.10
-Specification (Issues)
-
-    None
-
-Additions to the AGL/EGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Errors
-
-    TBD
-
-New State
-
-    TBD
-
-New Implementation Dependent State
-
-    TBD
-
-Sample Code
-
-    TBD
-
-Revision History
-
-    29 May 2006
-        Initial draft. (Michal Krol)
-    30 July 2006
-        Add Overview, New Procedures and Functions, New Tokens sections.
-        Add sections 8.10.1, 8.10.2 to GLSL spec.
diff --git a/docs/specs/MESA_shader_integer_functions.txt b/docs/specs/MESA_shader_integer_functions.txt
deleted file mode 100644 (file)
index 9fcc9b4..0000000
+++ /dev/null
@@ -1,522 +0,0 @@
-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 3, March 31, 2017
-
-Number
-
-    OpenGL Extension #495
-
-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 (OpenGL) or GLSL ES 3.00 (OpenGL ES) 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 and version
-    3.00 of the OpenGL ES 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
-    ----  -----------  --------  -----------------------------------------
-     3    31-Mar-2017  Jon Leech Add ES support (OpenGL-Registry/issues/3)
-     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/docs/specs/MESA_swap_control.spec b/docs/specs/MESA_swap_control.spec
deleted file mode 100644 (file)
index a002563..0000000
+++ /dev/null
@@ -1,129 +0,0 @@
-Name
-
-    MESA_swap_control
-
-Name Strings
-
-    GLX_MESA_swap_control
-
-Contact
-
-    Ian Romanick, IBM, idr at us.ibm.com
-
-Status
-
-    Deployed in DRI drivers post-XFree86 4.3.
-
-Version
-
-    Date: 5/1/2003   Revision: 1.1
-
-Number
-
-    ???
-
-Dependencies
-
-    None
-
-    Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
-    version 1.5.
-
-Overview
-
-    This extension allows an application to specify a minimum periodicity
-    of color buffer swaps, measured in video frame periods.
-
-Issues
-
-    * Should implementations that export GLX_MESA_swap_control also export
-      GL_EXT_swap_control for compatibility with WGL_EXT_swap_control?
-
-    UNRESOLVED.
-
-New Procedures and Functions
-
-    int glXSwapIntervalMESA(unsigned int interval)
-    int glXGetSwapIntervalMESA(void)
-
-New Tokens
-
-    None
-
-Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
-and the Framebuffer)
-
-    None
-
-Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
-
-    None
-
-Additions to the GLX 1.3 Specification
-
-    [Add the following to Section 3.3.10 of the GLX Specification (Double
-     Buffering)]
-
-    glXSwapIntervalMESA specifies the minimum number of video frame periods
-    per buffer swap.  (e.g. a value of two means that the color buffers
-    will be swapped at most every other video frame.)  A return value
-    of zero indicates success; otherwise an error occurred.  The interval
-    takes effect when glXSwapBuffers is first called subsequent to the
-    glXSwapIntervalMESA call.
-
-    A video frame period is the time required by the monitor to display a 
-    full frame of video data.  In the case of an interlaced monitor,
-    this is typically the time required to display both the even and odd 
-    fields of a frame of video data.
-
-    If <interval> is set to a value of 0, buffer swaps are not synchro-
-    nized to a video frame.  The <interval> value is silently clamped to
-    the maximum implementation-dependent value supported before being
-    stored.
-
-    The swap interval is not part of the render context state.  It cannot
-    be pushed or popped.  The current swap interval for the window
-    associated with the current context can be obtained by calling
-    glXGetSwapIntervalMESA.  The default swap interval is 0.
-
-    On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets
-    the swap interval to 1.
-
-Errors
-
-    glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
-    GLXContext or if the current context is not a direct rendering context.
-
-GLX Protocol
-
-    None.  This extension only extends to direct rendering contexts.
-
-New State
-
-    Get Value          Get Command     Type        Initial Value
-    ---------          -----------     ----        -------------
-    [swap interval]    GetSwapInterval Z+          0
-
-New Implementation Dependent State
-
-    None
-
-
-Revision History
-
-    1.1,  5/1/03   Added the issues section and contact information.
-                  Changed the default swap interval to 0.
-    1.0,  3/17/03  Initial version based on GLX_SGI_swap_control and
-                   WGL_EXT_swap_control.
diff --git a/docs/specs/MESA_swap_frame_usage.spec b/docs/specs/MESA_swap_frame_usage.spec
deleted file mode 100644 (file)
index 5023ead..0000000
+++ /dev/null
@@ -1,201 +0,0 @@
-Name
-
-    MESA_swap_frame_usage
-
-Name Strings
-
-    GLX_MESA_swap_frame_usage
-
-Contact
-
-    Ian Romanick, IBM, idr at us.ibm.com
-
-Status
-
-    Deployed in DRI drivers post-XFree86 4.3.
-
-Version
-
-    Date: 5/1/2003   Revision: 1.1
-
-Number
-
-    ???
-
-Dependencies
-
-    GLX_SGI_swap_control affects the definition of this extension.
-    GLX_MESA_swap_control affects the definition of this extension.
-    GLX_OML_sync_control affects the definition of this extension.
-
-    Based on WGL_I3D_swap_frame_usage version 1.3.
-
-Overview
-
-    This extension allows an application to determine what portion of the
-    swap period has elapsed since the last swap operation completed.  The
-    "usage" value is a floating point value on the range [0,max] which is
-    calculated as follows:
-
-                              td
-                   percent = ----
-                              tf
-
-    where td is the time measured from the last completed buffer swap (or
-    call to enable the statistic) to when the next buffer swap completes, tf
-    is the entire time for a frame which may be multiple screen refreshes
-    depending on the swap interval as set by the GLX_SGI_swap_control or
-    GLX_OML_sync_control extensions. 
-
-    The value, percent, indicates the amount of time spent between the
-    completion of the two swaps.  If the value is in the range [0,1], the
-    buffer swap occurred within the time period required to maintain a
-    constant frame rate.  If the value is in the range (1,max], a constant
-    frame rate was not achieved.  The value indicates the number of frames
-    required to draw.
-
-    This definition of "percent" differs slightly from
-    WGL_I3D_swap_frame_usage.  In WGL_I3D_swap_frame_usage, the measurement
-    is taken from the completion of one swap to the issuance of the next.
-    This representation may not be as useful as measuring between
-    completions, as a significant amount of time may pass between the
-    issuance of a swap and the swap actually occurring.
-
-    There is also a mechanism to determine whether a frame swap was
-    missed.
-
-New Procedures and Functions
-
-    int glXGetFrameUsageMESA(Display *dpy,
-                             GLXDrawable drawable,
-                            float *usage)
-
-    int glXBeginFrameTrackingMESA(Display *dpy,
-                                  GLXDrawable drawable)
-
-    int glXEndFrameTrackingMESA(Display *dpy,
-                                GLXDrawable drawable)
-
-    int glXQueryFrameTrackingMESA(Display *dpy,
-                                  GLXDrawable drawable,
-                                 int64_t *swapCount,
-                                  int64_t *missedFrames,
-                                  float *lastMissedUsage)
-
-New Tokens
-
-    None
-
-Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
-and the Framebuffer)
-
-    None
-
-Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
-
-    None
-
-Additions to the GLX 1.3 Specification
-
-    The frame usage is measured as the percentage of the swap period elapsed
-    between two buffer-swap operations being committed.  In unextended GLX the
-    swap period is the vertical refresh time.  If SGI_swap_control or
-    MESA_swap_control are supported, the swap period is the vertical refresh
-    time multiplied by the swap interval (or one if the swap interval is set
-    to zero).
-    
-    If OML_sync_control is supported, the swap period is the vertical
-    refresh time multiplied by the divisor parameter to
-    glXSwapBuffersMscOML.  The frame usage in this case is less than 1.0 if
-    the swap is committed before target_msc, and is greater than or equal to
-    1.0 otherwise.  The actual usage value is based on the divisor and is
-    never less than 0.0.
-
-       int glXBeginFrameTrackingMESA(Display *dpy,
-                                     GLXDrawable drawable,
-                                    float *usage)
-
-    glXGetFrameUsageMESA returns a floating-point value in <usage>
-    that represents the current swap usage, as defined above.
-
-    Missed frame swaps can be tracked by calling the following function:
-
-       int glXBeginFrameTrackingMESA(Display *dpy,
-                                     GLXDrawable drawable)
-
-    glXBeginFrameTrackingMESA resets a "missed frame" count and
-    synchronizes with the next frame vertical sync before it returns.
-    If a swap is missed based in the rate control specified by the
-    <interval> set by glXSwapIntervalSGI or the default swap of once
-    per frame, the missed frame count is incremented.
-
-    The current missed frame count and total number of swaps since
-    the last call to glXBeginFrameTrackingMESA can be obtained by
-    calling the following function:
-
-       int glXQueryFrameTrackingMESA(Display *dpy,
-                                     GLXDrawable drawable,
-                                    int64_t *swapCount,
-                                     int64_t *missedFrames,
-                                     float *lastMissedUsage)
-
-    The location pointed to by <swapCount> will be updated with the
-    number of swaps that have been committed.  This value may not match the
-    number of swaps that have been requested since swaps may be
-    queued by the implementation.  This function can be called at any
-    time and does not synchronize to vertical blank.
-
-    The location pointed to by <missedFrames> will contain the number
-    swaps that missed the specified frame.  The frame usage for the
-    last missed frame is returned in the location pointed to by
-    <lastMissedUsage>.
-
-    Frame tracking is disabled by calling the function
-
-       int glXEndFrameTrackingMESA(Display *dpy,
-                                   GLXDrawable drawable)
-
-    This function will not return until all swaps have occurred.  The
-    application can call glXQueryFrameTrackingMESA for a final swap and
-    missed frame count.
-
-    If these functions are successful, zero is returned.  If the context
-    associated with dpy and drawable is not a direct context,
-    GLX_BAD_CONTEXT is returned.
-
-Errors
-
-    If the function succeeds, zero is returned.  If the function
-    fails, one of the following error codes is returned:
-
-       GLX_BAD_CONTEXT         The current rendering context is not a direct
-                                      context.
-
-GLX Protocol
-
-    None.  This extension only extends to direct rendering contexts.
-
-New State
-
-    None
-
-New Implementation Dependent State
-
-    None
-
-Revision History
-
-    1.1,  5/1/03   Added contact information.
-    1.0,  3/17/03  Initial version based on WGL_I3D_swap_frame_usage.
diff --git a/docs/specs/MESA_texture_array.spec b/docs/specs/MESA_texture_array.spec
deleted file mode 100644 (file)
index 88f8815..0000000
+++ /dev/null
@@ -1,804 +0,0 @@
-Name
-
-    MESA_texture_array
-
-Name Strings
-
-    GL_MESA_texture_array
-
-Contact
-
-    Ian Romanick, IBM (idr 'at' us.ibm.com)
-
-IP Status
-
-    No known IP issues.
-
-Status
-
-    DEPRECATED - Support removed in Mesa 10.1.
-
-Version
-
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.2 or GL_EXT_texture3D is required.
-
-    Support for ARB_fragment_program is assumed, but not required.
-
-    Support for ARB_fragment_program_shadow is assumed, but not required.
-
-    Support for EXT_framebuffer_object is assumed, but not required.
-
-    Written based on the wording of the OpenGL 2.0 specification and
-    ARB_fragment_program_shadow but not dependent on them.
-
-Overview
-
-    There are a number of circumstances where an application may wish to
-    blend two textures out of a larger set of textures.  Moreover, in some
-    cases the selected textures may vary on a per-fragment basis within
-    a polygon.  Several examples include:
-
-       1. High dynamic range textures.  The application stores several
-       different "exposures" of an image as different textures.  On a
-       per-fragment basis, the application selects which exposures are
-       used.
-
-       2. A terrain engine where the altitude of a point determines the
-       texture applied to it.  If the transition is from beach sand to
-       grass to rocks to snow, the application will store each texture
-       in a different texture map, and dynamically select which two
-       textures to blend at run-time.
-
-       3. Storing short video clips in textures.  Each depth slice is a
-       single frame of video.
-
-    Several solutions to this problem have been proposed, but they either
-    involve using a separate texture unit for each texture map or using 3D
-    textures without mipmaps.  Both of these options have major drawbacks.
-
-    This extension provides a third alternative that eliminates the major
-    drawbacks of both previous methods.  A new texture target,
-    TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in
-    all aspects except the sizes of the non-base level images.  In
-    traditional 3D texturing, the size of the N+1 LOD is half the size
-    of the N LOD in all three dimensions.  For the TEXTURE_2D_ARRAY target,
-    the height and width of the N+1 LOD is halved, but the depth is the
-    same for all levels of detail. The texture then becomes an array of
-    2D textures.  The per-fragment texel is selected by the R texture
-    coordinate.
-
-    References:
-
-        https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
-        https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
-        https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903
-        http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm
-
-New Procedures and Functions
-
-    All functions come directly from EXT_texture_array.
-
-    void FramebufferTextureLayerEXT(enum target, enum attachment,
-                                    uint texture, int level, int layer);
-
-New Tokens
-
-    All token names and values come directly from EXT_texture_array.
-
-    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by
-    the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
-    GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage,
-    GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and
-    GetTexParameterfv:
-
-        TEXTURE_1D_ARRAY_EXT                            0x8C18
-        TEXTURE_2D_ARRAY_EXT                            0x8C1A
-
-    Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
-    CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D,
-    CompressedTexSubImage2D, GetTexLevelParameteriv, and 
-    GetTexLevelParameterfv:
-
-        TEXTURE_1D_ARRAY_EXT
-        PROXY_TEXTURE_1D_ARRAY_EXT                      0x8C19
-
-    Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
-    CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D,
-    GetTexLevelParameteriv, and GetTexLevelParameterfv:
-
-        TEXTURE_2D_ARRAY_EXT
-        PROXY_TEXTURE_2D_ARRAY_EXT                      0x8C1B
-
-    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
-    GetFloatv, and GetDoublev
-
-        TEXTURE_BINDING_1D_ARRAY_EXT                    0x8C1C
-        TEXTURE_BINDING_2D_ARRAY_EXT                    0x8C1D
-        MAX_ARRAY_TEXTURE_LAYERS_EXT                    0x88FF
-
-    Accepted by the <param> parameter of TexParameterf, TexParameteri,
-    TexParameterfv, and TexParameteriv when the <pname> parameter is
-    TEXTURE_COMPARE_MODE_ARB:
-
-        COMPARE_REF_DEPTH_TO_TEXTURE_EXT                0x884E
-
-    (Note:  COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
-    existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
-    reflects the fact that the R coordinate is not always used.)
-
-    Accepted by the <internalformat> parameter of TexImage3D and
-    CompressedTexImage3D, and by the <format> parameter of
-    CompressedTexSubImage3D:
-
-        COMPRESSED_RGB_S3TC_DXT1_EXT
-        COMPRESSED_RGBA_S3TC_DXT1_EXT
-        COMPRESSED_RGBA_S3TC_DXT3_EXT
-        COMPRESSED_RGBA_S3TC_DXT5_EXT
-
-    Accepted by the <pname> parameter of
-    GetFramebufferAttachmentParameterivEXT:
-
-        FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT          0x8CD4
-
-    (Note:  FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
-    FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
-    EXT_framebuffer_object.  This extension generalizes the notion of
-    "<zoffset>" to include layers of an array texture.)
-
-Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
-
-    -- Section 3.8.1 "Texture Image Specification"
-
-       Change the first paragraph (page 150) to say (spec changes identical to
-       EXT_texture_array):
-
-       "The command
-
-         void TexImage3D(enum target, int level, int internalformat,
-                         sizei width, sizei height, sizei depth, int border,
-                         enum format, enum type, void *data);
-
-       is used to specify a three-dimensional texture image. target must be one
-       one of TEXTURE_3D for a three-dimensional texture or
-       TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture.
-       Additionally, target may be either PROXY_TEXTURE_3D for a
-       three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a
-       two-dimensional proxy array texture."
-
-       Change the fourth paragraph on page 151 to say (spec changes identical
-       to EXT_texture_array):
-
-       "Textures with a base internal format of DEPTH_COMPONENT are supported
-       by texture image specification commands only if target is TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
-       PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or
-       PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any
-       other target will result in an INVALID_OPERATION error."
-
-
-       Change the fourth paragraph on page 156 to say (spec changes identical
-       to EXT_texture_array):
-       
-       "The command
-
-         void TexImage2D(enum target, int level,
-                         int internalformat, sizei width, sizei height,
-                         int border, enum format, enum type, void *data);
-
-       is used to specify a two-dimensional texture image. target must be one
-       of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
-       one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
-       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
-       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
-       TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally,
-       target may be either PROXY_TEXTURE_2D for a two-dimensional proxy
-       texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array
-       texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the
-       special case discussed in section 3.8.11.  The other parameters match
-       the corresponding parameters of TexImage3D.
-
-       For the purposes of decoding the texture image, TexImage2D is
-       equivalent to calling TexImage3D with corresponding arguments and depth
-       of 1, except that
-
-         * The border depth, d_b, is zero, and the depth of the image is
-           always 1 regardless of the value of border. 
-
-         * The border height, h_b, is zero if <target> is
-           TEXTURE_1D_ARRAY_EXT, and <border> otherwise.
-
-         * Convolution will be performed on the image (possibly changing its
-           width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
-
-         * UNPACK SKIP IMAGES is ignored."
-
-    -- Section 3.8.2 "Alternate Texture Image Specification Commands"
-
-       Change the second paragraph (page 159) (spec changes identical
-       to EXT_texture_array):
-
-       "The command
-
-         void CopyTexImage2D(enum target, int level,
-                             enum internalformat, int x, int y, sizei width,
-                             sizei height, int border);
-
-       defines a two-dimensional texture image in exactly the manner of
-       TexImage2D, except that the image data are taken from the framebuffer
-       rather than from client memory. Currently, target must be one of
-       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
-       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
-       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
-       TEXTURE_CUBE_MAP_NEGATIVE_Z.
-
-
-       Change the last paragraph on page 160 to say (spec changes identical
-       to EXT_texture_array):
-
-       "Currently the target arguments of TexSubImage1D and CopyTexSubImage1D
-       must be TEXTURE_1D, the target arguments of TexSubImage2D and
-       CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
-       TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X,
-       TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y,
-       TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the
-       target arguments of TexSubImage3D and CopyTexSubImage3D must be
-       TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..."
-
-
-    -- Section 3.8.4 "Texture Parameters"
-
-       Change the first paragraph (page 166) to say:
-
-       "Various parameters control how the texel array is treated when
-       specified or changed, and when applied to a fragment. Each parameter is
-       set by calling
-
-         void TexParameter{if}(enum target, enum pname, T param); 
-         void TexParameter{if}v(enum target, enum pname, T params);
-
-       target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
-       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT."
-
-
-    -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail"
-
-       Change the first paragraph (page 172) to say:
-
-       "Let s(x,y) be the function that associates an s texture coordinate
-       with each set of window coordinates (x,y) that lie within a primitive;
-       define t(x,y) and r(x,y) analogously.  Let u(x,y) = w_t * s(x,y),
-       v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t,
-       and d_t are as defined by equations 3.15, 3.16, and 3.17 with
-       w_s, h_s, and d_s equal to the width, height, and depth of the
-       image array whose level is level_base.  For a one-dimensional
-       texture or a one-dimensional array texture, define v(x,y) = 0 and
-       w(x,y) = 0; for a two-dimensional texture or a two-dimensional array
-       texture, define w(x,y) = 0..."
-
-    -- Section 3.8.8 "Texture Minification" in the section "Mipmapping"
-
-       Change the third paragraph (page 174) to say:
-       
-       "For a two-dimensional texture, two-dimensional array texture, or
-       cube map texture,"
-
-       Change the fourth paragraph (page 174) to say:
-
-       "And for a one-dimensional texture or a one-dimensional array texture,"
-
-       After the first paragraph (page 175) add:
-
-       "For one-dimensional array textures, h_b and d_b are treated as 1,
-       regardless of the actual values, when performing mipmap calculations.
-       For two-dimensional array textures, d_b is always treated as one,
-       regardless of the actual value, when performing mipmap calculations."
-
-    -- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping"
-
-       Change the third paragraph (page 176) to say (spec changes identical
-       to EXT_texture_array):
-
-       "The contents of the derived arrays are computed by repeated, filtered
-       reduction of the level_base array.  For one- and two-dimensional array
-       textures, each layer is filtered independently.  ..."
-
-    -- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping"
-
-       Change first paragraph to say (spec changes identical to
-       EXT_texture_array):
-
-       "Mipmaps can be generated manually with the command
-
-         void GenerateMipmapEXT(enum target);
-
-       where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
-       TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY.  Mipmap generation
-       affects the texture image attached to <target>.  ..."
-
-    -- Section 3.8.10 "Texture Completeness"
-
-       Change the second paragraph (page 177) to say (spec changes identical
-       to EXT_texture_array):
-
-       "For one-, two-, or three-dimensional textures and one- or
-       two-dimensional array textures, a texture is complete if the following
-       conditions all hold true:"
-
-    -- Section 3.8.11 "Texture State and Proxy State"
-
-       Change the second and third paragraphs (page 179) to say (spec changes
-       identical to EXT_texture_array):
-
-       "In addition to image arrays for one-, two-, and three-dimensional
-       textures, one- and two-dimensional array textures, and the six image
-       arrays for the cube map texture, partially instantiated image arrays
-       are maintained for one-, two-, and three-dimensional textures and one-
-       and two-dimensional array textures.  Additionally, a single proxy image
-       array is maintained for the cube map texture.  Each proxy image array
-       includes width, height, depth, border width, and internal format state
-       values, as well as state for the red, green, blue, alpha, luminance,
-       and intensity component resolutions. Proxy image arrays do not include
-       image data, nor do they include texture properties. When TexImage3D is
-       executed with target specified as PROXY_TEXTURE_3D, the
-       three-dimensional proxy state values of the specified level-of-detail
-       are recomputed and updated. If the image array would not be supported
-       by TexImage3D called with target set to TEXTURE 3D, no error is
-       generated, but the proxy width, height, depth, border width, and
-       component resolutions are set to zero. If the image array would be
-       supported by such a call to TexImage3D, the proxy state values are set
-       exactly as though the actual image array were being specified. No pixel
-       data are transferred or processed in either case.
-
-       Proxy arrays for one- and two-dimensional textures and one- and
-       two-dimensional array textures are operated on in the same way when
-       TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
-       TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
-       PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
-       specified as PROXY_TETXURE_2D_ARRAY_EXT."
-
-    -- Section 3.8.12 "Texture Objects"
-
-       Change section (page 180) to say (spec changes identical to 
-       EXT_texture_array):
-
-       "In addition to the default textures TEXTURE_1D, TEXTURE_2D,
-       TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT,
-       named one-, two-, and three-dimensional, cube map, and one- and
-       two-dimensional array texture objects can be created and operated upon.
-       The name space for texture objects is the unsigned integers, with zero
-       reserved by the GL.
-
-       A texture object is created by binding an unused name to TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
-       TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
-
-         void BindTexture(enum target, uint texture);
-
-       with <target> set to the desired texture target and <texture> set to
-       the unused name.  The resulting texture object is a new state vector,
-       comprising all the state values listed in section 3.8.11, set to the
-       same initial values. If the new texture object is bound to TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
-       TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-,
-       three-dimensional, cube map, one- or two-dimensional array texture
-       respectively until it is deleted.
-
-       BindTexture may also be used to bind an existing texture object to
-       either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
-       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error
-       INVALID_OPERATION is generated if an attempt is made to bind a texture
-       object of different dimensionality than the specified target. If the
-       bind is successful no change is made to the state of the bound texture
-       object, and any previous binding to target is broken.
-
-       While a texture object is bound, GL operations on the target to which
-       it is bound affect the bound object, and queries of the target to which
-       it is bound return state from the bound object. If texture mapping of
-       the dimensionality of the target to which a texture object is bound is
-       enabled, the state of the bound texture object directs the texturing
-       operation.
-
-       In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
-       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
-       one-, two-, three-dimensional, cube map, and one- and two-dimensional
-       array texture state vectors respectively associated with them. In order
-       that access to these initial textures not be lost, they are treated as
-       texture objects all of whose names are 0. The initial one-, two-,
-       three-dimensional, cube map, one- and two-dimensional array textures
-       are therefore operated upon, queried, and applied as TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
-       TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
-       targets.
-
-       Change second paragraph on page 181 to say (spec changes identical to 
-       EXT_texture_array):
-       
-       "...  If a texture that is currently bound to one of the targets
-       TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
-       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as
-       though BindTexture had been executed with the same target and texture
-       zero. ..."
-
-       Change second paragraph on page 182 to say (spec changes identical to 
-       EXT_texture_array):
-       
-       "The texture object name space, including the initial one-, two-, and
-       three dimensional, cube map, and one- and two-dimensional array texture
-       objects, is shared among all texture units. ..."
-
-
-    -- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes"
-
-       Change second through fourth paragraphs (page 188) to say:
-
-       "Let D_t be the depth texture value, in the range [0, 1].  For
-       texture lookups from one- and two-dimensional, rectangle, and
-       one-dimensional array targets, let R be the interpolated <r>
-       texture coordinate, clamped to the range [0, 1].  For texture lookups
-       from two-dimensional array texture targets, let R be the interpolated
-       <q> texture coordinate, clamped to the range [0, 1].  Then the
-       effective texture value L_t, I_t, or A_t is computed as follows:
-
-       If the value of TEXTURE_COMPARE_MODE is NONE, then
-
-          r = Dt
-
-       If the value of TEXTURE_COMPARE_MODE is
-       COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture
-       comparison function as shown in table 3.27."
-
-    -- Section 3.8.15 "Texture Application"
-
-       Change the first paragraph (page 189) to say:
-
-       "Texturing is enabled or disabled using the generic Enable and Disable
-       commands, respectively, with the symbolic constants TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
-       TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube
-       map, one-dimensional array, or two-dimensional array texture,
-       respectively.  If both two- and one-dimensional textures are enabled,
-       the two-dimensional texture is used.  If the three-dimensional and
-       either of the two- or one-dimensional textures is enabled, the
-       three-dimensional texture is used.  If the cube map texture and any of
-       the three-, two-, or one-dimensional textures is enabled, then cube map
-       texturing is used.  If one-dimensional array texture is enabled and any
-       of cube map, three-, two-, or one-dimensional textures is enabled, 
-       one-dimensional array texturing is used.  If two-dimensional array
-       texture is enabled and any of cube map, three-, two-, one-dimensional
-       textures or one-dimensional array texture is enabled, two-dimensional
-       array texturing is used..."
-
-    -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions):
-
-       (mostly add to existing grammar rules)
-
-       <optionName>           ::= "MESA_texture_array"
-
-       <texTarget>            ::= "1D"
-                               | "2D"
-                               | "3D"
-                               | "CUBE"
-                               | "RECT"
-                               | <arrayTarget> (if program option is present)
-                               | <shadowTarget> (if program option is present)
-
-       <arrayTarget>          ::= "ARRAY1D"
-                               | "ARRAY2D"
-
-       <shadowTarget>         ::= "SHADOW1D"
-                               | "SHADOW2D"
-                               | "SHADOWRECT"
-                               | <shadowArrayTarget> (if program option is present)
-
-       <shadowArrayTarget>    ::= "SHADOWARRAY1D"
-                               | "SHADOWARRAY2D"
-
-
-    -- Add Section 3.11.4.5.4 "Texture Stack Option"
-
-       "If a fragment program specifies the "MESA_texture_array" program
-       option, the <texTarget> rule is modified to add the texture targets
-       ARRAY1D and ARRAY2D (See Section 3.11.2)."
-
-    -- Section 3.11.6 "Fragment Program Texture Instruction Set"
-
-       (replace 1st and 2nd paragraphs with the following paragraphs)
-
-       "The first three texture instructions described below specify the
-       mapping of 4-tuple input vectors to 4-tuple output vectors.
-       The sampling of the texture works as described in section 3.8,
-       except that texture environments and texture functions are not
-       applicable, and the texture enables hierarchy is replaced by explicit
-       references to the desired texture target (i.e., 1D, 2D, 3D, cube map,
-       rectangle, ARRAY1D, ARRAY2D).  These texture instructions specify
-       how the 4-tuple is mapped into the coordinates used for sampling.  The
-       following function is used to describe the texture sampling in the
-       descriptions below: 
-
-         vec4 TextureSample(vec4 coord, float lodBias, int texImageUnit,
-                            enum texTarget);
-
-       Note that not all four components of the texture coordinates <coord>
-       are used by all texture targets.  Component usage for each <texTarget>
-       is defined in table X.
-
-                                                        coordinates used
-         texTarget          Texture Type               s t r  layer  shadow
-         ----------------   ---------------------      -----  -----  ------
-         1D                 TEXTURE_1D                 x - -    -      -
-         2D                 TEXTURE_2D                 x y -    -      -
-         3D                 TEXTURE_3D                 x y z    -      -
-         CUBE               TEXTURE_CUBE_MAP           x y z    -      -
-         RECT               TEXTURE_RECTANGLE_ARB      x y -    -      -
-         ARRAY1D            TEXTURE_1D_ARRAY_EXT       x - -    y      -
-         ARRAY2D            TEXTURE_2D_ARRAY_EXT       x y -    z      -
-         SHADOW1D           TEXTURE_1D                 x - -    -      z
-         SHADOW2D           TEXTURE_2D                 x y -    -      z
-         SHADOWRECT         TEXTURE_RECTANGLE_ARB      x y -    -      z
-         SHADOWARRAY1D      TEXTURE_1D_ARRAY_EXT       x - -    y      z
-         SHADOWARRAY2D      TEXTURE_2D_ARRAY_EXT       x y -    z      w
-
-         Table X:  Texture types accessed for each of the <texTarget>, and
-         coordinate mappings.  The "coordinates used" column indicate the
-         input values used for each coordinate of the texture lookup, the
-         layer selector for array textures, and the reference value for
-         texture comparisons."
-
-    -- Section 3.11.6.2 "TXP: Project coordinate and map to color"
-    
-       Add to the end of the section:
-       
-       "A program will fail to load if the TXP instruction is used in
-       conjunction with the SHADOWARRAY2D target."
-
-Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations)
-
-    -- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer"
-
-       Add to the end of the section (spec changes identical to
-       EXT_texture_array):
-
-       "The command
-
-         void FramebufferTextureLayerEXT(enum target, enum attachment,
-                                         uint texture, int level, int layer);
-
-       operates identically to FramebufferTexture3DEXT, except that it
-       attaches a single layer of a three-dimensional texture or a one- or
-       two-dimensional array texture.  <layer> is an integer indicating the
-       layer number, and is treated identically to the <zoffset> parameter in
-       FramebufferTexture3DEXT.  The error INVALID_VALUE is generated if
-       <layer> is negative.  The error INVALID_OPERATION is generated if
-       <texture> is non-zero and is not the name of a three dimensional
-       texture or one- or two-dimensional array texture.  Unlike
-       FramebufferTexture3D, no <textarget> parameter is accepted.
-
-       If <texture> is non-zero and the command does not result in an error,
-       the framebuffer attachment state corresponding to <attachment> is
-       updated as in the other FramebufferTexture commands, except that
-       FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>."
-
-    -- Section 4.4.4.1 "Framebuffer Attachment Completeness"
-
-      Add to the end of the list of completeness rules (spec changes
-      identical to EXT_texture_array):
-
-        "* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
-           FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or 
-           two-dimensional array texture, then
-           FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the
-           number of layers in the texture."
-
-Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
-
-    -- Section 5.4 "Display Lists"
-
-       Change the first paragraph on page 242 to say (spec changes
-       identical to EXT_texture_array):
-
-       "TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are
-       executed immediately when called with the corresponding proxy arguments
-       PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D,
-       PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT;
-       PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE,
-       PROXY_POST_CONVOLUTION_COLOR_TABLE, or
-       PROXY_POST_COLOR_MATRIX_COLOR_TABLE."
-
-Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
-
-    -- Section 6.1.3 "Enumerated Queries"
-
-       Add after the line beginning "If the value of
-       FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes
-       identical to EXT_texture_array):
-
-       "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the
-       texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
-       three-dimensional texture or a one- or two-dimensional array texture,
-       then <params> will contain the number of texture layer attached to the
-       attachment point.  Otherwise, <params> will contain the value zero."
-
-    -- Section 6.1.4 "Texture Queries"
-    
-       Change the first three paragraphs (page 248) to say (spec changes
-       identical to EXT_texture_array):
-
-       "The command
-
-         void GetTexImage(enum tex, int lod, enum format,
-                          enum type, void *img);
-
-       is used to obtain texture images. It is somewhat different from the
-       other get commands; tex is a symbolic value indicating which texture
-       (or texture face in the case of a cube map texture target name) is to
-       be obtained.  TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT,
-       and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional
-       texture, or one- or two-dimensional array texture, respectively.
-       TEXTURE_CUBE_MAP_POSITIVE_X, ...
-
-       GetTexImage obtains... from the first image to the last for
-       three-dimensional textures.  One- and two-dimensional array textures
-       are treated as two- and three-dimensional images, respectively, where
-       the layers are treated as rows or images.  These groups are then...
-
-       For three-dimensional and two-dimensional array textures, pixel storage
-       operations are applied as if the image were two-dimensional, except
-       that the additional pixel storage state values PACK_IMAGE_HEIGHT and
-       PACK_SKIP_IMAGES are applied. ..."
-
-Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
-
-    None
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Dependencies on ARB_fragment_program
-
-    If ARB_fragment_program is not supported, the changes to section 3.11
-    should be ignored.
-
-Dependencies on EXT_framebuffer_object
-
-    If EXT_framebuffer_object is not supported, the changes to section
-    3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored.
-
-Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc
-
-    (Identical dependency as EXT_texture_array.)
-
-    S3TC texture compression is supported for two-dimensional array textures.
-    When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
-    as a compressed two-dimensional textures.  When specifying or querying
-    compressed images using one of the S3TC formats, the images are provided
-    and/or returned as a series of two-dimensional textures stored
-    consecutively in memory, with the layer closest to zero specified first.
-    For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
-    the three-dimensional compression format provided in the
-    EXT_texture_compression_vtc extension.  Pixel store parameters, including
-    those specific to three-dimensional images, are ignored when compressed
-    image data are provided or returned, as in the
-    EXT_texture_compression_s3tc extension.
-
-    S3TC compression is not supported for one-dimensional texture targets in
-    EXT_texture_compression_s3tc, and is not supported for one-dimensional
-    array textures in this extension.  If compressed one-dimensional arrays
-    are needed, use a two-dimensional texture with a height of one.
-
-    This extension allows the use of the four S3TC internal format types in
-    TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls.
-
-Errors
-
-    None
-
-New State
-
-    (add to table 6.15, p. 276)
-
-                                                     Initial
-    Get Value                     Type   Get Command  Value Description           Sec.    Attribute
-    ----------------------------  -----  -----------  ----- --------------------  ------  ---------
-    TEXTURE_BINDING_1D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
-                                                            to TEXTURE_1D_ARRAY
-    TEXTURE_BINDING_2D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
-                                                            to TEXTURE_2D_ARRAY
-
-
-New Implementation Dependent State
-
-    (add to Table 6.32, p. 293)
-
-                                                    Minimum
-    Get Value                     Type  Get Command  Value  Description         Sec.  Attribute
-    ----------------------------  ----  ----------- ------- ------------------  ----- ---------
-    MAX_TEXTURE_ARRAY_LAYERS_EXT   Z+   GetIntegerv   64    maximum number of   3.8.1     -
-                                                            layers for texture
-                                                            arrays
-
-Issues
-
-    (1) Is "texture stack" a good name for this functionality?
-
-        NO.  The name is changed to "array texture" to match the
-        nomenclature used by GL_EXT_texture_array.
-
-    (2) Should the R texture coordinate be treated as normalized or
-    un-normalized?  If it were un-normalized, floor(R) could be thought
-    of as a direct index into the array texture.  This may be more
-    convenient for applications.
-
-        RESOLVED.  All texture coordinates are normalized.  The issue of
-        un-normalized texture coordinates has been discussed in the ARB
-        before and should be left for a layered extension.
-
-        RE-RESOLVED.  The R coordinate is un-normalized.  Accessing an array
-        using [0, layers-1] coordinates is much more natural.
-
-    (3) How does LOD selection work for stacked textures?
-
-        RESOLVED.  For 2D array textures the R coordinate is ignored, and
-        the LOD selection equations for 2D textures are used.  For 1D
-        array textures the T coordinate is ignored, and the LOD selection
-        equations for 1D textures are used.  The expected usage is in a
-        fragment program with an explicit LOD selection.
-
-    (4) What is the maximum size of a 2D array texture?  Is it the same
-    as for a 3D texture, or should a new query be added?  How about for 1D
-    array textures?
-
-        RESOLVED.  A new query is added.
-
-    (5) How are array textures exposed in GLSL?
-    
-        RESOLVED.  Use GL_EXT_texture_array.
-        
-    (6) Should a 1D array texture also be exposed?
-
-        RESOLVED.  For orthogonality, yes.
-
-    (7) How are stacked textures attached to framebuffer objects?
-
-        RESOLVED.  Layers of both one- and two-dimensional array textures
-        are attached using FreambufferTextureLayerEXT.  Once attached, the
-        array texture layer behaves exactly as either a one- or
-        two-dimensional texture.
-
-    (8) How is this extension related to GL_EXT_texture_array?
-    
-        This extension adapats GL_MESAX_texture_stack to the notation,
-        indexing, and FBO access of GL_EXT_texture_array.  This extension
-        replaces the GLSL support of GL_EXT_texture_array with
-        GL_ARB_fragment_program support.
-
-        Assembly program support is also provided by GL_NV_gpu_program4.
-        GL_NV_gpu_program4 also adds support for other features that are
-        specific to Nvidia hardware, while this extension adds only support
-        for array textures.
-
-        Much of text of this extension that has changed since
-        GL_MESAX_texture_stack comes directly from either
-        GL_EXT_texture_array or GL_NV_gpu_program4.
-
-Revision History
-
-    ||2005/11/15||0.1||idr||Initial draft MESAX version.||
-    ||2005/12/07||0.2||idr||Added framebuffer object interactions.||
-    ||2005/12/12||0.3||idr||Updated fragment program interactions.||
-    ||2007/05/16||0.4||idr||Converted to MESA_texture_array.  Brought in line with EXT_texture_array and NV_gpu_program4.||
diff --git a/docs/specs/MESA_texture_signed_rgba.spec b/docs/specs/MESA_texture_signed_rgba.spec
deleted file mode 100644 (file)
index e3a6b59..0000000
+++ /dev/null
@@ -1,214 +0,0 @@
-Name
-
-    MESA_texture_signed_rgba
-
-Name Strings
-
-    GL_MESA_texture_signed_rgba
-
-Contact
-
-
-
-Notice
-
-
-
-IP Status
-
-    No known IP issues
-
-Status
-
-
-
-Version
-
-    0.3, 2009-03-24
-
-Number
-
-    Not assigned ?
-
-Dependencies
-
-    Written based on the wording of the OpenGL 2.0 specification.
-
-    This extension trivially interacts with ARB_texture_float.
-    This extension shares some language with ARB_texture_compression_rgtc
-    but does not depend on it.
-
-Overview
-
-    OpenGL prior to 3.1 does not support any signed texture formats.
-    ARB_texture_compression_rgtc introduces some compressed red and
-    red_green signed formats but no uncompressed ones, which might
-    still be useful. NV_texture_shader adds signed texture formats,
-    but also a lot of functionality which has been superseded by fragment
-    shaders.
-    It is usually possible to get the same functionality
-    using a unsigned format by doing scale and bias in a shader, but this
-    is undesirable since modern hardware has direct support for this.
-    This extension adds a signed 4-channel texture format by backporting
-    the relevant features from OpenGL 3.1, as a means to support this in
-    OpenGL implementations only supporting older versions.
-
-Issues
-
-    1) What should this extension be called?
-
-       RESOLVED: MESA_texture_signed_rgba seems reasonable.
-       The rgba part is there because only 4 channel format is supported.
-
-
-    2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
-       be supported?
-
-       RESOLVED: NO. To keep this extension simple, only add the most
-       universal format, rgba. alpha/luminance can't be trivially supported
-       since OpenGL 3.1 does not support them any longer, and there is some
-       implied dependency on ARB_texture_rg for red/red_green formats so
-       avoid all this. Likewise, only 8 bits per channel is supported.
-
-
-    3) Should this extension use new enums for the texture formats?
-
-       RESOLVED: NO. Same enums as those used in OpenGL 3.1.
-
-
-    4) How are signed integer values mapped to floating-point values?
-
-       RESOLVED: Same as described in issue 5) of
-       ARB_texture_compression_rgtc (quote):
-       A signed 8-bit two's complement value X is computed to
-       a floating-point value Xf with the formula:
-
-                { X / 127.0, X > -128
-           Xf = {
-                { -1.0,      X == -128
-
-       This conversion means -1, 0, and +1 are all exactly representable,
-       however -128 and -127 both map to -1.0.  Mapping -128 to -1.0
-       avoids the numerical awkwardness of have a representable value
-       slightly more negative than -1.0.
-
-       This conversion is intentionally NOT the "byte" conversion listed
-       in Table 2.9 for component conversions.  That conversion says:
-
-           Xf = (2*X + 1) / 255.0
-
-       The Table 2.9 conversion is incapable of exactly representing
-       zero.
-
-       (Difference to ARB_texture_compression_rgtc):
-       This is the same mapping as OpenGL 3.1 uses.
-       This is also different to what NV_texture_shader used.
-       The above mapping should be considered the reference, but there
-       is some leeway so other mappings are allowed for implementations which
-       cannot do this. Particularly the mapping given in NV_texture_shader or
-       the standard OpenGL byte/float mapping is considered acceptable too, as
-       might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
-       127 (that is, uses different scale factors for negative and positive
-       numbers).
-       Also, it is ok to store incoming GL_BYTE user data as-is, without
-       converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
-       and converting back (using the mapping described here).
-       Other than those subtle issues there are no other non-standard
-       conversions used, so when using for instance CopyTexImage2D with
-       a framebuffer clamped to [0,1] all converted numbers will be in the range
-       [0, 127] (and not scaled and biased).
-
-
-    5) How will signed components resulting from RGBA8_SNORM texture
-       fetches interact with fragment coloring?
-
-       RESOLVED: Same as described in issue 6) of
-       ARB_texture_compression_rgtc (quote):
-       The specification language for this extension is silent
-       about clamping behavior leaving this to the core specification
-       and other extensions.  The clamping or lack of clamping is left
-       to the core specification and other extensions.
-
-       For assembly program extensions supporting texture fetches
-       (ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
-       etc.) or the OpenGL Shading Language, these signed formats will
-       appear as expected with unclamped signed components as a result
-       of a texture fetch instruction.
-
-       If ARB_color_buffer_float is supported, its clamping controls
-       will apply.
-
-       NV_texture_shader extension, if supported, adds support for
-       fixed-point textures with signed components and relaxed the
-       fixed-function texture environment clamping appropriately.  If the
-       NV_texture_shader extension is supported, its specified behavior
-       for the texture environment applies where intermediate values
-       are clamped to [-1,1] unless stated otherwise as in the case
-       of explicitly clamped to [0,1] for GL_COMBINE.  or clamping the
-       linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.
-
-       Otherwise, the conventional core texture environment clamps
-       incoming, intermediate, and output color components to [0,1].
-
-       This implies that the conventional texture environment
-       functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
-       using GLSL (and with none of the extensions referred to above)
-       is unable to make proper use of the signed texture formats added
-       by this extension because the conventional texture environment
-       requires texture source colors to be clamped to [0,1].  Texture
-       filtering of these signed formats would be still signed, but
-       negative values generated post-filtering would be clamped to
-       zero by the core texture environment functionality.  The
-       expectation is clearly that this extension would be co-implemented
-       with one of the previously referred to extensions or used with
-       GLSL for the new signed formats to be useful.
-
-
-    6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
-       functions?
-
-       RESOLVED: YES.
-
-
-    7) What to do with GetTexParameter if ARB_texture_float is supported,
-       in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
-       TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?
-
-       RESOLVED: ARB_texture_float states type is either NONE,
-       UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
-       SIGNED_NORMALIZED, which will be returned accordingly. This is the
-       same behaviour as in OpenGL 3.1.
-
-
-New Tokens
-
-
-    Accepted by the <internalformat> parameter of
-    TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
-
-        RGBA_SNORM                                0x8F93
-        RGBA8_SNORM                               0x8F97
-
-    Returned by the <params> parameter of GetTexLevelParameter:
-
-        SIGNED_NORMALIZED                         0x8F9C
-
-
-Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):
-
- -- Section 3.8.1, Texture Image Specification
-
-    Add to Table 3.16 (page 154): Sized internal formats
-
-    Sized             Base             R    G    B    A    L    I    D
-    Internal Format   Internal Format bits bits bits bits bits bits bits
-    ---------------   --------------- ---- ---- ---- ---- ---- ---- ----
-    RGBA8_SNORM       RGBA             8    8    8    8    0    0    0
-
-
-Dependencies on ARB_texture_float extension:
-
-    If ARB_texture_float is supported, GetTexParameter queries with <value>
-    of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
-    TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
-    the base internal format is RGBA_SNORM.
diff --git a/docs/specs/MESA_window_pos.spec b/docs/specs/MESA_window_pos.spec
deleted file mode 100644 (file)
index 9e81e9c..0000000
+++ /dev/null
@@ -1,126 +0,0 @@
-Name
-
-    MESA_window_pos
-
-Name Strings
-
-    GL_MESA_window_pos
-
-Contact
-
-    Brian Paul, brian.paul 'at' tungstengraphics.com
-
-Status
-
-    Shipping (since Mesa version 1.2.8)
-
-Version
-
-
-Number
-
-    197
-
-Dependencies
-
-    OpenGL 1.0 is required.
-    The extension is written against the OpenGL 1.2 Specification
-
-Overview
-
-    In order to set the current raster position to a specific window
-    coordinate with the RasterPos command, the modelview matrix, projection
-    matrix and viewport must be set very carefully.  Furthermore, if the
-    desired window coordinate is outside of the window's bounds one must
-    rely on a subtle side-effect of the Bitmap command in order to circumvent
-    frustum clipping.
-
-    This extension provides a set of functions to directly set the
-    current raster position, bypassing the modelview matrix, the
-    projection matrix and the viewport to window mapping.  Furthermore,
-    clip testing is not performed.
-
-    This greatly simplifies the process of setting the current raster
-    position to a specific window coordinate prior to calling DrawPixels,
-    CopyPixels or Bitmap.
-
-New Procedures and Functions
-
-    void WindowPos2dMESA(double x, double y)
-    void WindowPos2fMESA(float x, float y)
-    void WindowPos2iMESA(int x, int y)
-    void WindowPos2sMESA(short x, short y)
-    void WindowPos2ivMESA(const int *p)
-    void WindowPos2svMESA(const short *p)
-    void WindowPos2fvMESA(const float *p)
-    void WindowPos2dvMESA(const double *p)
-    void WindowPos3iMESA(int x, int y, int z)
-    void WindowPos3sMESA(short x, short y, short z)
-    void WindowPos3fMESA(float x, float y, float z)
-    void WindowPos3dMESA(double x, double y, double z)
-    void WindowPos3ivMESA(const int *p)
-    void WindowPos3svMESA(const short *p)
-    void WindowPos3fvMESA(const float *p)
-    void WindowPos3dvMESA(const double *p)
-    void WindowPos4iMESA(int x, int y, int z, int w)
-    void WindowPos4sMESA(short x, short y, short z, short w)
-    void WindowPos4fMESA(float x, float y, float z, float w)
-    void WindowPos4dMESA(double x, double y, double z, double )
-    void WindowPos4ivMESA(const int *p)
-    void WindowPos4svMESA(const short *p)
-    void WindowPos4fvMESA(const float *p)
-    void WindowPos4dvMESA(const double *p)
-
-New Tokens
-
-    none
-
-Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
-
-  - (2.12, p. 41) Insert after third paragraph:
-
-      Alternately, the current raster position may be set by one of the
-      WindowPosMESA commands:
-
-         void WindowPos{234}{sidf}MESA( T coords );
-         void WindowPos{234}{sidf}vMESA( T coords );
-
-      WindosPos4MESA takes four values indicating x, y, z, and w.
-      WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only
-      x, y, and z with w implicitly set to 1 (or only x and y with z
-      implicitly set to 0 and w implicitly set to 1).
-
-      WindowPosMESA operates like RasterPos except that the current modelview
-      matrix, projection matrix and viewport parameters are ignored and the
-      clip test operation always passes.  The current raster position values
-      are directly set to the parameters passed to WindowPosMESA.  The current
-      color, color index and texture coordinate update the current raster
-      position's associated data.
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    Not specified at this time.  However, a protocol message very similar
-    to that of RasterPos is expected.
-
-Errors
-
-    INVALID_OPERATION is generated if WindowPosMESA is called between
-    Begin and End.
-
-New State
-
-    None.
-
-New Implementation Dependent State
-
-    None.
-
-Revision History
-
-  * Revision 1.0 - Initial specification
-  * Revision 1.1 - Minor clean-up  (7 Jan 2000, Brian Paul)
-
diff --git a/docs/specs/MESA_ycbcr_texture.spec b/docs/specs/MESA_ycbcr_texture.spec
deleted file mode 100644 (file)
index 6a730e8..0000000
+++ /dev/null
@@ -1,204 +0,0 @@
-Name
-
-    MESA_ycbcr_texture
-
-Name Strings
-
-    GL_MESA_ycbcr_texture
-
-Contact
-
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
-    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
-
-Status
-
-    Shipping (Mesa 4.0.4 and later)
-
-Version
-
-    1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required
-    This extension is written against the OpenGL 1.4 Specification.
-    NV_texture_rectangle effects the definition of this extension.
-
-Overview
-
-    This extension supports texture images stored in the YCbCr format.
-    There is no support for converting YCbCr images to RGB or vice versa
-    during pixel transfer.  The texture's YCbCr colors are converted to
-    RGB during texture sampling, after-which, all the usual per-fragment
-    operations take place.  Only 2D texture images are supported (not
-    glDrawPixels, glReadPixels, etc).
-
-    A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
-    The first component is luminance (Y).  For pixels in even-numbered
-    image columns, the second component is Cb.  For pixels in odd-numbered
-    image columns, the second component is Cr.  If one were to convert the
-    data to RGB one would need to examine two pixels from columns N and N+1
-    (where N is even) to deduce the RGB color.
-
-IP Status
-
-    None
-
-Issues
-
-    None
-
-New Procedures and Functions
-
-    None
-
-New Tokens
-
-    Accepted by the <internalFormat> and <format> parameters of
-    TexImage2D and TexSubImage2D:
-
-        YCBCR_MESA                   0x8757
-
-    Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
-
-        UNSIGNED_SHORT_8_8_MESA      0x85BA /* same as Apple's */
-        UNSIGNED_SHORT_8_8_REV_MESA  0x85BB /* same as Apple's */
-
-Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
-
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
-    add the following to Table 3.8 (Packed pixel formats):
-    
-    type Parameter                GL Data   Number of        Matching
-     Token Name                    Type     Components     Pixel Formats
-    --------------                -------   ----------     -------------
-    UNSIGNED_SHORT_8_8_MESA       ushort         2         YCBCR_MESA
-    UNSIGNED_SHORT_8_8_REV_MESA   ushort         2         YCBCR_MESA
-
-
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
-    add the following to Table 3.10 (UNSIGNED_SHORT formats):
-
-    UNSIGNED_SHORT_8_8_MESA:
-
-      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-    +-------------------------------+-------------------------------+
-    |              1st              |              2nd              |
-    +-------------------------------+-------------------------------+
-                        
-    UNSIGNED_SHORT_8_8_REV_MESA:
-
-      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-    +-------------------------------+-------------------------------+
-    |              2nd              |              1st              |
-    +-------------------------------+-------------------------------+
-
-
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
-    add the following to Table 3.12 (Packed pixel field assignments):
-
-                       First       Second     Third      Fourth
-    Format             Element     Element    Element    Element
-    ------             -------     -------    -------    -------
-    YCBCR_MESA         luminance   chroma
-
-
-    In section 3.8.1, Texture Image Specification, on page 125, add
-    another item to the list of TexImage2D and TexImage3D equivalence
-    exceptions:
-
-    * The value of internalformat and format may be YCBCR_MESA to
-      indicate that the image data is in YCbCr format.  type must
-      be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA
-      as seen in tables 3.8 and 3.10.  Table 3.12 describes the mapping
-      between Y and Cb/Cr to the components.
-      If NV_texture_rectangle is supported target may also be
-      TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
-      All pixel transfer operations are bypassed.  The texture is stored as
-      YCbCr, not RGB.  Queries of the texture's red, green and blue component
-      sizes will return zero.  The YCbCr colors are converted to RGB during
-      texture sampling using an implementation dependent conversion.
-
-
-    In section 3.8.1, Texture Image Specification, on page 126, add
-    another item to the list of TexImage1D and TexImage2D equivalence
-    exceptions:
-
-    * The value of internalformat and format can not be YCBCR_MESA.
-
-
-    In section 3.8.2, Alternate Texture Image Specification Commands, on
-    page 129, insert this paragraph after the first full paragraph on the
-    page:
-
-         "If the internal storage format of the image being updated by
-    TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA.
-    The error INVALID_OPERATION will be generated otherwise."
-
-
-Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    None
-
-Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
-State Requests)
-
-    None
-
-Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
-
-    None
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Errors
-
-    INVALID_ENUM is generated by TexImage2D if <internalFormat> is
-    MESA_YCBCR but <format> is not MESA_YCBCR.
-
-    INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but
-    <internalFormat> is not MESA_YCBCR.
-
-    INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and
-    <internalFormat> is MESA_YCBCR and <border> is not zero.
-
-    INVALID_OPERATION is generated by TexSubImage2D if the internal image
-    format is YCBCR_MESA and <format> is not YCBCR_MESA.
-
-    INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
-    image is YCBCR_MESA.
-    
-New State
-
-    Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT
-    from n x Z42 to n x Z43 to indicate that internal format may also be
-    YCBCR_MESA.
-
-Revision History
-
-    20 September 2002 - Initial draft
-    29 April 2003 - minor updates
-     3 September 2003 - further clarify when YCbCr->RGB conversion takes place
-    19 September 2003 - a few more updates prior to submitting to extension
-                        registry.
-     3 April 2004 - fix assorted inaccuracies
diff --git a/docs/specs/OLD/EGL_MESA_screen_surface.txt b/docs/specs/OLD/EGL_MESA_screen_surface.txt
deleted file mode 100644 (file)
index 698a240..0000000
+++ /dev/null
@@ -1,564 +0,0 @@
-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/docs/specs/OLD/MESA_agp_offset.spec b/docs/specs/OLD/MESA_agp_offset.spec
deleted file mode 100644 (file)
index ac5ad7d..0000000
+++ /dev/null
@@ -1,94 +0,0 @@
-Name
-
-    MESA_agp_offset
-
-Name Strings
-
-    GLX_MESA_agp_offset
-
-Contact
-
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
-    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
-
-Status
-
-    Obsolete. Effectively superseded by ARB_vertex_buffer_object.
-
-Version
-
-    1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required
-    GLX_NV_vertex_array_range is required.
-    This extensions is written against the OpenGL 1.4 Specification.
-
-Overview
-
-    This extensions provides a way to convert pointers in an AGP memory
-    region into byte offsets into the AGP aperture.
-    Note, this extension depends on GLX_NV_vertex_array_range, for which
-    no real specification exists.  See GL_NV_vertex_array_range for more
-    information.
-
-IP Status
-
-    None
-
-Issues
-
-    None
-
-New Procedures and Functions
-
-    unsigned int glXGetAGPOffsetMESA( const void *pointer )
-
-New Tokens
-
-    None
-
-Additions to the OpenGL 1.4 Specification
-
-    None
-
-Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
-
-    Add a new section, 3.6 as follows:
-
-    3.6 AGP Memory Access
-
-    On "PC" computers, AGP memory can be allocated with glXAllocateMemoryNV
-    and freed with glXFreeMemoryNV.  Sometimes it's useful to know where a
-    block of AGP memory is located with respect to the start of the AGP
-    aperture.  The function
-
-        GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
-
-    Returns the offset of the given memory block from the start of AGP
-    memory in basic machine units (i.e. bytes).  If pointer is invalid
-    the value ~0 will be returned.
-
-GLX Protocol
-
-    None.  This is a client side-only extension.
-
-Errors
-
-    glXGetAGPOffsetMESA will return ~0 if the pointer does not point to
-    an AGP memory region.
-
-New State
-
-    None
-
-Revision History
-
-    20 September 2002 - Initial draft
-    2 October 2002 - finished GLX chapter 3 additions
-    27 July 2004 - use unsigned int instead of GLuint, void instead of GLvoid
diff --git a/docs/specs/OLD/MESA_packed_depth_stencil.spec b/docs/specs/OLD/MESA_packed_depth_stencil.spec
deleted file mode 100644 (file)
index 112b730..0000000
+++ /dev/null
@@ -1,230 +0,0 @@
-Name
-
-    MESA_packed_depth_stencil
-
-Name Strings
-
-    GL_MESA_packed_depth_stencil
-
-Contact
-
-    Keith Whitwell, VA Linux Systems Inc. (keithw 'at' valinux.com)
-    Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
-
-Status
-
-    Obsolete.
-
-Version
-
-
-Number
-
-    ???
-
-Dependencies
-
-    EXT_abgr affects the definition of this extension
-    SGIS_texture4D affects the definition of this extension
-    EXT_cmyka affects the definition of this extension
-    ARB_packed_pixels affects the definition of this extension
-
-Overview
-       
-    Provides a mechanism for DrawPixels and ReadPixels to efficiently
-    transfer depth and stencil image data.  Specifically, we defined new
-    packed pixel formats and types which pack both stencil and depth
-    into one value.
-
-Issues:
-
-    1. Is this the right way to distinguish between 24/8 and 8/24
-       pixel formats?  Should we instead provide both:
-       
-       GL_DEPTH_STENCIL_MESA
-       GL_STENCIL_DEPTH_MESA
-
-       And perhaps just use GL_UNSIGNED_INT, GL_UNSIGNED_SHORT ?
-
-    2. If not, is it correct to use _REV to indicate that stencil
-       preceeds depth in the 1_15 and 8_24 formats?
-
-    3. Do we really want the GL_UNSIGNED_SHORT formats?  
-
-       
-New Procedures and Functions
-
-    None.
-
-New Tokens
-    
-    Accepted by the <format> parameter of ReadPixels and DrawPixels:
-
-       GL_DEPTH_STENCIL_MESA           0x8750
-
-    Accepted by the <type> parameter of ReadPixels and DrawPixels:
-
-       GL_UNSIGNED_INT_24_8_MESA       0x8751
-       GL_UNSIGNED_INT_8_24_REV_MESA   0x8752
-       GL_UNSIGNED_SHORT_15_1_MESA     0x8753
-       GL_UNSIGNED_SHORT_1_15_REV_MESA 0x8754
-
-Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.1 Specification (Rasterization)
-
-    One entry is added to table 3.5 (DrawPixels and ReadPixels formats).
-    The new table is:
-
-                       Target
-       Format Name     Buffer  Element Meaning and Order
-       -----------     ------  -------------------------
-       COLOR_INDEX     Color   Color index
-       STENCIL_INDEX   Stencil Stencil index
-       DEPTH_COMPONENT Depth   Depth component
-       RED             Color   R component
-       GREEN           Color   G component
-       BLUE            Color   B component
-       ALPHA           Color   A component
-       RGB             Color   R, G, B components
-       RGBA            Color   R, G, B, A components
-       BGRA            Color   B, G, R, A components
-       ABGR_EXT        Color   A, B, G, R components
-       CMYK_EXT        Color   Cyan, Magenta, Yellow, Black components
-       CMYKA_EXT       Color   Cyan, Magenta, Yellow, Black, A components
-       LUMINANCE       Color   Luminance component
-       LUMINANCE_ALPHA Color   Luminance, A components
-       DEPTH_STENCIL   Depth,  Depth component, stencil index.
-                       Stencil
-
-       Table 3.5: DrawPixels and ReadPixels formats.  The third column
-       gives a description of and the number and order of elements in a
-       group.
-
-    Add to the description of packed pixel formats:
-
-       <type> Parameter                Data    of        Matching
-       Token Name                      Type    Elements  Pixel Formats
-       ----------------                ----    --------  -------------
-
-       UNSIGNED_BYTE_3_3_2           ubyte   3       RGB
-       UNSIGNED_BYTE_2_3_3_REV       ubyte   3       RGB
-       UNSIGNED_SHORT_5_6_5          ushort  3       RGB
-       UNSIGNED_SHORT_5_6_5_REV      ushort  3       RGB
-       UNSIGNED_SHORT_4_4_4_4        ushort  4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
-       UNSIGNED_SHORT_4_4_4_4_REV    ushort  4       RGBA,BGRA
-       UNSIGNED_SHORT_5_5_5_1        ushort  4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
-       UNSIGNED_SHORT_1_5_5_5_REV    ushort  4       RGBA,BGRA
-       UNSIGNED_INT_8_8_8_8          uint    4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
-       UNSIGNED_INT_8_8_8_8_REV      uint    4       RGBA,BGRA
-       UNSIGNED_INT_10_10_10_2       uint    4       RGBA,BGRA,ABGR_EXT,CMYK_EXT
-       UNSIGNED_INT_2_10_10_10_REV   uint    4       RGBA,BGRA
-       UNSIGNED_SHORT_15_1_MESA      ushort  2       DEPTH_STENCIL_MESA
-       UNSIGNED_SHORT_1_15_REV_MESA  ushort  2       DEPTH_STENCIL_MESA
-       UNSIGNED_SHORT_24_8_MESA      ushort  2       DEPTH_STENCIL_MESA
-       UNSIGNED_SHORT_8_24_REV_MESA  ushort  2       DEPTH_STENCIL_MESA
-
-       UNSIGNED_INT_8_24:
-
-            31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
-           +-----------------------+-----------------------------------------------------------------------+
-           |                       |                                                                       |
-           +-----------------------+-----------------------------------------------------------------------+
-
-                   first                                       second              
-                   element                                     element             
-
-
-       UNSIGNED_INT_24_8:
-
-            31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
-           +----------------------------------------------------------------------+------------------------+
-           |                                                                      |                        |
-           +----------------------------------------------------------------------+------------------------+
-
-                   first                                                                 second                    
-                   element                                                               element                   
-
-       UNSIGNED_SHORT_15_1:
-
-             15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-           +-----------------------------------------------------------+---+
-           |                                                           |   |
-           +-----------------------------------------------------------+---+
-
-                       first                                           second  
-                       element                                         element 
-
-
-       UNSIGNED_SHORT_1_15_REV:
-
-             15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-           +---+-----------------------------------------------------------+
-           |   |                                                           |
-           +---+-----------------------------------------------------------+
-
-           second                  first
-           element                 element
-
-    The assignment of elements to fields in the packed pixel is as
-    described in the table below:
-
-                          First       Second   Third       Fourth
-       Format             Element     Element  Element     Element
-       ------             -------     -------  -------     -------
-       RGB                red         green    blue
-       RGBA               red         green    blue        alpha
-       BGRA               blue        green    red         alpha
-       ABGR_EXT           alpha       blue     green       red
-       CMYK_EXT           cyan        magenta  yellow      black
-       DEPTH_STENCIL_MESA depth       stencil
-
-Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
-and the Frame Buffer)
-
-    The new format is added to the discussion of Obtaining Pixels from the
-    Framebuffer.  It should read " If the <format> is one of RED, GREEN,
-    BLUE, ALPHA, RGB, RGBA, ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, and
-    the GL is in color index mode, then the color index is obtained."
-
-    The new format is added to the discussion of Index Lookup.  It should
-    read "If <format> is one of RED, GREEN, BLUE, ALPHA, RGB, RGBA,
-    ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, then the index is used to
-    reference 4 tables of color components: PIXEL_MAP_I_TO_R,
-    PIXEL_MAP_I_TO_G, PIXEL_MAP_I_TO_B, and PIXEL_MAP_I_TO_A."
-
-
-Additions to Chapter 5 of the 1.1 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
-
-    None
-
-Additions to the GLX Specification
-
-    None
-
-GLX Protocol
-
-    TBD
-
-Errors
-
-    None
-
-New State
-
-    None
-
-Revision History
-
-    Version 1.0 - 23 Sep 2000
-        Keith's original version.
-
-    Version 1.1 - 3 Nov 2000
-        Brian's edits, assigned values to new enums.
-
diff --git a/docs/specs/OLD/MESA_program_debug.spec b/docs/specs/OLD/MESA_program_debug.spec
deleted file mode 100644 (file)
index dd4b43b..0000000
+++ /dev/null
@@ -1,356 +0,0 @@
-Name
-
-    MESA_program_debug
-
-Name Strings
-
-    GL_MESA_program_debug
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Obsolete.
-
-Version
-
-    Last Modified Date: July 20, 2003
-    Author Revision: 1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.4 is required
-    The extension is written against the OpenGL 1.4 specification.
-    ARB_vertex_program or ARB_fragment_program or NV_vertex_program
-    or NV_fragment_program is required.
-
-Overview
-
-    The extension provides facilities for implementing debuggers for
-    vertex and fragment programs.
-
-    The concept is that vertex and fragment program debuggers will be
-    implemented outside of the GL as a utility package.  This extension
-    only provides the minimal hooks required to implement a debugger.
-
-    There are facilities to do the following:
-    1. Have the GL call a user-specified function prior to executing
-       each vertex or fragment instruction.
-    2. Query the current program string's execution position.
-    3. Query the current values of intermediate program values.
-
-    The main feature is the ProgramCallbackMESA function.  It allows the
-    user to register a callback function with the GL.  The callback will
-    be called prior to executing each vertex or fragment program instruction.
-
-    From within the callback, the user may issue Get* commands to
-    query current GL state.  The GetProgramRegisterfvMESA function allows
-    current program values to be queried (such as temporaries, input
-    attributes, and result registers).
-
-    There are flags for enabling/disabling the program callbacks.
-
-    The current execution position (as an offset from the start of the
-    program string) can be queried with
-    GetIntegerv(GL_FRAGMENT_PROGRAM_POSITION_MESA, &pos) or
-    GetIntegerv(GL_VERTEX_PROGRAM_POSITION_MESA, &pos).
-
-
-IP Status
-
-    None
-
-Issues
-
-    1. Is this the right model for a debugger?
-
-       It seems prudent to minimize the scope of this extension and leave
-       it up to the developer (or developer community) to write debuggers
-       that layer on top of this extension.
-
-       If the debugger were fully implemented within the GL it's not
-       clear how terminal and GUI-based interfaces would work, for
-       example.
-
-    2. There aren't any other extensions that register callbacks with
-       the GL.  Isn't there another solution?
-
-       If we want to be able to single-step through vertex/fragment
-       programs I don't see another way to do it.
-
-    3. How do we prevent the user from doing something crazy in the
-       callback function, like trying to call glBegin (leading to
-       recursion)?
-
-       The rule is that the callback function can only issue glGet*()
-       functions and no other GL commands.  It could be difficult to
-       enforce this, however.  Therefore, calling any non-get GL
-       command from within the callback will result in undefined
-       results.    
-
-    4. Is this extension amenable to hardware implementation?
-
-       Hopefully, but if not, the GL implementation will have to fall
-       back to a software path when debugging.  This may be acceptable
-       for debugging.
-
-    5. What's the <data> parameter to ProgramCallbackMESA for?
-
-       It's a common programming practice to associate a user-supplied
-       value with callback functions.
-
-    6. Debuggers often allow one to modify intermediate program values,
-       then continue.  Does this extension support that?
-
-       No.
-
-
-New Procedures and Functions (and datatypes)
-
-    typedef void (*programcallbackMESA)(enum target, void *data)
-
-    void ProgramCallbackMESA(enum target, programcallbackMESA callback,
-                             void *data)
-
-    void GetProgramRegisterfvMESA(enum target, sizei len,
-                                  const ubyte *registerName, float *v)
-
-New Tokens
-
-    Accepted by the <cap> parameter of Enable, Disable, IsEnabled,
-    GetBooleanv, GetDoublev, GetFloatv and GetIntegerv:
-
-        FRAGMENT_PROGRAM_CALLBACK_MESA      0x8bb1
-        VERTEX_PROGRAM_CALLBACK_MESA        0x8bb4
-
-    Accepted by the <pname> parameter GetBooleanv, GetDoublev,
-    GetFloatv and GetIntegerv:
-
-        FRAGMENT_PROGRAM_POSITION_MESA      0x8bb0
-        VERTEX_PROGRAM_POSITION_MESA        0x8bb5
-
-    Accepted by the <pname> parameter of GetPointerv:
-
-        FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x8bb2
-        FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x8bb3
-        VERTEX_PROGRAM_CALLBACK_FUNC_MESA   0x8bb6
-        VERTEX_PROGRAM_CALLBACK_DATA_MESA   0x8bb7
-
-Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
-
-    None.
-
-Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    None.
-
-Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
-
-    In section 5.4 "Display Lists", page 202, add the following command
-    to the list of those that are not compiled into display lists:
-
-        ProgramCallbackMESA.
-
-
-    Add a new section 5.7 "Callback Functions"
-
-    The function
-
-        void ProgramCallbackMESA(enum target, programcallbackMESA callback,
-                                 void *data)
-
-    registers a user-defined callback function with the GL.  <target>
-    may be FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB.  The enabled
-    callback functions registered with these targets will be called
-    prior to executing each instruction in the current fragment or
-    vertex program, respectively.  The callbacks are enabled and
-    disabled by calling Enable or Disable with <cap>
-    FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB.
-
-    The callback function's signature must match the typedef
-
-        typedef void (*programcallbackMESA)(enum target, void *data)
-
-    When the callback function is called, <target> will either be
-    FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB to indicate which
-    program is currently executing and <data> will be the value
-    specified when ProgramCallbackMESA was called.
-
-    From within the callback function, only the following GL commands
-    may be called:
-
-        GetBooleanv
-        GetDoublev
-        GetFloatv
-        GetIntegerv
-        GetProgramLocalParameter
-        GetProgramEnvParameter
-        GetProgramRegisterfvMESA
-        GetProgramivARB
-        GetProgramStringARB
-        GetError
-
-    Calling any other command from within the callback results in
-    undefined behaviour.
-
-
-Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
-State Requests)
-
-    Add a new section 6.1.3 "Program Value Queries":
-
-    The command
-
-        void GetProgramRegisterfvMESA(enum target, sizei len,
-                                      const ubyte *registerName,
-                                      float *v)
-        
-    Is used to query the value of program variables and registers
-    during program execution.  GetProgramRegisterfvMESA may only be
-    called from within a callback function registered with
-    ProgramCallbackMESA.
-
-    <registerName> and <len> specify the name a variable, input
-    attribute, temporary, or result register in the program string.
-    The current value of the named variable is returned as four
-    values in <v>.  If <name> doesn't exist in the program string,
-    the error INVALID_OPERATION is generated.
-
-Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
-
-    None.
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None.
-
-GLX Protocol
-
-    XXX TBD
-
-Dependencies on NV_vertex_program and NV_fragment_program
-
-    If NV_vertex_program and/or NV_fragment_program are supported,
-    vertex and/or fragment programs defined by those extensions may
-    be debugged as well.  Register queries will use the syntax used
-    by those extensions (i.e. "v[X]" to query vertex attributes,
-    "o[X]" for vertex outputs, etc.)
-
-Errors
-
-    INVALID_OPERATION is generated if ProgramCallbackMESA is called
-    between Begin and End.
-
-    INVALID_ENUM is generated by ProgramCallbackMESA if <target> is not
-    a supported vertex or fragment program type.
-
-    Note: INVALID_OPERAION IS NOT generated by GetProgramRegisterfvMESA,
-    GetBooleanv, GetDoublev, GetFloatv, or GetIntegerv if called between
-    Begin and End when a vertex or fragment program is currently executing.
-
-    INVALID_ENUM is generated by ProgramCallbackMESA,
-    GetProgramRegisterfvMESA if <target> is not a program target supported
-    by ARB_vertex_program, ARB_fragment_program (or NV_vertex_program or
-    NV_fragment_program).
-
-    INVALID_VALUE is generated by GetProgramRegisterfvMESA if <registerName>
-    does not name a known program register or variable.
-
-    INVALID_OPERATION is generated by GetProgramRegisterfvMESA when a
-    register query is attempted for a program target that's not currently
-    being executed.
-
-
-New State
-
-    XXX finish
-
-(table 6.N, p. ###)
-                                                            Initial
-    Get Value                            Type Get Command   Value    Description  Sec.  Attribute
-    ---------                            ---- -----------   -----    -----------  ----  ---------
-    FRAGMENT_PROGRAM_CALLBACK_MESA        B   IsEnabled     FALSE    XXX          XXX   enable
-    VERTEX_PROGRAM_CALLBACK_MESA          B   IsEnabled     FALSE    XXX          XXX   enable
-    FRAGMENT_PROGRAM_POSITION_MESA        Z+  GetIntegerv   -1       XXX          XXX   -
-    VERTEX_PROGRAM_POSITION_MESA          Z+  GetIntegerv   -1       XXX          XXX   -
-    FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA   P   GetPointerv   NULL     XXX          XXX   -
-    VERTEX_PROGRAM_CALLBACK_FUNC_MESA     P   GetPointerv   NULL     XXX          XXX   -
-    FRAGMENT_PROGRAM_CALLBACK_DATA_MESA   P   GetPointerv   NULL     XXX          XXX   -
-    VERTEX_PROGRAM_CALLBACK_DATA_MESA     P   GetPointerv   NULL     XXX          XXX   -
-
-    XXX more?
-
-New Implementation Dependent State
-
-    None.
-
-Revision History
-
-    8 July 2003
-        Initial draft. (Brian Paul)
-    11 July 2003
-        Second draft. (Brian Paul)
-    20 July 2003
-        Third draft.  Lots of fundamental changes. (Brian Paul)
-    23 July 2003
-        Added chapter 5 and 6 spec language. (Brian Paul)
-
-Example Usage
-
-   The following is a very simple example of how this extension may
-   be used to print the values of R0, R1, R2 and R3 while executing
-   vertex programs.
-
-
-    /* This is called by the GL when the vertex program is executing.
-     * We can only make glGet* calls from within this function!
-     */
-    void DebugCallback(GLenum target, GLvoid *data)
-    {
-       GLint pos;
-       GLuint i;
-
-       /* Get PC and current instruction string */
-       glGetIntegerv(GL_VERTEX_PROGRAM_POSITION_ARB, &pos);
-
-       printf("Current position: %d\n", pos);
-
-       printf("Current temporary registers:\n");
-       for (i = 0; i < 4; i++) {
-         GLfloat v[4];
-         char s[10];
-         sprintf(s, "R%d", i);
-         glGetProgramRegisterfvMESA(GL_VERTEX_PROGRAM_ARB, strlen(s), s, v);
-         printf("R%d = %g, %g, %g, %g\n", i, v[0], v[1], v[2], v[3]);
-       }
-    }
-
-
-    /*
-     * elsewhere...
-     */
-
-    /* Register our debugger callback function */
-    glProgramCallbackMESA(GL_VERTEX_PROGRAM_ARB, DebugCallback, NULL);
-    glEnable(GL_VERTEX_PROGRAM_CALLBACK_MESA);
-
-    /* define/bind a vertex program */
-
-    glEnable(GL_VERTEX_PROGRAM);
-
-    /* render something */
-    glBegin(GL_POINTS);
-    glVertex2f(0, 0);
-    glEnd();
-
diff --git a/docs/specs/OLD/MESA_resize_buffers.spec b/docs/specs/OLD/MESA_resize_buffers.spec
deleted file mode 100644 (file)
index aed3caf..0000000
+++ /dev/null
@@ -1,81 +0,0 @@
-Name
-
-    MESA_resize_buffers
-
-Name Strings
-
-    GL_MESA_resize_buffers
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Obsolete.
-
-Version
-
-
-Number
-
-    196
-
-Dependencies
-
-    Mesa 2.2 or later is required.
-
-Overview
-
-    Mesa is often used as a client library with no integration with
-    the computer's window system (an X server, for example).  And since
-    Mesa does not have an event loop nor window system callbacks, it
-    cannot properly respond to window system events.  In particular,
-    Mesa cannot automatically detect when a window has been resized.
-
-    Mesa's glViewport command queries the current window size and updates
-    its internal data structors accordingly.  This normally works fine
-    since most applications call glViewport in response to window size
-    changes.
-
-    In some situations, however, the application may not call glViewport
-    when a window size changes but would still like Mesa to adjust to
-    the new window size.  This extension exports a new function to solve
-    this problem.
-
-New Procedures and Functions
-
-    void glResizeBuffersMESA( void )
-
-New Tokens
-
-    none
-
-Additions to the OpenGL Specification (no particular section)
-
-    The glResizeBuffersMESA command may be called when the client
-    determines that a window has been resized.  Calling
-    glResizeBuffersMESA causes Mesa to query the current window size
-    and adjust its internal data structures.  This may include
-    reallocating depth, stencil, alpha and accumulation buffers.
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-Errors
-
-    INVALID_OPERATION is generated if glResizeBuffersMESA is called between
-    Begin and End.
-
-New State
-
-    None.
-
-New Implementation Dependent State
-
-    None.
-
-Revision History
-
-  * Revision 1.0 - Initial specification
diff --git a/docs/specs/OLD/MESA_set_3dfx_mode.spec b/docs/specs/OLD/MESA_set_3dfx_mode.spec
deleted file mode 100644 (file)
index e4eea2a..0000000
+++ /dev/null
@@ -1,85 +0,0 @@
-Name
-
-    MESA_set_3dfx_mode
-
-Name Strings
-
-    GLX_MESA_set_3dfx_mode
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Obsolete.
-
-Version
-
-    Last Modified Date:  8 June 2000
-
-Number
-
-    218
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    The Mesa Glide driver allows full-screen rendering or rendering into
-    an X window.  The glXSet3DfxModeMESA() function allows an application
-    to switch between full-screen and windowed rendering.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    GLboolean glXSet3DfxModeMESA( GLint mode );
-
-New Tokens
-
-    GLX_3DFX_WINDOW_MODE_MESA      0x1
-    GLX_3DFX_FULLSCREEN_MODE_MESA   0x2
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    The Mesa Glide device driver allows either rendering in full-screen
-    mode or rendering into an X window.  An application can switch between
-    full-screen and window rendering with the command:
-
-       GLboolean glXSet3DfxModeMESA( GLint mode );
-
-    <mode> may either be GLX_3DFX_WINDOW_MODE_MESA to indicate window
-    rendering or GLX_3DFX_FULLSCREEN_MODE_MESA to indicate full-screen mode.
-
-    GL_TRUE is returned if <mode> is valid and the operation completed
-    normally.  GL_FALSE is returned if <mode> is invalid or if the Glide
-    driver is not being used.
-
-    Note that only one drawable and context can be created at any given
-    time with the Mesa Glide driver.
-
-GLX Protocol
-
-    None since this is a client-side extension.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    8 June 2000 - initial specification
diff --git a/docs/specs/OLD/MESA_sprite_point.spec b/docs/specs/OLD/MESA_sprite_point.spec
deleted file mode 100644 (file)
index b50d78e..0000000
+++ /dev/null
@@ -1,190 +0,0 @@
-Name
-
-    MESA_sprite_point
-
-Name Strings
-
-    GL_MESA_sprite_point
-
-Contact
-
-    Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
-
-Status
-
-    Obsolete - see GL_ARB_point_sprite.
-
-Version
-
-
-Number
-
-    ???
-
-Dependencies
-
-    GL_EXT_point_parameters effects the definition of this extension
-    GL_ARB_multitexture effects the definition of this extension
-
-Overview
-       
-    This extension modifies the way in which points are rendered,
-    specifically when they're textured.  When SPRITE_POINT_MESA is enabled
-    a point is rendered as if it were a quadrilateral with unique texture
-    coordinates at each vertex.  This extension effectively turns points
-    into sprites which may be rendered more easily and quickly than using
-    conventional textured quadrilaterals.
-
-    When using point size > 1 or attenuated points this extension is an
-    effective way to render many small sprite images for particle systems
-    or other effects.
-
-Issues:
-
-    1. How are the texture coordinates computed?
-
-       The lower-left corner has texture coordinate (0,0,r,q).
-       The lower-right, (1,0,r,q).  The upper-right, (1,1,r,q).
-       The upper-left, (0,1,r,q).
-
-    2. What about texgen and texture matrices?
-
-       Texgen and the texture matrix have no effect on the point's s and t
-       texture coordinates.  The r and q coordinates may have been computed
-       by texgen or the texture matrix.  Note that with a 3D texture and/or
-       texgen that the r coordinate could be used to select a slice in the
-       3D texture.
-
-    3. What about point smoothing?
-
-       When point smoothing is enabled, a triangle fan could be rendered
-       to approximate a circular point.  This could be problematic to
-       define and implement so POINT_SMOOTH is ignored when drawing sprite
-       points.
-
-       Smoothed points can be approximated by using an appropriate texture
-       images, alpha testing and blending.
-
-       POLYGON_SMOOTH does effect the rendering of the quadrilateral, however.
-
-    4. What about sprite rotation?
-
-       There is none.  Sprite points are always rendered as window-aligned
-       squares.  One could define rotated texture images if desired.  A 3D
-       texture and appropriate texture r coordinates could be used to
-       effectively specify image rotation per point.
-
-    5. What about POLYGON_MODE?
-
-       POLYGON_MODE does not effect the rasterization of the quadrilateral.
-
-    6. What about POLYGON_CULL?
-
-       TBD.  Polygon culling is normally specified and implemented in the
-       transformation stage of OpenGL.  However, some rasterization hardware
-       implements it later during triangle setup.
-
-       Polygon culling wouldn't be useful for sprite points since the
-       quadrilaterals are always defined in counter-clockwise order in
-       window space.  For that reason, polygon culling should probably be
-       ignored.
-
-    7. Should sprite points be alpha-attenuated if their size is below the
-       point parameter's threshold size?
-
-    8. Should there be an advertisized maximum sprite point size?
-
-       No.  Since we're rendering the point as a quadrilateral there's no
-       need to limit the size.
-
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-    
-    Accepted by the <pname> parameter of Enable, Disable, IsEnabled,
-    GetIntegerv, GetBooleanv, GetFloatv and GetDoublev:
-
-       SPRITE_POINT_MESA               0x????
-        MAX_SPRITE_POINT_SIZE_MESA      0x????   (need this?)
-
-Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.1 Specification (Rasterization)
-
-    Section ???.
-
-    When SPRITE_POINT_MESA is enabled points are rasterized as screen-
-    aligned quadrilaterals.  If the four vertices of the quadrilateral
-    are labeled A, B, C, and D, starting at the lower-left corner and moving
-    counter-clockwise around the quadrilateral, then the vertex and
-    texture coordinates are computed as follows:
-
-      vertex   window coordinate       texture coordinate
-        A      (x-r, y-r, z, w)          (0, 0, r, q)
-        B      (x+r, y-r, z, w)          (1, 0, r, q)
-        C      (x+r, y+r, z, w)          (1, 1, r, q)
-        D      (x-r, y+r, z, w)          (0, 1, r, q)
-
-    where x, y, z, w are the point's window coordinates, r and q are the
-    point's 3rd and 4th texture coordinates  and r is half the point's
-    size.  The other vertex attributes (such as the color and fog coordinate)
-    are simply duplicated from the original point vertex.
-
-    Point size may either be specified with PointSize or computed
-    according to the EXT_point_parameters extension.
-
-    The new texture coordinates are not effected by texgen or the texture
-    matrix.  Note, however, that the texture r and q coordinates are passed
-    unchanged and may have been computed with texgen and/or the texture
-    matrix.
-
-    If multiple texture units are present the same texture coordinate is
-    used for all texture units.
-
-    The point is then rendered as if it were a quadrilateral using the
-    normal point sampling rules.  POLYGON_MODE does not effect the
-    rasterization of the quadrilateral but POLYGON_SMOOTH does.
-
-    POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled.
-
-Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
-and the Frame Buffer)
-
-    None.
-
-Additions to Chapter 5 of the 1.1 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
-
-    None
-
-Additions to the GLX Specification
-
-    None
-
-GLX Protocol
-
-    TBD
-
-Errors
-
-    None
-
-New State
-
-    Add boolean variable SPRITE_POINT_MESA to the point attribute group.
-
-Revision History
-
-    Version 1.0 - 4 Dec 2000
-        Original draft.
-
-
-
diff --git a/docs/specs/OLD/MESA_trace.spec b/docs/specs/OLD/MESA_trace.spec
deleted file mode 100644 (file)
index dc4166e..0000000
+++ /dev/null
@@ -1,359 +0,0 @@
-Name
-
-     MESA_trace
-
-Name Strings
-
-     GL_MESA_trace
-
-Contact
-    
-    Bernd Kreimeier, Loki Entertainment, bk 'at' lokigames.com
-    Brian Paul, VA Linux Systems, Inc., brianp 'at' valinux.com
-
-Status
-
-    Obsolete.
-
-Version
-
-
-Number
-
-    none yet
-
-Dependencies
-
-    OpenGL 1.2 is required.
-    The extension is written against the OpenGL 1.2 Specification
-
-Overview
-
-    Provides the application with means to enable and disable logging
-    of GL calls including parameters as readable text. The verbosity
-    of the generated log can be controlled. The resulting logs are
-    valid (but possibly incomplete) C code and can be compiled and 
-    linked for standalone test programs. The set of calls and the 
-    amount of static data that is logged can be controlled at runtime. 
-    The application can add comments and enable or disable tracing of GL 
-    operations at any time. The data flow from the application to GL
-    and back is unaffected except for timing.
-
-    Application-side implementation of these features raises namespace
-    and linkage issues. In the driver dispatch table a simple
-    "chain of responsibility" pattern (aka "composable piepline")
-    can be added.
-
-IP Status
-
-    The extension spec is in the public domain.  The current implementation
-    in Mesa is covered by Mesa's XFree86-style copyright by the authors above.
-    This extension is partially inspired by the Quake2 QGL wrapper.
-
-Issues
-
-    (1) Is this Extension obsolete because it can
-    be implemented as a wrapper DLL?
-
-      RESOLVED: No. While certain operating systems (Win32) provide linkers 
-      that facilitate this kind of solution, other operating systems
-      (Linux) do not support hierarchical linking, so a wrapper solution
-      would result in symbol collisions.
-      Further, IHV's might have builtin support for tracing GL execution 
-      that enjoys privileged access, or that they do not wish to separate
-      the tracing code from their driver code base.
-
-    (2) Should the Trace API explicitely support the notion of "frames? 
-    This would require hooking into glXSwapBuffers calls as well.
-
-      RESOLVED: No. The application can use NewTraceMESA/EndTraceMESA
-      and TraceComment along with external parsing tools to split the 
-      trace into frames, in whatever way considered adequate.
-
-    (2a) Should GLX calls be traced?
-
-      PBuffers and other render-to-texture solutions demonstrate that
-      context level commands beyond SwapBuffers might have to be
-      traced. The GL DLL exports the entry points, so this would not
-      be out of the question. 
-
-    (3) Should the specification mandate the actual output format?
-
-      RESOLVED: No. It is sufficient to guarantee that all data and commands 
-      will be traced as requested by Enable/DisableTraceMESA, in the order
-      encountered. Whether the resulting trace is available as a readable 
-      text file, binary metafile, compilable source code, much less which 
-      indentation and formatting has been used, is up to the implementation. 
-      For the same reason this specification does not enforce or prohibit
-      additional information added to the trace (statistics, profiling/timing, 
-      warnings on possible error conditions).
-
-    (4) Should the comment strings associated with names and pointer (ranges) 
-    be considered persistent state?
-
-      RESOLVED: No. The implementation is not forced to use this information 
-      on subsequent occurences of name/pointer, and is free to consider it 
-      transient state.
-    (5) Should comment commands be prohibited between Begin/End?
-
-      RESOLVED: Yes, with the exception of TraceCommentMESA. TraceCommentMESA 
-      is transient, the other commands might cause storage of persistent
-      data in the context. There is no need to have the ability mark names 
-      or pointers between Begin and End.
-
-
-New Procedures and Functions
-    void NewTraceMESA( bitfield mask, const ubyte * traceName )
-
-    void EndTraceMESA( void )
-
-    void EnableTraceMESA( bitfield mask )
-
-    void DisableTraceMESA( bitfield mask )
-
-    void TraceAssertAttribMESA( bitfield attribMask )
-
-    void TraceCommentMESA( const ubyte* comment )
-
-    void TraceTextureMESA( uint name, const ubyte* comment )
-
-    void TraceListMESA( uint name, const ubyte* comment )
-
-    void TracePointerMESA( void* pointer, const ubyte* comment )
-
-    void TracePointerRangeMESA( const void* first, 
-                                const void* last, 
-                                const ubyte* comment ) 
-
-New Tokens
-    Accepted by the <mask> parameter of EnableTrace and DisableTrace:
-
-       TRACE_ALL_BITS_MESA           0xFFFF
-       TRACE_OPERATIONS_BIT_MESA     0x0001
-       TRACE_PRIMITIVES_BIT_MESA     0x0002
-       TRACE_ARRAYS_BIT_MESA         0x0004
-       TRACE_TEXTURES_BIT_MESA       0x0008
-       TRACE_PIXELS_BIT_MESA         0x0010
-       TRACE_ERRORS_BIT_MESA         0x0020
-
-    Accepted by the <pname> parameter of GetIntegerv, GetBooleanv,
-    GetFloatv, and GetDoublev:
-
-       TRACE_MASK_MESA               0x8755
-
-    Accepted by the <pname> parameter to GetString:
-
-       TRACE_NAME_MESA               0x8756
-
-
-Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 3 of the OpenGL 1.2.1 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 4 of the OpenGL 1.2.1 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
-
-    Add a new section:
-
-    5.7 Tracing
-
-    The tracing facility is used to record the execution of a GL program
-    to a human-readable log.  The log appears as a sequence of GL commands
-    using C syntax.  The primary intention of tracing is to aid in program
-    debugging.
-
-    A trace is started with the command
-
-      void NewTraceMESA( bitfield mask, const GLubyte * traceName )
-
-    <mask> may be any value accepted by PushAttrib and specifies a set of
-    attribute groups.  The state values included in those attribute groups
-    is written to the trace as a sequence of GL commands.
-
-    <traceName> specifies a name or label for the trace.  It is expected
-    that <traceName> will be interpreted as a filename in most implementations.
-
-    A trace is ended by calling the command
-
-      void EndTraceMESA( void )
-
-    It is illegal to call NewTraceMESA or EndTraceMESA between Begin and End. 
-
-    The commands
-
-      void EnableTraceMESA( bitfield mask )
-      void DisableTraceMESA( bitfield mask )
-
-    enable or disable tracing of different classes of GL commands.
-    <mask> may be the union of any of TRACE_OPERATIONS_BIT_MESA,
-    TRACE_PRIMITIVES_BIT_MESA, TRACE_ARRAYS_BIT_MESA, TRACE_TEXTURES_BIT_MESA,
-    and TRACE_PIXELS_BIT_MESA.  The special token TRACE_ALL_BITS_MESA
-    indicates all classes of commands are to be logged.
-
-    TRACE_OPERATIONS_BIT_MESA controls logging of all commands outside of
-    Begin/End, including Begin/End.
-  
-    TRACE_PRIMITIVES_BIT_MESA controls logging of all commands inside of
-    Begin/End, including Begin/End.
-    TRACE_ARRAYS_BIT_MESA controls logging of VertexPointer, NormalPointer,
-    ColorPointer, IndexPointer, TexCoordPointer and EdgeFlagPointer commands.
-
-    TRACE_TEXTURES_BIT_MESA controls logging of texture data dereferenced by
-    TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, and
-    TexSubImage3D commands.
-
-    TRACE_PIXELS_BIT_MESA controls logging of image data dereferenced by
-    Bitmap and DrawPixels commands.
-
-    TRACE_ERRORS_BIT_MESA controls logging of all errors. If this bit is 
-    set, GetError will be executed whereever applicable, and the result will 
-    be added to the trace as a comment. The error returns are cached and 
-    returned to the application on its GetError calls. If the user does not 
-    wish the additional GetError calls to be performed, this bit should not
-    be set.
-    
-    The command
-
-      void TraceCommentMESA( const ubyte* comment )
-
-    immediately adds the <comment> string to the trace output, surrounded
-    by C-style comment delimiters.
-
-    The commands
-
-      void TraceTextureMESA( uint name, const ubyte* comment )
-      void TraceListMESA( uint name, const ubyte* comment )
-
-    associates <comment> with the texture object or display list specified
-    by <name>.  Logged commands which reference the named texture object or
-    display list will be annotated with <comment>.  If IsTexture(name) or
-    IsList(name) fail (respectively) the command is quietly ignored.
-
-    The commands
-
-      void TracePointerMESA( void* pointer, const ubyte* comment )
-
-      void TracePointerRangeMESA( const void* first, 
-                                  const void* last,
-                                  const ubyte* comment ) 
-
-    associate <comment> with the address specified by <pointer> or with
-    a range of addresses specified by <first> through <last>.
-    Any logged commands which reference <pointer> or an address between
-    <first> and <last> will be annotated with <comment>.
-
-    The command
-
-      void TraceAssertAttribMESA( bitfield attribMask )
-
-    will add GL state queries and assertion statements to the log to
-    confirm that the current state at the time TraceAssertAttrib is
-    executed matches the current state when the trace log is executed
-    in the future.
-
-    <attribMask> is any value accepted by PushAttrib and specifies
-    the groups of state variables which are to be asserted.
-
-    The commands NewTraceMESA, EndTraceMESA, EnableTraceMESA, DisableTraceMESA,
-    TraceAssertAttribMESA, TraceCommentMESA, TraceTextureMESA, TraceListMESA, 
-    TracePointerMESA and TracePointerRangeMESA are not compiled into display lists.
-
-
-    Examples:
-
-    The command NewTraceMESA(DEPTH_BUFFER_BIT, "log") will query the state
-    variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
-    to get the values <test>, <func>, <mask>, and <clear> respectively.
-    Statements equivalent to the following will then be logged:
-
-       glEnable(GL_DEPTH_TEST);   (if <test> is true)
-       glDisable(GL_DEPTH_TEST);  (if <test> is false)
-       glDepthFunc(<func>); 
-       glDepthMask(<mask>);
-       glClearDepth(<clear>);
-   
-
-    The command TraceAssertAttribMESA(DEPTH_BUFFER_BIT) will query the state
-    variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
-    to get the values <test>, <func>, <mask>, and <clear> respectively.
-    The resulting trace might then look will like this:
-
-    {
-      GLboolean b;
-      GLint i;
-      GLfloat f;
-      b = glIsEnabled(GL_DEPTH_TEST);
-      assert(b == <test>);
-      glGetIntegerv(GL_DEPTH_FUNC, &i);
-      assert(i == <func>);
-      glGetIntegerv(GL_DEPTH_MASK, &i);
-      assert(i == <mask>);
-      glGetFloatv(GL_DEPTH_CLEAR_VALUE, &f);
-      assert(f == <clear>);
-    }
-
-
-Additions to Chapter 6 of the OpenGL 1.2.1 Specification 
-    (State and State Requests)
-
-    Querying TRACE_MASK_MESA with GetIntegerv, GetFloatv, GetBooleanv or
-    GetDoublev returns the current command class trace mask.
-
-    Querying TRACE_NAME_MESA with GetString returns the current trace name.
-
-
-Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance)
-
-    The MESA_trace extension can be used in a way that does not affect data 
-    flow from application to OpenGL, as well as data flow from OpenGL to 
-    application, except for timing, possible print I/O. TRACE_ERRORS_BIT_MESA
-    will add additional GetError queries. Setting a trace mask with NewTraceMESA
-    as well as use of TraceAssertAttribMESA might cause additional state queries.
-    With the possible exception of performance, OpenGL rendering should not be
-    affected at all by a properly chosen logging operation.
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None.
-
-GLX Protocol
-
-    None. The logging operation is carried out client-side, by exporting
-    entry points to the wrapper functions that execute the logging operation.
-
-Errors
-
-    INVALID_OPERATION is generated if any trace command except TraceCommentMESA
-    is called between Begin and End.
-
-New State
-
-    The current trace name and current command class mask are stored
-    per-context.
-
-New Implementation Dependent State
-
-    None.
-
-Revision History
-
-  * Revision 0.1 - Initial draft from template (bk000415)
-  * Revision 0.2 - Draft (bk000906)
-  * Revision 0.3 - Draft (bk000913)
-  * Revision 0.4 - Reworked text, fixed typos (bp000914)
-  * Revision 0.5 - Assigned final GLenum values (bp001103)
-  * Revision 0.6 - TRACE_ERRORS_BIT_MESA (bk000916)
-  * Revision 0.7 - Added MESA postfix (bk010126)
-
diff --git a/docs/specs/WL_bind_wayland_display.spec b/docs/specs/WL_bind_wayland_display.spec
deleted file mode 100644 (file)
index 7854890..0000000
+++ /dev/null
@@ -1,202 +0,0 @@
-Name
-
-    WL_bind_wayland_display
-
-Name Strings
-
-    EGL_WL_bind_wayland_display
-
-Contact
-
-    Kristian Høgsberg <krh@bitplanet.net>
-    Benjamin Franzke <benjaminfranzke@googlemail.com>
-
-Status
-
-    Proposal
-
-Version
-
-    Version 5, July 16, 2013
-
-Number
-
-    EGL Extension #not assigned
-
-Dependencies
-
-    Requires 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 binding and unbinding the
-    wl_display of a Wayland compositor to an EGLDisplay.  Binding a
-    wl_display means that the EGL implementation should provide one or
-    more interfaces in the Wayland protocol to allow clients to create
-    wl_buffer objects.  On the server side, this extension also
-    provides a new target for eglCreateImageKHR, to create an EGLImage
-    from a wl_buffer
-
-    Adding an implementation specific wayland interface, allows the
-    EGL implementation to define specific wayland requests and events,
-    needed for buffer sharing in an EGL wayland platform.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Procedures and Functions
-
-    EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
-                                       struct wl_display *display);
-
-    EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
-                                         struct wl_display *display);
-
-    EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
-                                       struct wl_resource *buffer,
-                                       EGLint attribute, EGLint *value);
-
-New Tokens
-
-    Accepted as <target> in eglCreateImageKHR
-
-        EGL_WAYLAND_BUFFER_WL                   0x31D5
-
-    Accepted in the <attrib_list> parameter of eglCreateImageKHR:
-
-        EGL_WAYLAND_PLANE_WL                    0x31D6
-
-    Possible values for EGL_TEXTURE_FORMAT:
-
-        EGL_TEXTURE_Y_U_V_WL                    0x31D7
-        EGL_TEXTURE_Y_UV_WL                     0x31D8
-        EGL_TEXTURE_Y_XUXV_WL                   0x31D9
-        EGL_TEXTURE_EXTERNAL_WL                 0x31DA
-
-    Accepted in the <attribute> parameter of eglQueryWaylandBufferWL:
-
-        EGL_TEXTURE_FORMAT                      0x3080
-        EGL_WAYLAND_Y_INVERTED_WL               0x31DB
-
-
-Additions to the EGL 1.4 Specification:
-
-    To bind a server side wl_display to an EGLDisplay, call
-
-        EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
-                                           struct wl_display *display);
-
-    To unbind a server side wl_display from an EGLDisplay, call
-    
-        EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
-                                             struct wl_display *display);
-
-    eglBindWaylandDisplayWL returns EGL_FALSE when there is already a
-    wl_display bound to EGLDisplay otherwise EGL_TRUE.
-
-    eglUnbindWaylandDisplayWL returns EGL_FALSE when there is no
-    wl_display bound to the EGLDisplay currently otherwise EGL_TRUE.
-
-    A wl_buffer can have several planes, typically in case of planar
-    YUV formats.  Depending on the exact YUV format in use, the
-    compositor will have to create one or more EGLImages for the
-    various planes.  The eglQueryWaylandBufferWL function should be
-    used to first query the wl_buffer texture format using
-    EGL_TEXTURE_FORMAT as the attribute.  If the wl_buffer object is
-    not an EGL wl_buffer (wl_shm and other wayland extensions can
-    create wl_buffer objects of different types), this query will
-    return EGL_FALSE.  In that case the wl_buffer can not be used with
-    EGL and the compositor should have another way to get the buffer
-    contents.
-
-    If eglQueryWaylandBufferWL succeeds, the returned value will be
-    one of EGL_TEXTURE_RGB, EGL_TEXTURE_RGBA, EGL_TEXTURE_Y_U_V_WL,
-    EGL_TEXTURE_Y_UV_WL, EGL_TEXTURE_Y_XUXV_WL.  The value returned
-    describes how many EGLImages must be used, which components will
-    be sampled from each EGLImage and how they map to rgba components
-    in the shader.  The naming conventions separates planes by _ and
-    within each plane, the order or R, G, B, A, Y, U, and V indicates
-    how those components map to the rgba value returned by the
-    sampler.  X indicates that the corresponding component in the rgba
-    value isn't used.
-
-    RGB and RGBA buffer types:
-
-        EGL_TEXTURE_RGB
-                One plane, samples RGB from the texture to rgb in the
-                shader.  Alpha channel is not valid.
-
-        EGL_TEXTURE_RGBA
-                One plane, samples RGBA from the texture to rgba in the
-                shader.
-
-    YUV buffer types:
-
-        EGL_TEXTURE_Y_U_V_WL
-                Three planes, samples Y from the first plane to r in
-                the shader, U from the second plane to r, and V from
-                the third plane to r.
-
-        EGL_TEXTURE_Y_UV_WL
-                Two planes, samples Y from the first plane to r in
-                the shader, U and V from the second plane to rg.
-
-        EGL_TEXTURE_Y_XUXV_WL
-                Two planes, samples Y from the first plane to r in
-                the shader, U and V from the second plane to g and a.
-
-        EGL_TEXTURE_EXTERNAL_WL
-                Treated as a single plane texture, but sampled with
-                samplerExternalOES according to OES_EGL_image_external
-
-    After querying the wl_buffer layout, create EGLImages for the
-    planes by calling eglCreateImageKHR with wl_buffer as
-    EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
-    context.  If no attributes are given, an EGLImage will be created
-    for the first plane.  For multi-planar buffers, specify the plane
-    to create the EGLImage for by using the EGL_WAYLAND_PLANE_WL
-    attribute.  The value of the attribute is the index of the plane,
-    as defined by the buffer format.  Writing to an EGLImage created
-    from a wl_buffer in any way (such as glTexImage2D, binding the
-    EGLImage as a renderbuffer etc) will result in undefined behavior.
-
-    Further, eglQueryWaylandBufferWL accepts attributes EGL_WIDTH and
-    EGL_HEIGHT to query the width and height of the wl_buffer.
-
-    Also, eglQueryWaylandBufferWL may accept
-    EGL_WAYLAND_Y_INVERTED_WL attribute to query orientation of
-    wl_buffer. If EGL_WAYLAND_Y_INVERTED_WL is supported
-    eglQueryWaylandBufferWL returns EGL_TRUE and value is a boolean
-    that tells if wl_buffer is y-inverted or not. If
-    EGL_WAYLAND_Y_INVERTED_WL is not supported
-    eglQueryWaylandBufferWL returns EGL_FALSE, in that case
-    wl_buffer should be treated as if value of
-    EGL_WAYLAND_Y_INVERTED_WL was EGL_TRUE.
-
-Issues
-
-Revision History
-
-    Version 1, March 1, 2011
-        Initial draft (Benjamin Franzke)
-    Version 2, July 5, 2012
-        Add EGL_WAYLAND_PLANE_WL attribute to allow creating an EGLImage
-        for different planes of planar buffer. (Kristian Høgsberg)
-    Version 3, July 10, 2012
-        Add eglQueryWaylandBufferWL and the various buffer
-        formats. (Kristian Høgsberg)
-    Version 4, July 19, 2012
-        Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
-        and just define the new YUV texture formats.  Add support for
-        EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian Høgsberg)
-    Version 5, July 16, 2013
-        Change eglQueryWaylandBufferWL to take a resource pointer to the
-        buffer instead of a pointer to a struct wl_buffer, as the latter has
-        been deprecated. (Ander Conselvan de Oliveira)
-    Version 6, September 16, 2013
-        Add EGL_WAYLAND_Y_INVERTED_WL attribute to allow specifying
-        wl_buffer's orientation.
diff --git a/docs/specs/WL_create_wayland_buffer_from_image.spec b/docs/specs/WL_create_wayland_buffer_from_image.spec
deleted file mode 100644 (file)
index aa5eb4d..0000000
+++ /dev/null
@@ -1,101 +0,0 @@
-Name
-
-    WL_create_wayland_buffer_from_image
-
-Name Strings
-
-    EGL_WL_create_wayland_buffer_from_image
-
-Contributors
-
-    Neil Roberts
-    Axel Davy
-    Daniel Stone
-
-Contact
-
-    Neil Roberts <neil.s.roberts@intel.com>
-
-Status
-
-    Proposal
-
-Version
-
-    Version 2, October 25, 2013
-
-Number
-
-    EGL Extension #not assigned
-
-Dependencies
-
-    Requires 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 an entry point to create a wl_buffer which shares
-    its contents with a given EGLImage. The expected use case for this is in a
-    nested Wayland compositor which is using subsurfaces to present buffers
-    from its clients. Using this extension it can attach the client buffers
-    directly to the subsurface without having to blit the contents into an
-    intermediate buffer. The compositing can then be done in the parent
-    compositor.
-
-    The nested compositor can create an EGLImage from a client buffer resource
-    using the existing WL_bind_wayland_display extension. It should also be
-    possible to create buffers using other types of images although there is
-    no expected use case for that.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Procedures and Functions
-
-    struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
-                                                        EGLImageKHR image);
-
-New Tokens
-
-    None.
-
-Additions to the EGL 1.4 Specification:
-
-    To create a client-side wl_buffer from an EGLImage call
-
-      struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
-                                                          EGLImageKHR image);
-
-    The returned buffer will share the contents with the given EGLImage. Any
-    updates to the image will also be updated in the wl_buffer. Typically the
-    EGLImage will be generated in a nested Wayland compositor using a buffer
-    resource from a client via the EGL_WL_bind_wayland_display extension.
-
-    If there was an error then the function will return NULL. In particular it
-    will generate EGL_BAD_MATCH if the implementation is not able to represent
-    the image as a wl_buffer. The possible reasons for this error are
-    implementation-dependant but may include problems such as an unsupported
-    format or tiling mode or that the buffer is in memory that is inaccessible
-    to the GPU that the given EGLDisplay is using.
-
-Issues
-
-    1) Under what circumstances can the EGL_BAD_MATCH error be generated? Does
-       this include for example unsupported tiling modes?
-
-       RESOLVED: Yes, the EGL_BAD_MATCH error can be generated for any reason
-       which prevents the implementation from representing the image as a
-       wl_buffer. For example, these problems can be but are not limited to
-       unsupported tiling modes, inaccessible memory or an unsupported pixel
-       format.
-
-Revision History
-
-    Version 1, September 6, 2013
-        Initial draft (Neil Roberts)
-    Version 2, October 25, 2013
-        Added a note about more possible reasons for returning EGL_BAD_FORMAT.
diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
deleted file mode 100644 (file)
index 2ab068b..0000000
+++ /dev/null
@@ -1,104 +0,0 @@
-The definitive source for enum values and reserved ranges are the XML files in
-the Khronos registry:
-
-    https://github.com/KhronosGroup/EGL-Registry/blob/master/api/egl.xml
-    https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/gl.xml
-    https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/glx.xml
-    https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/wgl.xml
-
-GL blocks allocated to Mesa:
-       0x8750-0x875F
-       0x8BB0-0x8BBF
-
-Unused EGL blocks allocated to Mesa:
-       0x31DC
-       0x31DE
-       0x31DF
-       0x3290-0x329F
-
-GL_MESA_packed_depth_stencil
-       GL_DEPTH_STENCIL_MESA            0x8750
-       GL_UNSIGNED_INT_24_8_MESA        0x8751
-       GL_UNSIGNED_INT_8_24_REV_MESA    0x8752
-       GL_UNSIGNED_SHORT_15_1_MESA      0x8753
-       GL_UNSIGNED_SHORT_1_15_REV_MESA  0x8754
-
-GL_MESA_trace:
-       GL_TRACE_ALL_BITS_MESA           0xFFFF
-       GL_TRACE_OPERATIONS_BIT_MESA     0x0001
-       GL_TRACE_PRIMITIVES_BIT_MESA     0x0002
-       GL_TRACE_ARRAYS_BIT_MESA         0x0004
-       GL_TRACE_TEXTURES_BIT_MESA       0x0008
-       GL_TRACE_PIXELS_BIT_MESA         0x0010
-       GL_TRACE_ERRORS_BIT_MESA         0x0020
-       GL_TRACE_MASK_MESA               0x8755
-       GL_TRACE_NAME_MESA               0x8756
-
-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:
-       GL_PACK_INVERT_MESA              0x8758
-
-GL_MESA_shader_debug.spec: (obsolete)
-        GL_DEBUG_OBJECT_MESA             0x8759
-        GL_DEBUG_PRINT_MESA              0x875A
-        GL_DEBUG_ASSERT_MESA             0x875B
-
-GL_MESA_program_debug: (obsolete)
-        GL_FRAGMENT_PROGRAM_POSITION_MESA       0x8BB0
-        GL_FRAGMENT_PROGRAM_CALLBACK_MESA       0x8BB1
-        GL_FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA  0x8BB2
-        GL_FRAGMENT_PROGRAM_CALLBACK_DATA_MESA  0x8BB3
-        GL_VERTEX_PROGRAM_POSITION_MESA         0x8BB4
-        GL_VERTEX_PROGRAM_CALLBACK_MESA         0x8BB5
-        GL_VERTEX_PROGRAM_CALLBACK_FUNC_MESA    0x8BB6
-        GL_VERTEX_PROGRAM_CALLBACK_DATA_MESA    0x8BB7
-
-GL_MESAX_texture_stack:
-       GL_TEXTURE_1D_STACK_MESAX            0x8759
-       GL_TEXTURE_2D_STACK_MESAX            0x875A
-       GL_PROXY_TEXTURE_1D_STACK_MESAX      0x875B
-       GL_PROXY_TEXTURE_2D_STACK_MESAX      0x875C
-       GL_TEXTURE_1D_STACK_BINDING_MESAX    0x875D
-       GL_TEXTURE_2D_STACK_BINDING_MESAX    0x875E
-
-GL_MESA_program_binary_formats:
-        GL_PROGRAM_BINARY_FORMAT_MESA           0x875F
-
-GL_MESA_tile_raster_order
-       GL_TILE_RASTER_ORDER_FIXED_MESA         0x8BB8
-       GL_TILE_RASTER_ORDER_INCREASING_X_MESA  0x8BB9
-       GL_TILE_RASTER_ORDER_INCREASING_Y_MESA  0x8BBA
-
-GL_MESA_framebuffer_flip_y
-       GL_FRAMEBUFFER_FLIP_Y_MESA           0x8BBB
-
-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_MESA_drm_image
-        EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA  0x3290
-        EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA     0x3291
-        EGL_DRM_BUFFER_FORMAT_RGB565_MESA       0x3292
-
-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