--- /dev/null
+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
--- /dev/null
+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)
--- /dev/null
+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
--- /dev/null
+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)
--- /dev/null
+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
--- /dev/null
+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.
--- /dev/null
+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).
--- /dev/null
+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)
--- /dev/null
+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
+
--- /dev/null
+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.
--- /dev/null
+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)
--- /dev/null
+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)
+
--- /dev/null
+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.
--- /dev/null
+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
--- /dev/null
+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
--- /dev/null
+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.
--- /dev/null
+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
--- /dev/null
+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.
--- /dev/null
+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.
--- /dev/null
+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.
--- /dev/null
+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.
--- /dev/null
+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.||
--- /dev/null
+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.
--- /dev/null
+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)
+
--- /dev/null
+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
--- /dev/null
+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.
+
--- /dev/null
+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
--- /dev/null
+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.
+
--- /dev/null
+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();
+
--- /dev/null
+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
--- /dev/null
+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
--- /dev/null
+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.
+
+
+
--- /dev/null
+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)
+
--- /dev/null
+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.
--- /dev/null
+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.
--- /dev/null
+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
html_static_path = []
html_extra_path = [
+ '_extra/',
'features.txt',
'libGL.txt',
'README.UVD',
+++ /dev/null
-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
+++ /dev/null
-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)
+++ /dev/null
-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
+++ /dev/null
-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)
+++ /dev/null
-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
+++ /dev/null
-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.
+++ /dev/null
-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).
+++ /dev/null
-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)
+++ /dev/null
-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
-
+++ /dev/null
-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.
+++ /dev/null
-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)
+++ /dev/null
-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)
-
+++ /dev/null
-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.
+++ /dev/null
-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
+++ /dev/null
-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
+++ /dev/null
-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.
+++ /dev/null
-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
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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.||
+++ /dev/null
-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.
+++ /dev/null
-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)
-
+++ /dev/null
-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
+++ /dev/null
-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.
-
+++ /dev/null
-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
+++ /dev/null
-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.
-
+++ /dev/null
-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();
-
+++ /dev/null
-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
+++ /dev/null
-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
+++ /dev/null
-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.
-
-
-
+++ /dev/null
-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)
-
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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
projects / mesa.git / commitdiff