Import Cobalt 10.58719
diff --git a/src/third_party/angle/extensions/ANGLE_client_arrays.txt b/src/third_party/angle/extensions/ANGLE_client_arrays.txt
new file mode 100644
index 0000000..1922b34
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_client_arrays.txt
@@ -0,0 +1,100 @@
+Name
+
+ ANGLE_client_arrays
+
+Name Strings
+
+ GL_ANGLE_client_arrays
+
+Contributors
+
+ Geoff Lang
+
+Contact
+
+ Geoff Lang (geofflang 'at' google.com)
+
+Notice
+
+ Copyright (c) 2016 The Khronos Group Inc. Copyright terms at
+ http://www.khronos.org/registry/speccopyright.html
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, February 13, 2016
+
+Number
+
+ OpenGL ES Extension #??
+
+Dependencies
+
+ Requires OpenGL ES 2.0
+
+ Written against the OpenGL ES 2.0 specification.
+
+Overview
+
+ This extension allows the OpenGL context to indicate if it supports drawing
+ with client-side vertex or index data. Client-side can be very inefficient
+ and unsafe, it is convenient for some users to completely disable its usage.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <cap> parameter to IsEnabled and the <pname> parameter to
+ GetBooleanv, GetIntegerv, GetFloatv, and GetInteger64v:
+
+ CLIENT_ARRAYS_ANGLE 0x93AA
+
+Additions to the OpenGL ES Specification
+
+ Add after paragraph 3 of section 2.8 "Vertex Arrays":
+
+ If VertexAttribPointer is called while zero is bound to the ARRAY_BUFFER
+ buffer object binding point, the pointer argument is not NULL, and
+ CLIENT_ARRAYS_ANGLE is TRUE, an INVALID_OPERATION error is generated.
+
+ Add to the end of section 2.9.1 "Vertex Arrays in Buffer Objects":
+
+ Rendering commands that draw more than 0 primitives using enabled vertex
+ attributes with no buffer bound when CLIENT_ARRAYS_ANGLE is TRUE generate
+ an INVALID_OPERATION error.
+
+ Add to the end of section 2.9.2 "Array Indices in Buffer Objects":
+
+ Rendering commands that draw more than 0 primitives using index data when
+ no buffer is bound to the ELEMENT_ARRAY_BUFFER binding point when
+ CLIENT_ARRAYS_ANGLE is TRUE generate an INVALID_OPERATION error.
+
+New State
+
+ Modify Table 6.22, Miscellaneous
+
+ Add:
+
+ Initial
+ Get Value Type Get Command Value Description
+ -------------------- ---- ----------- ------- ---------------------
+ CLIENT_ARRAYS_ANGLE B IsEnabled TRUE Client arrays enabled
+
+Conformance Tests
+
+ TBD
+
+Issues
+
+ None
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- ----------------------------------------
+ 1 Feb 13, 2016 geofflang Initial version
diff --git a/src/third_party/angle/extensions/ANGLE_lossy_etc_decode.txt b/src/third_party/angle/extensions/ANGLE_lossy_etc_decode.txt
new file mode 100644
index 0000000..1488192
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_lossy_etc_decode.txt
@@ -0,0 +1,159 @@
+Name
+
+ ANGLE_lossy_etc_decode
+
+Name Strings
+
+ GL_ANGLE_lossy_etc_decode
+
+Contributors
+
+ Minmin Gong (mgong 'at' microsoft.com)
+
+Contacts
+
+ Minmin Gong (mgong 'at' microsoft.com)
+
+Status
+
+ Draft
+
+Version
+
+ Last Modified Date: Nov 25, 2015
+ Author Revision: 1
+
+Number
+
+ TBD
+
+Dependencies
+
+ Requires OpenGL ES 3.0 for ETC2 and EAC formats, or OpenGL ES 2.0 and
+ OES_compressed_ETC1_RGB8_texture for ETC1 format.
+ The extension is written against the OpenGL ES 2.0 specification.
+
+Overview
+
+ Both the OpenGL ES 3.0 specification and OES_compressed_ETC1_RGB8_texture
+ specify that Ericsson Texture Compression (ETC) decoding must not be lossy.
+ The goal of this extension is to allow a lossy decode of
+ compressed textures in the ETC formats in OpenGL ES, for lower memory
+ and bandwidth consumption.
+
+ This extension uses the same ETC compression format as OpenGL ES 3.0
+ and OES_compressed_ETC1_RGB8_texture, with the restriction that the texture
+ dimensions must be a multiple of four (except for mip levels where the
+ dimensions are either 2 or 1). And the requirement that ETC decoding must
+ not be lossy is relaxed.
+
+ See OES_compressed_ETC1_RGB8_texture for a description of the ETC1 format.
+ Also see OpenGL ES 3.0 specification appendix C.2 (ETC Compressed Texture
+ ImageFormats) for a description of ETC2 and EAC formats.
+
+IP Status
+
+ See Ericsson's "IP Statement"
+
+New Procedures and Functions
+
+ None.
+
+New Types
+
+ None.
+
+New Tokens
+
+ Accepted by the <internalformat> parameter of CompressedTexImage2D
+ and the <format> parameter of CompressedTexSubImage2D:
+
+ ETC1_RGB8_LOSSY_DECODE_ANGLE 0x9690
+ COMPRESSED_R11_LOSSY_DECODE_EAC_ANGLE 0x9691
+ COMPRESSED_SIGNED_R11_LOSSY_DECODE_EAC_ANGLE 0x9692
+ COMPRESSED_RG11_LOSSY_DECODE_EAC_ANGLE 0x9693
+ COMPRESSED_SIGNED_RG11_LOSSY_DECODE_EAC_ANGLE 0x9694
+ COMPRESSED_RGB8_LOSSY_DECODE_ETC2_ANGLE 0x9695
+ COMPRESSED_SRGB8_LOSSY_DECODE_ETC2_ANGLE 0x9696
+ COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_LOSSY_DECODE_ETC2_ANGLE 0x9697
+ COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_LOSSY_DECODE_ETC2_ANGLE 0x9698
+ COMPRESSED_RGBA8_LOSSY_DECODE_ETC2_EAC_ANGLE 0x9699
+ COMPRESSED_SRGB8_ALPHA8_LOSSY_DECODE_ETC2_EAC_ANGLE 0x969A
+
+Additions to Chapter 3 of the OpenGL ES 2.0 Specification (Rasterization)
+
+ Add the following to Section 3.7.3 (Compressed Texture Images)
+ (at the end of the description of the CompressedTexImage2D command):
+
+ Compressed Internal Format Base Internal Format
+ ========================== ====================
+ ETC1_RGB8_LOSSY_DECODE_ANGLE RGB
+ COMPRESSED_R11_LOSSY_DECODE_EAC_ANGLE R
+ COMPRESSED_SIGNED_R11_LOSSY_DECODE_EAC_ANGLE R
+ COMPRESSED_RG11_LOSSY_DECODE_EAC_ANGLE RG
+ COMPRESSED_SIGNED_RG11_LOSSY_DECODE_EAC_ANGLE RG
+ COMPRESSED_RGB8_LOSSY_DECODE_ETC2_ANGLE RGB
+ COMPRESSED_SRGB8_LOSSY_DECODE_ETC2_ANGLE RGB
+ COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_LOSSY_DECODE_ETC2_ANGLE RGBA
+ COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_LOSSY_DECODE_ETC2_ANGLE RGBA
+ COMPRESSED_RGBA8_LOSSY_DECODE_ETC2_EAC_ANGLE RGBA
+ COMPRESSED_SRGB8_ALPHA8_LOSSY_DECODE_ETC2_EAC_ANGLE RGBA
+
+ Table 3.x: Specific Compressed Internal Formats
+
+ If <internalformat> is one of the ETC lossy decode formats listed in
+ Table 3.x, the compressed texture is stored in an unspecified compressed
+ texture format, that may introduce losses of precision in the texture data.
+ The GL and the ETC texture compression algorithm support only 2D images
+ without borders.
+
+ CompressedTexImage2D will produce the INVALID_OPERATION error when
+ <internalformat> is one of the lossy decode ETC-format values from
+ Table 3.x under the following conditions:
+
+ * <border> is non-zero.
+ * <width> is not one, two, nor a multiple of four.
+ * <height> is not one, two, nor a multiple of four.
+
+ Add the following to Section 3.7.3 (Compressed Texture Images)
+ (at the end of the description of the CompressedTexSubImage2D command):
+
+ If the internal format of the texture image being modified is an ETC-format
+ listed in Table 3.x, the compressed texture is stored in an unspecified
+ compressed texture format. The xoffset and yoffset must also be aligned to
+ 4x4 texel block boundaries, since ETC encoding makes it difficult to modify
+ non-aligned regions. CompressedTexSubImage2D will result in an
+ INVALID_OPERATION error only if one of the following conditions occurs:
+
+ * <width> is not a multiple of four nor equal to TEXTURE_WIDTH.
+ * <height> is not a multiple of four nor equal to TEXTURE_HEIGHT.
+ * <xoffset> or <yoffset> is not a multiple of four.
+ * <format> does not match the internal format of the texture image
+ being modified.
+
+Errors
+
+ INVALID_OPERATION is generated by CompressedTexImage2D if
+ lossy decode ETC-format is used and <internalformat> is one of the
+ compressed internal formats from Table 3.x and any of the following apply:
+ - <border> is not equal to zero.
+ - <width> is not one, two, nor a multiple of four.
+ - <height> is not one, two, nor a multiple of four.
+
+ INVALID_OPERATION is generated by CompressedTexSubImage2D if
+ lossy decode ETC-format is used and <format> is one of the compressed
+ interal formats from Table 3.x and any of the following apply:
+ - <width> is not a multiple of four nor equal to TEXTURE_WIDTH;
+ - <height> is not a multiple of four nor equal to TEXTURE_HEIGHT;
+ - <xoffset> or <yoffset> is not a multiple of four;
+ - <format> does not match the internal format of the texture image
+ being modified.
+
+New State
+
+ None.
+
+Revision History
+
+ Revision 1, 2015/11/25 - mgong
+ - Initial revision
diff --git a/src/third_party/angle/extensions/ANGLE_platform_angle.txt b/src/third_party/angle/extensions/ANGLE_platform_angle.txt
new file mode 100644
index 0000000..b39815b
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_platform_angle.txt
@@ -0,0 +1,127 @@
+Name
+
+ ANGLE_platform_angle
+
+Name Strings
+
+ EGL_ANGLE_platform_angle
+
+Contributors
+
+ Scott Graham, Google
+ Shannon Woods, Google
+ Geoff Lang, Google
+
+Contacts
+
+ Scott Graham, Google (scottmg 'at' google 'dot' com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 3, 2014-10-20
+
+Number
+
+ EGL Extension XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires EGL_EXT_client_extensions to query its existence without
+ a display.
+
+ Requires EGL_EXT_platform_base.
+
+ This extension is written against the wording of version 9 of the
+ EGL_EXT_platform_base specification.
+
+ ANGLE_platform_angle_d3d affects the definition of this extension.
+ ANGLE_platform_angle_opengl affects the definition of this extension.
+
+Overview
+
+ This extension defines how to create EGL resources from native resources
+ using the functions defined by EGL_EXT_platform_base.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as the <platform> argument of eglGetPlatformDisplayEXT:
+
+ EGL_PLATFORM_ANGLE_ANGLE 0x3202
+
+ Accepted as an attribute name in the <attrib_list> argument of
+ eglGetPlatformDisplayEXT:
+
+ EGL_PLATFORM_ANGLE_TYPE_ANGLE 0x3203
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MAJOR_ANGLE 0x3204
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MINOR_ANGLE 0x3205
+
+ Accepted as values for the EGL_PLATFORM_ANGLE_TYPE_ANGLE attribute:
+
+ EGL_PLATFORM_ANGLE_TYPE_DEFAULT_ANGLE 0x3206
+
+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 backed by a ANGLE display, call
+ eglGetPlatformDisplayEXT with <platform> set to EGL_PLATFORM_ANGLE_ANGLE.
+
+ The <native_display> parameter is of type EGLNativeDisplayType. If
+ <native_display> is EGL_DEFAULT_DISPLAY a default display is returned.
+ Multiple calls with the same <native_display> will return the same
+ EGLDisplay handle. If <platform> is set to EGL_PLATFORM_ANGLE_ANGLE and
+ the returned display is in an uninitialized state, its attributes are
+ overwritten by those provided in the <attrib_list>, if any.
+
+ If no <attrib_list> is specified, the value of
+ EGL_PLATFORM_ANGLE_TYPE_ANGLE is implicitly set to
+ EGL_PLATFORM_ANGLE_TYPE_DEFAULT_ANGLE.
+
+ If no <attrib_list> is specified, the values of
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MAJOR_ANGLE and
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MINOR_ANGLE are implicitly set to
+ EGL_DONT_CARE.
+
+ If EGL_PLATFORM_ANGLE_MAX_VERSION_MAJOR_ANGLE is set to EGL_DONT_CARE and
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MINOR_ANGLE is not set to EGL_DONT_CARE,
+ an EGL_BAD_ATTRIBUTE error is generated and EGL_NO_DISPLAY is returned.
+
+ If no display matching the requested <native_display> or of the type
+ requested by the value of EGL_PLATFORM_ANGLE_TYPE_ANGLE is available,
+ EGL_NO_DISPLAY is returned. No error condition is raised in this case.
+
+Issues
+
+ None
+
+Revision History
+
+ Version 1, 2014-02-04 (Scott Graham)
+ - Initial draft
+ Version 2, 2014-06-05 (Geoff Lang)
+ - Rename extension from ANGLE_platform_angle_d3d to ANGLE_platform_angle.
+ - Add sub-extensions for specific platforms.
+ Version 3, 2014-10-20 (Geoff Lang)
+ - Add attributes to request specific feature level and context versions.
+ - Moved descriptions of platforms to child extension specs.
diff --git a/src/third_party/angle/extensions/ANGLE_platform_angle_d3d.txt b/src/third_party/angle/extensions/ANGLE_platform_angle_d3d.txt
new file mode 100644
index 0000000..0c35005
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_platform_angle_d3d.txt
@@ -0,0 +1,140 @@
+Name
+
+ ANGLE_platform_angle_d3d
+
+Name Strings
+
+ EGL_ANGLE_platform_angle_d3d
+
+Contributors
+
+ Shannon Woods, Google
+ Geoff Lang, Google
+
+Contacts
+
+ Geoff Lang, Google (geofflang 'at' chromium 'dot' org)
+
+Status
+
+ Draft
+
+Version
+
+ Version 3, 2014-11-26
+
+Number
+
+ EGL Extension XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires ANGLE_platform_angle.
+
+Overview
+
+ This extension enables selection of D3D display types.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as values for the EGL_PLATFORM_ANGLE_TYPE_ANGLE attribute:
+
+ EGL_PLATFORM_ANGLE_TYPE_D3D9_ANGLE 0x3207
+ EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE 0x3208
+
+ Accepted as an attribute name in the <attrib_list> argument of
+ eglGetPlatformDisplayEXT:
+
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_ANGLE 0x3209
+ EGL_PLATFORM_ANGLE_ENABLE_AUTOMATIC_TRIM_ANGLE 0x320F
+
+ Accepted as values for the EGL_PLATFORM_ANGLE_DEVICE_TYPE_ANGLE attribute:
+
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_HARDWARE_ANGLE 0x320A
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_WARP_ANGLE 0x320B
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_REFERENCE_ANGLE 0x320C
+
+Additions to the EGL Specification
+
+ None.
+
+New Behavior
+
+ To request a display that is backed by Direct3D resources, the value of
+ EGL_PLATFORM_ANGLE_TYPE_ANGLE should be:
+ - EGL_PLATFORM_ANGLE_TYPE_D3D9_ANGLE for a D3D9 display,
+ - EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE for a D3D11 display.
+
+ To request a specific maximum feature level to be used by the D3D11
+ display, EGL_PLATFORM_ANGLE_MAX_VERSION_MAJOR_ANGLE and
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MINOR_ANGLE can be used. Only feature
+ levels that are capable of supporting all available client APIs will be
+ used unless explicitly requested.
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MAJOR_ANGLE and
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MINOR_ANGLE have no effect when requesting
+ a D3D9 display.
+
+ If no <attrib_list> is specified to eglGetPlatformDisplayEXT, the value of
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_ANGLE is implicitly set to
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_HARDWARE_ANGLE. Otherwise, the value of
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_ANGLE should be:
+ - EGL_PLATFORM_ANGLE_DEVICE_TYPE_HARDWARE_ANGLE to request a hardware
+ accelerated device.
+ - EGL_PLATFORM_ANGLE_DEVICE_TYPE_WARP_ANGLE to request an
+ optimized software rasterizer.
+ - EGL_PLATFORM_ANGLE_DEVICE_TYPE_REFERENCE_ANGLE to request a
+ reference rasterizer.
+
+ If EGL_PLATFORM_ANGLE_TYPE_ANGLE is set to
+ EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE, the display can automatically respond
+ to trim events from the operating system. If the attribute
+ EGL_PLATFORM_ANGLE_ENABLE_AUTOMATIC_TRIM_ANGLE is unspecified, it is
+ implicitly set to EGL_FALSE. Otherwise, the value of
+ EGL_PLATFORM_ANGLE_ENABLE_AUTOMATIC_TRIM_ANGLE should be EGL_TRUE or
+ EGL_FALSE.
+
+ If EGL_PLATFORM_ANGLE_DEVICE_TYPE_ANGLE is set to
+ EGL_PLATFORM_ANGLE_DEVICE_TYPE_WARP_ANGLE and EGL_PLATFORM_ANGLE_TYPE_ANGLE
+ is not set to EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE, an EGL_BAD_ATTRIBUTE
+ error is generated and EGL_NO_DISPLAY is returned.
+
+ If EGL_PLATFORM_ANGLE_ENABLE_AUTOMATIC_TRIM_ANGLE is specified when
+ EGL_PLATFORM_ANGLE_TYPE_ANGLE is not EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE
+ or a value other than EGL_TRUE or EGL_FALSE is used, an EGL_BAD_ATTRIBUTE
+ error is generated and EGL_NO_DISPLAY is returned.
+
+Issues
+
+ 1) Some multithreaded applications can crash if the display automatically
+ responds to trim events while the application is rendering from another
+ thread.
+
+ RESOLVED: Added an EGL_PLATFORM_ANGLE_ENABLE_AUTOMATIC_TRIM_ANGLE
+ enum to specify if the display should respond to trim events.
+ Applications that do multithreaded rendering should disable automatic
+ trim and handle the trim events on their own.
+
+Revision History
+
+ Version 1, 2014-06-05 (Geoff Lang)
+ - Initial draft
+ Version 2, 2014-10-27 (Geoff Lang)
+ - Separate WARP devices into a new attribute instead of a platform type.
+ - Moved descriptions of platforms and major/minor versions from
+ EGL_ANGLE_platform_angle spec to EGL_ANGLE_platform_angle_d3d.
+ Version 3, 2014-11-26 (Geoff Lang)
+ - Remove the USE_WARP bool and replace it with a DEVICE_TYPE enum.
+ Version 4, 2015-03-11 (Geoff Lang)
+ - Add the ENABLE_AUTOMATIC_TRIM enum.
diff --git a/src/third_party/angle/extensions/ANGLE_platform_angle_null.txt b/src/third_party/angle/extensions/ANGLE_platform_angle_null.txt
new file mode 100644
index 0000000..e9b8ee2
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_platform_angle_null.txt
@@ -0,0 +1,73 @@
+Name
+
+ ANGLE_platform_angle_null
+
+Name Strings
+
+ EGL_ANGLE_platform_angle_null
+
+Contributors
+
+ Geoff Lang, Google
+
+Contacts
+
+ Geoff Lang, Google (geofflang 'at' google 'dot' com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, September 23, 2016
+
+Number
+
+ EGL Extension #??
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires ANGLE_platform_angle.
+
+Overview
+
+ This extension enables selection of null display types which perform state
+ tracking and validation but do not render any content.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as values for the EGL_PLATFORM_ANGLE_TYPE_ANGLE attribute:
+
+ EGL_PLATFORM_ANGLE_TYPE_NULL_ANGLE 0x33AE
+
+Additions to the EGL Specification
+
+ None.
+
+New Behavior
+
+ To request a display that performs no rendering and has no platform
+ dependencies, the value of EGL_PLATFORM_ANGLE_TYPE_ANGLE should be
+ EGL_PLATFORM_ANGLE_TYPE_NULL_ANGLE.
+
+Issues
+
+ None
+
+Revision History
+
+ Version 1, 2016-09-23 (Geoff Lang)
+ - Initial draft
diff --git a/src/third_party/angle/extensions/ANGLE_platform_angle_opengl.txt b/src/third_party/angle/extensions/ANGLE_platform_angle_opengl.txt
new file mode 100644
index 0000000..9768638
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_platform_angle_opengl.txt
@@ -0,0 +1,84 @@
+Name
+
+ ANGLE_platform_angle_opengl
+
+Name Strings
+
+ EGL_ANGLE_platform_angle_opengl
+
+Contributors
+
+ Shannon Woods, Google
+ Geoff Lang, Google
+
+Contacts
+
+ Geoff Lang, Google (geofflang 'at' chromium 'dot' org)
+
+Status
+
+ Draft
+
+Version
+
+ Version 3, 2014-11-26
+
+Number
+
+ EGL Extension XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires ANGLE_platform_angle.
+
+Overview
+
+ This extension enables selection of OpenGL display types.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as values for the EGL_PLATFORM_ANGLE_TYPE_ANGLE attribute:
+
+ EGL_PLATFORM_ANGLE_TYPE_OPENGL_ANGLE 0x320D
+ EGL_PLATFORM_ANGLE_TYPE_OPENGLES_ANGLE 0x320E
+
+Additions to the EGL Specification
+
+ None.
+
+New Behavior
+
+ To request a display that translates to OpenGL or OpenGL ES, the value of
+ EGL_PLATFORM_ANGLE_TYPE_ANGLE should be:
+ - EGL_PLATFORM_ANGLE_TYPE_OPENGL_ANGLE for an OpenGL display,
+ - EGL_PLATFORM_ANGLE_TYPE_OPENGLES_ANGLE for a native OpenGL ES display.
+
+ To request a specific maximum context version to use for the underlying
+ API, EGL_PLATFORM_ANGLE_MAX_VERSION_MAJOR_ANGLE and
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MINOR_ANGLE can be used.
+
+Issues
+
+ None
+
+Revision History
+
+ Version 1, 2014-06-05 (Geoff Lang)
+ - Initial draft
+ Version 2, 2014-10-27 (Geoff Lang)
+ - Moved descriptions of platforms and major/minor versions from
+ EGL_ANGLE_platform_angle spec to EGL_ANGLE_platform_angle_opengl.
+ Version 3, 2014-11-26 (Geoff Lang)
+ - Updated enum values.
diff --git a/src/third_party/angle/extensions/ANGLE_platform_angle_vulkan.txt b/src/third_party/angle/extensions/ANGLE_platform_angle_vulkan.txt
new file mode 100644
index 0000000..7c426f7
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_platform_angle_vulkan.txt
@@ -0,0 +1,110 @@
+Name
+
+ ANGLE_platform_angle_vulkan
+
+Name Strings
+
+ EGL_ANGLE_platform_angle_vulkan
+
+Contributors
+
+ Jamie Madill, Google
+
+Contacts
+
+ Jamie Madill, Google (jmadill 'at' google 'dot' com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, 2016-11-17
+
+Number
+
+ EGL Extension XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires ANGLE_platform_angle.
+
+Overview
+
+ This extension enables selection of Vulkan display types.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as values for the EGL_PLATFORM_ANGLE_TYPE_ANGLE attribute:
+
+ EGL_PLATFORM_ANGLE_TYPE_VULKAN_ANGLE 0x3450
+
+ Accepted as an attribute name in the <attrib_list> argument of
+ eglGetPlatformDisplayEXT:
+
+ EGL_PLATFORM_ANGLE_ENABLE_VALIDATION_LAYER_ANGLE 0x3451
+
+Additions to the EGL Specification
+
+ None.
+
+New Behavior
+
+ To request a display that is backed by a Vulkan driver, the value of
+ EGL_PLATFORM_ANGLE_TYPE_ANGLE should be
+ EGL_PLATFORM_ANGLE_TYPE_VULKAN_ANGLE.
+
+ If EGL_PLATFORM_ANGLE_ENABLE_VALIDATION_LAYER_ANGLE is specified, it
+ controls enabling the standard Vulkan validation layers. EGL_TRUE enables
+ the validation and EGL_FALSE disables it. Any value other than these will
+ result in an error. If the flag is not specified, validation may default
+ to either enabled or disabled, depending on compile-time parameters in the
+ implementation.
+
+ If EGL_PLATFORM_ANGLE_MAX_VERSION_MAJOR_ANGLE and
+ EGL_PLATFORM_ANGLE_MAX_VERSION_MINOR_ANGLE are not specified, the
+ implementation will decide which version of Vulkan to instantiate. If they
+ are specified, it will choose a version that is lower or equal to the
+ specified major and minor versions. The only current values accepted for
+ major and minor version are 1 for major and 0 for minor.
+
+Issues
+
+ 1) Would it be better to specify validation layers individually?
+
+ RESOLVED: It would give more fined grained control, but the layers
+ are sensitive to ordering, and there may be new ones added or old ones
+ removed, this abstracts the logic into a simpler form. The validation
+ layers maintainers are also moving towards a single-layer model from
+ the current multiple layers approach.
+
+ 2) Should the validation layers default to on, off, or no guarantee?
+
+ Defaulting to off offers some consistency. However, it's customary for
+ some applications like ANGLE to turn on debugging features by default
+ in Debug builds.
+
+ 3) Should ANGLE always instantiate the highest available version of Vulkan?
+
+ RESOLVED: It's possible that in a future implementation of Vulkan there
+ may be driver issues present only on some version of Vulkan, and there's
+ no explicit guarantee higher versions will be more stable. Hence, we should
+ give ANGLE some flexiblity in this regard and leave this unspecified.
+
+Revision History
+
+ Version 1, 2016-11-17 (Jamie Madill)
+ - Initial draft
diff --git a/src/third_party/angle/extensions/ANGLE_request_extension.txt b/src/third_party/angle/extensions/ANGLE_request_extension.txt
new file mode 100644
index 0000000..6536035
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_request_extension.txt
@@ -0,0 +1,116 @@
+Name
+
+ ANGLE_request_extension
+
+Name Strings
+
+ GL_ANGLE_request_extension
+
+Contributors
+
+ Geoff Lang
+
+Contact
+
+ Geoff Lang (geofflang 'at' google.com)
+
+Notice
+
+ Copyright (c) 2016 The Khronos Group Inc. Copyright terms at
+ http://www.khronos.org/registry/speccopyright.html
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, November 28, 2016
+
+Number
+
+ OpenGL ES Extension #??
+
+Dependencies
+
+ Requires OpenGL ES 2.0
+
+ Written against the OpenGL ES 3.0 specification.
+
+Overview
+
+ This extension allows the client to query extensions that can be enabled and
+ explicitly request than an extension be enabled.
+
+New Procedures and Functions
+
+ void RequestExtension(const char *name)
+
+New Tokens
+
+ Accepted by the <name> parameter of GetString and GetStringi:
+
+ REQUESTABLE_EXTENSIONS_ANGLE 0x93A8
+
+ Accepted by the <value> parameter of the GetInteger* functions:
+
+ NUM_REQUESTABLE_EXTENSIONS_ANGLE 0x93A9
+
+Additions to the OpenGL ES 3.0 Specification
+
+ Add the following paragraph to the end paragraph 4 of section 6.1.6, String
+ Queries:
+
+ "REQUESTABLE_EXTENSIONS_ANGLE returns a list of extensions that can be
+ enabled at runtime by calling RequestExtension."
+
+ Change the following section of paragraph 6 of section 6.1.6, String Queries:
+
+ - "name may only be EXTENSIONS, indicating that the extension name
+ - corresponding to the indexth supported extension should be returned.
+ - <index> may range from zero to the value of NUM_EXTENSIONS minus one"
+ + "name may be EXTENSIONS or REQUESTABLE_EXTENSIONS_ANGLE, indicating that
+ + the extension name corresponding to the indexth supported or requestable
+ + extension should be returned. <index> may range from zero to the value of
+ + NUM_EXTENSIONS and NUM_REQUESTABLE_EXTENSIONS_ANGLE minus one"
+
+ The command
+
+ void RequestExtension(const char *name)
+
+ enables the requestable OpenGL ES extension named <name>. If the extension
+ was not requestable, INVALID_OPERATION is generated.
+
+New State
+
+ Add to Table 6.30 (Implementation Dependent Version and Extension Support)
+
+ Get value Type Get Cmd Min Value Description Sec.
+ -------------------------------- ---- ----------- --------- -------------------------------- -----
+ NUM_REQUESTABLE_EXTENSIONS_ANGLE Z+ GetIntegerv - Number of individual requestable 6.1.6
+ extension names
+
+Interactions with the OpenGL ES 2.0 specification:
+
+ Remove all references to GetStringi and NUM_REQUESTABLE_EXTENSIONS_ANGLE.
+
+Issues
+
+ (1) How can the user determine which extensions can be enabled without
+ potentially generating errors?
+
+ This can be solved by:
+ a) Never generate an error in EnableExtensions, simply return false when
+ the extension is not recognized or cannot be enabled.
+ b) Add another query for the extensions that the context supports
+ enabling.
+
+ RESOLVED: Use (b) because it allows the context to explicity advertise
+ which extensions support enabling and doesn't generate errors in the
+ normal use case.
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- ----------------------------------------
+ 1 Nov 28, 2016 geofflang Initial version
diff --git a/src/third_party/angle/extensions/ANGLE_robust_client_memory.txt b/src/third_party/angle/extensions/ANGLE_robust_client_memory.txt
new file mode 100644
index 0000000..933deb0
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_robust_client_memory.txt
@@ -0,0 +1,180 @@
+Name
+
+ ANGLE_robust_client_memory
+
+Name Strings
+
+ GL_ANGLE_robust_client_memory
+
+Contributors
+
+ Geoff Lang, Google
+
+Contacts
+
+ Geoff Lang, Google (geofflang 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 4, March 30, 2017
+
+Number
+
+ OpenGL ES Extension #??
+
+Dependencies
+
+ OpenGL ES 2.0 is required.
+
+ This extension is written against the wording of the OpenGL ES
+ 3.2 specification.
+
+ Interacts with GL_KHR_debug, GL_EXT_disjoint_timer_queries,
+ GL_KHR_robustness.
+
+Overview
+
+ This extension adds overloads of many OpenGL ES functions that read from
+ and write to client memory to ensure that all reads and writes done by the
+ OpenGL ES implementation are safe. When the OpenGL ES API is exposed to
+ users through complex bindings such as WebGL, allowing undefined behaviour
+ that may result in crashing the implementation is not acceptable.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ void GetBooleanvRobustANGLE(enum pname, sizei bufSize, sizei *length, boolean *data)
+ void GetBufferParameterivRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetFloatvRobustANGLE(enum pname, sizei bufSize, sizei *length, float *data)
+ void GetFramebufferAttachmentParameterivRobustANGLE(enum target, enum attachment, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetIntegervRobustANGLE(enum pname, sizei bufSize, sizei *length, int *data)
+ void GetProgramivRobustANGLE(uint program, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetRenderbufferParameterivRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetShaderivRobustANGLE(uint shader, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetTexParameterfvRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, float *params)
+ void GetTexParameterivRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetUniformfvRobustANGLE(uint program, int location, sizei bufSize, sizei *length, float *params)
+ void GetUniformivRobustANGLE(uint program, int location, sizei bufSize, sizei *length, int *params)
+ void GetVertexAttribfvRobustANGLE(uint index, enum pname, sizei bufSize, sizei *length, float *params)
+ void GetVertexAttribivRobustANGLE(uint index, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetVertexAttribPointervRobustANGLE(uint index, enum pname, sizei bufSize, sizei *length, void **pointer)
+ void ReadPixelsRobustANGLE(int x, int y, sizei width, sizei height, enum format, enum type, sizei bufSize, sizei *length, sizei *columns, sizei *rows, void *pixels)
+ void TexImage2DRobustANGLE(enum target, int level, int internalformat, sizei width, sizei height, int border, enum format, enum type, sizei bufSize, const void *pixels)
+ void TexParameterfvRobustANGLE(enum target, enum pname, sizei bufSize, const GLfloat *params)
+ void TexParameterivRobustANGLE(enum target, enum pname, sizei bufSize, const GLint *params)
+ void TexSubImage2DRobustANGLE(enum target, int level, int xoffset, int yoffset, sizei width, sizei height, enum format, enum type, sizei bufSize, const void *pixels)
+ void CompressedTexImage2D(enum target, int level, enum internalformat, sizei width, sizei height, int border, sizei imageSize, sizei bufSize, const void* data)
+ void CompressedTexSubImage2D(enum target, int level, int xoffset, int yoffset, sizei width, sizei height, enum format, sizei imageSize, sizei bufSize, const void* data)
+ void CompressedTexImage3D(enum target, int level, enum internalformat, sizei width, sizei height, sizei depth, int border, sizei imageSize, sizei bufSize, const void* data)
+ void CompressedTexSubImage3D(enum target, int level, int xoffset, int yoffset, int zoffset, sizei width, sizei height, sizei depth, enum format, sizei imageSize, sizei bufSize, const void* data)
+
+ void TexImage3DRobustANGLE(enum target, int level, int internalformat, sizei width, sizei height, sizei depth, int border, enum format, enum type, sizei bufSize, const void *pixels);
+ void TexSubImage3DRobustANGLE(enum target, int level, int xoffset, int yoffset, int zoffset, sizei width, sizei height, sizei depth, enum format, enum type, sizei bufSize, const void *pixels);
+ void GetQueryivRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetQueryObjectuivRobustANGLE(uint id, enum pname, sizei bufSize, sizei *length, uint *params)
+ void GetBufferPointervRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, void **params)
+ void GetIntegeri_vRobustANGLE(enum target, uint index, sizei bufSize, sizei *length, int *data)
+ void GetInternalformativRobustANGLE(enum target, enum internalformat, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetVertexAttribIivRobustANGLE(uint index, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetVertexAttribIuivRobustANGLE(uint index, enum pname, sizei bufSize, sizei *length, uint *params)
+ void GetUniformuivRobustANGLE(uint program, int location, sizei bufSize, sizei *length, uint *params)
+ void GetActiveUniformBlockivRobustANGLE(uint program, uint uniformBlockIndex, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetInteger64vRobustANGLE(enum pname, sizei bufSize, sizei *length, int64 *data)
+ void GetInteger64i_vRobustANGLE(enum target, uint index, sizei bufSize, sizei *length, int64 *data)
+ void GetBufferParameteri64vRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, int64 *params)
+ void SamplerParameterivRobustANGLE(uint sampler, enum pname, sizei bufSize, const GLint *param)
+ void SamplerParameterfvRobustANGLE(uint sampler, enum pname, sizei bufSize, const GLfloat *param)
+ void GetSamplerParameterivRobustANGLE(uint sampler, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetSamplerParameterfvRobustANGLE(uint sampler, enum pname, sizei bufSize, sizei *length, float *params)
+
+ void GetFramebufferParameterivRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetProgramInterfaceivRobustANGLE(uint program, enum programInterface, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetBooleani_vRobustANGLE(enum target, uint index, sizei bufSize, sizei *length, boolean *data)
+ void GetMultisamplefvRobustANGLE(enum pname, uint index, sizei bufSize, sizei *length, float *val)
+ void GetTexLevelParameterivRobustANGLE(enum target, int level, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetTexLevelParameterfvRobustANGLE(enum target, int level, enum pname, sizei bufSize, sizei *length, float *params)
+
+ void GetPointervRobustANGLERobustANGLE(enum pname, sizei bufSize, sizei *length, void **params)
+ void ReadnPixelsRobustANGLE(int x, int y, sizei width, sizei height, enum format, enum type, sizei bufSize, sizei *length, sizei *columns, sizei *rows, void *data)
+ void GetnUniformfvRobustANGLE(uint program, int location, sizei bufSize, sizei *length, float *params)
+ void GetnUniformivRobustANGLE(uint program, int location, sizei bufSize, sizei *length, int *params)
+ void GetnUniformuivRobustANGLE(uint program, int location, sizei bufSize, sizei *length, uint *params)
+ void TexParameterIivRobustANGLE(enum target, enum pname, sizei bufSize, const GLint *params)
+ void TexParameterIuivRobustANGLE(enum target, enum pname, sizei bufSize, const GLuint *params)
+ void GetTexParameterIivRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetTexParameterIuivRobustANGLE(enum target, enum pname, sizei bufSize, sizei *length, uint *params)
+ void SamplerParameterIivRobustANGLE(uint sampler, enum pname, sizei bufSize, const GLint *param)
+ void SamplerParameterIuivRobustANGLE(uint sampler, enum pname, sizei bufSize, const GLuint *param)
+ void GetSamplerParameterIivRobustANGLE(uint sampler, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetSamplerParameterIuivRobustANGLE(uint sampler, enum pname, sizei bufSize, sizei *length, uint *params)
+
+ void GetQueryObjectivRobustANGLE(uint id, enum pname, sizei bufSize, sizei *length, int *params)
+ void GetQueryObjecti64vRobustANGLE(uint id, enum pname, sizei bufSize, sizei *length, int64 *params)
+ void GetQueryObjectui64vRobustANGLE(uint id, enum pname, sizei bufSize, sizei *length, uint64 *params)
+
+New Tokens
+
+ None
+
+Additions to the OpenGL ES Specification:
+
+ The xRobustANGLE entry points perform additional validation using <bufSize>
+ to indicate the maximum number of values that can be read from or written
+ to the provided buffer. INVALID_OPERATION is generated if <bufSize> is not
+ large enough. The optional <length> specifies an address of a variable to
+ recieve the number of values written to the buffer. When an error is
+ generated nothing will be written to <length>.
+
+ The <columns> and <rows> parameters of ReadPixelsRobustANGLE and
+ ReadnPixelsRobustANGLE specify addresses of variables to recieve the number
+ of columns and rows of pixels written to the buffer which may be less than
+ the <width> and <height> parameters if they would have read outside of the
+ framebuffer.
+
+ Calls to "xRobustANGLE" will generate errors under the same conditions as
+ "x". Any instances of undefined behaviour in "x" will also be undefined in
+ "xRobustANGLE". For example, it is invalid to call
+ GetPointervRobustANGLERobustANGLE without first verifying that the context
+ is at least OpenGL ES version 3.2 or the GL_KHR_debug extension is present.
+
+Issues
+
+ 1) Should additional entry points be added to specify sizes of client side
+ data provided to the VertexAttribPointer functions?
+
+ 2) Should <length> be allowed to be null?
+
+ RESOLVED: Yes, <length> will not be written to when it is a null
+ pointer.
+
+ 3) Should <bufSize> be specified in bytes or values (uint, int, float,
+ etc)?
+
+ There is no consistancy in current entry points for this. For example,
+ glGetnUniformuiv indicates that bufSize is in bytes while GetSynciv
+ uses values despite GetnUniformuiv having a clear value type.
+
+ RESOLOVED: <bufSize> always indicates size in values. Functions that
+ specify data by void* such as TexImage2DRobustANGLE treat the client
+ data as bytes.
+
+ 4) Should <length> be written to if an error is generated?
+
+ RESOLVED: No, using the prescedent set by glGetSynciv.
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- -------------------------------------------
+ 1 Sept 26, 2016 geofflang Initial version
+ 2 Sept 28, 2016 geofflang Changed name from ANGLE_robust_queries to
+ ANGLE_robust_client_memory, added issue 3.
+ 3 Oct 7, 2016 geofflang Added and resolved issue 4.
+ 4 Mar 30, 2017 geofflang Added columns and rows to ReadPixels.
diff --git a/src/third_party/angle/extensions/ANGLE_robust_resource_initialization.txt b/src/third_party/angle/extensions/ANGLE_robust_resource_initialization.txt
new file mode 100644
index 0000000..dbe2828
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_robust_resource_initialization.txt
@@ -0,0 +1,143 @@
+Name
+
+ ANGLE_robust_resource_initialization.txt
+
+Name Strings
+
+ ANGLE_robust_resource_intialization
+
+Contributors
+
+ Geoff Lang, Google
+ Ken Russell, Google
+
+Contacts
+
+ Shannon Woods, Google (shannonwoods 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, January 7, 2015
+
+Number
+
+ OpenGL ES Extension TBD
+
+Dependencies
+
+ OpenGL ES 2.0 is required.
+
+ This extension is written against the wording of the OpenGL ES
+ 3.1 specification.
+
+ EGL_ANGLE_create_context_robust_initialization is required to request a
+ context that supports this extension, and resource initialization.
+
+Overview
+
+ This extension specifies the behavior for initialization of
+ resources such as textures and buffers to default values. This
+ initialization ensures that access will not be provided by the
+ GL to previously allocated data not owned by the application.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <value> parameter of GetBooleanv, GetIntegerv,
+ GetFloatv, GetDoublev, GetInteger64v, and IsEnabled:
+
+ CONTEXT_ROBUST_RESOURCE_INITIALIZATION_ANGLE 0x93A7
+
+Additions to Chapter 6 of the OpenGL ES 3.1 Specification (Buffer
+Objects)
+
+ Replace the last sentence of the first paragraph of section 6.2
+ "BufferData":
+
+ If <data> is NULL, and robust resource initialization is enabled,
+ the contents of the buffer object's data store are set to zero.
+ Otherwise, the contents of the buffer object's data store are
+ undefined.
+
+Additions to Chapter 8 of the OpenGL ES 3.1 Specification (Textures and
+Samplers)
+
+ Replace the first two sentances of the final paragraph in section
+ 8.5.3 "Texture Image Structure":
+
+ If the <data> argument of TexImage2D or TexImage3D is NULL, and the
+ pixel unpack buffer object is zero, a two- or three-dimensional
+ texel array is created with the specified <target>, <level>,
+ <internalformat>, <border>, <width>, <height>, and <depth>. If
+ robust resource initialization is enabled, the contents of the image
+ are initialized as though a zero value were provided for each
+ component of each pixel, and processed and transferred to the GL
+ as described above. The components comprising this zero-filled data
+ are determined by <internalformat>. If robust resource
+ initialization is not enabled, the image contents are undefined, and
+ no pixel processing is performed. In either case, no pixel values
+ are accessed in client memory.
+
+ Replace the first sentence of the fifth paragraph in section 8.8
+ "Multisample Textures":
+
+ Upon success, TexStorage2DMultisample deletes any existing image
+ for target. If robust resource initialization is enabled, the
+ contents of each texel are initialized as though a zero value were
+ written to each channel of each sample; otherwise the contents of
+ texels are undefined.
+
+ Add to the final paragraph of section 8.17 "Immutable-Format Texture
+ Images":
+
+ If robust resource initialization is enabled, the contents of each
+ texel is initialized as though a zero value were provided for each
+ component of each pixel, and processed and transferred to the GL
+ as for a call to the appropriate TexSubImage* call for <target>.
+ Otherwise, the contents of texels are undefined.
+
+Additions to Chapter 9 of the OpenGL ES 3.1 Specification (Framebuffers
+and Framebuffer Objects)
+
+ Replace the sentence in section 9.2.4 "Renderbuffer Objects"
+ beginning "Upon success, RenderbufferStorageMultisample":
+
+ Upon success, RenderbufferStorageMultisample deletes any existing
+ data store for the renderbuffer image. If robust resource
+ initialization is enabled, the contents of each pixel in the data
+ store are initialized as though a zero value was written to each
+ channel of each sample; otherwise, the contents of the data store
+ are undefined.
+
+Interactions with EGL_ANGLE_create_context_robust_resource_initialization
+
+ If the EGL window-system binding API is used to create a context,
+ the EGL_ANGLE_create_context_robust_initialization extension is
+ supported, and the attribute
+ EGL_CONTEXT_ROBUST_RESOURCE_INITIALIZATION_ANGLE is set to
+ EGL_TRUE when eglCreateContext is called, the resulting context
+ will perform robust resource initialization as described above in
+ section <section>, and the
+ CONTEXT_ROBUST_RESOURCE_INITIALIZATION_ANGLE
+ query will return GL_TRUE as described above in section 2.6.1.1.
+ Otherwise queries will return GL_FALSE.
+
+Issues
+
+ None
+
+Revision History
+
+ Version 1, 2015/01/07 - first draft.
+ Version 2, 2017/03/07 - fixed EGL naming and added IsEnabled.
diff --git a/src/third_party/angle/extensions/ANGLE_timer_query.txt b/src/third_party/angle/extensions/ANGLE_timer_query.txt
index 3cc3858..c1371ad 100644
--- a/src/third_party/angle/extensions/ANGLE_timer_query.txt
+++ b/src/third_party/angle/extensions/ANGLE_timer_query.txt
@@ -1,591 +1,591 @@
-Name
-
- ANGLE_timer_query
-
-Name Strings
-
- GL_ANGLE_timer_query
-
-Contributors
-
- Contributors to ARB_occlusion_query
- Contributors to EXT_timer_query
- Contributors to ARB_timer_query
- Ben Vanik, Google Inc.
- Daniel Koch, TransGaming Inc.
-
-Contact
-
- Ben Vanik, Google Inc. (benvanik 'at' google 'dot' com)
-
-Status
-
- Draft
-
-Version
-
- Last Modified Date: Apr 28, 2011
- Author Revision: 1
-
-Number
-
- OpenGL ES Extension #??
-
-Dependencies
-
- OpenGL ES 2.0 is required.
-
- The extension is written against the OpenGL ES 2.0 specification.
-
-Overview
-
- Applications can benefit from accurate timing information in a number of
- different ways. During application development, timing information can
- help identify application or driver bottlenecks. At run time,
- applications can use timing information to dynamically adjust the amount
- of detail in a scene to achieve constant frame rates. OpenGL
- implementations have historically provided little to no useful timing
- information. Applications can get some idea of timing by reading timers
- on the CPU, but these timers are not synchronized with the graphics
- rendering pipeline. Reading a CPU timer does not guarantee the completion
- of a potentially large amount of graphics work accumulated before the
- timer is read, and will thus produce wildly inaccurate results.
- glFinish() can be used to determine when previous rendering commands have
- been completed, but will idle the graphics pipeline and adversely affect
- application performance.
-
- This extension provides a query mechanism that can be used to determine
- the amount of time it takes to fully complete a set of GL commands, and
- without stalling the rendering pipeline. It uses the query object
- mechanisms first introduced in the occlusion query extension, which allow
- time intervals to be polled asynchronously by the application.
-
-IP Status
-
- No known IP claims.
-
-New Procedures and Functions
-
- void GenQueriesANGLE(sizei n, uint *ids);
- void DeleteQueriesANGLE(sizei n, const uint *ids);
- boolean IsQueryANGLE(uint id);
- void BeginQueryANGLE(enum target, uint id);
- void EndQueryANGLE(enum target);
- void QueryCounterANGLE(uint id, enum target);
- void GetQueryivANGLE(enum target, enum pname, int *params);
- void GetQueryObjectivANGLE(uint id, enum pname, int *params);
- void GetQueryObjectuivANGLE(uint id, enum pname, uint *params);
- void GetQueryObjecti64vANGLE(uint id, enum pname, int64 *params);
- void GetQueryObjectui64vANGLE(uint id, enum pname, uint64 *params);
-
-New Tokens
-
- Accepted by the <pname> parameter of GetQueryivANGLE:
-
- QUERY_COUNTER_BITS_ANGLE 0x8864
- CURRENT_QUERY_ANGLE 0x8865
-
- Accepted by the <pname> parameter of GetQueryObjectivANGLE,
- GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, and
- GetQueryObjectui64vANGLE:
-
- QUERY_RESULT_ANGLE 0x8866
- QUERY_RESULT_AVAILABLE_ANGLE 0x8867
-
- Accepted by the <target> parameter of BeginQueryANGLE, EndQueryANGLE, and
- GetQueryivANGLE:
-
- TIME_ELAPSED_ANGLE 0x88BF
-
- Accepted by the <target> parameter of GetQueryivANGLE and
- QueryCounterANGLE:
-
- TIMESTAMP_ANGLE 0x8E28
-
-Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL ES Operation)
-
- (Modify table 2.1, Correspondence of command suffix letters to GL argument)
- Add two new types:
-
- Letter Corresponding GL Type
- ------ ---------------------
- i64 int64ANGLE
- ui64 uint64ANGLE
-
- (Modify table 2.2, GL data types) Add two new types:
-
- GL Type Minimum Bit Width Description
- ------- ----------------- -----------------------------
- int64ANGLE 64 Signed 2's complement integer
- uint64ANGLE 64 Unsigned binary integer
-
-Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special Functions)
-
- Add a new section 5.3 "Timer Queries":
-
- "5.3 Timer Queries
-
- Timer queries use query objects to track the amount of time needed to
- fully complete a set of GL commands, or to determine the current time
- of the GL.
-
- Timer queries are associated with query objects. The command
-
- void GenQueriesANGLE(sizei n, uint *ids);
-
- returns <n> previously unused query object names in <ids>. These
- names are marked as used, but no object is associated with them until
- the first time they are used by BeginQueryANGLE. Query objects contain
- one piece of state, an integer result value. This result value is
- initialized to zero when the object is created. Any positive integer
- except for zero (which is reserved for the GL) is a valid query
- object name.
-
- Query objects are deleted by calling
-
- void DeleteQueriesANGLE(sizei n, const uint *ids);
-
- <ids> contains <n> names of query objects to be deleted. After a
- query object is deleted, its name is again unused. Unused names in
- <ids> are silently ignored.
- If an active query object is deleted its name immediately becomes unused,
- but the underlying object is not deleted until it is no longer active.
-
- A timer query can be started and finished by calling
-
- void BeginQueryANGLE(enum target, uint id);
- void EndQueryANGLE(enum target);
-
- where <target> is TIME_ELAPSED_ANGLE. If BeginQueryANGLE is called
- with an unused <id>, that name is marked as used and associated with
- a new query object.
-
- If BeginQueryANGLE is called with an <id> of zero, if the active query
- object name for <target> is non-zero, if <id> is the name of an existing
- query object whose type does not match <target>, or if <id> is the active
- query object name for any query type, the error INVALID_OPERATION is
- generated. If EndQueryANGLE is called while no query with the same target
- is in progress, an INVALID_OPERATION error is generated.
-
- When BeginQueryANGLE and EndQueryANGLE are called with a <target> of
- TIME_ELAPSED_ANGLE, the GL prepares to start and stop the timer used for
- timer queries. The timer is started or stopped when the effects from all
- previous commands on the GL client and server state and the framebuffer
- have been fully realized. The BeginQueryANGLE and EndQueryANGLE commands
- may return before the timer is actually started or stopped. When the timer
- query timer is finally stopped, the elapsed time (in nanoseconds) is
- written to the corresponding query object as the query result value, and
- the query result for that object is marked as available.
-
- If the elapsed time overflows the number of bits, <n>, available to hold
- elapsed time, its value becomes undefined. It is recommended, but not
- required, that implementations handle this overflow case by saturating at
- 2^n - 1.
-
- The necessary state is a single bit indicating whether an timer
- query is active, the identifier of the currently active timer
- query, and a counter keeping track of the time that has passed.
-
- When the command
-
- void QueryCounterANGLE(uint id, enum target);
-
- is called with <target> TIMESTAMP_ANGLE, the GL records the current time
- into the corresponding query object. The time is recorded after all
- previous commands on the GL client and server state and the framebuffer
- have been fully realized. When the time is recorded, the query result for
- that object is marked available. QueryCounterANGLE timer queries can be
- used within a BeginQueryANGLE / EndQueryANGLE block where the <target> is
- TIME_ELAPSED_ANGLE and it does not affect the result of that query object.
- The error INVALID_OPERATION is generated if the <id> is already in use
- within a BeginQueryANGLE/EndQueryANGLE block."
-
-Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and State
-Requests)
-
- Add a new section 6.1.9 "Timer Queries":
-
- "The command
-
- boolean IsQueryANGLE(uint id);
-
- returns TRUE if <id> is the name of a query object. If <id> is zero,
- or if <id> is a non-zero value that is not the name of a query
- object, IsQueryANGLE returns FALSE.
-
- Information about a query target can be queried with the command
-
- void GetQueryivANGLE(enum target, enum pname, int *params);
-
- <target> identifies the query target and can be TIME_ELAPSED_ANGLE or
- TIMESTAMP_ANGLE for timer queries.
-
- If <pname> is CURRENT_QUERY_ANGLE, the name of the currently active query
- for <target>, or zero if no query is active, will be placed in <params>.
-
- If <pname> is QUERY_COUNTER_BITS_ANGLE, the implementation-dependent number
- of bits used to hold the query result for <target> will be placed in
- <params>. The number of query counter bits may be zero, in which case
- the counter contains no useful information.
-
- For timer queries (TIME_ELAPSED_ANGLE and TIMESTAMP_ANGLE), if the number
- of bits is non-zero, the minimum number of bits allowed is 30 which
- will allow at least 1 second of timing.
-
- The state of a query object can be queried with the commands
-
- void GetQueryObjectivANGLE(uint id, enum pname, int *params);
- void GetQueryObjectuivANGLE(uint id, enum pname, uint *params);
- void GetQueryObjecti64vANGLE(uint id, enum pname, int64 *params);
- void GetQueryObjectui64vANGLE(uint id, enum pname, uint64 *params);
-
- If <id> is not the name of a query object, or if the query object
- named by <id> is currently active, then an INVALID_OPERATION error is
- generated.
-
- If <pname> is QUERY_RESULT_ANGLE, then the query object's result
- value is returned as a single integer in <params>. If the value is so
- large in magnitude that it cannot be represented with the requested type,
- then the nearest value representable using the requested type is
- returned. If the number of query counter bits for target is zero, then
- the result is returned as a single integer with the value zero.
-
- There may be an indeterminate delay before the above query returns. If
- <pname> is QUERY_RESULT_AVAILABLE_ANGLE, FALSE is returned if such a delay
- would be required; otherwise TRUE is returned. It must always be true
- that if any query object returns a result available of TRUE, all queries
- of the same type issued prior to that query must also return TRUE.
-
- Querying the state for a given timer query forces that timer query to
- complete within a finite amount of time.
-
- If multiple queries are issued on the same target and id prior to
- calling GetQueryObject[u]i[64]vANGLE, the result returned will always be
- from the last query issued. The results from any queries before the
- last one will be lost if the results are not retrieved before starting
- a new query on the same <target> and <id>."
-
-Errors
-
- The error INVALID_VALUE is generated if GenQueriesANGLE is called where
- <n> is negative.
-
- The error INVALID_VALUE is generated if DeleteQueriesANGLE is called
- where <n> is negative.
-
- The error INVALID_OPERATION is generated if BeginQueryANGLE is called
- when a query of the given <target> is already active.
-
- The error INVALID_OPERATION is generated if EndQueryANGLE is called
- when a query of the given <target> is not active.
-
- The error INVALID_OPERATION is generated if BeginQueryANGLE is called
- where <id> is zero.
-
- The error INVALID_OPERATION is generated if BeginQueryANGLE is called
- where <id> is the name of a query currently in progress.
-
- The error INVALID_OPERATION is generated if BeginQueryANGLE is called
- where <id> is the name of an existing query object whose type does not
- match <target>.
-
- The error INVALID_ENUM is generated if BeginQueryANGLE or EndQueryANGLE
- is called where <target> is not TIME_ELAPSED_ANGLE.
-
- The error INVALID_ENUM is generated if GetQueryivANGLE is called where
- <target> is not TIME_ELAPSED_ANGLE or TIMESTAMP_ANGLE.
-
- The error INVALID_ENUM is generated if GetQueryivANGLE is called where
- <pname> is not QUERY_COUNTER_BITS_ANGLE or CURRENT_QUERY_ANGLE.
-
- The error INVALID_ENUM is generated if QueryCounterANGLE is called where
- <target> is not TIMESTAMP_ANGLE.
-
- The error INVALID_OPERATION is generated if QueryCounterANGLE is called
- on a query object that is already in use inside a
- BeginQueryANGLE/EndQueryANGLE.
-
- The error INVALID_OPERATION is generated if GetQueryObjectivANGLE,
- GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or
- GetQueryObjectui64vANGLE is called where <id> is not the name of a query
- object.
-
- The error INVALID_OPERATION is generated if GetQueryObjectivANGLE,
- GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or
- GetQueryObjectui64vANGLE is called where <id> is the name of a currently
- active query object.
-
- The error INVALID_ENUM is generated if GetQueryObjectivANGLE,
- GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or
- GetQueryObjectui64vANGLE is called where <pname> is not
- QUERY_RESULT_ANGLE or QUERY_RESULT_AVAILABLE_ANGLE.
-
-New State
-
- (Add a new table 6.xx, "Query Operations")
-
- Get Value Type Get Command Initial Value Description Sec
- --------- ---- ----------- ------------- ----------- ------
- - B - FALSE query active 5.3
- CURRENT_QUERY_ANGLE Z+ GetQueryivANGLE 0 active query ID 5.3
- QUERY_RESULT_ANGLE Z+ GetQueryObjectuivANGLE, 0 samples-passed count 5.3
- GetQueryObjectui64vANGLE
- QUERY_RESULT_AVAILABLE_ANGLE B GetQueryObjectivANGLE FALSE query result available 5.3
-
-New Implementation Dependent State
-
- (Add the following entry to table 6.18):
-
- Get Value Type Get Command Minimum Value Description Sec
- -------------------------- ---- ----------- ------------- ---------------- ------
- QUERY_COUNTER_BITS_ANGLE Z+ GetQueryivANGLE see 6.1.9 Number of bits in 6.1.9
- query counter
-
-Examples
-
- (1) Here is some rough sample code that demonstrates the intended usage
- of this extension.
-
- GLint queries[N];
- GLint available = 0;
- // timer queries can contain more than 32 bits of data, so always
- // query them using the 64 bit types to avoid overflow
- GLuint64ANGLE timeElapsed = 0;
-
- // Create a query object.
- glGenQueriesANGLE(N, queries);
-
- // Start query 1
- glBeginQueryANGLE(GL_TIME_ELAPSED_ANGLE, queries[0]);
-
- // Draw object 1
- ....
-
- // End query 1
- glEndQueryANGLE(GL_TIME_ELAPSED_ANGLE);
-
- ...
-
- // Start query N
- glBeginQueryANGLE(GL_TIME_ELAPSED_ANGLE, queries[N-1]);
-
- // Draw object N
- ....
-
- // End query N
- glEndQueryANGLE(GL_TIME_ELAPSED_ANGLE);
-
- // Wait for all results to become available
- while (!available) {
- glGetQueryObjectivANGLE(queries[N-1], GL_QUERY_RESULT_AVAILABLE_ANGLE, &available);
- }
-
- for (i = 0; i < N; i++) {
- // See how much time the rendering of object i took in nanoseconds.
- glGetQueryObjectui64vANGLE(queries[i], GL_QUERY_RESULT_ANGLE, &timeElapsed);
-
- // Do something useful with the time. Note that care should be
- // taken to use all significant bits of the result, not just the
- // least significant 32 bits.
- AdjustObjectLODBasedOnDrawTime(i, timeElapsed);
- }
-
- This example is sub-optimal in that it stalls at the end of every
- frame to wait for query results. Ideally, the collection of results
- would be delayed one frame to minimize the amount of time spent
- waiting for the GPU to finish rendering.
-
- (2) This example is basically the same as the example above but uses
- QueryCounter instead.
-
- GLint queries[N+1];
- GLint available = 0;
- // timer queries can contain more than 32 bits of data, so always
- // query them using the 64 bit types to avoid overflow
- GLuint64ANGLE timeStart, timeEnd, timeElapsed = 0;
-
- // Create a query object.
- glGenQueriesANGLE(N+1, queries);
-
- // Query current timestamp 1
- glQueryCounterANGLE(queries[0], GL_TIMESTAMP_ANGLE);
-
- // Draw object 1
- ....
-
- // Query current timestamp N
- glQueryCounterANGLE(queries[N-1], GL_TIMESTAMP_ANGLE);
-
- // Draw object N
- ....
-
- // Query current timestamp N+1
- glQueryCounterANGLE(queries[N], GL_TIMESTAMP_ANGLE);
-
- // Wait for all results to become available
- while (!available) {
- glGetQueryObjectivANGLE(queries[N], GL_QUERY_RESULT_AVAILABLE_ANGLE, &available);
- }
-
- for (i = 0; i < N; i++) {
- // See how much time the rendering of object i took in nanoseconds.
- glGetQueryObjectui64vANGLE(queries[i], GL_QUERY_RESULT_ANGLE, &timeStart);
- glGetQueryObjectui64vANGLE(queries[i+1], GL_QUERY_RESULT_ANGLE, &timeEnd);
- timeElapsed = timeEnd - timeStart;
-
- // Do something useful with the time. Note that care should be
- // taken to use all significant bits of the result, not just the
- // least significant 32 bits.
- AdjustObjectLODBasedOnDrawTime(i, timeElapsed);
- }
-
-Issues from EXT_timer_query
-
- (1) What time interval is being measured?
-
- RESOLVED: The timer starts when all commands prior to BeginQuery() have
- been fully executed. At that point, everything that should be drawn by
- those commands has been written to the framebuffer. The timer stops
- when all commands prior to EndQuery() have been fully executed.
-
- (2) What unit of time will time intervals be returned in?
-
- RESOLVED: Nanoseconds (10^-9 seconds). This unit of measurement allows
- for reasonably accurate timing of even small blocks of rendering
- commands. The granularity of the timer is implementation-dependent. A
- 32-bit query counter can express intervals of up to approximately 4
- seconds.
-
- (3) What should be the minimum number of counter bits for timer queries?
-
- RESOLVED: 30 bits, which will allow timing sections that take up to 1
- second to render.
-
- (4) How are counter results of more than 32 bits returned?
-
- RESOLVED: Via two new datatypes, int64ANGLE and uint64ANGLE, and their
- corresponding GetQueryObject entry points. These types hold integer
- values and have a minimum bit width of 64.
-
- (5) Should the extension measure total time elapsed between the full
- completion of the BeginQuery and EndQuery commands, or just time
- spent in the graphics library?
-
- RESOLVED: This extension will measure the total time elapsed between
- the full completion of these commands. Future extensions may implement
- a query to determine time elapsed at different stages of the graphics
- pipeline.
-
- (6) If multiple query types are supported, can multiple query types be
- active simultaneously?
-
- RESOLVED: Yes; an application may perform a timer query and another
- type of query simultaneously. An application can not perform multiple
- timer queries or multiple queries of other types simultaneously. An
- application also can not use the same query object for another query
- and a timer query simultaneously.
-
- (7) Do query objects have a query type permanently associated with them?
-
- RESOLVED: No. A single query object can be used to perform different
- types of queries, but not at the same time.
-
- Having a fixed type for each query object simplifies some aspects of the
- implementation -- not having to deal with queries with different result
- sizes, for example. It would also mean that BeginQuery() with a query
- object of the "wrong" type would result in an INVALID_OPERATION error.
-
- UPDATE: This resolution was relevant for EXT_timer_query and OpenGL 2.0.
- Since EXT_transform_feedback has since been incorporated into the core,
- the resolution is that BeginQuery will generate error INVALID_OPERATION
- if <id> represents a query object of a different type.
-
- (8) How predictable/repeatable are the results returned by the timer
- query?
-
- RESOLVED: In general, the amount of time needed to render the same
- primitives should be fairly constant. But there may be many other
- system issues (e.g., context switching on the CPU and GPU, virtual
- memory page faults, memory cache behavior on the CPU and GPU) that can
- cause times to vary wildly.
-
- Note that modern GPUs are generally highly pipelined, and may be
- processing different primitives in different pipeline stages
- simultaneously. In this extension, the timers start and stop when the
- BeginQuery/EndQuery commands reach the bottom of the rendering pipeline.
- What that means is that by the time the timer starts, the GL driver on
- the CPU may have started work on GL commands issued after BeginQuery,
- and the higher pipeline stages (e.g., vertex transformation) may have
- started as well.
-
- (9) What should the new 64 bit integer type be called?
-
- RESOLVED: The new types will be called GLint64ANGLE/GLuint64ANGLE. The new
- command suffixes will be i64 and ui64. These names clearly convey the
- minimum size of the types. These types are similar to the C99 standard
- type int_least64_t, but we use names similar to the C99 optional type
- int64_t for simplicity.
-
-Issues from ARB_timer_query
-
- (10) What about tile-based implementations? The effects of a command are
- not complete until the frame is completely rendered. Timing recorded
- before the frame is complete may not be what developers expect. Also
- the amount of time needed to render the same primitives is not
- consistent, which conflicts with issue (8) above. The time depends on
- how early or late in the scene it is placed.
-
- RESOLVED: The current language supports tile-based rendering okay as it
- is written. Developers are warned that using timers on tile-based
- implementation may not produce results they expect since rendering is not
- done in a linear order. Timing results are calculated when the frame is
- completed and may depend on how early or late in the scene it is placed.
-
- (11) Can the GL implementation use different clocks to implement the
- TIME_ELAPSED and TIMESTAMP queries?
-
- RESOLVED: Yes, the implemenation can use different internal clocks to
- implement TIME_ELAPSED and TIMESTAMP. If different clocks are
- used it is possible there is a slight discrepancy when comparing queries
- made from TIME_ELAPSED and TIMESTAMP; they may have slight
- differences when both are used to measure the same sequence. However, this
- is unlikely to affect real applications since comparing the two queries is
- not expected to be useful.
-
-Issues
-
- (12) What should we call this extension?
-
- RESOLVED: ANGLE_timer_query
-
- (13) Why is this done as a separate extension instead of just supporting
- ARB_timer_query?
-
- ARB_timer_query is written against OpenGL 3.2, which includes a lot of
- the required support for dealing with query objects. None of these
- functions or tokens exist in OpenGL ES, and as such have to be added in
- this specification.
-
- (14) How does this extension differ from ARB_timer_query?
-
- This extension contains most ARB_timer_query behavior unchanged as well
- as a subset of the query support required to use it from the core
- OpenGL 3.2 spec. It omits the glGetInteger(TIMESTAMP) functionality used to
- query the current time on the GPU, but the behavior for all remaining
- functionality taken from ARB_timer_query is the same.
-
- (15) Are query objects shareable between multiple contexts?
-
- RESOLVED: No. Query objects are lightweight and we normally share
- large data across contexts. Also, being able to share query objects
- across contexts is not particularly useful. In order to do the async
- query across contexts, a query on one context would have to be finished
- before the other context could query it.
-
-Revision History
-
- Revision 1, 2011/04/28
- - copied from revision 9 of ARB_timer_query and revision 7 of
- ARB_occlusion_query
- - removed language that was clearly not relevant to ES2
- - rebased changes against the OpenGL ES 2.0 specification
+Name
+
+ ANGLE_timer_query
+
+Name Strings
+
+ GL_ANGLE_timer_query
+
+Contributors
+
+ Contributors to ARB_occlusion_query
+ Contributors to EXT_timer_query
+ Contributors to ARB_timer_query
+ Ben Vanik, Google Inc.
+ Daniel Koch, TransGaming Inc.
+
+Contact
+
+ Ben Vanik, Google Inc. (benvanik 'at' google 'dot' com)
+
+Status
+
+ Draft
+
+Version
+
+ Last Modified Date: Apr 28, 2011
+ Author Revision: 1
+
+Number
+
+ OpenGL ES Extension #??
+
+Dependencies
+
+ OpenGL ES 2.0 is required.
+
+ The extension is written against the OpenGL ES 2.0 specification.
+
+Overview
+
+ Applications can benefit from accurate timing information in a number of
+ different ways. During application development, timing information can
+ help identify application or driver bottlenecks. At run time,
+ applications can use timing information to dynamically adjust the amount
+ of detail in a scene to achieve constant frame rates. OpenGL
+ implementations have historically provided little to no useful timing
+ information. Applications can get some idea of timing by reading timers
+ on the CPU, but these timers are not synchronized with the graphics
+ rendering pipeline. Reading a CPU timer does not guarantee the completion
+ of a potentially large amount of graphics work accumulated before the
+ timer is read, and will thus produce wildly inaccurate results.
+ glFinish() can be used to determine when previous rendering commands have
+ been completed, but will idle the graphics pipeline and adversely affect
+ application performance.
+
+ This extension provides a query mechanism that can be used to determine
+ the amount of time it takes to fully complete a set of GL commands, and
+ without stalling the rendering pipeline. It uses the query object
+ mechanisms first introduced in the occlusion query extension, which allow
+ time intervals to be polled asynchronously by the application.
+
+IP Status
+
+ No known IP claims.
+
+New Procedures and Functions
+
+ void GenQueriesANGLE(sizei n, uint *ids);
+ void DeleteQueriesANGLE(sizei n, const uint *ids);
+ boolean IsQueryANGLE(uint id);
+ void BeginQueryANGLE(enum target, uint id);
+ void EndQueryANGLE(enum target);
+ void QueryCounterANGLE(uint id, enum target);
+ void GetQueryivANGLE(enum target, enum pname, int *params);
+ void GetQueryObjectivANGLE(uint id, enum pname, int *params);
+ void GetQueryObjectuivANGLE(uint id, enum pname, uint *params);
+ void GetQueryObjecti64vANGLE(uint id, enum pname, int64 *params);
+ void GetQueryObjectui64vANGLE(uint id, enum pname, uint64 *params);
+
+New Tokens
+
+ Accepted by the <pname> parameter of GetQueryivANGLE:
+
+ QUERY_COUNTER_BITS_ANGLE 0x8864
+ CURRENT_QUERY_ANGLE 0x8865
+
+ Accepted by the <pname> parameter of GetQueryObjectivANGLE,
+ GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, and
+ GetQueryObjectui64vANGLE:
+
+ QUERY_RESULT_ANGLE 0x8866
+ QUERY_RESULT_AVAILABLE_ANGLE 0x8867
+
+ Accepted by the <target> parameter of BeginQueryANGLE, EndQueryANGLE, and
+ GetQueryivANGLE:
+
+ TIME_ELAPSED_ANGLE 0x88BF
+
+ Accepted by the <target> parameter of GetQueryivANGLE and
+ QueryCounterANGLE:
+
+ TIMESTAMP_ANGLE 0x8E28
+
+Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL ES Operation)
+
+ (Modify table 2.1, Correspondence of command suffix letters to GL argument)
+ Add two new types:
+
+ Letter Corresponding GL Type
+ ------ ---------------------
+ i64 int64ANGLE
+ ui64 uint64ANGLE
+
+ (Modify table 2.2, GL data types) Add two new types:
+
+ GL Type Minimum Bit Width Description
+ ------- ----------------- -----------------------------
+ int64ANGLE 64 Signed 2's complement integer
+ uint64ANGLE 64 Unsigned binary integer
+
+Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special Functions)
+
+ Add a new section 5.3 "Timer Queries":
+
+ "5.3 Timer Queries
+
+ Timer queries use query objects to track the amount of time needed to
+ fully complete a set of GL commands, or to determine the current time
+ of the GL.
+
+ Timer queries are associated with query objects. The command
+
+ void GenQueriesANGLE(sizei n, uint *ids);
+
+ returns <n> previously unused query object names in <ids>. These
+ names are marked as used, but no object is associated with them until
+ the first time they are used by BeginQueryANGLE. Query objects contain
+ one piece of state, an integer result value. This result value is
+ initialized to zero when the object is created. Any positive integer
+ except for zero (which is reserved for the GL) is a valid query
+ object name.
+
+ Query objects are deleted by calling
+
+ void DeleteQueriesANGLE(sizei n, const uint *ids);
+
+ <ids> contains <n> names of query objects to be deleted. After a
+ query object is deleted, its name is again unused. Unused names in
+ <ids> are silently ignored.
+ If an active query object is deleted its name immediately becomes unused,
+ but the underlying object is not deleted until it is no longer active.
+
+ A timer query can be started and finished by calling
+
+ void BeginQueryANGLE(enum target, uint id);
+ void EndQueryANGLE(enum target);
+
+ where <target> is TIME_ELAPSED_ANGLE. If BeginQueryANGLE is called
+ with an unused <id>, that name is marked as used and associated with
+ a new query object.
+
+ If BeginQueryANGLE is called with an <id> of zero, if the active query
+ object name for <target> is non-zero, if <id> is the name of an existing
+ query object whose type does not match <target>, or if <id> is the active
+ query object name for any query type, the error INVALID_OPERATION is
+ generated. If EndQueryANGLE is called while no query with the same target
+ is in progress, an INVALID_OPERATION error is generated.
+
+ When BeginQueryANGLE and EndQueryANGLE are called with a <target> of
+ TIME_ELAPSED_ANGLE, the GL prepares to start and stop the timer used for
+ timer queries. The timer is started or stopped when the effects from all
+ previous commands on the GL client and server state and the framebuffer
+ have been fully realized. The BeginQueryANGLE and EndQueryANGLE commands
+ may return before the timer is actually started or stopped. When the timer
+ query timer is finally stopped, the elapsed time (in nanoseconds) is
+ written to the corresponding query object as the query result value, and
+ the query result for that object is marked as available.
+
+ If the elapsed time overflows the number of bits, <n>, available to hold
+ elapsed time, its value becomes undefined. It is recommended, but not
+ required, that implementations handle this overflow case by saturating at
+ 2^n - 1.
+
+ The necessary state is a single bit indicating whether an timer
+ query is active, the identifier of the currently active timer
+ query, and a counter keeping track of the time that has passed.
+
+ When the command
+
+ void QueryCounterANGLE(uint id, enum target);
+
+ is called with <target> TIMESTAMP_ANGLE, the GL records the current time
+ into the corresponding query object. The time is recorded after all
+ previous commands on the GL client and server state and the framebuffer
+ have been fully realized. When the time is recorded, the query result for
+ that object is marked available. QueryCounterANGLE timer queries can be
+ used within a BeginQueryANGLE / EndQueryANGLE block where the <target> is
+ TIME_ELAPSED_ANGLE and it does not affect the result of that query object.
+ The error INVALID_OPERATION is generated if the <id> is already in use
+ within a BeginQueryANGLE/EndQueryANGLE block."
+
+Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and State
+Requests)
+
+ Add a new section 6.1.9 "Timer Queries":
+
+ "The command
+
+ boolean IsQueryANGLE(uint id);
+
+ returns TRUE if <id> is the name of a query object. If <id> is zero,
+ or if <id> is a non-zero value that is not the name of a query
+ object, IsQueryANGLE returns FALSE.
+
+ Information about a query target can be queried with the command
+
+ void GetQueryivANGLE(enum target, enum pname, int *params);
+
+ <target> identifies the query target and can be TIME_ELAPSED_ANGLE or
+ TIMESTAMP_ANGLE for timer queries.
+
+ If <pname> is CURRENT_QUERY_ANGLE, the name of the currently active query
+ for <target>, or zero if no query is active, will be placed in <params>.
+
+ If <pname> is QUERY_COUNTER_BITS_ANGLE, the implementation-dependent number
+ of bits used to hold the query result for <target> will be placed in
+ <params>. The number of query counter bits may be zero, in which case
+ the counter contains no useful information.
+
+ For timer queries (TIME_ELAPSED_ANGLE and TIMESTAMP_ANGLE), if the number
+ of bits is non-zero, the minimum number of bits allowed is 30 which
+ will allow at least 1 second of timing.
+
+ The state of a query object can be queried with the commands
+
+ void GetQueryObjectivANGLE(uint id, enum pname, int *params);
+ void GetQueryObjectuivANGLE(uint id, enum pname, uint *params);
+ void GetQueryObjecti64vANGLE(uint id, enum pname, int64 *params);
+ void GetQueryObjectui64vANGLE(uint id, enum pname, uint64 *params);
+
+ If <id> is not the name of a query object, or if the query object
+ named by <id> is currently active, then an INVALID_OPERATION error is
+ generated.
+
+ If <pname> is QUERY_RESULT_ANGLE, then the query object's result
+ value is returned as a single integer in <params>. If the value is so
+ large in magnitude that it cannot be represented with the requested type,
+ then the nearest value representable using the requested type is
+ returned. If the number of query counter bits for target is zero, then
+ the result is returned as a single integer with the value zero.
+
+ There may be an indeterminate delay before the above query returns. If
+ <pname> is QUERY_RESULT_AVAILABLE_ANGLE, FALSE is returned if such a delay
+ would be required; otherwise TRUE is returned. It must always be true
+ that if any query object returns a result available of TRUE, all queries
+ of the same type issued prior to that query must also return TRUE.
+
+ Querying the state for a given timer query forces that timer query to
+ complete within a finite amount of time.
+
+ If multiple queries are issued on the same target and id prior to
+ calling GetQueryObject[u]i[64]vANGLE, the result returned will always be
+ from the last query issued. The results from any queries before the
+ last one will be lost if the results are not retrieved before starting
+ a new query on the same <target> and <id>."
+
+Errors
+
+ The error INVALID_VALUE is generated if GenQueriesANGLE is called where
+ <n> is negative.
+
+ The error INVALID_VALUE is generated if DeleteQueriesANGLE is called
+ where <n> is negative.
+
+ The error INVALID_OPERATION is generated if BeginQueryANGLE is called
+ when a query of the given <target> is already active.
+
+ The error INVALID_OPERATION is generated if EndQueryANGLE is called
+ when a query of the given <target> is not active.
+
+ The error INVALID_OPERATION is generated if BeginQueryANGLE is called
+ where <id> is zero.
+
+ The error INVALID_OPERATION is generated if BeginQueryANGLE is called
+ where <id> is the name of a query currently in progress.
+
+ The error INVALID_OPERATION is generated if BeginQueryANGLE is called
+ where <id> is the name of an existing query object whose type does not
+ match <target>.
+
+ The error INVALID_ENUM is generated if BeginQueryANGLE or EndQueryANGLE
+ is called where <target> is not TIME_ELAPSED_ANGLE.
+
+ The error INVALID_ENUM is generated if GetQueryivANGLE is called where
+ <target> is not TIME_ELAPSED_ANGLE or TIMESTAMP_ANGLE.
+
+ The error INVALID_ENUM is generated if GetQueryivANGLE is called where
+ <pname> is not QUERY_COUNTER_BITS_ANGLE or CURRENT_QUERY_ANGLE.
+
+ The error INVALID_ENUM is generated if QueryCounterANGLE is called where
+ <target> is not TIMESTAMP_ANGLE.
+
+ The error INVALID_OPERATION is generated if QueryCounterANGLE is called
+ on a query object that is already in use inside a
+ BeginQueryANGLE/EndQueryANGLE.
+
+ The error INVALID_OPERATION is generated if GetQueryObjectivANGLE,
+ GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or
+ GetQueryObjectui64vANGLE is called where <id> is not the name of a query
+ object.
+
+ The error INVALID_OPERATION is generated if GetQueryObjectivANGLE,
+ GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or
+ GetQueryObjectui64vANGLE is called where <id> is the name of a currently
+ active query object.
+
+ The error INVALID_ENUM is generated if GetQueryObjectivANGLE,
+ GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or
+ GetQueryObjectui64vANGLE is called where <pname> is not
+ QUERY_RESULT_ANGLE or QUERY_RESULT_AVAILABLE_ANGLE.
+
+New State
+
+ (Add a new table 6.xx, "Query Operations")
+
+ Get Value Type Get Command Initial Value Description Sec
+ --------- ---- ----------- ------------- ----------- ------
+ - B - FALSE query active 5.3
+ CURRENT_QUERY_ANGLE Z+ GetQueryivANGLE 0 active query ID 5.3
+ QUERY_RESULT_ANGLE Z+ GetQueryObjectuivANGLE, 0 samples-passed count 5.3
+ GetQueryObjectui64vANGLE
+ QUERY_RESULT_AVAILABLE_ANGLE B GetQueryObjectivANGLE FALSE query result available 5.3
+
+New Implementation Dependent State
+
+ (Add the following entry to table 6.18):
+
+ Get Value Type Get Command Minimum Value Description Sec
+ -------------------------- ---- ----------- ------------- ---------------- ------
+ QUERY_COUNTER_BITS_ANGLE Z+ GetQueryivANGLE see 6.1.9 Number of bits in 6.1.9
+ query counter
+
+Examples
+
+ (1) Here is some rough sample code that demonstrates the intended usage
+ of this extension.
+
+ GLint queries[N];
+ GLint available = 0;
+ // timer queries can contain more than 32 bits of data, so always
+ // query them using the 64 bit types to avoid overflow
+ GLuint64ANGLE timeElapsed = 0;
+
+ // Create a query object.
+ glGenQueriesANGLE(N, queries);
+
+ // Start query 1
+ glBeginQueryANGLE(GL_TIME_ELAPSED_ANGLE, queries[0]);
+
+ // Draw object 1
+ ....
+
+ // End query 1
+ glEndQueryANGLE(GL_TIME_ELAPSED_ANGLE);
+
+ ...
+
+ // Start query N
+ glBeginQueryANGLE(GL_TIME_ELAPSED_ANGLE, queries[N-1]);
+
+ // Draw object N
+ ....
+
+ // End query N
+ glEndQueryANGLE(GL_TIME_ELAPSED_ANGLE);
+
+ // Wait for all results to become available
+ while (!available) {
+ glGetQueryObjectivANGLE(queries[N-1], GL_QUERY_RESULT_AVAILABLE_ANGLE, &available);
+ }
+
+ for (i = 0; i < N; i++) {
+ // See how much time the rendering of object i took in nanoseconds.
+ glGetQueryObjectui64vANGLE(queries[i], GL_QUERY_RESULT_ANGLE, &timeElapsed);
+
+ // Do something useful with the time. Note that care should be
+ // taken to use all significant bits of the result, not just the
+ // least significant 32 bits.
+ AdjustObjectLODBasedOnDrawTime(i, timeElapsed);
+ }
+
+ This example is sub-optimal in that it stalls at the end of every
+ frame to wait for query results. Ideally, the collection of results
+ would be delayed one frame to minimize the amount of time spent
+ waiting for the GPU to finish rendering.
+
+ (2) This example is basically the same as the example above but uses
+ QueryCounter instead.
+
+ GLint queries[N+1];
+ GLint available = 0;
+ // timer queries can contain more than 32 bits of data, so always
+ // query them using the 64 bit types to avoid overflow
+ GLuint64ANGLE timeStart, timeEnd, timeElapsed = 0;
+
+ // Create a query object.
+ glGenQueriesANGLE(N+1, queries);
+
+ // Query current timestamp 1
+ glQueryCounterANGLE(queries[0], GL_TIMESTAMP_ANGLE);
+
+ // Draw object 1
+ ....
+
+ // Query current timestamp N
+ glQueryCounterANGLE(queries[N-1], GL_TIMESTAMP_ANGLE);
+
+ // Draw object N
+ ....
+
+ // Query current timestamp N+1
+ glQueryCounterANGLE(queries[N], GL_TIMESTAMP_ANGLE);
+
+ // Wait for all results to become available
+ while (!available) {
+ glGetQueryObjectivANGLE(queries[N], GL_QUERY_RESULT_AVAILABLE_ANGLE, &available);
+ }
+
+ for (i = 0; i < N; i++) {
+ // See how much time the rendering of object i took in nanoseconds.
+ glGetQueryObjectui64vANGLE(queries[i], GL_QUERY_RESULT_ANGLE, &timeStart);
+ glGetQueryObjectui64vANGLE(queries[i+1], GL_QUERY_RESULT_ANGLE, &timeEnd);
+ timeElapsed = timeEnd - timeStart;
+
+ // Do something useful with the time. Note that care should be
+ // taken to use all significant bits of the result, not just the
+ // least significant 32 bits.
+ AdjustObjectLODBasedOnDrawTime(i, timeElapsed);
+ }
+
+Issues from EXT_timer_query
+
+ (1) What time interval is being measured?
+
+ RESOLVED: The timer starts when all commands prior to BeginQuery() have
+ been fully executed. At that point, everything that should be drawn by
+ those commands has been written to the framebuffer. The timer stops
+ when all commands prior to EndQuery() have been fully executed.
+
+ (2) What unit of time will time intervals be returned in?
+
+ RESOLVED: Nanoseconds (10^-9 seconds). This unit of measurement allows
+ for reasonably accurate timing of even small blocks of rendering
+ commands. The granularity of the timer is implementation-dependent. A
+ 32-bit query counter can express intervals of up to approximately 4
+ seconds.
+
+ (3) What should be the minimum number of counter bits for timer queries?
+
+ RESOLVED: 30 bits, which will allow timing sections that take up to 1
+ second to render.
+
+ (4) How are counter results of more than 32 bits returned?
+
+ RESOLVED: Via two new datatypes, int64ANGLE and uint64ANGLE, and their
+ corresponding GetQueryObject entry points. These types hold integer
+ values and have a minimum bit width of 64.
+
+ (5) Should the extension measure total time elapsed between the full
+ completion of the BeginQuery and EndQuery commands, or just time
+ spent in the graphics library?
+
+ RESOLVED: This extension will measure the total time elapsed between
+ the full completion of these commands. Future extensions may implement
+ a query to determine time elapsed at different stages of the graphics
+ pipeline.
+
+ (6) If multiple query types are supported, can multiple query types be
+ active simultaneously?
+
+ RESOLVED: Yes; an application may perform a timer query and another
+ type of query simultaneously. An application can not perform multiple
+ timer queries or multiple queries of other types simultaneously. An
+ application also can not use the same query object for another query
+ and a timer query simultaneously.
+
+ (7) Do query objects have a query type permanently associated with them?
+
+ RESOLVED: No. A single query object can be used to perform different
+ types of queries, but not at the same time.
+
+ Having a fixed type for each query object simplifies some aspects of the
+ implementation -- not having to deal with queries with different result
+ sizes, for example. It would also mean that BeginQuery() with a query
+ object of the "wrong" type would result in an INVALID_OPERATION error.
+
+ UPDATE: This resolution was relevant for EXT_timer_query and OpenGL 2.0.
+ Since EXT_transform_feedback has since been incorporated into the core,
+ the resolution is that BeginQuery will generate error INVALID_OPERATION
+ if <id> represents a query object of a different type.
+
+ (8) How predictable/repeatable are the results returned by the timer
+ query?
+
+ RESOLVED: In general, the amount of time needed to render the same
+ primitives should be fairly constant. But there may be many other
+ system issues (e.g., context switching on the CPU and GPU, virtual
+ memory page faults, memory cache behavior on the CPU and GPU) that can
+ cause times to vary wildly.
+
+ Note that modern GPUs are generally highly pipelined, and may be
+ processing different primitives in different pipeline stages
+ simultaneously. In this extension, the timers start and stop when the
+ BeginQuery/EndQuery commands reach the bottom of the rendering pipeline.
+ What that means is that by the time the timer starts, the GL driver on
+ the CPU may have started work on GL commands issued after BeginQuery,
+ and the higher pipeline stages (e.g., vertex transformation) may have
+ started as well.
+
+ (9) What should the new 64 bit integer type be called?
+
+ RESOLVED: The new types will be called GLint64ANGLE/GLuint64ANGLE. The new
+ command suffixes will be i64 and ui64. These names clearly convey the
+ minimum size of the types. These types are similar to the C99 standard
+ type int_least64_t, but we use names similar to the C99 optional type
+ int64_t for simplicity.
+
+Issues from ARB_timer_query
+
+ (10) What about tile-based implementations? The effects of a command are
+ not complete until the frame is completely rendered. Timing recorded
+ before the frame is complete may not be what developers expect. Also
+ the amount of time needed to render the same primitives is not
+ consistent, which conflicts with issue (8) above. The time depends on
+ how early or late in the scene it is placed.
+
+ RESOLVED: The current language supports tile-based rendering okay as it
+ is written. Developers are warned that using timers on tile-based
+ implementation may not produce results they expect since rendering is not
+ done in a linear order. Timing results are calculated when the frame is
+ completed and may depend on how early or late in the scene it is placed.
+
+ (11) Can the GL implementation use different clocks to implement the
+ TIME_ELAPSED and TIMESTAMP queries?
+
+ RESOLVED: Yes, the implemenation can use different internal clocks to
+ implement TIME_ELAPSED and TIMESTAMP. If different clocks are
+ used it is possible there is a slight discrepancy when comparing queries
+ made from TIME_ELAPSED and TIMESTAMP; they may have slight
+ differences when both are used to measure the same sequence. However, this
+ is unlikely to affect real applications since comparing the two queries is
+ not expected to be useful.
+
+Issues
+
+ (12) What should we call this extension?
+
+ RESOLVED: ANGLE_timer_query
+
+ (13) Why is this done as a separate extension instead of just supporting
+ ARB_timer_query?
+
+ ARB_timer_query is written against OpenGL 3.2, which includes a lot of
+ the required support for dealing with query objects. None of these
+ functions or tokens exist in OpenGL ES, and as such have to be added in
+ this specification.
+
+ (14) How does this extension differ from ARB_timer_query?
+
+ This extension contains most ARB_timer_query behavior unchanged as well
+ as a subset of the query support required to use it from the core
+ OpenGL 3.2 spec. It omits the glGetInteger(TIMESTAMP) functionality used to
+ query the current time on the GPU, but the behavior for all remaining
+ functionality taken from ARB_timer_query is the same.
+
+ (15) Are query objects shareable between multiple contexts?
+
+ RESOLVED: No. Query objects are lightweight and we normally share
+ large data across contexts. Also, being able to share query objects
+ across contexts is not particularly useful. In order to do the async
+ query across contexts, a query on one context would have to be finished
+ before the other context could query it.
+
+Revision History
+
+ Revision 1, 2011/04/28
+ - copied from revision 9 of ARB_timer_query and revision 7 of
+ ARB_occlusion_query
+ - removed language that was clearly not relevant to ES2
+ - rebased changes against the OpenGL ES 2.0 specification
diff --git a/src/third_party/angle/extensions/ANGLE_webgl_compatibility.txt b/src/third_party/angle/extensions/ANGLE_webgl_compatibility.txt
new file mode 100644
index 0000000..cc01313
--- /dev/null
+++ b/src/third_party/angle/extensions/ANGLE_webgl_compatibility.txt
@@ -0,0 +1,81 @@
+Name
+
+ ANGLE_webgl_compatibility
+
+Name Strings
+
+ GL_ANGLE_webgl_compatibility
+
+Contributors
+
+ Geoff Lang
+
+Contact
+
+ Geoff Lang (geofflang 'at' google.com)
+
+Notice
+
+ Copyright (c) 2016 The Khronos Group Inc. Copyright terms at
+ http://www.khronos.org/registry/speccopyright.html
+
+Status
+
+ Draft
+
+Version
+
+ Version 2, November 28, 2016
+
+Number
+
+ OpenGL ES Extension #??
+
+Dependencies
+
+ Requires OpenGL ES 2.0
+
+ Written against the OpenGL ES 2.0 specification.
+
+ Interacts with EGL_ANGLE_create_context_webgl_compatibility (or equivalent)
+ extension.
+
+Overview
+
+ With this extension enabled, the OpenGL ES context will have additional
+ features and validation to be compatible with the WebGL specification.
+
+New Procedures and Functions
+
+ None
+
+
+New Tokens
+
+ None
+
+Additions to the OpenGL ES Specification
+
+ Additional validation will be performed according to the the sections of
+ the WebGL specification entitled "Differences Between WebGL and OpenGL ES
+ 2.0" and "Differences Between WebGL and OpenGL ES 3.0".
+
+New State
+
+ None
+
+Conformance Tests
+
+ TBD
+
+Issues
+
+ None
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- ----------------------------------------
+ 1 Sept 16, 2016 geofflang Initial version
+ 2 Nov 28, 2016 geofflang Break the extension requests into a
+ separate extension.
diff --git a/src/third_party/angle/extensions/CHROMIUM_bind_generates_resource.txt b/src/third_party/angle/extensions/CHROMIUM_bind_generates_resource.txt
new file mode 100644
index 0000000..498acad
--- /dev/null
+++ b/src/third_party/angle/extensions/CHROMIUM_bind_generates_resource.txt
@@ -0,0 +1,118 @@
+Name
+
+ CHROMIUM_bind_generates_resource
+
+Name Strings
+
+ GL_CHROMIUM_bind_generates_resource
+
+Contributors
+
+ Geoff Lang
+
+Contact
+
+ Geoff Lang (geofflang 'at' google.com)
+
+Notice
+
+ Copyright (c) 2016 The Khronos Group Inc. Copyright terms at
+ http://www.khronos.org/registry/speccopyright.html
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, September 19, 2016
+
+Number
+
+ OpenGL ES Extension #??
+
+Dependencies
+
+ Requires OpenGL ES 2.0
+
+ Written against the OpenGL ES 2.0 specification.
+
+Overview
+
+ This extension allows the user to control the behaviour when binding an
+ object that has not been generated. This functionality is useful to
+ notify the user of potential use-after-free errors or support other APIs
+ such as WebGL on top of an OpenGL ES context.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <cap> parameter to IsEnabled and the <pname> parameter to
+ GetBooleanv, GetIntegerv, GetFloatv, and GetInteger64v:
+
+ BIND_GENERATES_RESOURCE_CHROMIUM 0x9244
+
+Additions to the OpenGL ES Specification
+
+ Add to the end of Section 2.9 "Buffer Objects":
+
+ If BIND_GENERATES_RESOURCE_CHROMIUM is false, BindBuffer fails and an
+ INVALID_OPERATION error is generated if buffer is not zero or a name
+ returned from a previous call to GenBuffers, or if such a name has since
+ been deleted with DeleteBuffers.
+
+ Add to the end of Section 3.7.13 "Texture Objects":
+
+ If BIND_GENERATES_RESOURCE_CHROMIUM is false, BindTexture fails and an
+ INVALID_OPERATION error is generated if texture is not zero or a name
+ returned from a previous call to GenTextures, or if such a name has since
+ been deleted with DeleteTextures.
+
+ Add to the end of Section 4.4.1 "Binding and Managing Framebuffer Objects":
+
+ If BIND_GENERATES_RESOURCE_CHROMIUM is false, BindFramebuffer fails and an
+ INVALID_OPERATION error is generated if framebuffer is not zero or a name
+ returned from a previous call to GenFramebuffers, or if such a name has
+ since been deleted with DeleteFramebuffers.
+
+ Add to the end of Section 4.4.3 "Renderbuffer Objects":
+
+ If BIND_GENERATES_RESOURCE_CHROMIUM is false, BindRenderbuffer fails and an
+ INVALID_OPERATION error is generated if renderbuffer is not zero or a name
+ returned from a previous call to GenRenderbuffers, or if such a name has
+ since been deleted with DeleteRenderbuffers.
+
+New State
+
+ Modify Table 6.22, Miscellaneous
+
+ Add:
+
+ Initial
+ Get Value Type Get Command Value Description
+ ----------------------- ---- ----------- ------- --------------
+ BIND_GENERATES_RESOURCE_CHROMIUM B IsEnabled TRUE Bind generates
+ new resources
+
+Conformance Tests
+
+ TBD
+
+Issues
+
+ (1) Should the BIND_GENERATES_RESOURCE_CHROMIUM state be enabled at context
+ creation time or dynamically through the Enable and Disable functions?
+
+ RESOLOVED: BIND_GENERATES_RESOURCE_CHROMIUM is initialized by a context
+ creation attribute and cannot be modified. One of the major use cases of
+ this extension is to back WebGL contexts and the end user should not be
+ allowed to modify this state.
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- ----------------------------------------
+ 1 Sept 19, 2016 geofflang Initial version
diff --git a/src/third_party/angle/extensions/CHROMIUM_bind_uniform_location.txt b/src/third_party/angle/extensions/CHROMIUM_bind_uniform_location.txt
new file mode 100644
index 0000000..b08c4c6
--- /dev/null
+++ b/src/third_party/angle/extensions/CHROMIUM_bind_uniform_location.txt
@@ -0,0 +1,141 @@
+Name
+
+ CHROMIUM_bind_uniform_location
+
+Name Strings
+
+ GL_CHROMIUM_bind_uniform_location
+
+Version
+
+ Last Modifed Date: September 8, 2015
+
+Dependencies
+
+ OpenGL ES 2.0 is required.
+
+Overview
+
+ This extension is simlar to glBindAttribLocation but instead
+ lets you choose a location for a uniform. This allows you
+ to not have to query the locations of uniforms.
+
+ This allows the client program to know the locations of uniforms
+ without having to wait for shaders to compile or GLSL programs to
+ link to query the locations and therefore have no blocking calls
+ when initializing programs.
+
+Issues
+
+ If a uniform is an array you can only call glBindUniformLocation
+ for the location of the first element. Other elements' locations
+ must be queried if you need them. Often this is not an issue
+ because you can set all the elements with a single gl call from
+ the first location.
+
+ Good Example:
+
+ --shader--
+ uniform float u_someArray[4];
+
+ --C--
+ GLint location = 123;
+ glBindUniformLocation(program, location, "u_someArray");
+ glLinkProgram(program);
+ glUseProgram(program);
+
+ // set all 4 floats in u_someArray
+ float values[] = { 0.1f, 0.2f, 0.3f, 0.4f, };
+ glUniform1fv(location, 4, values);
+
+ Bad example 1:
+
+ GLint location = 123;
+ glBindUniformLocation(program, location, "u_someArray");
+ glLinkProgram(program);
+ glUseProgram(program);
+
+ // set floats in u_someArray one at a time
+ glUniform1f(location, 0.1f);
+ glUniform1f(location + 1, 0.2f); // ERROR! math not allowed on locations
+
+ Bad example 2:
+
+ GLint location0 = 123;
+ GLint location1 = 124;
+ glBindUniformLocation(program, location0, "u_someArray[0]");
+ glBindUniformLocation(program, location1, "u_someArray[1]"); // ERROR!
+ // not allowed to assign locations to array elements
+
+ If you need to set individual elements of a uniform array you must query the
+ location of the each element you wish to set.
+
+ If a uniform has its location explicitly set within the shader text and a
+ different location set via the API, the assignment in the shader text is
+ used.
+
+ If the location of a statically used uniform set via the API conflicts with
+ the location of a different uniform set in the shader text, linking must
+ fail.
+
+New Tokens
+
+ None
+
+New Procedures and Functions
+
+ void BindUniformLocationCHROMIUM (GLuint program, GLint location,
+ const GLhchar* name);
+
+ specifes that the uniform variable named <name> in program <program>
+ should be bound to uniform location <location> when the program is next
+ linked. If <name> was bound previously, its assigned binding is replaced
+ with <location>. <name> must be a null terminated string. The error
+ INVALID_VALUE is generated if <location> is equal or greater than
+
+ (MAX_VERTEX_UNIFORM_VECTORS + MAX_FRAGMENT_UNIFORM_VECTORS) * 4
+
+ or less than 0. BindUniformLocation has no effect until the program is
+ linked. In particular, it doesn't modify the bindings of active uniforms
+ variables in a program that has already been linked.
+
+ The error INVALID_OPERATION is generated if name starts with the reserved
+ "gl_" prefix. The error INVALID_VALUE is generated if name ends with
+ an array element expression other than "[0]".
+
+ When a program is linked, any active uniforms without a binding specified
+ through BindUniformLocation will be automatically be bound to locations by
+ the GL. Such bindings can be queried using the command
+ GetUniformLocation.
+
+ BindUniformLocation may be issued before any shader objects are attached
+ to a program object. Hence it is allowed to bind any name (except a name
+ starting with "gl_") to an index, including a name that is never used as a
+ uniform in any shader object. Assigned bindings for uniform variables
+ that do not exist or are not active are ignored. Using such bindings
+ behaves as if passed location was -1.
+
+ It is possible for an application to bind more than one uniform name to
+ the same location. This is referred to as aliasing. This will only work
+ if only one of the aliased uniforms is active in the executable program,
+ or if no path through the shader consumes more than one uniform of a set
+ of uniforms aliased to the same location. If two statically used uniforms
+ in a program are bound to the name location, link must fail.
+
+Errors
+
+ None.
+
+New State
+
+ None.
+
+Revision History
+
+ 7/20/2012 Documented the extension
+ 9/8/2015 Require program link to fail if two statically used uniforms
+ are bound to the same location.
+ 11/6/2015 Require inactive and non-existing, bound uniform locations
+ to behave like location -1.
+ 3/9/2017 Locations set in the shader override ones set by the binding
+ API.
diff --git a/src/third_party/angle/extensions/CHROMIUM_compressed_copy_texture.txt b/src/third_party/angle/extensions/CHROMIUM_compressed_copy_texture.txt
new file mode 100644
index 0000000..a2cfb2c
--- /dev/null
+++ b/src/third_party/angle/extensions/CHROMIUM_compressed_copy_texture.txt
@@ -0,0 +1,88 @@
+Name
+
+ CHROMIUM_copy_compressed_texture
+
+Name Strings
+
+ GL_CHROMIUM_copy_compressed_texture
+
+Version
+
+ Last Modifed Date: August 5, 2015
+
+Dependencies
+
+ OpenGL ES 2.0 is required.
+
+ GL_AMD_compressed_ATC_texture, GL_ATI_texture_compression_atitc,
+ GL_EXT_texture_compression_dxt1, GL_ANGLE_texture_compression_dxt5,
+ GL_EXT_texture_compression_s3tc and GL_OES_compressed_ETC1_RGB8_texture
+ affects the definition of this extension.
+
+Overview
+
+ This extension provides functionality for copying compressed textures. It
+ adds a new function glCompressedCopyTextureCHROMIUM that works similarily
+ to glCopyTextureCHROMIUM, but for compressed textures.
+
+ Which compressed texture formats that this extension supports depends on
+ the supported texture compression formats of the host GPU.
+
+Issues
+
+ glCompressedCopyTextureCHROMIUM will first try to copy into a compressed
+ texture of the same format as the source texture. If unsucessful, the
+ destination texture format will be changed to GL_RGBA and the texture will
+ be stored uncompressed.
+
+New Procedures and Functions
+
+ The command
+
+ void glCompressedCopyTextureCHROMIUM (GLuint source_id, GLuint dest_id)
+
+ Copies the contents of a compressed texture referred to by <source_id> to
+ <dest_id> texture.
+
+ Texture level 0 is copied from the source image to level 0 of the
+ destination texture.
+
+ The internal format of the source texture must be one of the following
+ symbolic constants: GL_ATC_RGB_AMD, GL_ATC_RGBA_INTERPOLATED_ALPHA_AMD,
+ GL_COMPRESSED_RGB_S3TC_DXT1_EXT, GL_COMPRESSED_RGBA_S3TC_DXT5_EXT,
+ GL_ETC1_RGB8_OES
+
+ The destination texture will be created or replaced with the same internal
+ format as the source texture.
+
+ INVALID_OPERATION is generated if internal format of source texture is not
+ one of the valid formats described above.
+
+ INVALID_OPERATION is generated if destination texture is immutable.
+
+ INVALID_VALUE is generated if <source_id> or <dest_id> are not valid texture
+ objects.
+
+ INVALID_VALUE is generated if textures corresponding to <dest_id> have not
+ been bound as GL_TEXTURE_2D object.
+
+ INVALID_VALUE is generated if level 0 of the source texture is not defined.
+
+Errors
+
+ None.
+
+New Tokens
+
+ None.
+
+New State
+
+ None.
+
+Revision History
+
+ 15/6/2015 Documented the extension.
+ 5/8/2015 Added glCompressedCopySubTextureCHROMIUM.
+ 1/6/2016 Remove glCompressedCopySubTextureCHROMIUM.
+ 1/8/2016 Remove <target> argument.
diff --git a/src/third_party/angle/extensions/CHROMIUM_copy_texture.txt b/src/third_party/angle/extensions/CHROMIUM_copy_texture.txt
new file mode 100644
index 0000000..5e7fad8
--- /dev/null
+++ b/src/third_party/angle/extensions/CHROMIUM_copy_texture.txt
@@ -0,0 +1,264 @@
+Name
+
+ CHROMIUM_copy_texture
+
+Name Strings
+
+ GL_CHROMIUM_copy_texture
+
+Version
+
+ Last Modifed Date: March 24, 2017
+
+Dependencies
+
+ OpenGL ES 2.0 or OpenGL ES 3.0 is required.
+
+ EXT_texture_format_BGRA8888 affects the definition of this extension.
+ ARB_texture_rg affects the definition of this extension.
+ CHROMIUM_ycbcr_422_image affects the definition of this extension.
+
+Overview
+
+ This extension expands on the functionality provided by the
+ glCopyTexImage2D command. A new function is exported,
+ glCopyTextureCHROMIUM, that performs the same copy operation as
+ glCopyTexImage2D.
+
+ The extension also supports copying BGRA textures and copying
+ EXTERNAL_OES texture to BGRA texture, which is not explicitly
+ granted by EXT_texture_format_BGRA8888.
+
+New Procedures and Functions
+
+ void CopyTextureCHROMIUM(uint sourceId,
+ int sourceLevel,
+ enum destTarget,
+ uint destId,
+ int destLevel,
+ int internalFormat,
+ enum destType,
+ boolean unpackFlipY,
+ boolean unpackPremultiplyAlpha,
+ boolean unpackUnmultiplyAlpha)
+
+
+ void CopySubTextureCHROMIUM(uint sourceId,
+ int sourceLevel,
+ enum destTarget,
+ uint destId,
+ int destLevel,
+ int xoffset,
+ int yoffset,
+ int x,
+ int y,
+ sizei width,
+ sizei height,
+ boolean unpackFlipY,
+ boolean unpackPremultiplyAlpha,
+ boolean unpackUnmultiplyAlpha)
+
+Additions to the OpenGL ES 2.0 Specification
+
+ The command
+
+ CopyTextureCHROMIUM
+
+ Copies the contents of <sourceLevel> level of <sourceId> texture to
+ <destLevel> level and <destTarget> target of <destId> texture.
+
+ <destTarget> must be TEXTURE_2D,
+ 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, TEXTURE_CUBE_MAP_NEGATIVE_Z,
+ TEXTURE_RECTANGLE_ARB.
+
+ The internal format of the destination texture is converted to that
+ specified by <internalFormat>.
+
+ When source texture doens't contain a superset of the component
+ required by <internalFormat>, fill the components by following rules.
+
+ source format color components
+ ----------------------------------------
+ ALPHA (0, 0, 0, A)
+ RED (R, 0, 0, 1)
+ LUMINANCE (L, L, L, 1)
+ LUMINANCE_ALPHA (L, L, L, A)
+ RGB (R, G, B, 1)
+ RGB8 (R, G, B, 1)
+ RGBA (R, G, B, A)
+ RGBA8 (R, G, B, A)
+ BGRA_EXT (R, G, B, A)
+ BGRA8_EXT (R, G, B, A)
+ RGB_YCBCR_420V_CHROMIUM (R, G, B, 1)
+ RGB_YCBCR_422_CHROMIUM (R, G, B, 1)
+
+ The format type of the destination texture is converted to that specified
+ by <destType>.
+
+ If <flipY> is true, vertically flip texture image data.
+
+ If <unpackPremultiplyAlpha> and <unpackUnmultiplyAlpha> are true,
+ no alpha processing occurs. This is the equivalent of having neither flag
+ set.
+
+ When <sourceId> refers to a stream texture, the texture matrix will be
+ applied as part of the copy operation.
+
+ INVALID_OPERATION is generated if <internalFormat> is not one of the
+ formats in Table 1.0.
+
+ INVALID_OPERATION is generated if the internal format of <sourceId> is not
+ one of formats in Table 1.1.
+
+ INVALID_VALUE is generated if <sourceId> or <destId> are not valid texture
+ objects.
+
+ INVALID_ENUM is generated if <destTarget> is not one of the valid targets
+ described above.
+
+ INVALID_OPERATION is generated if the bound target of destination texture
+ does not match <target>.
+
+ INVALID_VALUE is generated if textures corresponding to <destId> have not
+ been bound as TEXTURE_2D, TEXTURE_CUBE_MAP, or
+ TEXTURE_RECTANGLE_ARB objects.
+
+ INVALID_VALUE is generated if textures corresponding to <sourceId> have not
+ been bound as TEXTURE_2D, TEXTURE_RECTANGLE_ARB or
+ TEXTURE_EXTERNAL_OES objects.
+
+ INVALID_VALUE is generated if <sourceLevel> is not 0 for ES 2.0, or if
+ <sourceLevel> or <destLevel> is less than 0 for ES 3.0.
+
+ INVALID_VALUE is generated if <sourceLevel> of the source texture is not
+ defined.
+
+ The command
+
+ CopySubTextureCHROMIUM
+
+ Copies the sub contents of texture referred to by <sourceId> to <destId>
+ texture without redefining <destId> texture.
+
+ See CopyTextureCHROMIUM for the interpretation of the <destTarget>,
+ <sourceLevel>, <destLevel>, <flipY>, <premultiplyAlpha>, and
+ <unmultiplyAlpha> arguments.
+
+ <xoffset> and <yoffset> specify a texel offset in the x and y direction
+ respectively within the destination texture.
+
+ <x> and <y> specify specify a texel offset in the x and y direction
+ respectively within the source texture.
+
+ <width> specifies the width of the texture subimage.
+
+ <height> specifies the width of the texture subimage.
+
+ INVALID_VALUE is generated if either <sourceId> texture or <destId>
+ texture is not defined.
+
+ INVALID_OPERATION is generated if the internal format of <sourceId> or
+ <destId> is not one of formats in Table 1.1.
+
+ INVALID_OPERATION is generated if the destination texture array has not
+ been defined.
+
+ INVALID_VALUE is generated if <destId> texture is not bound as
+ TEXTURE_2D or TEXTURE_RECTANGLE_ARB.
+
+ INVALID_VALUE is generated if level 0 of the source texture or
+ the destination texture is not defined.
+
+ INVALID_VALUE is generated if (<xoffset> + <width>) > destWidth,
+ or (<yoffset> + <height>) > destHeight.
+
+ Table 1.0 Valid internal formats for CopyTextureCHROMIUM:
+
+ <internalFormat>
+ ---------------
+ RGB
+ RGBA
+ RGB8
+ RGBA8
+ BGRA_EXT
+ BGRA8_EXT,
+ SRGB_EXT
+ SRGB_ALPHA_EXT
+ R8
+ R8UI
+ RG8
+ RG8UI
+ SRGB8
+ RGB565
+ RGB8UI
+ SRGB8_ALPHA8
+ RGB5_A1
+ RGBA4
+ RGBA4
+ RGBA8UI
+ RGB9_E5
+ R16F
+ R32F
+ RG16F
+ RG32F
+ RGB16F
+ RGB32F
+ RGBA16F
+ RGBA32F
+ R11F_G11F_B10F
+
+ Table 1.1 Valid source texture internal formats for CopyTextureCHROMIUM and
+ source and destination formats for CopySubTextureCHROMIUM:
+
+ internal format
+ ---------------
+ RED
+ ALPHA
+ LUMINANCE
+ LUMINANCE_ALPHA
+ RGB
+ RGBA
+ RGB8
+ RGBA8
+ BGRA_EXT
+ BGRA8_EXT
+ RGB_YCBCR_420V_CHROMIUM
+ RGB_YCBCR_422_CHROMIUM.
+
+Dependencies on ARB_texture_rg
+
+ If ARB_texture_rg is not supported:
+ * delete any reference to the R8 format.
+
+Dependencies on CHROMIUM_ycbcr_422_image
+
+ If CHROMIUM_ycbcr_422_image is not supported:
+ * delete any reference to the RGB_YCBCR_422_CHROMIUM format.
+
+Errors
+
+ None.
+
+New Tokens
+
+ None.
+
+New State
+
+ None.
+
+Revision History
+
+ 8/1/2011 Documented the extension
+ 7/4/2013 Add a new parameter dest_type to glCopyTextureCHROMIUM()
+ 16/7/2014 Add TEXTURE_RECTANGLE_ARB as valid source_id target
+ 19/6/2015 Add arguments unpack_flip_y, unpack_premultiply_alpha, and
+ unpack_unmultiply_alpha to both commands.
+ 4/1/2016 Removed the argument target.
+ 4/1/2016 Added TEXTURE_RECTANGLE_ARB as valid dest_id target.
+ 19/12/2016 Supported more ES 3.0 formats.
+ 18/1/2017 Supported source_level and dest_level.
+ 19/1/2017 Added TEXTURE_CUBE_MAP as valid dest_id target.
+ 24/3/2017 Clean up naming and move formats into tables.
diff --git a/src/third_party/angle/extensions/CHROMIUM_sync_query.txt b/src/third_party/angle/extensions/CHROMIUM_sync_query.txt
new file mode 100644
index 0000000..98763d0
--- /dev/null
+++ b/src/third_party/angle/extensions/CHROMIUM_sync_query.txt
@@ -0,0 +1,53 @@
+Name
+
+ CHROMIUM_sync_query
+
+Name Strings
+
+ GL_CHROMIUM_sync_query
+
+Version
+
+ Last Modifed Date: April 15, 2014
+
+Dependencies
+
+ OpenGL ES 2.0 is required.
+
+ EXT_occlusion_query_boolean is required.
+
+Overview
+
+ This extension provides a query mechanism that allow for synchronization
+ between the host CPU and the GPU, which may be accessing the same
+ resources (typically memory).
+
+ This extension is useful in conjunction with CHROMIUM_map_image to
+ determine when it is safe to access a mapped image. Once the result of
+ a COMMANDS_COMPLETED_CHROMIUM query is available, all drawing commands
+ issued before the query must have finished. This ensures that the memory
+ corresponding to the issued commands can be safely modified (assuming no
+ other outstanding drawing commands are issued subsequent to the query).
+
+New Procedures and Functions
+
+ None.
+
+Errors
+
+ None.
+
+New Tokens
+
+ Accepted by the <target> parameter of BeginQueryEXT, EndQueryEXT,
+ and GetQueryivEXT:
+
+ COMMANDS_COMPLETED_CHROMIUM 0x84F7
+
+New State
+
+ None.
+
+Revision History
+
+ 4/15/2014 Documented the extension
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_create_context_client_arrays.txt b/src/third_party/angle/extensions/EGL_ANGLE_create_context_client_arrays.txt
new file mode 100644
index 0000000..994695a
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_create_context_client_arrays.txt
@@ -0,0 +1,87 @@
+Name
+
+ ANGLE_create_context_client_arrays
+
+Name Strings
+
+ EGL_ANGLE_create_context_client_arrays
+
+Contributors
+
+ Geoff Lang
+
+Contacts
+
+ Geoff Lang (geofflang 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, February 13, 2016
+
+Number
+
+ EGL Extension #??
+
+Dependencies
+
+ Requires EGL 1.4.
+
+ Written against the EGL 1.4 specification.
+
+ An OpenGL ES implementation supporting GL_ANGLE_client_arrays or equivalent
+ functionality is required.
+
+Overview
+
+ This extension allows the creation of an OpenGL or OpenGL ES context that
+ allows or disallows drawing with client-side vertex or index data.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as an attribute name in the <*attrib_list> argument to
+ eglCreateContext:
+
+ EGL_CONTEXT_CLIENT_ARRAYS_ENABLED_ANGLE 0x3452
+
+Additions to the EGL 1.4 Specification
+
+ Add the following to section 3.7.1 "Creating Rendering Contexts":
+
+ EGL_CONTEXT_CLIENT_ARRAYS_ENABLED_ANGLE indicates whether the context
+ should be created with the GL_CLIENT_ARRAYS_ANGLE state initialized to
+ GL_TRUE or GL_FALSE. The default value of
+ EGL_CONTEXT_CLIENT_ARRAYS_ENABLED_ANGLE is EGL_FALSE.
+
+Errors
+
+ None
+
+New State
+
+ None
+
+Conformance Tests
+
+ TBD
+
+Issues
+
+ None
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- ----------------------------------------
+ 1 Feb 13, 2016 geofflang Initial version
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_create_context_robust_resource_initialization.txt b/src/third_party/angle/extensions/EGL_ANGLE_create_context_robust_resource_initialization.txt
new file mode 100644
index 0000000..7714774
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_create_context_robust_resource_initialization.txt
@@ -0,0 +1,81 @@
+Name
+
+ EGL_ANGLE_create_context_robust_resource_initialization.txt
+
+Name Strings
+
+ EGL_ANGLE_create_context_robust_resource_initialization
+
+Contributors
+
+ Geoff Lang, Google
+ Ken Russell, Google
+
+Contacts
+
+ Shannon Woods, Google (shannonwoods 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, January 7, 2015
+
+Number
+
+ EGL Extension TBD
+
+Dependencies
+
+ This extension is written against the wording of the EGL 1.5
+ specification.
+
+ An OpenGL ES implementation supporting ANGLE_robust_resource_initialization
+ or an implementation supporting equivalent functionality is required.
+
+Overview
+
+ This extension allows creating an OpenGL ES context supporting
+ robust resource initialization.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as an attribute name in the <*attrib_list> argument to
+ eglCreateContext:
+
+ EGL_CONTEXT_ROBUST_RESOURCE_INITIALIZATION_ANGLE 0x320F
+
+Additions to the EGL 1.5 Specification
+
+ Add a new section entitled "OpenGL ES Robust Resource Initialization"
+ to section 3.7.1:
+
+ "If the attribute EGL_CONTEXT_ROBUST_RESOURCE_INITIALIZATION_ANGLE
+ is set to EGL_TRUE, a context supporting <robust resource initialization>
+ will be created. OpenGL ES contexts must support the
+ ANGLE_robust_resource_initialization extension, or equivalent core API
+ functionality.
+ This attribute is supported only for OpenGL ES contexts. If the
+ implementation does not support robust resource initialization,
+ context creation will fail.
+ The default value of EGL_CONTEXT_ROBUST_RESOURCE_INITIALIZATION_ANGLE
+ is EGL_FALSE."
+
+Issues
+
+ None
+
+Revision History
+
+ Version 1, 2015/01/07 - first draft.
+ Version 2, 2017/03/01 - renamed extension and enum.
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_create_context_webgl_compatibility.txt b/src/third_party/angle/extensions/EGL_ANGLE_create_context_webgl_compatibility.txt
new file mode 100644
index 0000000..2e7fb82
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_create_context_webgl_compatibility.txt
@@ -0,0 +1,88 @@
+Name
+
+ ANGLE_create_context_webgl_compatibility
+
+Name Strings
+
+ EGL_ANGLE_create_context_webgl_compatibility
+
+Contributors
+
+ Geoff Lang
+
+Contacts
+
+ Geoff Lang (geofflang 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, September 16, 2016
+
+Number
+
+ EGL Extension #??
+
+Dependencies
+
+ Requires EGL 1.4.
+
+ Written against the EGL 1.4 specification.
+
+ This spec interacts with GL_ANGLE_webgl_compatibility (or equivalent)
+ extension.
+
+Overview
+
+ This extension allows the creation of an OpenGL or OpenGL ES context that
+ provides additional WebGL features and validation.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as an attribute name in the <*attrib_list> argument to
+ eglCreateContext:
+
+ EGL_CONTEXT_WEBGL_COMPATIBILITY_ANGLE 0x3AAC
+
+Additions to the EGL 1.4 Specification
+
+ Add the following to section 3.7.1 "Creating Rendering Contexts":
+
+ EGL_CONTEXT_WEBGL_COMPATIBILITY_ANGLE indicates whether a WebGL mode should
+ be enabled for the OpenGL ES context. In this mode, the OpenGL ES context
+ will provide additional features and validation to be compatible with the
+ WebGL specification. The default value of
+ EGL_CONTEXT_WEBGL_COMPATIBILITY_ANGLE is EGL_FALSE.
+
+Errors
+
+ None
+
+New State
+
+ None
+
+Conformance Tests
+
+ TBD
+
+Issues
+
+ None
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- ----------------------------------------
+ 1 Sept 16, 2016 geofflang Initial version
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_d3d_texture_client_buffer.txt b/src/third_party/angle/extensions/EGL_ANGLE_d3d_texture_client_buffer.txt
new file mode 100644
index 0000000..df3201c
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_d3d_texture_client_buffer.txt
@@ -0,0 +1,111 @@
+Name
+
+ ANGLE_d3d_texture_client_buffer
+
+Name Strings
+
+ EGL_ANGLE_d3d_texture_client_buffer
+
+Contributors
+
+ Geoff Lang
+
+Contacts
+
+ Geoff Lang, Google Inc. (geofflang 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, Oct 5, 2016
+
+Number
+
+ EGL Extension #??
+
+Dependencies
+
+ This extension is written against the wording of the EGL 1.4
+ Specification.
+
+ References the EGL_ANGLE_device_d3d extension.
+
+Overview
+
+ This extension allows creating EGL surfaces from D3D texture objects.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted in the <buftype> parameter of eglCreatePbufferFromClientBuffer:
+
+ EGL_D3D_TEXTURE_ANGLE 0x33A3
+
+Additions to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors)
+
+ Replace the last sentence of paragraph 1 of Section 3.5.3 with the
+ following text.
+ "Currently, the only client API resources which may be bound in this
+ fashion are OpenVG VGImage objects and Direct3D texture objects."
+
+ Replace the last sentence of paragraph 2 ("To bind a client API...") of
+ Section 3.5.3 with the following text.
+ "When <buftype> is EGL_OPENVG_IMAGE or EGL_D3D_TEXTURE_ANGLE, the width and
+ height of the pbuffer are determined by the width and height of <buffer>."
+
+ Replace the third paragraph of Section 3.5.3 with the following text.
+ "<buftype> specifies the type of buffer to be bound. The only allowed values
+ of <buftype> are EGL_OPENVG_IMAGE and EGL_D3D_TEXTURE_ANGLE".
+
+ Append the following text to the fourth paragraph of Section 3.5.3.
+ "When <buftype> is EGL_D3D_TEXTURE_ANGLE, <buffer> must be
+ a valid D3D texture object, cast into the type EGLClientBuffer. See table
+ egl.restrictions for acceptable texture object types and formats. If the
+ EGL_ANGLE_device_d3d extension is present, the provided D3D texture object
+ must have been created by the same D3D device queried from the display.
+ If these requirements are not met, an EGL_BAD_PARAMETER error is
+ generated."
+
+ ---------------------------------------------------------------------------
+ Resource Type Resource Restrictions
+ ---------------------------------------------------------------------------
+ IDirect3DTexture9 Memory pool must be D3DPOOL_DEFAULT. Format must be
+ D3DFMT_R8G8B8, D3DFMT_A8R8G8B8, D3DFMT_A16B16G16R16F or
+ D3DFMT_A32B32G32R32F.
+ ID3D11Texture2D Usage flags must be D3D11_USAGE_DEFAULT. Format must be
+ DXGI_FORMAT_R8G8B8A8_UNORM,
+ DXGI_FORMAT_R8G8B8A8_UNORM_SRGB,
+ DXGI_FORMAT_B8G8R8A8_UNORM,
+ DXGI_FORMAT_B8G8R8A8_UNORM_SRGB,
+ DXGI_FORMAT_R16G16B16A16_FLOAT or
+ DXGI_FORMAT_R32G32B32A32_FLOAT.
+ --------------------------------------------------------------------------
+ Table egl.restrictions - Restrictions on D3D resources that can be used
+ as a <buffer>.
+ --------------------------------------------------------------------------
+
+ Append to the end of Section 3.5.3.
+ "When a pbuffer is created with type EGL_D3D_TEXTURE_ANGLE, the contents
+ of the associcated D3D texture object are undefined while the pbuffer is
+ the current read surface, draw surface or bound to a client texture."
+
+Issues
+
+ 1. What renderers allow the use of a multi-sampled texture?
+
+ PROPOSED: Mutli-sampled texture support is currently limited to D3D11. Additionally,
+ the client is responsible for resolving the texture.
+
+Revision History
+
+ Version 1, 2016/10/05 - first draft.
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_device_creation.txt b/src/third_party/angle/extensions/EGL_ANGLE_device_creation.txt
new file mode 100644
index 0000000..2401a09
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_device_creation.txt
@@ -0,0 +1,120 @@
+Name
+
+ ANGLE_device_creation
+
+Name Strings
+
+ EGL_ANGLE_device_creation
+
+Contributors
+
+ Austin Kinross (aukinros 'at' microsoft.com)
+
+Contact
+
+ Austin Kinross (aukinros 'at' microsoft.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, Nov 02, 2015
+
+Number
+
+ EGL Extension #XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires EGL_EXT_device_query.
+
+ Written against the wording of EGL 1.5 as modified by EGL_EXT_device_query.
+
+Overview
+
+ Increasingly, EGL and its client APIs are being used in place of "native"
+ rendering APIs to implement the basic graphics functionality of native
+ windowing systems. This extension defines a way to create an EGL device
+ which maps to an inputted "native" rendering API device.
+
+ This extension is intended to be used with EGL_EXT_platform_device to
+ initialize a display using an existing "native" rendering device, but
+ EGL_EXT_platform_device is not required.
+
+IP Status
+
+ No known claims.
+
+New Types
+
+ None.
+
+New Procedures and Functions
+
+ EGLDeviceEXT eglCreateDeviceANGLE(EGLint device_type,
+ void *native_device,
+ cost EGLAttrib *attrib_list)
+
+ EGLBoolean eglReleaseDeviceANGLE(EGLDeviceEXT device)
+
+New Tokens
+
+ None.
+
+Changes to section 3.2 (Devices)
+
+ Add the following after the final paragraph to section 3.2 (Devices):
+
+ To create an EGL device wrapping an existing native rendering device, use:
+
+ EGLDeviceEXT eglCreateDeviceANGLE(EGLint device_type,
+ void *native_device,
+ cost EGLAttrib *attrib_list);
+
+ On success, a valid EGLDeviceEXT is returned. On failure, EGL_NO_DEVICE_EXT
+ is returned.
+
+ An EGL_BAD_ATTRIBUTE error is generated if <device_type> is not a valid
+ device type. This extension defines no valid values for <device_type>.
+
+ All attribute names in <attrib_list> are immediately followed by the
+ corresponding desired value. The list is terminated with EGL_NONE. The
+ <attrib_list> is considered empty if either <attrib_list> is NULL or if its
+ first element is EGL_NONE. This specification defines no valid attribute
+ names for inclusion in <attrib_list>. If <attrib_list> is not empty then
+ an EGL_BAD_ATTRIBUTE error is generated.
+
+ If a device is created using eglCreateDeviceANGLE then it is the
+ caller's responsibility to manage the lifetime of the device, and to call
+ eglReleaseDeviceANGLE at an appropriate time.
+
+ To release a device, use:
+
+ EGLBoolean eglReleaseDeviceANGLE(EGLDeviceEXT device);
+
+ On success, EGL_TRUE is returned. On failure, EGL_FALSE is returned.
+
+ If <device> equals EGL_NO_DEVICE_EXT then an EGL_BAD_DEVICE_EXT error is
+ generated. If <device> is not a valid device then the behavior is undefined.
+
+ <device> must have been created using eglGetDeviceANGLE. If <device> was
+ obtained by other means, such as through eglQueryDisplayAttribEXT, then an
+ EGL_BAD_DEVICE_EXT error is generated.
+
+ If eglReleaseDeviceANGLE is called on a device that is still in use by other
+ EGL objects, then the resulting behavior of those objects is undefined.
+
+Issues
+
+ None.
+
+Revision History
+
+ Version 1, Nov 2, 2015 (Austin Kinross)
+ - Initial Draft
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_device_creation_d3d11.txt b/src/third_party/angle/extensions/EGL_ANGLE_device_creation_d3d11.txt
new file mode 100644
index 0000000..6f25f53
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_device_creation_d3d11.txt
@@ -0,0 +1,92 @@
+Name
+
+ ANGLE_device_creation_d3d11
+
+Name Strings
+
+ EGL_ANGLE_device_creation_d3d11
+
+Contributors
+
+ Austin Kinross (aukinros 'at' microsoft.com)
+
+Contact
+
+ Austin Kinross (aukinros 'at' microsoft.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, Nov 02, 2015
+
+Number
+
+ EGL Extension #XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires EGL_ANGLE_device_d3d and EGL_ANGLE_device_creation.
+
+ Written against the wording of EGL 1.5 as modified by EGL_ANGLE_device_d3d
+ and EGL_ANGLE_device_creation.
+
+Overview
+
+ ANGLE has the ability to run GPU commands on a native D3D device. This
+ extension defines a way to create a EGL device which maps to an inputted
+ Direct3D 11 device.
+
+ This extension is intended to be used with EGL_EXT_platform_device to
+ initialize a display using an existing Direct3D 11 device, but
+ EGL_EXT_platform_device is not required.
+
+IP Status
+
+ No known claims.
+
+New Types
+
+ None.
+
+New Procedures and Functions
+
+ None.
+
+New Tokens
+
+ None.
+
+Changes to section 3.2 (Devices)
+
+ Modify the language in section 3.2 (Devices) describing valid attribute
+ names passed into eglCreateDeviceANGLE via <device_type>:
+
+ "This specification defines one value for <device_type>:
+ EGL_D3D11_DEVICE_ANGLE. If this device type is specified then
+ <native_device> must be a valid pointer to a Direct3D 11 device. If
+ <native_device> is not a valid pointer to a Direct3D 11 device then the
+ resulting behavior is undefined."
+
+ Append the following to the end of section 3.2 (Devices):
+
+ "If a Direct3D 11 device used to create a device experiences a "lost device"
+ then all resulting behavior of the device (and any dependent EGL objects) is
+ undefined. It is the caller's responsibility to monitor for "lost device"
+ and to create a new device (and dependent EGL objects) as appropriate. For
+ more information on "lost device", see the Direct3D documentation."
+
+Issues
+
+ None.
+
+Revision History
+
+ Version 1, Nov 2, 2015 (Austin Kinross)
+ - Initial Draft
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_device_d3d.txt b/src/third_party/angle/extensions/EGL_ANGLE_device_d3d.txt
new file mode 100644
index 0000000..6e56247
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_device_d3d.txt
@@ -0,0 +1,93 @@
+Name
+
+ ANGLE_device_d3d
+
+Name Strings
+
+ EGL_ANGLE_device_d3d
+
+Contributors
+
+ Jamie Madill (jmadill 'at' google.com)
+
+Contact
+
+ Jamie Madill (jmadill 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, Mar 25, 2015
+
+Number
+
+ EGL Extension #XXX
+
+Extension Type
+
+ EGL device extension
+
+Dependencies
+
+ This extension is written against the language of EGL 1.5 as
+ modified by EGL_EXT_device_query.
+
+ EGL_EXT_device_query is required.
+
+Overview
+
+ ANGLE has the ability to run GPU commands on a native D3D device.
+ This extension defines a mapping from an EGL device to a D3D
+ device, after it's queried from an EGL display.
+
+IP Status
+
+ No known claims.
+
+New Types
+
+ None.
+
+New Procedures and Functions
+
+ None.
+
+New Tokens
+
+ Accepted as a queried <attribute> in eglQueryDeviceAttribEXT:
+
+ EGL_D3D9_DEVICE_ANGLE 0x33A0
+ EGL_D3D11_DEVICE_ANGLE 0x33A1
+
+Add a new section 2.1.3 (D3D Devices) after 2.1.2 (Devices)
+
+ Somewhat analogous to an EGL device, a D3D device establishes a
+ namespace for D3D operations. In the D3D APIs, such devices are
+ represented by pointers. For more details, see the D3D
+ documentation.
+
+Changes to section 3.2 (Devices)
+
+ Replace the paragraph immediately following the prototype for
+ eglQueryDeviceAttribEXT:
+
+ <attribute> may be either EGL_D3D9_DEVICE_ANGLE or EGL_D3D11_DEVICE_ANGLE.
+ On success, EGL_TRUE is returned, and a valid D3D9 or D3D11 device pointer
+ corresponding to the EGL device is returned in <value>. This handle
+ is compatible with D3D API functions. If the EGL device is not currently
+ associated with a D3D9 device and <attribute> is EGL_D3D9_DEVICE_ANGLE,
+ or if the EGL device is not currently associated with a D3D11 device and
+ <attribute> is EGL_D3D11_DEVICE_ANGLE, EGL_BAD_ATTRIBUTE is returned,
+ and <value> is left unchanged.
+
+Issues
+
+ None
+
+Revision History
+
+ Version 1, Mar 25, 2015 (Jamie Madill)
+ - Initial Draft
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_direct_composition.txt b/src/third_party/angle/extensions/EGL_ANGLE_direct_composition.txt
new file mode 100644
index 0000000..72bbfc3
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_direct_composition.txt
@@ -0,0 +1,97 @@
+Name
+
+ ANGLE_direct_composition
+
+Name Strings
+
+ EGL_ANGLE_direct_composition
+
+Contributors
+
+ John Bauman
+
+Contacts
+
+ John Bauman (jbauman 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 2, Dec 14, 2015
+
+Number
+
+ EGL Extension #??
+
+Dependencies
+
+ This extension is written against the wording of the EGL 1.5 Specification.
+
+Overview
+
+ This extension allows specifying that the contents of a window surface be
+ posted to the screen using the DirectComposition API.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <attribute> parameter of eglQuerySurface and by the
+ <attrib_list> parameter of eglCreateWindowSurface and
+ eglCreatePlatformWindowSurface
+
+ EGL_DIRECT_COMPOSITION_ANGLE 0x33A5
+
+Changes to Chapter 3 of the EGL 1.5 Specification (EGL Functions and Errors)
+
+ Modify the fourth paragraph of Section 3.5.1, page 32
+ (Creating On-Screen rendering Surfaces)
+
+ "<attrib_list> specifies a list of attributes for the window. The list has
+ the same structure as described for eglChooseConfig. Attributes that can
+ be specified in <attrib_list> include EGL_DIRECT_COMPOSITION_ANGLE,
+ EGL_GL_COLORSPACE, EGL_RENDER_BUFFER, EGL_VG_COLORSPACE, and
+ EGL_VG_ALPHA_FORMAT."
+
+ Add the following between paragraphs 6 and 7 of Section 3.5.1, page 32
+ (Creating On-Screen Rendering Surfaces)
+
+ "EGL_DIRECT_COMPOSITION_ANGLE specifies whether the surface will be posted
+ to the window using DirectComposition. The default is EGL_FALSE. If
+ EGL_TRUE is specified, <native_window> must be owned by the current
+ process, and contents drawn by native APIs or EGLSurfaces with
+ EGL_DIRECT_COMPOSITION_ANGLE as EGL_FALSE will appear underneath the
+ contents of this surface."
+
+
+ Add the following entry to Table 3.5, page 44 (Queryable surface
+ attributes and types)
+
+ Attribute Type Description
+ ---------------------------- ------- --------------------------------------
+ EGL_DIRECT_COMPOSITION_ANGLE boolean Surface will be posted to the window
+ using DirectComposition
+
+Issues
+ 1. Should a surface attrib or config be used to specify that
+ DirectComposition is needed.
+
+ PROPOSED: A surface attrib would work and avoids creating
+ otherwise-duplicate configs.
+
+Revision History
+
+ Version 2, 2015/12/14
+ - Use attrib instead of config.
+
+ Version 1, 2015/12/10
+ - Initial draft.
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_display_texture_share_group.txt b/src/third_party/angle/extensions/EGL_ANGLE_display_texture_share_group.txt
new file mode 100644
index 0000000..90f75ec
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_display_texture_share_group.txt
@@ -0,0 +1,82 @@
+Name
+
+ ANGLE_display_texture_share_group
+
+Name Strings
+
+ EGL_ANGLE_display_texture_share_group
+
+Contributors
+
+ Geoff Lang, Google
+
+Contacts
+
+ Geoff Lang, Google (geofflang 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, February 7, 2017
+
+Number
+
+ EGL Extension TBD
+
+Dependencies
+
+ This extension is written against the wording of the EGL 1.5 specification.
+
+Overview
+
+ This extension allows for the creation of OpenGL ES contexts that share
+ texture objects with other contexts owned by the same display. This method
+ of sharing textures can be used in conjuction with regular share groups.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as an attribute name in the <*attrib_list> argument to
+ eglCreateContext:
+
+ EGL_DISPLAY_TEXTURE_SHARE_GROUP_ANGLE 0x33AF
+
+Additions to the EGL 1.5 Specification
+
+ Add a new section entitled "OpenGL ES Global Texture Share Groups"
+ to section 3.7.1:
+
+ "If the attribute EGL_DISPLAY_TEXTURE_SHARE_GROUP_ANGLE is set to EGL_TRUE,
+ a context that shares textures with other contexts owned by the same
+ display and created with EGL_DISPLAY_TEXTURE_SHARE_GROUP_ANGLE set to
+ EGL_TRUE will be created. If the share_context parameter to
+ eglCreateContext is not NULL, all contexts within the share group must have
+ been created with the same value of EGL_DISPLAY_TEXTURE_SHARE_GROUP_ANGLE.
+ The default value of EGL_DISPLAY_TEXTURE_SHARE_GROUP_ANGLE is EGL_FALSE."
+
+Issues
+
+ (1) What happens to the shared textures when a context in the global share
+ group is destroyed?
+
+ RESOLOVED: When the last context in the global texture share group is
+ destroyed, all textures in the global texture share group are released. If
+ a new context is created in the global texture share group, no textures
+ will exist.
+
+ This mirrors how regular share groups work, releasing all objects when the
+ last context is destroyed.
+
+Revision History
+
+ Version 1, 2017/02/07 - first draft.
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_experimental_present_path.txt b/src/third_party/angle/extensions/EGL_ANGLE_experimental_present_path.txt
new file mode 100644
index 0000000..4f96c1f
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_experimental_present_path.txt
@@ -0,0 +1,106 @@
+Name
+
+ ANGLE_experimental_present_path
+
+Name Strings
+
+ EGL_ANGLE_experimental_present_path
+
+Contributors
+
+ Austin Kinross
+
+Contacts
+
+ Austin Kinross (aukinros 'at' microsoft 'dot' com)
+
+Status
+
+ Experimental
+
+Version
+
+ Version 1, Jan 22 2016
+
+Number
+
+ EGL Extension #XXX
+
+Extension Type
+
+ EGL display extension
+
+Dependencies
+
+ Requires ANGLE_platform_angle_d3d.
+
+ Written against the wording of EGL 1.4 as modified by
+ ANGLE_platform_angle_d3d.
+
+Overview
+
+ This extension exposes an optimized, but potentially non-conformant,
+ rendering path for ANGLE's D3D11 renderer on Windows.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as an attribute name in the <attrib_list> argument of
+ eglGetPlatformDisplayEXT:
+
+ EGL_EXPERIMENTAL_PRESENT_PATH_ANGLE 0x33A4
+
+ Accepted as values for the EGL_EXPERIMENTAL_PRESENT_PATH_ANGLE attribute:
+
+ EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE 0x33A9
+ EGL_EXPERIMENTAL_PRESENT_PATH_COPY_ANGLE 0x33AA
+
+Additions to the EGL Specification
+
+ None.
+
+New Behavior
+
+ To request a display that enables this optimized rendering path,
+ the value of EGL_EXPERIMENTAL_PRESENT_PATH_ANGLE should be set to
+ EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE. Setting this value may impact
+ OpenGL ES conformance (see Issue 1 below).
+
+ The only valid values for the attribute
+ EGL_EXPERIMENTAL_PRESENT_PATH_ANGLE are
+ EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE and
+ EGL_EXPERIMENTAL_PRESENT_PATH_COPY_ANGLE. If any other value is specified
+ then an EGL_BAD_ATTRIBUTE error is generated and EGL_NO_DISPLAY is
+ returned.
+
+ If a value for EGL_EXPERIMENTAL_PRESENT_PATH_ANGLE is specified and
+ EGL_PLATFORM_ANGLE_TYPE_ANGLE is not set to
+ EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE then an EGL_BAD_ATTRIBUTE error is
+ generated and EGL_NO_DISPLAY is returned.
+
+ If the attribute EGL_EXPERIMENTAL_PRESENT_PATH_ANGLE
+ is unspecified then it is implicitly set to
+ EGL_EXPERIMENTAL_PRESENT_PATH_COPY_ANGLE.
+
+Issues
+
+ 1) Does setting EGL_EXPERIMENTAL_PRESENT_PATH_ANGLE to be
+ EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE maintain OpenGL ES
+ conformance?
+
+ RESOLVED: Not necessarily, that is implementation-specific. Check then
+ EGL_CONFORMANT attribute to see if the implementation supports any
+ conformant EGL configs when EGL_EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE
+ is specified.
+
+Revision History
+
+ Version 1, Jan 22 2016 (Austin Kinross)
+ - Initial draft
\ No newline at end of file
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_flexible_surface_compatibility.txt b/src/third_party/angle/extensions/EGL_ANGLE_flexible_surface_compatibility.txt
new file mode 100644
index 0000000..55d9463
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_flexible_surface_compatibility.txt
@@ -0,0 +1,154 @@
+Name
+
+ ANGLE_flexible_surface_compatibility
+
+Name Strings
+
+ EGL_ANGLE_flexible_surface_compatibility
+
+Contributors
+
+ John Bauman (jbauman 'at' google.com)
+ Shannon Woods (shannonwoods 'at' google.com)
+
+Contact
+
+ John Bauman (jbauman 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 3, Dec 15, 2015
+
+Number
+
+ EGL Extension #XXX
+
+Extension Type
+
+ EGL display extension
+
+Dependencies
+
+ This extension is written against the language of EGL 1.5.
+
+Overview
+
+ Some EGL implementations may allow any surface to be made current with any
+ context from the same display, without restrictions due to bit depth.
+
+IP Status
+
+ No known claims.
+
+New Types
+
+ None.
+
+New Procedures and Functions
+
+ None.
+
+New Tokens
+
+ Accepted by the <attribute> parameter of eglQuerySurface and by the
+ <attrib_list> parameter of eglCreateWindowSurface,
+ eglCreatePlatformWindowSurface, eglCreatePbufferSurface, and
+ eglCreatePbufferFromClientBuffer:
+
+ EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE 0x33A6
+
+Changes to Chapter 2 of the EGL 1.5 Specification (EGL Operation)
+
+ Replace the first paragraph of the first bulleted list item in section
+ 2.2, page 4
+ (Rendering Contexts and Drawing Surfaces)
+
+ "They support the same type of color buffer (RGB or luminance), or the
+ surface has the EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE
+ attribute set to EGL_TRUE."
+
+ Replace the first paragraph of the second bulleted list item in section
+ 2.2, page 4
+ (Rendering Contexts and Drawing Surfaces)
+
+ "They have color buffers and ancillary buffers of the same depth, or the
+ surface has the EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE
+ attribute set to EGL_TRUE."
+
+Changes to Chapter 3 of the EGL 1.5 Specification (EGL Functions and Errors)
+
+ Modify the fourth paragraph of Section 3.5.1, page 32
+ (Creating On-Screen rendering Surfaces)
+
+ "<attrib_list> specifies a list of attributes for the window. The list has
+ the same structure as described for eglChooseConfig. Attributes that can
+ be specified in <attrib_list> include
+ EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE, EGL_GL_COLORSPACE,
+ EGL_RENDER_BUFFER, EGL_VG_COLORSPACE, and EGL_VG_ALPHA_FORMAT."
+
+ Add the following between paragraphs 6 and 7 of Section 3.5.1, page 32
+ (Creating On-Screen Rendering Surfaces)
+
+ "EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE specifies whether the
+ surface can be made current with a context with a config of different bit
+ depth. Its values can be EGL_TRUE, in which case that is supported, or
+ EGL_FALSE, in which case that is not supported."
+
+ Modify the fourth paragraph of Section 3.5.2, page 35
+ (Creating Off-Screen Rendering Surfaces)
+
+ "<attrib_list> specifies a list of attributes for the pbuffer. The list
+ has the same structure as described for eglChooseConfig. Attributes that
+ can be specified in <attrib_list> include EGL_WIDTH, EGL_HEIGHT,
+ EGL_LARGEST_PBUFFER, EGL_TEXTURE_FORMAT, EGL_TEXTURE_TARGET,
+ EGL_MIPMAP_TEXTURE, EGL_GL_COLORSPACE, EGL_VG_COLORSPACE,
+ EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE, and
+ EGL_VG_ALPHA_FORMAT."
+
+ Modify paragraph twelve of Section 3.5.2, page 36
+
+ "EGL_GL_COLORSPACE, EGL_VG_COLORSPACE,
+ EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE, and
+ EGL_VG_ALPHA_FORMAT have the same meaning and default values as when used
+ with eglCreatePlatformWindowSurface."
+
+ Modify the fifth paragraph of Section 3.5.3, page 37
+ (Binding Off-Screen Rendering Surfaces To Client Buffers)
+
+ "<attrib_list> specifies a list of attributes for the pbuffer. The list
+ has the same structure as described for eglChooseConfig. Attributes that
+ can be specified in <attrib_list> include EGL_TEXTURE_FORMAT,
+ EGL_TEXTURE_TARGET, EGL_- MIPMAP_TEXTURE, and
+ EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE. The meaning of these
+ attributes is as described above for eglCreatePbufferSurface. The
+ EGL_VG_COLORSPACE and EGL_VG_ALPHA_FORMAT attributes of the surface are
+ determined by the VGImageFormat of buffer."
+
+ Add the following entry to Table 3.5, page 44 (Queryable surface
+ attributes and types)
+
+ Attribute Type Description
+ -------------------------------------------------- ------- ------------------------
+ EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE boolean Surface can be made
+ current with contexts
+ of a different bit depth
+
+Issues
+
+ None
+
+Revision History
+
+ Version 3, Dec 15, 2015 (John Bauman)
+ - Modify EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE value.
+
+ Version 2, Dec 1, 2015 (John Bauman)
+ - Add EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE to specify
+ new behavior.
+
+ Version 1, Nov 24, 2015 (John Bauman)
+ - Initial Draft
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_keyed_mutex.txt b/src/third_party/angle/extensions/EGL_ANGLE_keyed_mutex.txt
new file mode 100644
index 0000000..647af90
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_keyed_mutex.txt
@@ -0,0 +1,75 @@
+Name
+
+ ANGLE_keyed_mutex
+
+Name Strings
+
+ EGL_ANGLE_keyed_mutex
+
+Contributors
+
+ Jeff Muizelaar
+
+Contacts
+
+ Jeff Muizelaar, Mozilla (jmuizelaar 'at' mozilla.org)
+
+Status
+
+ Implemented in ANGLE.
+
+Version
+
+ Version 1, Oct 29, 2014
+
+Number
+
+ EGL Extension #??
+
+Dependencies
+
+ Requires the EGL_ANGLE_query_surface_pointer extension.
+
+ This extension is written against the wording of the EGL 1.4
+ Specification.
+
+Overview
+
+ Some EGL implementations generate EGLSurface handles that are
+ backed by Direct3D 11 2D textures. This extension allows
+ obtaining the IDXGIKeyedMutex for such EGL surfaces.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted in the <attribute> parameter of eglQuerySurfacePointerANGLE:
+
+ EGL_DXGI_KEYED_MUTEX_ANGLE 0x33A2
+
+ Add to table 3.5, "Queryable surface attributes and types":
+
+ Attribute Type Description
+ --------- ---- -----------
+ EGL_DXGI_KEYED_MUTEX_ANGLE pointer IDXGIKeyedMutex
+
+ Add before the last paragraph in section 3.5, "Surface attributes":
+
+ "Querying EGL_DXGI_KEYED_MUTEX_ANGLE returns a IDXGIKeyedMutex, or NULL
+ if a keyed mutex for the surface is not available. The keyed mutex
+ must be queried using eglQuerySurfaceAttribPointerANGLE. Keyed Mutexes
+ are only available from EGL surfaces backed by Direct3D 11 surfaces.
+ Before using the keyed mutex, ensure that all rendering to the EGLSurface
+ with EGL client APIs has completed."
+
+Issues
+
+Revision History
+
+ Version 1, 2014/10/29 - first draft.
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_stream_producer_d3d_texture_nv12.txt b/src/third_party/angle/extensions/EGL_ANGLE_stream_producer_d3d_texture_nv12.txt
new file mode 100644
index 0000000..427f800
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_stream_producer_d3d_texture_nv12.txt
@@ -0,0 +1,156 @@
+Name
+
+ ANGLE_stream_producer_d3d_texture_nv12
+
+Name Strings
+
+ EGL_ANGLE_stream_producer_d3d_texture_nv12
+
+Contributors
+
+ Ian Ewell
+ Geoff Lang
+ John Bauman
+
+Contacts
+
+ Geoff Lang, Google (geofflang ‘at’ google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, April 6, 2016
+
+Number
+
+ EGL Extension #XXX
+
+Dependencies
+
+ Requires EGL 1.5.
+ Requires OpenGL ES 2.0.
+
+ Requires the EGL_KHR_stream extension.
+ Requires the EGL_NV_stream_consumer_gltexture_yuv extension.
+ Requires the EGL_ANGLE_device_d3d extension.
+
+Overview
+
+ This extension allows D3D11 NV12 textures to be inserted into an EGL stream
+ with the expectation that the stream consumer will be a YUV GL texture
+ consumer using a two plane configuration (i.e. a Y plane and a UV plane).
+ This will act as the producer of the stream.
+
+New procedures and functions
+
+ EGLBoolean eglCreateStreamProducerD3DTextureNV12ANGLE
+ (EGLDisplay dpy,
+ EGLStreamKHR stream,
+ const EGLAttrib *attrib_list)
+ EGLBoolean eglStreamPostD3DTextureNV12ANGLE(EGLDisplay dpy,
+ EGLStreamKHR stream,
+ void *texture,
+ const EGLAttrib *attrib_list)
+
+New Tokens
+
+ Accepted as an <attribute> in eglStreamPostD3DTextureNV12ANGLE:
+
+ EGL_D3D_TEXTURE_SUBRESOURCE_ID_ANGLE 0x33AB
+
+Replace section "3.10.3.1 No way to connect producer to EGLStream" in the
+EGL_KHR_stream extension with this:
+
+ 3.10.3.1 Stream Surface Producer
+
+ Call
+
+ EGLBoolean eglCreateStreamProducerD3DTextureNV12ANGLE(
+ EGLDisplay dpy,
+ EGLStreamKHR stream,
+ const EGLAttrib *attrib_list)
+
+ to create a producer that accepts D3D11 NV12 textures and connect it as the
+ producer of <stream>. <attrib_list> is used to specify attributes for the
+ stream producer. Currently there are no attributes to specify, and the
+ attribute list is used as a placeholder for future additions.
+
+ On failure, eglCreateStreamProducerD3DTextureNV12ANGLE returns EGL_FALSE and
+ generates an error.
+
+ - EGL_BAD_STATE_KHR is generated if <stream> is not in the state
+ EGL_STREAM_STATE_CONNECTING_KHR.
+
+ - EGL_BAD_MATCH is generated if <stream> does not have a connected GL
+ texture YUV consumer that is configured to bind to two OpenGL
+ textures: one for the Y plane and one for the UV plane.
+
+ - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid EGLStream
+ generated for <dpy>.
+
+ - EGL_BAD_DISPLAY is generated if <dpy> is not a valid, initialized
+ display.
+
+Add a section preceding "3.9.3 Posting Semantics" in the EGL specification:
+
+ 3.9.x Posting to a Stream
+
+ To post a D3D11 NV12 texture to a stream, call
+
+ EGLBoolean eglStreamPostD3DTextureNV12ANGLE(
+ EGLDisplay dpy,
+ EGLStreamKHR stream,
+ void *texture,
+ const EGLAttrib *attrib_list);
+
+ If <stream> is an appropriately configured stream and <texture> points to a
+ valid ID3D11Texture2D object of the format DXGI_FORMAT_NV12 that is owned
+ by the same ID3D11Device that is queried with the EGL_ANGLE_device_d3d
+ extension, the texture will be posted to the stream and can be bound as one
+ or more OpenGL texture objects.
+
+ The parameter <attrib_list> allows for per-frame attributes to be specified
+ along with the texture. The only parameter currently available is
+ EGL_D3D_TEXTURE_SUBRESOURCE_ID_ANGLE, which allows the subresource id of
+ the texture that will be used to be specified. If this attribute is not
+ explicitly specified, it will default to the value of 0.
+
+ It is the responsibility of the application to perform any synchronization
+ between the insertion of the frame into the stream and the use of the
+ consumer textures output by the stream. The EGL_CONSUMER_LATENCY_USEC_KHR
+ attribute will have no effect on the function of the implementation of this
+ extension, but can still be used for communication between components of
+ the application.
+
+ The implementation will hold a reference to the D3D11 texture object if the
+ insertion is successful and will release the texture object when a new frame
+ is inserted or when the stream is destroyed.
+
+ On failure, eglStreamInsertD3DTextureNV12 returns EGL_FALSE and generates an
+ error.
+
+ - EGL_BAD_STATE is generated if <stream> is not in the state
+ EGL_STREAM_STATE_EMPTY_KHR, EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR,
+ or EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR.
+
+ - EGL_BAD_MATCH is generated if the stream is not associated with a
+ D3D11 NV12 texture producer.
+
+ - EGL_BAD_PARAMETER is generated if <texture> is not owned by the
+ queried device, is not in the format DXGI_FORMAT_NV12, is not
+ compatible with the implementation, or if the specified value for
+ EGL_D3D_TEXTURE_SUBRESOURCE_ID_ANGLE is not a valid subresource id for
+ the texture.
+
+ - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid EGLStream.
+
+ - EGL_BAD_ATTRIBUTE is generated if an attribute other than
+ EGL_D3D_TEXTURE_SUBRESOURCE_ID_ANGLE is specified in <attrib_list>.
+
+Revision History
+
+ #1 (April 6, 2016) Ian Ewell
+ - initial draft
\ No newline at end of file
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_surface_orientation.txt b/src/third_party/angle/extensions/EGL_ANGLE_surface_orientation.txt
new file mode 100644
index 0000000..c6e3b27
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_surface_orientation.txt
@@ -0,0 +1,133 @@
+Name
+
+ ANGLE_surface_orientation
+
+Name Strings
+
+ EGL_ANGLE_surface_orientation
+
+Contributors
+
+ Geoff Lang, Google
+
+Contacts
+
+ Geoff Lang, Google (geofflang 'at' google 'dot' com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, 2015-12-15
+
+Number
+
+ EGL Extension XXX
+
+Extension Type
+
+ EGL display extension
+
+Dependencies
+
+ Written based on the wording of the EGL 1.5 Specification
+ (August 7 2014).
+
+Overview
+
+ This extension provides a mechanism for querying the most optimal
+ orientation of a window surface and creating window sufraces with
+ non-default orientations for the most performant rendering.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ New EGLConfig bitmask attribute name:
+
+ EGL_OPTIMAL_SURFACE_ORIENTATION_ANGLE 0x33A7
+
+ Accepted as an attribute name in the <attrib_list> argument of
+ eglCreateWindowSurface and attribute name in the <attribute>
+ argument of eglQuerySurface:
+
+ EGL_SURFACE_ORIENTATION_ANGLE 0x33A8
+
+ Valid bitfields in the EGL_OPTIMAL_SURFACE_ORIENTATION_ANGLE bitmask
+ attribute of EGLConfig and EGL_SURFACE_ORIENTATION_ANGLE bitmask attribute
+ of eglCreateWindowSurface:
+
+ EGL_SURFACE_ORIENTATION_INVERT_X_ANGLE 0x0001
+ EGL_SURFACE_ORIENTATION_INVERT_Y_ANGLE 0x0002
+
+Additions to the EGL Specification
+
+ Additions to Chapter 3 of the EGL 1.5 Specification (EGL Functions and Errors)
+
+ Add to table 3.1 (EGLConfig Attributes)
+
+ Attribute Type Notes
+ ------------------------------------- ------- ----------------------
+ EGL_OPTIMAL_SURFACE_ORIENTATION_ANGLE bitmask Optimal window surface
+ orientation.
+
+
+ Add a paragraph to section 3.4, section Other EGLConfig Attribute
+ Descriptions.
+
+ "EGL_OPTIMAL_SURFACE_ORIENTATION_ANGLE is a mask indicating which
+ window surface orientation will provide the best performance."
+
+ Add to table 3.4 (Default values and match criteria for EGLConfig
+ attributes):
+
+ Attribute Default Selection Sort Sort
+ Criteria Order Priority
+ ------------------------------------- ------- --------- ------- --------
+ EGL_OPTIMAL_SURFACE_ORIENTATION_ANGLE 0 Exact None
+
+ Add a paragraph to section 3.5.1, section Creating On-Screen Rendering
+ Surfaces.
+
+ EGL_SURFACE_ORIENTATION_ANGLE attribute specifies how the surface's content
+ will appear on the screen. If its value contains
+ EGL_SURFACE_ORIENTATION_INVERT_X_ANGLE then all displayed content will be
+ inverted along the vertical axis. Similarly, if its value contains
+ EGL_SURFACE_ORIENTATION_INVERT_Y_ANGLE then all displayed content will be
+ inverted along the horizontal axis.
+
+ Add to table 3.5 (Queryable surface attributes and types):
+
+ Attribute Type Description
+ ----------------------------- ------- ----------------------
+ EGL_SURFACE_ORIENTATION_ANGLE bitmask Orientation of surface
+
+ Add a paragraph to section 3.5.6, Surface Attributes:
+
+ "Querying EGL_SURFACE_ORIENTATION_ANGLE returns the orientation of the
+ surface. For a window surface, this is the same attribute value specified
+ when the surface was created. For other types of surfaces, it is always
+ 0."
+
+Issues
+
+ 1) What about dirty regions and sub regions specified by extensions such as
+ NV_post_sub_buffer?
+
+ These regions will be applied to the same region of the window as
+ before because they are often specified based on events from the
+ operating system. The content in these regions will be displayed
+ according to the value of EGL_SURFACE_ORIENTATION_ANGLE.
+
+Revision History
+
+ Version 1, 2015-12-15 (Geoff Lang)
+ - Initial draft
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_window_fixed_size.txt b/src/third_party/angle/extensions/EGL_ANGLE_window_fixed_size.txt
new file mode 100644
index 0000000..e4c1ac3
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_window_fixed_size.txt
@@ -0,0 +1,136 @@
+Name
+
+ ANGLE_window_fixed_size
+
+Name Strings
+
+ EGL_ANGLE_window_fixed_size
+
+Contributors
+
+ John Bauman
+ Shannon Woods
+
+Contacts
+
+ John Bauman, Google Inc. (jbauman 'at' google.com)
+
+Status
+
+ Complete
+
+Version
+
+ Version 4, February 24, 2014
+
+Number
+
+ EGL Extension #??
+
+Dependencies
+
+ This extension is written against the wording of the EGL 1.4
+ Specification.
+
+Overview
+
+ This extension allows creating a window surface with a fixed size that is
+ specified when it is created.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <attribute> parameter of eglQuerySurface and by the
+ <attrib_list> parameter of eglCreateWindowSurface:
+
+ EGL_FIXED_SIZE_ANGLE 0x3201
+
+Additions to Chapter 3 of the EGL 1.4 Specification:
+
+ Modify the third paragraph of Section 3.5.1 (Creating On-Screen Rendering Surfaces)
+
+ "<attrib_list> specifies a list of attributes for the window. The list has
+ the same structure as described for eglChooseConfig. Attributes that can
+ be specified in <attrib_list> include EGL_RENDER_BUFFER,
+ EGL_VG_COLORSPACE, EGL_VG_ALPHA_FORMAT, EGL_FIXED_SIZE_ANGLE, EGL_WIDTH,
+ and EGL_HEIGHT."
+
+ Add before the last paragraph of Section 3.5.1
+
+ "EGL_FIXED_SIZE_ANGLE specifies whether the surface must be resized by the
+ implementation when the native window is resized. The default value is
+ EGL_FALSE. Its value can be EGL_TRUE, in which case the size must be
+ specified when the window is created, or EGL_FALSE, in which case the size
+ is taken from the native window. Its default value is EGL_FALSE.
+
+ If the value of EGL_FIXED_SIZE_ANGLE is EGL_TRUE, the window surface's
+ size in pixels is specified by the EGL_WIDTH and EGL_HEIGHT attributes,
+ and will not change throughout the lifetime of the surface. If its value
+ is EGL_FALSE, then the values of EGL_WIDTH and EGL_HEIGHT are ignored and
+ the window surface must be resized by the implementation subsequent to the
+ native window being resized, and prior to copying its contents to the
+ native window (e.g. in eglSwapBuffers, as described in section 3.9.1.1).
+ The default values for EGL_WIDTH and EGL_HEIGHT are zero. If the value
+ specified for either of EGL_WIDTH or EGL_HEIGHT is less than zero then an
+ EGL_BAD_PARAMETER error is generated."
+
+ Add the following entry to Table 3.5
+ (Queryable surface attributes and types)
+
+ Attribute Type Description
+ -------------------- ------- ---------------------------------------------
+ EGL_FIXED_SIZE_ANGLE boolean Surface will not be resized with a native
+ window
+
+ Replace the last paragraph on page 37 in Section 3.5.6 (Surface Attributes)
+
+ "Querying EGL_WIDTH and EGL_HEIGHT returns respectively the width and
+ height, in pixels, of the surface. For a pixmap surface or window surface
+ with EGL_FIXED_SIZE_ANGLE set to EGL_FALSE, these values are initially
+ equal to the width and height of the native window or pixmap with respect
+ to which the surface was created. If the native window is resized and the
+ corresponding window surface is not fixed size, the corresponding window
+ surface will eventually be resized by the implementation to match (as
+ discussed in section 3.9.1). If there is a discrepancy because EGL has not
+ yet resized the window surface, the size returned by eglQuerySurface will
+ always be that of the EGL surface, not the corresponding native window."
+
+ Add the following paragraph to Section 3.5.6 (Surface Attributes)
+
+ "Querying EGL_FIXED_SIZE_ANGLE returns EGL_FALSE if the surface will be
+ resized to match a native window, and EGL_TRUE if the surface cannot be
+ resized."
+
+ Alter the beginning of the first paragraph of Section 3.9.1.1 (Native
+ Window Resizing)
+
+ "If <surface> does not have EGL_FIXED_SIZE_ANGLE set and the native window
+ corresponding to <surface> has been resized prior to the swap, <surface>
+ must be resized to match."
+
+Issues
+
+ 1. Should there be a way to resize a window surface that had its size
+ specified initially.
+
+ RESOLVED: No. Surfaces that have their sizes specified initially must have
+ EGL_FIXED_SIZE_ANGLE set and can never be resized.
+
+Revision History
+
+ Version 4, 2014/02/24 - formatting changes.
+
+ Version 3, 2014/02/12 - ignore EGL_WIDTH and EGL_HEIGHT if
+ EGL_FIXED_SIZE_ANGLE is EGL_FALSE
+
+ Version 2, 2014/02/07 - rename to EGL_ANGLE_window_fixed_size, and add an
+ EGL_FIXED_SIZE_ANGLE token.
+
+ Version 1, 2014/02/05 - first draft.
diff --git a/src/third_party/angle/extensions/EGL_ANGLE_x11_visual.txt b/src/third_party/angle/extensions/EGL_ANGLE_x11_visual.txt
new file mode 100644
index 0000000..d77561e
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_ANGLE_x11_visual.txt
@@ -0,0 +1,106 @@
+Name
+
+ ANGLE_x11_visual
+
+Name Strings
+
+ EGL_ANGLE_x11_visual
+
+Contributors
+
+ Corentin Wallez, Google
+ Shannon Woods, Google
+ Jamie Madill, Google
+ Geoff Lang, Google
+
+Contacts
+
+ Corentin Wallez, Google (cwallez 'at' chromium 'dot' org)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, 2015-11-13
+
+Number
+
+ EGL Extension XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Requires EGL_EXT_client_extensions to query its existence without
+ a display.
+
+ Requires EGL_EXT_platform_base.
+
+ This extension is written against the wording of version 9 of the
+ EGL_EXT_platform_base specification.
+
+ Written based on the wording of the EGL 1.5 Specification
+ (August 7 2014).
+
+Overview
+
+ This extension allows passing the X11 visual ID used by the native
+ EGL surface types at display creation time. This will restrict
+ EGLSurfaces to be created from native types with this visual ID,
+ which may allow the created display to be more compatible and
+ performant.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as an attribute name in the <attrib_list> argument of
+ eglGetPlatformDisplayEXT:
+
+ EGL_X11_VISUAL_ID_ANGLE 0x33A3
+
+Additions to the EGL Specification
+
+ Modify section 3.5.1 (Creating On-Screen Rendering Surfaces), p. 34
+
+ Append the following to the errors of CreateWindowSurface:
+
+ "If an X11 visual was specified at display creation time using
+ EGL_ANGLE_X11_VISUAL_ID that is not equal to the ID of the
+ native_window's visual, an EGL_BAD_MATCH error is generated and
+ EGL_NO_SURFACE is returned."
+
+New Behavior
+
+ To request a display created with a X11 visual ID, the value of
+ EGL_ANGLE_X11_VISUAL_ID should be set to a valid X11 visual ID. If
+ present, this ID will be used during display creation to make a
+ display that is more compatible and potentially more performant when
+ used with EGLsurfaces created from native types with this ID. If the
+ visual ID passed isn't a valid visual ID, eglGetPlatformDisplay will
+ return EGL_NO_DISPLAY and generate an EGL_NOT_INITIALIZED error.
+
+Issues
+
+ 1) When the hint is present, should EGLsurface creation functions
+ only accept native types with the hint's visual ID?
+
+ RESOLVED: Yes, generate an error when the visual of the native
+ surface doesn't match. This will avoid having hidden performance
+ or compatibility losses when using this extension.
+
+Revision History
+
+ Version 1, 2015-11-13 (Corentin Wallez)
+ - Initial draft
+
diff --git a/src/third_party/angle/extensions/EGL_CHROMIUM_create_context_bind_generates_resource.txt b/src/third_party/angle/extensions/EGL_CHROMIUM_create_context_bind_generates_resource.txt
new file mode 100644
index 0000000..b34ce82
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_CHROMIUM_create_context_bind_generates_resource.txt
@@ -0,0 +1,87 @@
+Name
+
+ CHROMIUM_create_context_bind_generates_resource
+
+Name Strings
+
+ EGL_CHROMIUM_create_context_bind_generates_resource
+
+Contributors
+
+ Geoff Lang
+
+Contacts
+
+ Geoff Lang (geofflang 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1, September 21, 2016
+
+Number
+
+ EGL Extension #??
+
+Dependencies
+
+ Requires EGL 1.4.
+
+ Written against the EGL 1.4 specification.
+
+ This spec interacts with GL_CHROMIUM_bind_generates_resource (or
+ equivalent) extension.
+
+Overview
+
+ This extension allows the creation of an OpenGL or OpenGL ES context that
+ allows or disallows implicit creation of OpenGL resources on bind.
+
+New Types
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as an attribute name in the <*attrib_list> argument to
+ eglCreateContext:
+
+ EGL_CONTEXT_BIND_GENERATES_RESOURCE_CHROMIUM 0x3AAD
+
+Additions to the EGL 1.4 Specification
+
+ Add the following to section 3.7.1 "Creating Rendering Contexts":
+
+ EGL_CONTEXT_BIND_GENERATES_RESOURCE_CHROMIUM indicates whether the context
+ should be created with the GL_BIND_GENERATES_RESOURCE_CHROMIUM state
+ initialized to GL_TRUE or GL_FALSE. The default value of
+ EGL_CONTEXT_BIND_GENERATES_RESOURCE_CHROMIUM is EGL_TRUE.
+
+Errors
+
+ None
+
+New State
+
+ None
+
+Conformance Tests
+
+ TBD
+
+Issues
+
+ None
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ------------- --------- ----------------------------------------
+ 1 Sept 21, 2016 geofflang Initial version
diff --git a/src/third_party/angle/extensions/EGL_CHROMIUM_get_sync_values.txt b/src/third_party/angle/extensions/EGL_CHROMIUM_get_sync_values.txt
new file mode 100644
index 0000000..d95b348
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_CHROMIUM_get_sync_values.txt
@@ -0,0 +1,131 @@
+Name
+
+ CHROMIUM_get_sync_values
+
+Name Strings
+
+ EGL_CHROMIUM_get_sync_values
+
+Contact
+
+ Stéphane Marchesin, Google (marcheu 'at' google.com)
+
+Status
+
+ Draft.
+
+Version
+
+ Last Modified Date: N/A Revision: 1.0
+
+ Based on GLX_OML_sync_control Revision 6.0
+
+Number
+
+ ???
+
+Dependencies
+
+ The extension is written against the EGL 1.2 Specification, although it
+ should work on other versions of these specifications. This extension
+ also requires an operating system which supports CLOCK_MONOTONIC.
+
+Overview
+
+ This extension provides counters which let applications know about the
+ timing of the last vertical retrace. By looking at the system clock, as
+ well as the refresh rate of the monitor, this should enable applications
+ to predict the position of future retraces so as to schedule an optimal
+ workload.
+
+ This extension incorporates the use of three counters that provide
+ the necessary synchronization. The Unadjusted System Time (or UST)
+ is the 64-bit CLOCK_MONOTONIC clock; in particular this lets the
+ application schedule future vertical retraces by querying this clock.
+ The graphics Media Stream Counter (or graphics MSC) is a counter
+ that is unique to the graphics subsystem and increments for each
+ vertical retrace that occurs. The Swap Buffer Counter (SBC) is an
+ attribute of an EGLSurface and is incremented each time a swap
+ buffer action is performed on the associated surface.
+
+ The use of these three counters allows the application to
+ synchronize graphics rendering to vertical retraces and/or swap
+ buffer actions. For example, by querying the synchronization values for
+ a given surface, the application can accurately predict the timing for
+ the next vertical retraces and schedule rendering accordingly.
+
+Issues
+
+ None.
+
+IP Status
+
+ No known issues.
+
+New Procedures and Functions
+
+ Bool eglGetSyncValuesCHROMIUM(EGLDisplay dpy,
+ EGLSurface surface,
+ int64_t* ust,
+ int64_t* msc,
+ int64_t* sbc)
+
+
+New Tokens
+
+ None
+
+Additions to the EGL 1.3 Specification
+
+ eglGetSyncValuesCHROMIUM returns the current UST/MSC/SBC triple. A UST
+ timestamp is obtained each time the graphics MSC is incremented.
+ If this value does not reflect the value of the UST at the time the
+ first scan line of the display begins passing through the video
+ output port, it will be adjusted by the graphics driver to do so
+ prior to being returned by any of the functions defined by this
+ extension.
+
+ This UST timestamp, together with the current graphics MSC and the
+ current SBC, comprise the current UST/MSC/SBC triple. The UST,
+ graphics MSC, and SBC values are not part of the render context
+ state. These values cannot be pushed or popped. The graphics MSC
+ value is initialized to 0 when the graphics device is initialized.
+ The SBC is per-surface state and is initialized to 0 when the
+ EGLSurface data structure is initialized.
+
+ The SBC value is incremented by the graphics driver at the completion
+ of each buffer swap (e.g., the pixel copy has been completed or the
+ hardware register that swaps memory banks has been written). For pixel
+ formats that do not contain a back buffer, the SBC will always be
+ returned as 0.
+
+ The graphics MSC value is incremented once for each screen refresh.
+ For a non-interlaced display, this means that the graphics MSC value
+ is incremented for each frame. For an interlaced display, it means
+ that it will be incremented for each field. For a multi-monitor
+ system, the monitor used to determine MSC is the one where the surface
+ is located. If the surface spans multiple monitors, the monitor used
+ to determine MSC is the one with the biggest coverage in pixels.
+
+ The function eglGetSyncValuesCHROMIUM will return TRUE if the function
+ completed successfully, FALSE otherwise.
+
+ Each time eglSwapBuffer succeeds, the SBC will be increased within a
+ finite time period.
+
+Errors
+
+ eglGetSyncValuesCHROMIUM will return FALSE if there is no current
+ EGLContext.
+
+New State
+
+ Get Value Get Command Type Initial Value
+ --------- ----------- ---- -------------
+ [UST] eglGetSyncValuesCHROMIUM Z unspecified
+ [MSC] eglGetSyncValuesCHROMIUM Z 0
+ [SBC] eglGetSyncValuesCHROMIUM Z 0
+
+New Implementation Dependent State
+
+ None
diff --git a/src/third_party/angle/extensions/EGL_EXT_device_query.txt b/src/third_party/angle/extensions/EGL_EXT_device_query.txt
new file mode 100644
index 0000000..d92fb6d
--- /dev/null
+++ b/src/third_party/angle/extensions/EGL_EXT_device_query.txt
@@ -0,0 +1,188 @@
+Name
+
+ EXT_device_query
+
+Name Strings
+
+ EGL_EXT_device_query
+
+Contributors
+
+ James Jones, NVIDIA (jajones 'at' nvidia.com)
+ Jamie Madill, Google (jmadill 'at' google.com)
+
+Contacts
+
+ Jamie Madill, Google (jmadill 'at' google.com)
+
+Status
+
+ Draft
+
+Version
+
+ Version 1 - Mar 25rd, 2015
+
+Number
+
+ EGL Extension #XXX
+
+Extension Type
+
+ EGL client extension
+
+Dependencies
+
+ Written against the wording of EGL 1.5.
+
+ Requires EGL 1.5 or an earlier verison of EGL with the
+ EGL_EXT_client_extensions extension.
+
+Overview
+
+ Increasingly, EGL and its client APIs are being used in place of
+ "native" rendering APIs to implement the basic graphics
+ functionality of native windowing systems. This creates demand
+ for a method to access native GPU or device objects directly
+ rather than calling EGL or GL entry points.
+
+ This extension defines the method for an application to query
+ native device objects from an EGL Display.
+
+New Types
+
+ This is the type of a handle that represents an EGLDeviceEXT
+ object.
+
+ typedef void* EGLDeviceEXT;
+
+ If EGL 1.5 is not supported, the following type is added, as
+ defined in the EGL 1.5 specification:
+
+ typedef intptr_t EGLAttrib;
+
+New Functions
+
+ EGLBoolean eglQueryDeviceAttribEXT(EGLDeviceEXT device,
+ EGLint attribute,
+ EGLAttrib *value);
+
+ const char *eglQueryDeviceStringEXT(EGLDeviceEXT device,
+ EGLint name);
+
+ EGLBoolean eglQueryDisplayAttribEXT(EGLDisplay dpy,
+ EGLint attribute,
+ EGLAttrib *value);
+
+New Tokens
+
+ Functions with a return type of EGLDeviceEXT will return this
+ value on failure:
+
+ EGL_NO_DEVICE_EXT ((EGLDeviceEXT)0)
+
+ This error value will be generated by functions that take an
+ EGLDeviceEXT object as a parameter:
+
+ EGL_BAD_DEVICE_EXT 0x322B
+
+ Accepted by the <attribute> parameter of
+ eglQueryDisplayAttribEXT:
+
+ EGL_DEVICE_EXT 0x322C
+
+Add a new section "2.1.2 Devices" after "2.1.1 Scalar Types"
+
+ All EGL operations occur on an EGLDeviceEXT. However, devices
+ themselves expose no functionality. They are simple abstract
+ objects that exist only for the sake of enumeration and
+ defining a namespace.
+
+Modify the last sentence of section "2.1.3" Displays" to read:
+
+ Besides devices, objects are always specified by the combination
+ of an EGLDisplay parameter with a parameter representing the
+ handle of the object.
+
+Add a new extension type to the list in section "2.8 Extensions"
+
+ Device Extensions
+ A *device extension* adds functionality to an individual
+ EGLDeviceEXT. Different instances of EGLDeviceEXT may support
+ different sets of device extensions
+
+Add a new error to section "3.1 Errors"
+
+ EGL_BAD_DEVICE_EXT
+ An EGLDeviceEXT argument does not refer to a valid
+ EGLDeviceEXT. Any command taking an EGLDeviceEXT parameter
+ may generate this error.
+
+Add a section "3.2 Devices" after "3.1 Errors"
+
+ To query the properties of a device, use:
+
+ EGLBoolean eglQueryDeviceAttribEXT(EGLDeviceEXT device,
+ EGLint attribute,
+ EGLAttrib *value);
+
+ On success, EGL_TRUE is returned and the requested attribute value
+ is returned in <value>. Currently there are no valid values of
+ <attribute> defined.
+
+ On failure, EGL_FALSE is returned. An EGL_BAD_ATTRIBUTE error is
+ generated if <attribute> is not a valid attribute. An
+ EGL_BAD_DEVICE_EXT error is generated if <device> is not a valid
+ EGLDeviceEXT.
+
+ const char *eglQueryDeviceStringEXT(EGLDeviceEXT device,
+ EGLint name);
+
+ returns a pointer to a static, zero-terminated string describing
+ some aspect of the specified EGLDeviceEXT. <name> must be
+ EGL_EXTENSIONS.
+
+ The EGL_EXTENSIONS string describes which device extensions are
+ supported by <device>. The string is of the same format specified
+ for display and client extension strings in section 3.4. Note that
+ device extensions are properties of the device, and are distinct
+ from other extension strings.
+
+ On failure, NULL is returned. An EGL_BAD_DEVICE_EXT error is
+ generated if <device> is not a valid EGLDeviceEXT. An
+ EGL_BAD_PARAMETER error is generated if <name> is not one of the
+ values described above.
+
+Add a section "3.4 Display Attributes" after "3.3 EGL Versioning"
+
+ To query attributes of an initialized display, use:
+
+ EGLBoolean eglQueryDisplayAttribEXT(EGLDisplay dpy,
+ EGLint name,
+ EGLAttrib *value);
+
+ On success, EGL_TRUE is returned. If <name> is EGL_DEVICE_EXT,
+ the EGLDeviceEXT associated with <dpy> is returned in <value>.
+ All displays have an associated EGLDeviceEXT, regardless of how
+ they were created. A successful query of EGL_DEVICE_EXT will
+ never return EGL_NO_DEVICE_EXT.
+
+ On failure, EGL_FALSE is returned. An EGL_NOT_INITIALIZED error
+ is generated if EGL is not initialized for <dpy>. An
+ EGL_BAD_ATTRIBUTE error is generated if <name> is not a valid
+ value.
+
+ Because the EGLDeviceEXT is a property of <dpy>, any use of an
+ associated EGLDeviceEXT after <dpy> has been terminated gives
+ undefined results. Querying an EGL_DEVICE_EXT from <dpy> after a
+ call to eglTerminate() (and subsequent re-initialization) may
+ return a different value.
+
+Issues
+
+ None.
+
+Revision History:
+
+ #1 (Mar 25rd, 2015) Jamie Madill
+ - Initial Draft based on EGL_EXT_device_base
diff --git a/src/third_party/angle/extensions/EXT_blend_func_extended.txt b/src/third_party/angle/extensions/EXT_blend_func_extended.txt
new file mode 100644
index 0000000..13f93e6
--- /dev/null
+++ b/src/third_party/angle/extensions/EXT_blend_func_extended.txt
@@ -0,0 +1,771 @@
+Name
+
+ EXT_blend_func_extended
+
+Name Strings
+
+ GL_EXT_blend_func_extended
+
+Contact
+
+ Mark Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
+
+Contributors
+
+ Daniel Koch, NVIDIA
+ Slawomir Grajewski, Intel
+ Chris Dalton, NVIDIA
+ Brian Salomon, Google
+
+ From ARB_blend_func_extended...
+
+ Graham Sellers, AMD
+ Mark Young, AMD
+ Nick Haemel, AMD
+ Pierre Boudier, AMD
+ Mais Alnasser, AMD
+ Jeff Bolz, NVIDIA
+ Pat Brown, NVIDIA
+ Ian Stewart, NVIDIA
+ Jon Leech, Khronos
+
+Status
+
+ Draft, almost complete
+
+Version
+
+ Last Modified Date: July 29, 2015
+ Revision: 5
+
+Number
+
+ XXX
+
+Dependencies
+
+ This extension is written against the OpenGL ES 3.1 (June 4, 2014)
+ specification, but can apply to earlier versions back to ES 2.0.
+
+ GLSL version 300 and 310 language is written against The OpenGL ES
+ Shading Language (July 11, 2012).
+
+ GLSL version 100 language is written against The OpenGL ES Shading
+ Language (May 12, 2009).
+
+ The NV_draw_buffers and EXT_draw_buffers extensions trivially affect
+ the definition of this extension.
+
+ The EXT_draw_buffers_indexed extension affects the definition of
+ this extension.
+
+Overview
+
+ This extension provides an ES version of the ARB_blend_func_extended
+ functionality.
+
+ Traditional OpenGL includes fixed-function blending that combines
+ source colors with the existing content of a render buffer in
+ a variety of ways. A number of extensions have enhanced this
+ functionality by adding further sources of blending weights and
+ methods to combine them. However, the inputs to the fixed-function
+ blending units are constrained to a source color (as output from
+ fragment shading), destination color (as the current content of the
+ frame buffer) or constants that may be used in their place.
+
+ This extension adds new blending functions whereby a fragment
+ shader may output two colors, one of which is treated as the
+ source color, and the other used as a blending factor for either
+ source or destination colors. Furthermore, this extension increases
+ orthogonality by allowing the SRC_ALPHA_SATURATE function to be used
+ as the destination weight.
+
+ Because of the limitations of the OpenGL ES 2.0 shading language,
+ new built-in variables (gl_SecondaryFragColorEXT,
+ gl_SecondaryFragDataEXT) are added to the ES 1.00 shading language
+ rather than introduce more complex features for user-defined fragment
+ outputs. Because such built-in variable are deprecated in ES 3.0,
+ these variables are NOT available in the OpenGL ES 3.xx shading
+ language verisons.
+
+IP Status
+
+ No known IP claims.
+
+New Procedures and Functions
+
+ void BindFragDataLocationIndexedEXT(uint program, uint colorNumber,
+ uint index, const char * name);
+
+ int GetFragDataIndexEXT(uint program, const char * name);
+
+ void BindFragDataLocationEXT(uint program, uint colorNumber, const char * name)
+
+ int GetProgramResourceLocationIndexEXT(uint program, enum programInterface, const char *name);
+
+New Tokens
+
+ Accepted by the <src> and <dst> parameters of BlendFunc and
+ BlendFunciEXT, and by the <srcRGB>, <dstRGB>, <srcAlpha> and <dstAlpha>
+ parameters of BlendFuncSeparate and BlendFuncSeparateiEXT:
+
+ SRC1_COLOR_EXT 0x88F9
+ SRC1_ALPHA_EXT 0x8589 // OpenGL 1.5 token value
+ ONE_MINUS_SRC1_COLOR_EXT 0x88FA
+ ONE_MINUS_SRC1_ALPHA_EXT 0x88FB
+ SRC_ALPHA_SATURATE_EXT 0x0308
+
+ Accepted in the <props> array of GetProgramResourceiv:
+
+ LOCATION_INDEX_EXT 0x930F
+
+ Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
+ and GetFloatv:
+
+ MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT 0x88FC
+
+Additions to Chapter 7 of the OpenGL ES 3.1 Specification (Programs and
+Shaders)
+
+ Add a row to table 7.2 "GetProgramResourceiv properties and supported
+ interfaces" (page 82):
+
+ Property Supported Interfaces
+ ------------------ --------------------
+ LOCATION_INDEX_EXT PROGRAM_OUTPUT
+
+ Modify section 7.3.1.1 "Naming Active Resources" subsection to include
+ after the LOCATION paragraph (page 84):
+
+ "For the property LOCATION_INDEX_EXT, a single integer identifying the
+ fragment color index of an active fragment shader output variable
+ is written to params. If the active variable is not an output for a
+ fragment shader, the value -1 will be written to params."
+
+ Modify (page 87) the paragraph introducing GetProgramResourceLocation
+ to begin:
+
+ "The commands
+
+ int GetProgramResourceLocation( uint program,
+ enum programInterface, const char *name );
+ int GetProgramResourceLocationIndexEXT( uint program,
+ enum programInterface, const char *name );
+
+ return the location or the fragment color index, respectively,
+ assigned to the variable named name in interface programInterface
+ of program object program."
+
+ Change the ending of the same paragraph to read:
+
+ "For GetProgramResourceLocationIndexEXT, programInterface must be
+ PROGRAM_OUTPUT. The value -1 will be returned by either command if
+ an error occurs, if name does not identify an active variable on
+ programInterface, or if name identifies an active variable that
+ does not have a valid location assigned, as described above. The
+ locations returned by these commands are the same locations returned
+ when querying the LOCATION and LOCATION_INDEX resource properties."
+
+ Change the next paragaph to begin:
+
+ "A string provided to GetProgramResourceLocation or
+ GetProgramResourceLocationIndexEXT is considered to match an active
+ variable if ..."
+
+ Change the last paragraph of the section (page 88) to read:
+
+ ... "If the string specifies an element of an array variable,
+ GetProgramResourceLocation and GetProgramResourceLocationIndexEXT
+ return the location or fragment color index assigned to that
+ element. If it specifies the base name of an array, it identifies
+ the resources associated with the first element of the array."
+
+Additions to Chapter 14 of the OpenGL ES 3.1 Specification (Programmable
+Fragment Processing)
+
+ Modify section 14.2.3 "Shader Outputs" subsection to include:
+
+ "The binding of a user-defined varying out variable to a fragment color number
+ can be specified explicitly. The command
+
+ void BindFragDataLocationIndexedEXT(uint program, uint colorNumber,
+ uint index, const char * name);
+
+ specifies that the varying out variable name in <program> should
+ be bound to fragment color <colorNumber> when the program is next
+ linked. <index> may be zero or one to specify that the color
+ be used as either the first or second color input to the blend
+ equation, respectively, as described in Section 15.1.5 (Blending).
+ If <name> was bound previously, its assigned binding is replaced
+ with colorNumber. <name> must be a null-terminated string. The error
+ INVALID_VALUE is generated if <colorNumber> is equal or greater
+ than the value of MAX_DRAW_BUFFERS and <index> is zero,
+ or if <colorNumber> is equal or greater than the value of
+ MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT and <index> is greater than or
+ equal to one. The command
+
+ void BindFragDataLocationEXT(uint program, uint colorNumber,
+ const char * name)
+
+ is equivalent to calling BindFragDataLocationIndexedEXT with the
+ same values for <program>, <colorNumber> and <name>, and with <index>
+ set to zero.
+
+ When a program is linked, any varying out variables without
+ a binding specified through BindFragDataLocationIndexedEXT or
+ BindFragDataLocationEXT will automatically be bound to fragment
+ colors and indices by the GL. All such assignments will use color
+ indices of zero. Such bindings can be queried using the commands
+ GetFragDataLocation and GetFragDataIndexEXT. Output binding
+ assignments will cause LinkProgram to fail:
+
+ * if the number of active outputs is greater than the value of
+ MAX_DRAW_BUFFERS_EXT;
+
+ * if the program has an active output assigned to a location greater
+ than or equal to the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT
+ and has an active output assigned an index greater than or equal
+ to one;
+
+ * if more than one varying out variable is bound to the same number
+ and index; or
+
+ * if the explicit binding assignments do not leave enough space
+ for the linker to automatically assign a location for a varying
+ out array, which requires multiple contiguous locations.
+
+ BindFragDataLocationIndexedEXT may be issued before any shader objects
+ are attached to a program object. Hence it is allowed to bind any
+ name (except a name starting with gl_) to a color number and index,
+ including a name that is never used as a varying out variable in
+ any fragment shader object. Assigned bindings for variables that
+ do not exist are ignored."
+
+ Add to end of section:
+
+ "The command
+
+ int GetFragDataIndexEXT(uint program, const char * name);
+
+ returns the index of the fragment color to which the variable <name>
+ was bound when the program object <program> was last linked. If
+ program has not been successfully linked, the error INVALID_OPERATION
+ is generated. If name is not a varying out variable, or if an error
+ occurs, -1 will be returned. The command is equivalent to
+
+ GetProgramResourceLocationIndex(program, PROGRAM_OUTPUT, name);"
+
+Additions to Chapter 15 of the OpenGL ES 3.1 Specification (Writing
+Fragments and Samples to the Framebuffer)
+
+ Modify section 15.1.5.2 "Blend Functions":
+
+ Change the first paragraph to read:
+
+ "The weighting factors used by the blend equation are determined by
+ the blend functions. There are four possible sources for weighting
+ factors. These are the constant color (Rc, Gc, Bc, Ac) (see
+ BlendColor, p. 211), the first source color (Rs0, Gs0, Bs0, As0),
+ the second source color (Rs1, Gs1, Bs1, As1), and the destination
+ color (the existing content of the draw buffer). Additionally the
+ special constants ZERO and ONE are available as weighting factors."
+
+ Modify Table 15.2 (RGB and ALPHA source and destination blend
+ functions ...) as follows
+
+ RGB Blend Factors Alpha Blend Factors
+ Value (Sr, Sg, Sb) or (Dr, Dg, Db) Sa or Da
+ ----- ---------------------------- -------------------
+ ZERO (0, 0, 0) 0
+ ONE (1, 1, 1) 1
+ SRC_COLOR (Rs0, Gs0, Bs0) As0
+ ONE_MINUS_SRC_COLOR (1, 1, 1) - (Rs0, Gs0, Bs0) 1 - As0
+ DST_COLOR (Rd, Gd, Bd) Ad
+ ONE_MINUS_DST_COLOR (1, 1, 1) - (Rd, Gd, Bd) 1 - Ad
+ SRC_ALPHA (As0, As0, As0) As0
+ ONE_MINUS_SRC_ALPHA (1, 1, 1) - (As0, As0, As0) 1 - As0
+ DST_ALPHA (Ad, Ad, Ad) Ad
+ ONE_MINUS_DST_ALPHA (1, 1, 1) - (Ad, Ad, Ad) 1 - Ad
+ CONSTANT_COLOR (Rc, Gc, Bc) Ac
+ ONE_MINUS_CONSTANT_COLOR (1, 1, 1) - (Rc, Gc, Bc) 1 - Ac
+ CONSTANT_ALPHA (Ac, Ac, Ac) Ac
+ ONE_MINUS_CONSTANT_ALPHA (1, 1, 1) - (Ac, Ac, Ac) 1 - Ac
+ SRC_ALPHA_SATURATE (f, f, f) 1 New (for ES 2.x)
+ SRC1_COLOR_EXT (Rs1, Gs1, Bs1) As1 New
+ ONE_MINUS_SRC1_COLOR_EXT (1, 1, 1) - (Rs1, Gs1, Bs1) 1 - As1 New
+ SRC1_ALPHA_EXT (As1, As1, As1) As1 New
+ ONE_MINUS_SRC1_ALPHA_EXT (1, 1, 1) - (As1, As1, As1) 1 - As1 New
+
+ For ES 2.0, remove table's footnote saying (ES 3.x already has this
+ removed):
+
+ SRC_ALPHA_SATURATE is valid only for source RGB and alpha
+ blending functions.
+
+ Add the following subsections to Section 5.1.5 Blending, at the end
+ of the subsection 15.1.5.2 "Blend Functions":
+
+ "15.1.5.X Dual Source Blending and Multiple Draw Buffers
+
+ Blend functions that require the second color input, <Rs1, Gs1, Bs1,
+ As1> (SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or
+ ONE_MINUS_SRC1_ALPHA_EXT) may consume hardware resources that could
+ otherwise be used for rendering to multiple draw buffers. Therefore,
+ the number of draw buffers that can be attached to a frame buffer
+ may be lower when using dual-source blending.
+
+ The maximum number of draw buffers that may be attached to a
+ single frame buffer when using dual-source blending functions is
+ implementation dependent and can be queried by calling GetIntegerv
+ with the symbolic constant MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT. When
+ using dual-source blending, MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT should be
+ used in place of MAX_DRAW_BUFFERS_EXT to determine the maximum number
+ of draw buffers that may be attached to a single frame buffer. The
+ value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must be at least 1. If
+ the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT is 1, then dual-source
+ blending and multiple draw buffers cannot be used simultaneously.
+
+ If either blend function is set to one of the second source factors
+ (SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or
+ ONE_MINUS_SRC1_ALPHA_EXT) for any draw buffer and any draw buffers
+ equal to or greater than the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT
+ have values other than NONE, the error INVALID_OPERATION is generated
+ by drawing commands.
+
+ 15.1.5.Y Generation of Second Color Source for Blending
+
+ Rendering using any of the blend functions that consume the second
+ input color (SRC1_COLOR_EXT, ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT
+ or ONE_MINUS_SRC1_ALPHA_EXT) using a shader that does not output
+ a second source color will produce undefined results. To produce
+ input for the second source color, a shader must be used that outputs
+ a second source color.
+
+ When using a GLSL version 300 es or higher fragment shader with
+ dual-source blending functions, the color output varyings are bound
+ to the first (index 0) and second (index 1) inputs of a draw buffer
+ using BindFragDataLocationIndexedEXT as described in the "Shader
+ Outputs" subsection of Section 3.12.2 or by layout qualifiers for
+ location=/n/ and index=/m/. Data written to the first of these outputs
+ becomes the first source color input to the blender (corresponding
+ to SRC_COLOR and SRC_ALPHA). Data written to the second of these
+ outputs generates the second source color input to the blender
+ (corresponding to SRC1_COLOR_EXT and SRC1_ALPHA_EXT).
+
+ Alternatively if the GLSL version 100 fragment shader is used (where
+ user-defined color outputs are unsupported, hence a user-defined
+ color output is not available for BindFragDataLocationIndexEXT), the
+ gl_FragColor and gl_SecondaryFragColorEXT fragment outputs correspond
+ to the first and second source color respectively. Similarly the
+ gl_FragData and gl_SecondaryFragDataEXT fragment output arrays
+ correspond to the first and second source color respectively of each
+ color buffer output.
+
+ If the second color input to the blender is not written in the
+ shader, or if no output is bound to the second input of a blender,
+ the result of the blending operation is not defined.
+
+ Other shading languages may define similar methods for producing
+ the first and second color inputs to blending equations."
+
+Additions to the OpenGL ES Shading Language 1.00 Specification
+
+ Including the following line in a shader can be used to control the
+ language features described in this extension:
+
+ #extension GL_EXT_blend_func_extended : <behavior>
+
+ where <behavior> is as specified in section 3.4.
+
+ A new preprocessor #define is added to the OpenGL ES Shading Language:
+
+ #define GL_EXT_blend_func_extended 1
+
+ Modify paragraphs in section 7.2 "Fragment Shader Special Variables" as follows:
+
+ First paragraph, second sentence:
+
+ "Fragment shaders output values to the OpenGL ES pipeline using
+ the built-in variables gl_FragColor, gl_SecondaryFragColorEXT,
+ gl_FragData, and gl_SecondaryFragDataEXT, unless the discard keyword
+ is executed."
+
+ Second paragraph, first sentence:
+
+ "It is not a requirement for the fragment shader to write to
+ either gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData, or
+ gl_SecondaryFragDataEXT."
+
+ Add after the fourth paragraph:
+
+ "Writing to gl_SecondaryFragColorEXT specifies a second fragment color
+ that will be used by the subsequent fixed functionality pipeline for
+ dual source blending. If subsequent fixed functionality consumes the
+ second fragment color and an execution of a fragment shader does
+ not write a value to gl_SecondaryFragColorEXT then the secondary
+ fragment color consumed is undefined."
+
+ Add after the fifth paragraph:
+
+ "The variable gl_SecondaryFragDataEXT is an array. Writing to
+ gl_SecondaryFragDataEXT[n] specifies the secondary fragment data that
+ will be used by the subsequent fixed functionality pipeline for data n
+ for dual source blending. If subsequent fixed functionality consumes
+ secondary fragment data and an execution of a fragment shader does
+ not write a value to it, then the secondary fragment data consumed
+ is undefined."
+
+ Modify the sixth paragraph to read:
+
+ "If a shader statically assigns a value to gl_FragColor or
+ gl_SecondaryFragColorEXT, it may not assign a value to any
+ element of gl_FragData or gl_SecondaryFragDataEXT. If a shader
+ statically writes a value to any element of gl_FragData or
+ gl_SecondaryFragDataEXT, it may not assign a value to gl_FragColor
+ or gl_SecondaryFragColorEXT. That is, a shader may assign values to
+ either the set of gl_FragColor and gl_SecondaryFragColorEXT or the
+ set of gl_FragData and gl_SecondaryFragDataEXT, but not both."
+
+ Modify the eighth paragraph to read:
+
+ "If a shader executes the discard keyword, the fragment is discarded,
+ and the values of gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData,
+ and gl_SecondaryFragDataEXT become irrelevant."
+
+ Add these built-in variable to the list "accessible from a fragment shader":
+
+ mediump vec4 gl_SecondaryFragColorEXT;
+ mediump vec4 gl_SecondaryFragDataEXT[gl_MaxDualSourceDrawBuffersEXT];
+
+ Add to section 7.4 "Built-In Constants" the following constant:
+
+ const mediump int gl_MaxDualSourceDrawBuffersEXT = 1;
+
+Additions to the OpenGL ES Shading Language 3.00 and 3.10 Specification
+
+ Including the following line in a shader can be used to control the
+ language features described in this extension:
+
+ #extension GL_EXT_blend_func_extended : <behavior>
+
+ where <behavior> is as specified in section 3.4.
+
+ A new preprocessor #define is added to the OpenGL ES Shading Language:
+
+ #define GL_EXT_blend_func_extended 1
+
+ Modify section 4.4.2 "Output Layout Qualifiers":
+
+ Change the second paragraph to read:
+
+ "Fragment shaders allow output layout qualifiers only on the interface
+ qualifier out. The layout qualifier identifier for fragment shader
+ outputs is:
+
+ layout-qualifier-id
+ location = integer-constant
+ index = integer-constant
+
+ Each of these qualifiers may appear at most once. If index is
+ specified, location must also be specified. If index is not
+ specified, the value 0 is used."
+
+ Add an additional example to the end of the fourth paragraph's example:
+
+ "And,
+
+ layout(location = 3, index = 1) out vec4 factor;
+
+ will establish that the fragment shader output factor is copied out
+ to fragment color 3 as the second (index one) input to the blend
+ equation."
+
+ Change the first sentence of the second to last paragraph to read:
+
+ "If there is more than one fragment output, the location must
+ be specified for all outputs unless the EXT_blend_func_extended
+ extension is enabled in which case more than one unassigned fragment
+ output locations are allowed though they must be assigned to unique
+ locations assigned with glBindFragDataLocationIndexedEXT prior to
+ linking."
+
+ Add to section 7.4 "Built-In Constants" the following constant:
+
+ const mediump int gl_MaxDualSourceDrawBuffersEXT = 1;
+
+Dependencies on OpenGL ES 3.0
+
+ If OpenGL ES 3.0 or higher is not supported (meaning OpenGL ES 2.0
+ support only), remove all references to the functions:
+
+ BindFragDataLocationIndexedEXT
+ GetFragDataIndexEXT
+ BindFragDataLocationEXT
+ GetProgramResourceLocationIndexEXT
+
+ Also ignore the additions to chapters 7 and 14 and the paragraph in
+ section 15.1.5.Y related to GLSL version 300 es or higher.
+
+ When OpenGL ES 3.0 or higher, the "Additions to the OpenGL ES
+ Shading Language 1.00 Specification" applies to the version 100
+ shading language, but not later versions.
+
+Dependencies on OpenGL ES 3.1
+
+ If OpenGL ES 3.1 or higher is not supported (meaning OpenGL ES 3.0
+ or earlier), remove all references to the function
+
+ GetProgramResourceLocationIndexEXT
+
+ because program resource queries are added by ES 3.1.
+
+ Also ignore the additions to chapter 7.
+
+Dependencies on EXT_draw_buffers or NV_draw_buffers
+
+ Using dual-source blending functions may consume additional outputs
+ from hardware shading units and therefore can reduce the number
+ of draw buffers that may be attached to a single frame buffer when
+ dual-source blending functions are enabled. In this case, the value
+ of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT may be less than the value of
+ MAX_DRAW_BUFFERS_EXT. If EXT_draw_buffers or NV_draw_buffers is not
+ supported then the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must
+ be 1. Furthermore, the discussion in the subsection entitled "Dual
+ Source Blending and Multiple Draw Buffers" may be discarded.
+
+Dependencies on EXT_draw_buffers_indexed
+
+ If EXT_draw_buffers_indexed is not supported, all references to
+ BlendFunciEXT and BlendFuncSeparateiEXT should be removed. In this
+ case, the blend functions for all attached draw buffers will be the
+ same.
+
+Errors
+
+ The error INVALID_OPERATION is generated by Begin or any
+ procedure that implicitly calls Begin if any draw buffer has a
+ blend function requiring the second color input (SRC1_COLOR_EXT,
+ ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT or ONE_MINUS_SRC1_ALPHA_EXT),
+ and a framebuffer is bound that has more than the value of
+ MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT-1 active color attachments.
+
+New State
+
+ None
+
+ While no changes to table 20.12 (Pixel Operations) are strictly
+ necessary, new enumerations are supported for the BLEND_SRC_RGB,
+ BLEND_SRC_ALPHA, BLEND_DST_RGB, and BLEND_DST_ALPHA state to support
+ SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, and
+ ONE_MINUS_SRC1_ALPHA_EXT (and for ES 2.0, SRC_ALPHA_SATURATE_EXT).
+
+New Implementation Dependent State
+
+ Get Value Type Get Command Minimum Value Description Sec.
+ --------- ---- ----------- ------------- ------------------- ------
+ MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT Z+ GetIntegerv 1 Maximum number of 15.1.5
+ active draw buffers
+ when using dual-source
+ blending
+
+Example Use Cases
+
+ There are several potential uses for this functionality. A first
+ example is in the implementation of sub-pixel accurate font rendering
+ algorithms. Given a known layout of pixel elements (red, green
+ and blue components), coverage may be calculated independently for
+ each element and passed to the blender in the second source color
+ as a per-channel opacity. To use this mode, use the following blend
+ functions:
+
+ glBlendFunc(GL_SRC1_COLOR_EXT, GL_ONE_MINUS_SRC1_COLOR_EXT);
+
+ As a second example, consider a partially reflective colored glass
+ window. It will attenuate light passing through it, and reflect
+ some of the light that strikes it. Using an appropriate combination
+ of functions, this effect may be simulated in a single pass using
+ only fixed-function blending hardware. In this case, the following
+ blend functions may be used:
+
+ glBlendFunc(GL_SRC_ALPHA, GL_SRC1_COLOR_EXT);
+
+Issues
+
+ 0. What should this extension be named?
+
+ RESOLVED: EXT_blend_func_extended, matching the name of
+ ARB_blend_func_extended upon which this extension is based but
+ providing a multi-vendor extension for ES implementations.
+
+ 1. Is this extension compatible with the ARB_blend_func_extended
+ version?
+
+ RESOLVED: Yes. This extension is 100% functionally identical to
+ ARB_blend_func_extended but for the ES 2.x and 3.x APIs.
+
+ The token values are _EXT suffixed but have the same values as
+ the ARB_blend_func_extended tokens.
+
+ Philosophically if this extension is going for 100% parity and
+ functionality with ARB_blend_func_extended, it should simply add
+ all the stuff in ARB_blend_func_extended...
+
+ 2. Should the next commands be EXT suffixed?
+
+ RESOLVED: Yes. This is not an OES extension.
+
+ This means source code coming from a desktop environment should
+ call eglGetProcAddress on function names with the EXT suffix.
+ However because extension functions are called through function
+ pointers, this is only a minor change isolated to function pointer
+ initialization.
+
+ 2. Should this extension allow ES 2.0 contexts to use
+ GL_SRC_ALPHA_SATURATE for the destination blend function?
+
+ RESOLVED: Yes, the ARB_blend_func_extended extension adds support
+ for using GL_SRC_ALPHA_SATURATE as the destination factor as "bonus"
+ functionality.
+
+ ES 3.x already allows GL_SRC_ALPHA_SATURATE for the destination
+ factor so this additional functionality is new only to ES 2.0 contexts
+ supporting this extension.
+
+ We expect no GPU hardware capable of dual-source blending to not
+ also support GL_SRC_ALPHA_SATURATE as the destination factor.
+
+ 3. Should this extension provide the glBindFragDataLocation and
+ glBindFragDataLocationIndexed functionality?
+
+ RESOLVED: Yes. With EXT suffixes.
+
+ 4. Should this really be OES_blend_func_extended?
+
+ RESOLVED: Go with EXT is for expediency.
+
+ Additionally this extension supports functionality such
+ GL_SRC_ALPHA_SATURATE that all desktop GPU hardware is assumed to
+ have. ES-only vendors might not want this in an OES extension.
+
+ The same could be said for the glBindFragDataLocation* functionality.
+
+ 5. Does this extension need an interaction with
+ OES_blend_equation_separate?
+
+ RESOLVED: No, that's an ES 1.1 extension. ES 2.0 and on all support
+ separate blend functions.
+
+ 6. Are there any OpenGL ES Shading Language interactions?
+
+ RESOLVED: Yes, to use this extension, a #extension line will be needed
+ in the shader requesting the EXT_blend_func_extended functionality.
+ Example:
+
+ #extension GL_EXT_blend_func_extended : require
+
+ The ARB_blend_func_extended functionality does NOT require a special
+ #extension line to use its functionality because the ARB version
+ relies on existing GLSL functionality that allows for multiple
+ fragment outputs as part of supporting multiple render targets.
+ In the ARB version, then glBindFragDataLocationIndexed can bind
+ these unassigned locations to different source output colors.
+ But GLSL OpenGL ES 3.00 and 3.10 both explicitly preclude more than
+ one fragment shader output with an unassigned location. Hence a
+ #extension is needed to relax this error condition. And then this
+ extension's glBindFragDataLocationIndexedEXT must be used to assign
+ locations as necessary.
+
+ 7. Can the indexed location be assigned explicitly in the shader?
+
+ RESOLVED: Yes, for ES 3.x shaders where the GLSL ES 3.x supports
+ layout qualifiers. ES 2.0 does not support the layout qualifier or
+ user-defined fragment outputs.
+
+ 8. Should both the layout qualifier mechanism and the
+ glBindFragDataLocationIndexed-style API for specifying the index of
+ a user-defined fragment shader output be supported?
+
+ RESOLVED: Yes, both should be supported. This makes it easier
+ for existing applications to port to ES 3.0 as both mechanisms are
+ available.
+
+ FYI: The "layout(location=0,index=1)" type syntax for dual-source
+ blending was introduced to OpenGL in GLSL 3.30 and 4.00 in
+ conjunction with OpenGL 3.3 and 4.0 respectively. The original
+ ARB_blend_func_extended was written with respect to OpenGL 3.2 and
+ intended to support dual-source blending without the need to extend
+ the GLSL language by instead supporting assignment if the fragment
+ output index via glBindFragDataLocationIndexed.
+
+ 9. How to support OpenGL ES 2.0 where user-defined fragment shader
+ outputs are not supported?
+
+ RESOLVED: Introduce new gl_SecondaryFragColorEXT and
+ gl_SecondaryFragDataEXT built-in variables for specifying the second
+ source color.
+
+ These built-ins are only available in the ES 1.00 shader language
+ version.
+
+ It is important to provide an ES 2.0 mechanism because WebGL 1.0 is
+ based on ES 2.0. Chrome's internal command buffer mechanism is also
+ based around ES 2.0 and Skia intends to use this extension.
+
+ This includes adding a gl_MaxDualSourceDrawBuffersEXT
+ implementation-dependent constant.
+
+ 10. Does the version 100 syntax (gl_SecondaryFragColorEXT,
+ gl_SecondaryFragDataEXT) work in an ES 3.0 context?
+
+ RESOLVED: Yes. For compatibility reasons, an ES 3.0 context
+ advertising EXT_blend_func_extended must support the built-ins for
+ the fragment shader secondary color outputs.
+
+ 11. How many elements should be in the gl_SecondaryFragDataEXT array?
+
+ RESOLVED: The gl_SecondaryFragDataEXT array should have as
+ many elements as the GLSL built-in implementation constant
+ gl_MaxDualSourceDrawBuffersEXT which should be the value of the
+ context's GL_MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT implementation-dependent
+ constant.
+
+ This means the number of elements in gl_SecondaryFragDataEXT is
+ different than the number of gl_FragData elements.
+
+ 12. What precision should the gl_SecondaryFragColorEXT and
+ gl_SecondaryFragDataEXT be?
+
+ RESOLVED: mediump. This is consistent with gl_FragColor and
+ gl_FragData.
+
+ 13. Should gl_MaxDualSourceDrawBuffersEXT be exposed in both ES 2.0
+ (where it sizes the gl_SecondaryFragDataEXT array) and also 3.x
+ contexts (where there is no fixed-function array)?
+
+ RESOLVED: Implementation-wise, it is easiest to expose this
+ implementation-dependent constant for all ES contexts.
+
+ As a practical matter, we don't expect any implementations will
+ advertise any value other than 1 for this constant.
+
+ Note: There is no implementation-dependent GLSL constant comparable
+ to gl_MaxDualSourceDrawBuffersEXT in ARB_blend_func_extended
+ (or OpenGL 3.3/4.0 introducing the ARB_blend_func_extended
+ functionality).
+
+ 14. Any more issues?
+
+ RESOLVED: See the issues in the ARB_blend_func_extended
+ specification. This extension resolves those issues to match the
+ ARB extension version.
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- -------- --------- -----------------------------------------
+ 1 05/22/15 mjk Initial revision.
+ 2 07/06/15 mjk Proper ES 2.0 interactions; complete.
+ 3 07/08/15 mjk Feedback from Brian
+ 4 07/08/15 mjk Feedback from Daniel
+ 5 07/29/15 mjk ES 3.x contexts (as well as 2.0) expose
+ gl_MaxDualSourceDrawBuffersEXT
diff --git a/src/third_party/angle/extensions/EXT_blend_minmax.txt b/src/third_party/angle/extensions/EXT_blend_minmax.txt
new file mode 100644
index 0000000..522ac20
--- /dev/null
+++ b/src/third_party/angle/extensions/EXT_blend_minmax.txt
@@ -0,0 +1,164 @@
+Name
+
+ EXT_blend_minmax
+
+Name Strings
+
+ GL_EXT_blend_minmax
+
+Version
+
+ Last Modified Date: September 17, 2009
+ Version: 1.5
+
+Number
+
+ OpenGL Extension #37
+ OpenGL ES Extension #65
+
+Dependencies
+
+ There is an interaction with OpenGL ES.
+
+Overview
+
+ Blending capability is extended by respecifying the entire blend
+ equation. While this document defines only two new equations, the
+ BlendEquationEXT procedure that it defines will be used by subsequent
+ extensions to define additional blending equations.
+
+ The two new equations defined by this extension produce the minimum
+ (or maximum) color components of the source and destination colors.
+ Taking the maximum is useful for applications such as maximum projection
+ in medical imaging.
+
+Issues
+
+ * I've prefixed the ADD token with FUNC, to indicate that the blend
+ equation includes the parameters specified by BlendFunc. (The min
+ and max equations don't.) Is this necessary? Is it too ugly?
+ Is there a better way to accomplish the same thing?
+
+New Procedures and Functions
+
+ void BlendEquationEXT(enum mode);
+
+New Tokens
+
+ Accepted by the <mode> parameter of BlendEquationEXT:
+
+ FUNC_ADD_EXT 0x8006
+ MIN_EXT 0x8007
+ MAX_EXT 0x8008
+
+ Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
+ GetFloatv, and GetDoublev:
+
+ BLEND_EQUATION_EXT 0x8009
+
+Additions to Chapter 2 of the GL Specification (OpenGL Operation)
+
+ None
+
+Additions to Chapter 3 of the GL Specification (Rasterization)
+
+ None
+
+Additions to Chapter 4 of the GL Specification (Per-Fragment Operations
+and the Framebuffer)
+
+ The GL Specification defines a single blending equation. This
+ extension introduces a blend equation mode that is specified by calling
+ BlendEquationEXT with one of three enumerated values. The default
+ value FUNC_ADD_EXT specifies that the blending equation defined in
+ the GL Specification be used. This equation is
+
+ C' = (Cs * S) + (Cd * D)
+
+ / 1.0 C' > 1.0
+ C = (
+ \ C' C' <= 1.0
+
+ where Cs and Cd are the source and destination colors, and S and D are
+ as specified by BlendFunc.
+
+ If BlendEquationEXT is called with <mode> set to MIN_EXT, the
+ blending equation becomes
+
+ C = min (Cs, Cd)
+
+ Finally, if BlendEquationEXT is called with <mode> set to MAX_EXT, the
+ blending equation becomes
+
+ C = max (Cs, Cd)
+
+ In all cases the blending equation is evaluated separately for each
+ color component.
+
+Additions to Chapter 5 of the GL Specification (Special Functions)
+
+ None
+
+Additions to Chapter 6 of the GL Specification (State and State Requests)
+
+ None
+
+Additions to the GLX Specification
+
+ None
+
+GLX Protocol
+
+ A new GL rendering command is added. The following command is sent to the
+ server as part of a glXRender request:
+
+ BlendEquationEXT
+ 2 8 rendering command length
+ 2 4097 rendering command opcode
+ 4 ENUM mode
+
+Dependencies on OpenGL ES
+
+ If the GL is OpenGL ES, only the new MIN_EXT and MAX_EXT blend equations
+ are introduced by this extension. BlendEquationOES, FUNC_ADD_OES, and
+ BLEND_EQUATION_OES are introduced by the OES_blend_subtract extension,
+ which is required for this extension to operate. Alternatively,
+ OpenGL ES 2.0 is required, which introduces BlendEquation, FUNC_ADD, and
+ BLEND_EQUATION without the suffixes.
+
+ MIN_EXT and MAX_EXT should be added to Table 4.blendeq described in the
+ OES_blend_subtract extension specification, and Table 4.1 of the OpenGL
+ ES 2.0 specification.
+
+ Mentions of GetDoublev, Begin/End, and GLX in this extension specification
+ can be ignored for OpenGL ES. Also, BlendEquationEXT and FUNC_ADD_EXT
+ instead have the OES suffix courtesy of OES_blend_subtract, or no suffix
+ courtesy of core OpenGL ES 2.0.
+
+Errors
+
+ INVALID_ENUM is generated by BlendEquationEXT if its single parameter
+ is not FUNC_ADD_EXT, MIN_EXT, or MAX_EXT.
+
+ INVALID_OPERATION is generated if BlendEquationEXT is executed between
+ the execution of Begin and the corresponding execution to End.
+
+New State
+
+ Get Value Get Command Type Initial Value Attribute
+ --------- ----------- ---- ------------- ---------
+ BLEND_EQUATION_EXT GetIntegerv Z3 FUNC_ADD_EXT color-buffer
+
+New Implementation Dependent State
+
+ None
+
+Revision History
+
+ Version 1.5, September 17, 2009 (Jon Leech) -
+ Merge into OpenGL Registry version of the extension and assign
+ OpenGL ES extension number.
+ Version 1.4, May 19, 2009 (Benj Lipchak) -
+ Adapted for OpenGL ES.
+ Version 1.3, May 31, 1995 -
+ Last SGI revision.
diff --git a/src/third_party/angle/extensions/EXT_color_buffer_float.txt b/src/third_party/angle/extensions/EXT_color_buffer_float.txt
new file mode 100644
index 0000000..2eb163d
--- /dev/null
+++ b/src/third_party/angle/extensions/EXT_color_buffer_float.txt
@@ -0,0 +1,230 @@
+Name
+
+ EXT_color_buffer_float
+
+Name Strings
+
+ GL_EXT_color_buffer_float
+
+Contributors
+
+ OpenGL ES Working Group members
+
+Contact
+
+ Mark Callow, HI Corp. (callow.mark 'at' artspark.co.jp)
+
+Notice
+
+ ©2012 The Khronos Group Inc.
+
+Status
+
+ Complete
+
+IP Status
+
+ Graphics Properties Holdings (GPH, formerly SGI) owns US Patent
+ #6,650,327, issued November 18, 2003. GPH believes this patent
+ contains necessary IP for graphics systems implementing floating
+ point (FP) rasterization and FP framebuffer capabilities.
+
+ GPH will not grant Khronos royalty-free use of this IP for use
+ in OpenGL ES, but will discuss licensing on RAND terms, on an
+ individual basis with companies wishing to use this IP in the
+ context of conformant OpenGL ES implementations. GPH does not
+ plan to make any special exemption for open source
+ implementations.
+
+ See
+ https://www.khronos.org/files/ip-disclosures/opengl/SGI%20IP%20Disclosure%20Mar05_clean.pdf
+ for the full disclosure.
+
+Version
+
+ Date: January 11th, 2013
+ Revision: 5
+
+Number
+
+ OpenGL ES Extension #137
+
+Dependencies
+
+ Requires OpenGL ES 3.0.
+
+ Written based on the wording of the OpenGL ES 3.0.1 Specification
+ (January 10th, 2013).
+
+Overview
+
+ This extension allows a variety of floating point formats to be
+ rendered to via framebuffer objects.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ None
+
+Additions to Chapter 3 of the OpenGL ES 3.0 Specification
+(Rasterization)
+
+ 3.8.3 Texture Image Specification, unnumbered subsection "Required
+ Texture Formats", p. 126
+
+ Change the first two bullet items to the following:
+
+ - Texture and renderbuffer color formats (see section 4.4.2).
+ - RGBA32F, RGBA32I, RGBA32UI, RGBA16F, RGBA16I, RGBA16UI,
+ RGBA8, RGBA8I, RGBA8UI, SRGB8_ALPHA8, RGB10_A2, RGB10_-
+ A2UI, RGBA4, and RGB5_A1.
+ - RGB8 and RGB565.
+ - R11F G11F B10F.
+ - RG32F, RG32I, RG32UI, RG16F, RG16I, RG16UI, RG8, RG8I, and
+ RG8UI.
+ - R32F, R32I, R32UI, R16F, R16I, R16UI, R8, R8I, and R8UI.
+
+ - Texture-only color formats:
+ - RGBA8_SNORM.
+ - RGB32F, RGB32I, and RGB32UI.
+ - RGB16F, RGB16I, and RGB16UI.
+ - RGB8_SNORM, RGB8I, RGB8UI, and SRGB8.
+ - RGB9_E5.
+ - RG8_SNORM.
+ - R8_SNORM.
+
+ Table 3.12, p. 128 & 129
+
+ Convert the dash under 'Color-renderable' to a 'check' for the
+ following internal formats: R16F, RG16F, RGBA16F, R32F, RG32F,
+ RGBA32F and R11F_G11F_B10F.
+
+Additions to Chapter 4 of the OpenGL ES 3.0 Specification (Per-Fragment
+Operations and the Framebuffer)
+
+ (changed lines marked with *; added lines marked with +)
+
+ Chapter 4 Introduction, p. 167
+
+ Paragraph 5, sentence 3, p 168, insert "floating point" as shown:
+ "R, G, B, and A components may be represented as unsigned
+ * normalized fixed-point, floating point or signed or unsigned
+ integer values; ..." ^^^^^^^^^^^^^^
+
+ 4.1.7 Blending, p. 174
+
+ Modify paragraphs 3 & 4:
+
+ * "If the color buffer is fixed-point, the components of the
+ source and destination values and blend factors are clamped
+ * to [0; 1] prior to evaluating the blend equation. If the color
+ + buffer is floating-point, no clamping occurs. The resulting four
+ + values are sent to the next operation.
+
+ Blending applies only if the color buffer has a fixed-point or
+ * or floating-point format. If the color buffer has an integer
+ * format, proceed to the next operation. Furthermore, an
+ + INVALID_OPERATION error is generated by DrawArrays and the other
+ + drawing commands defined in section 2.8.3 if blending is enabled
+ + (see below) and any draw buffer has a 32-bit floating-point
+ + format."
+
+ 4.2.3 Clearing the Buffers, p. 183
+
+ Modify second paragraph, inserting "floating point":
+
+ " void ClearColor(float r, float g, float b, float a);
+
+ * sets the clear value for fixed- and floating-point color buffers.
+ ..." ^^^^^^^^^^^^^^^^^^
+
+ 4.3.1 Reading Pixels, p. 186
+
+ In paragraph 4, beginning "Only two combinations of format
+ and type are accepted ...", after the sentence ending "... type
+ UNSIGNED_BYTE is accepted." insert the following sentence:
+ "For floating-point rendering surfaces, the combination
+ format RGBA and type FLOAT is accepted."
+
+ 4.3.1 unnumbered subsection "Obtaining Pixels from the Framebuffer",
+ p. 188
+
+ Modify penultimate paragraph, p189, "If format is an integer ..."
+
+ "If format is an integer format and the color buffer is not an
+ integer format; if the color buffer is an integer format and
+ * format is not an integer format; if format is an integer format
+ * and type is FLOAT, HALF_FLOAT, or UNSIGNED_INT_10F_11F_11F_REV;
+ + or if the color buffer is a floating-point format and type is
+ + not FLOAT, HALF FLOAT, or UNSIGNED_INT_10F_11F_11F_REV, the error
+ INVALID_OPERATION occurs."
+
+ 4.3.1 unnumbered subsection "Conversion of RGBA values", p.190
+
+ Sole paragraph, sentence 3, insert "or floating point" as shown:
+ * "For an integer or floating point color buffer, the elements
+ are unmodified."^^^^^^^^^^^^^^^^^
+
+ 4.3.2 Copying Pixels, p192
+
+ Modify first error condition, at bottom of p193, "The read buffer
+ contains ..." to encompass floating-point buffers.
+
+ * "- The read buffer contains fixed-point or floating-point values
+ * and any draw buffer contains neither fixed-point nor
+ * floating-point values."
+
+ 4.4.2 Attaching Images to Framebuffer Objects, p. 197, unnumbered
+ subsection "Required Renderbuffer Formats", p. 200
+
+ In the last paragraph beginning "Implementations must support
+ creation ...", modify the final phrase to
+
+ * "with the exception of signed and unsigned integer, RGBA16F,
+ + R32F, RG32F and RGBA32F formats.
+
+Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special Functions)
+
+ None
+
+Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and State
+Requests)
+
+ 6.1.15 Internal Format Queries, p. 237
+
+ P. 238, paragraph 8 after "Since multisampling is not supported
+ for signed and unsigned integer internal formats, the value of
+ NUM_SAMPLE_COUNTS will be zero for such formats.", insert new
+ one-sentence paragraph:
+
+ "If <internalformat> is RGBA16F, R32F, RG32F, or RGBA32F, the
+ value of NUM_SAMPLE_COUNTS may be zero, or else the maximum
+ value in SAMPLES may be less than the value of MAX_SAMPLES."
+
+New Implementation Dependent State
+
+ None
+
+Issues
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- -------- --------- -----------------------------------------
+ 1 10/16/12 markc Initial version
+ 2 10/18/12 markc Referenced preliminary version of OpenGL
+ ES 3.0.1 specification and updated page
+ numbers.
+ 3 11/21/12 markc Corrected IP status.
+ 4 01/09/13 markc Changed date of referenced OpenGL ES
+ 3.0.1 specification. Made minor language
+ simplification.
+ 5 01/11/13 markc Changed date to release version of
+ OpenGL ES 3.0.1 specification.
+ Clarified change to "Required
+ renderbuffer formats" section.
+
+# vim:ai:ts=4:sts=4:sw=4:expandtab:textwidth=70
diff --git a/src/third_party/angle/extensions/EXT_shader_framebuffer_fetch.txt b/src/third_party/angle/extensions/EXT_shader_framebuffer_fetch.txt
new file mode 100644
index 0000000..4a9bed2
--- /dev/null
+++ b/src/third_party/angle/extensions/EXT_shader_framebuffer_fetch.txt
@@ -0,0 +1,263 @@
+Name
+
+ EXT_shader_framebuffer_fetch
+
+Name Strings
+
+ GL_EXT_shader_framebuffer_fetch
+
+Contact
+
+ Benj Lipchak, Apple (lipchak 'at' apple.com)
+
+Status
+
+ Complete
+
+Version
+
+ Last Modified Date: May 28, 2013
+ Author Revision: 4
+
+Number
+
+ OpenGL ES Extension #122
+
+Dependencies
+
+ OpenGL ES 2.0 is required.
+
+ This specification is written against the OpenGL ES 2.0.24 specification.
+ This extension is written against the OpenGL ES Shading Language 1.0.17
+ specification.
+
+ OpenGL ES 3.0 affects the definition of this extension.
+
+Overview
+
+ Conventional OpenGL blending provides a configurable series of operations
+ that can be used to combine the output values from a fragment shader with
+ the values already in the framebuffer. While these operations are
+ suitable for basic image compositing, other compositing operations or
+ operations that treat fragment output as something other than a color
+ (normals, for instance) may not be expressible without multiple passes or
+ render-to-texture operations.
+
+ This extension provides a mechanism whereby a fragment shader may read
+ existing framebuffer data as input. This can be used to implement
+ compositing operations that would have been inconvenient or impossible with
+ fixed-function blending. It can also be used to apply a function to the
+ framebuffer color, by writing a shader which uses the existing framebuffer
+ color as its only input.
+
+Issues
+
+ 1. How is framebuffer data treated during multisample rendering?
+
+ RESOLVED: Reading the value of gl_LastFragData produces a different
+ result for each sample. This implies that all or part of the shader be run
+ once for each sample. Input values to the shader from existing variables
+ in GLSL ES remain identical across samples.
+
+ 2. How does the use of gl_LastFragData interact with fragment discard?
+
+ RESOLVED: Hardware may not necessarily support discarding on sample
+ granularity. Therefore, three options were considered for this
+ functionality:
+
+ A) Allow discard based on variables calculated using the framebuffer
+ color when multisample rasterization is disabled, but disallow
+ discard in this manner when multisample rasterization is enabled.
+
+ B) Restrict usage of the framebuffer color until it is known whether
+ or not the pixel will be discarded.
+
+ C) Allow undefined results for fragment shaders that discard on a
+ per-sample basis on hardware that doesn't support it.
+
+ This extension has chosen option C. Restricting orthogonality of fragment
+ shaders between single-sample and multisample rendering is undesirable, as
+ is restricting usage of the framebuffer color, which can generally only be
+ done with detailed flow-control analysis.
+
+ 3. What is the precision of gl_LastFragData in practice?
+
+ RESOLVED: Three options were considered for this functionality:
+
+ A) gl_LastFragData is always mediump.
+
+ B) gl_LastFragData takes the precision most closely matching the
+ actual storage format of the framebuffer.
+
+ C) Allow redeclaration of gl_LastFragData in order to change its
+ precision.
+
+ This extension has chosen option C. A fixed precision per option A
+ increases the likelihood of redundant conversion operations in the shader,
+ and option B does not provide for clear behavior with regard to the
+ precision of intermediate results from calculations using the
+ framebuffer color.
+
+ 4. How does this extension iteract with conventional blending?
+
+ RESOLVED: There is no interaction. The two remain orthogonal. The rest
+ of the pipeline continues as usual after the fragment shader stage.
+
+
+ 5. How does this extension work in ES 3.0?
+
+ RESOLVED: Differently than in ES 2.0.
+
+ The built-in fragment outputs of ES 2.0 are replaced in #version 300 es
+ shaders by user-declared outputs, to accomodate integer and MRT
+ framebuffers. Three options were considered:
+
+ A) Add built-ins similar to gl_LastFragData.
+
+ B) Add a layout to mark user-declared fragment outputs as having
+ defined content on entry to fragment shader.
+
+ C) Allow marking user-declared fragment outputs as "inout".
+
+ This extension has chosen option C. Adding built-ins per option A is
+ unwieldy for MRT framebuffers with mixed attachment types and precisions.
+ Options B and C are semantically identical, but C requires fewer
+ modifications to the specification and to user shaders. Note that the
+ inout qualifier is not allowed for re-declaring existing fragment outputs
+ such as gl_FragDepth.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
+ and GetDoublev:
+
+ FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT 0x8A52
+
+New Builtin Variables
+
+ mediump vec4 gl_LastFragData[gl_MaxDrawBuffers]
+
+Changes to the OpenGL ES 2.0.24 Specification, Chapter 3
+
+ Remove the last sentence of Paragraph 2 of Section 3.8.1, page 84 ("These
+ built-in varying variables include [...]" and add:
+
+ These built-in varying variables include the fragment's position, eye z
+ coordinate, and front-facing flag, as well as the last data or color value
+ written to the framebuffer. When the value of SAMPLE_BUFFERS is 1 and the
+ current framebuffer color is accessed in the fragment shader, the fragment
+ shader will be invoked separately for each covered sample and a separate
+ value for the previous framebuffer color will be provided for each sample."
+
+ Add a new subsection to section 3.8.2, page 87 ("Shader Execution"):
+
+ "Discard
+
+ Fragment shaders may conditionally abandon operations using the discard
+ keyword. However, the ability of hardware to support abandoning operations
+ on a single sample when the shader is invoked once for each covered sample
+ is implementation-dependent. This capability can be determined by calling
+ GetBooleanv with the symbolic constant
+ FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT. If FALSE is returned, results from
+ shaders which discard based on per-sample logic are undefined."
+
+Changes to the OpenGL ES 2.0.24 Specification, Chapter 4
+
+ Replace first element of Figure 4.1, page 90 ("Fragment + Associated Data"):
+
+ "Fragment (or sample) + Associated Data"
+
+New Implementation Dependent State
+
+ Add to table 6.19 (Implementation Dependent Values (cont.)):
+
+ Get Value Type Get Command Minimum Value Description Section
+ --------- ---- ----------- ------------- -------------- -------
+ FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT B GetBooleanv - Samples may be 3.8.2
+ discarded
+ individually
+
+Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 3
+
+ Remove Paragraph 2 of section 3.8, page 17, Identifiers ("Identifiers
+ starting with "gl_" are reserved [...]") and add:
+
+ "Identifiers starting with "gl_" are reserved for use by OpenGL ES, and
+ may not be declared in a shader as either a variable or a function.
+ However, as noted in the specification, certain predeclared "gl_" names
+ are allowed to be redeclared in a shader for the specific purpose of
+ changing their precision qualifier."
+
+Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 7
+
+ Add after the last sentence of Paragraph 2 of Section 7.2, page 60,
+ Fragment Shader Special Variables ("These variables may be written to
+ more [...]"):
+
+ "... To access the existing framebuffer values (e.g., to implement a
+ complex blend operation inside the shader), fragment shaders should use
+ the read-only input array gl_LastFragData. gl_LastFragData returns the
+ value written by the most recent fragment at the same position.
+
+ Access to gl_LastFragData is optional, and must be enabled by
+
+ #extension GL_EXT_shader_framebuffer_fetch : <behavior>
+
+ Where <behavior> is as specified in section 3.3.
+
+ By default, gl_LastFragData is declared with the mediump precision
+ qualifier. This can be changed by redeclaring the corresponding variables
+ with the desired precision qualifier.
+
+ Redeclarations are done as follows
+
+ // Redeclaration that changes nothing is allowed
+ mediump vec4 gl_LastFragData[gl_MaxDrawBuffers];
+
+ // All the following are allowed redeclaration that change behavior
+ lowp vec4 gl_LastFragData[gl_MaxDrawBuffers];
+ highp vec4 gl_LastFragData[gl_MaxDrawBuffers];
+
+ Redeclarations must not otherwise alter the declared type or array size of
+ gl_LastFragData."
+
+Changes to the OpenGL ES Shading Language 3.00.3 Specification, Chapter 4
+
+ Modify Paragraph 2 of section 4.3.6:
+ "Except in the fragment stage, there is not an inout storage qualifier at
+ global scope for declaring a single variable name as both input and output
+ [...]"
+
+ Modify Paragraph 5 of section 4.3.6:
+ "Fragment outputs output per-fragment data and are declared using the out
+ or inout storage qualifier. It is an error to use centroid out or centroid
+ inout in a fragment shader [...]" and append new paragraph:
+
+ "Upon entry to the fragment shader, fragment outputs declared as inout will
+ contain the value written by the most recent fragment at the same position.
+ This behavior, and the ability to use the inout qualifier at global scope
+ in a fragment shader, is optional and must be enabled by
+
+ #extension GL_EXT_shader_framebuffer_fetch : <behavior>
+
+ Where <behavior> is as specified in section 3.4."
+
+Interactions with OES_standard_derivatives
+
+ Results from shaders which use the built-in derivative functions dFdx,
+ dFdy, and fwidth on variables calculated using the current framebuffer
+ color are undefined.
+
+Revision History
+
+ Version 4, 2013/05/28 - Added ES3 interaction as requested in Bug 10236
+ Version 3, 2012/09/24 - Remove obsolete issue 3 about derivatives
+ Version 2, 2012/06/21 - Fix MULTISAMPLE enabled -> SAMPLE_BUFFERS = 1,
+ recast from APPLE to multivendor EXT, clarify that
+ gl_LastFragData reflects value written by previous
+ pixel at same coordinates.
+ Version 1, 2012/06/01 - Conversion from ARB_sync to APPLE_sync for ES.
\ No newline at end of file
diff --git a/src/third_party/angle/extensions/EXT_texture_rg.txt b/src/third_party/angle/extensions/EXT_texture_rg.txt
new file mode 100644
index 0000000..968b28d
--- /dev/null
+++ b/src/third_party/angle/extensions/EXT_texture_rg.txt
@@ -0,0 +1,195 @@
+Name
+
+ EXT_texture_rg
+
+Name Strings
+
+ GL_EXT_texture_rg
+
+Contributors
+
+ Contributors to ARB_texture_rg, on which this extension is based
+ Kyle Haughey
+ Richard Schreyer
+
+Contact
+
+ Benj Lipchak, Apple (lipchak 'at' apple.com)
+
+Status
+
+ Complete
+
+Version
+
+ Date: July 22, 2011
+ Revision: 3
+
+Number
+
+ OpenGL ES Extension #103
+
+Dependencies
+
+ Requires OpenGL ES 2.0.
+
+ Written based on the wording of the OpenGL ES 2.0.25 Full Specification
+ (November 2, 2010).
+
+ OES_texture_float affects the definition of this extension.
+
+ OES_texture_half_float affects the definition of this extension.
+
+ APPLE_framebuffer_multisample affects the definition of this extension.
+
+Overview
+
+ Historically one- and two-component textures have been specified in OpenGL
+ ES using the luminance or luminance-alpha (L/LA) formats. With the advent
+ of programmable shaders and render-to-texture capabilities these legacy
+ formats carry some historical artifacts which are no longer useful.
+
+ For example, when sampling from such textures, the luminance values are
+ replicated across the color components. This is no longer necessary with
+ programmable shaders.
+
+ It is also desirable to be able to render to one- and two-component format
+ textures using capabilities such as framebuffer objects (FBO), but
+ rendering to L/LA formats is under-specified (specifically how to map
+ R/G/B/A values to L/A texture channels).
+
+ This extension adds new base internal formats for one-component RED and
+ two-component RG (red green) textures as well as sized RED and RG internal
+ formats for renderbuffers. The RED and RG texture formats can be used for
+ both texturing and rendering into with framebuffer objects.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <internalformat> parameter of TexImage2D and CopyTexImage2D,
+ and the <format> parameter of TexImage2D, TexSubImage2D, and ReadPixels:
+
+ RED_EXT 0x1903
+ RG_EXT 0x8227
+
+ Accepted by the <internalformat> parameter of RenderbufferStorage and
+ RenderbufferStorageMultisampleAPPLE:
+
+ R8_EXT 0x8229
+ RG8_EXT 0x822B
+
+Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL ES Operation)
+
+ None
+
+Additions to Chapter 3 of the OpenGL ES 2.0 Specification (Rasterization)
+
+ (Add the following to Table 3.3: "TexImage2D and ReadPixels formats")
+
+ Format Name Element Meaning and Order Target Buffer
+ ----------- ------------------------- -------------
+ RED_EXT R Color
+ RG_EXT R, G Color
+
+ (Add the following to Table 3.4: "Valid pixel format and type combinations")
+ (as modified by OES_texture_float and OES_texture_half_float)
+
+ Format Type Bytes per Pixel
+ ----------- ------------------------- ---------------
+ RED_EXT FLOAT 4
+ RED_EXT HALF_FLOAT_OES 2
+ RED_EXT UNSIGNED_BYTE 1
+ RG_EXT FLOAT 8
+ RG_EXT HALF_FLOAT_OES 4
+ RG_EXT UNSIGNED_BYTE 2
+
+ (Add the following to Table 3.8: "Conversion from RGBA and depth pixel
+ components to internal texture")
+
+ Base Internal Format RGBA Internal Components
+ -------------------- ------ -------------------
+ RED_EXT R R
+ RG_EXT R,G R,G
+
+ (Modify Table 3.9: "CopyTexImage internal format/color buffer combinations")
+
+ Texture Format
+ Color Buffer A L LA R RG RGB RGBA
+ ------------ - - -- - -- --- ----
+ A X
+ R X X
+ RG X X X
+ RGB X X X X
+ RGBA X X X X X X X
+
+ (Add the following to Table 3.12: "Correspondence of filtered texture
+ components to texture source color components")
+
+ Texture Base Texture source color
+ Internal Format C_s A_s
+ --------------- ------------- ------
+ RED_EXT (R_t, 0, 0) 1
+ RG_EXT (R_t, G_t, 0) 1
+
+Additions to Chapter 4 of the OpenGL ES 2.0 Specification (Per-Fragment
+Operations and the Framebuffer)
+
+ In section 4.3.1 "Reading Pixels", subsection "Obtaining Pixels from the
+ Framebuffer", modify the last sentence to read:
+
+ "If the framebuffer does not support G, B, or A values then the G, B, and A
+ values that are obtained are 0.0, 0.0, and 1.0 respectively."
+
+ In section 4.4.5 "Framebuffer Completeness", modify the last sentence of
+ the second paragraph to read:
+
+ "Color-renderable formats contain red, and possibly green, blue, and alpha
+ components; depth-renderable formats contain depth components; and
+ stencil-renderable formats contain stencil components."
+
+ (Add the following to Table 4.5: "Renderbuffer image formats, showing their
+ renderable type (color-, depth-, or stencil-renderable) and the number of
+ bits each format contains for color (R, G, B, A), depth (D), and stencil
+ (S) components")
+
+ Sized Internal Renderable Type R bits G bits B bits A bits D bits S bits
+ Format
+ -------------- ---------------- ------ ------ ------ ------ ------ ------
+ R8_EXT color-renderable 8
+ RG8_EXT color-renderable 8 8
+
+Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special Functions)
+
+ None
+
+Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and State
+Requests)
+
+ None
+
+Dependencies on OES_texture_float
+
+ If OES_texture_float is not supported, then omit the rows of
+ Table 3.4 that have Type FLOAT.
+
+Dependencies on OES_texture_half_float
+
+ If OES_texture_half_float is not supported, then omit the rows of
+ Table 3.4 that have Type HALF_FLOAT_OES.
+
+Dependencies on APPLE_framebuffer_multisample
+
+ If APPLE_framebuffer_multisample is not supported, then all references to
+ RenderbufferStorageMultisampleAPPLE should be ignored.
+
+Revision History
+
+ #1 February 22, 2011, khaughey
+ - initial version adapted from ARB_texture_rg.
+ #2 June 16, 2011, benj
+ - add interaction with APPLE_framebuffer_multisample
+ #3 July 22, 2011, benj
+ - rename from APPLE to EXT
