Skip to content

A
angle
Commit bc7554f9 by Geoff Lang Committed by Commit Bot
Options

Remove extension files that are not written by ANGLE.

We inconsistantly added some extension txt files to our extensions folder that are not maintained but possibly implemented by ANGLE. Some of these extensions trip up Android's automatic license detection. Bug: None Change-Id: I9bde4235c7ad2bf4d9bcf5385f4138296cef2c13 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2653848Reviewed-by: 's avatarJonah Ryan-Davis <jonahr@google.com> Commit-Queue: Geoff Lang <geofflang@chromium.org>
parent 8f6c328d
Showing with 0 additions and 925 deletions
extensions/EGL_EXT_create_context_robustness.txt deleted 100644 → 0
Name
EXT_create_context_robustness
Name Strings
EGL_EXT_create_context_robustness
Contributors
Daniel Koch, TransGaming
Contributors to EGL_KHR_create_context
Contact
Greg Roth (groth 'at' nvidia.com)
Status
Complete.
Version
Version 3, 2011/10/31
Number
EGL Extension #37
Dependencies
Requires EGL 1.4
Written against the EGL 1.4 specification.
An OpenGL implementation supporting GL_ARB_robustness, an OpenGL ES
implementation supporting GL_EXT_robustness, or an implementation
supporting equivalent functionality is required.
Overview
This extension allows creating an OpenGL or OpenGL ES context
supporting robust buffer access behavior and a specified graphics
reset notification behavior.
New Procedures and Functions
None
New Tokens
Accepted as an attribute name in the <*attrib_list> argument to
eglCreateContext:
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT 0x30BF
EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY_EXT 0x3138
Accepted as an attribute value for EGL_CONTEXT_RESET_NOTIFICATION_-
STRATEGY_EXT in the <*attrib_list> argument to eglCreateContext:
EGL_NO_RESET_NOTIFICATION_EXT 0x31BE
EGL_LOSE_CONTEXT_ON_RESET_EXT 0x31BF
Additions to the EGL 1.4 Specification
Replace section 3.7.1 "Creating Rendering Contexts" from the
fifth paragraph through the seventh paragraph:
<attrib_list> specifies a list of attributes for the context. The
list has the same structure as described for eglChooseConfig. If an
attribute is not specified in <attrib_list>, then the default value
specified below is used instead. <attrib_list> may be NULL or empty
(first attribute is EGL_NONE), in which case attributes assume their
default values as described below. Most attributes are only meaningful
for specific client APIs, and will generate an EGL_BAD_ATTRIBUTE
error when specified to create for another client API context.
Context Versions
----------------
EGL_CONTEXT_CLIENT_VERSION determines which version of an OpenGL ES
context to create. This attribute may only be specified when creating
an OpenGL ES context (e.g. when the current rendering API is
EGL_OPENGL_ES_API). An attribute value of 1 specifies creation of an
OpenGL ES 1.x context. An attribute value of 2 specifies creation of an
Open GL ES 2.x context. The default value for EGL_CONTEXT_CLIENT_VERSION
is 1.
Context Robust Access
-------------
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT indicates whether <robust buffer
access> should be enabled for the OpenGL ES context. Robust buffer
access is defined in the GL_EXT_robustness extension specification,
and the resulting context must support GL_EXT_robustness and robust
buffer access as described therein. The default value of
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT is EGL_FALSE.
Context Reset Notification
--------------------------
The attribute name EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY_-
EXT specifies the <reset notification behavior> of the rendering
context. This attribute is only meaningful for OpenGL ES contexts,
and specifying it for other types of contexts will generate an
EGL_BAD_ATTRIBUTE error.
Reset notification behavior is defined in the GL_EXT_robustness
extension for OpenGL ES, and the resulting context must support
GL_EXT_robustness and the specified reset strategy. The attribute
value may be either EGL_NO_RESET_NOTIFICATION_EXT or EGL_LOSE_-
CONTEXT_ON_RESET_EXT, which respectively result in disabling
delivery of reset notifications or the loss of all context state
upon reset notification as described by the GL_EXT_robustness. The
default value for EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY_EXT
is EGL_NO_RESET_NOTIFICATION_EXT.
Add to the eglCreateContext context creation errors:
* If <config> does not support a client API context compatible
with the requested context flags and context reset notification
behavior (for client API types where these attributes are
supported), then an EGL_BAD_CONFIG error is generated.
* If the reset notification behavior of <share_context> and the
newly created context are different then an EGL_BAD_MATCH error is
generated.
Errors
EGL_BAD_CONFIG is generated if EGL_CONTEXT_OPENGL_ROBUST_ACCESS_-
EXT is set to EGL_TRUE and no GL context supporting the GL_EXT_-
robustness extension and robust access as described therein can be
created.
EGL_BAD_CONFIG is generated if no GL context supporting the
GL_EXT_robustness extension and the specified reset notification
behavior (the value of attribute EGL_CONTEXT_RESET_NOTIFICATION_-
STRATEGY_EXT) can be created.
BAD_MATCH is generated if the reset notification behavior of
<share_context> does not match the reset notification behavior of
the context being created.
New State
None
Conformance Tests
TBD
Sample Code
TBD
Issues
None
Revision History
Rev. Date Author Changes
---- ------------ --------- ----------------------------------------
3 31 Oct 2011 groth Reverted to attribute for robust access. Now it's a
companion to rather than subset of KHR_create_context
2 11 Oct 2011 groth Merged ANGLE and NV extensions.
1 15 July 2011 groth Initial version
extensions/EXT_blend_minmax.txt deleted 100644 → 0
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.
extensions/EXT_color_buffer_float.txt deleted 100644 → 0
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
extensions/EXT_texture_rg.txt deleted 100644 → 0
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
extensions/KHR_parallel_shader_compile.txt deleted 100644 → 0
Name
KHR_parallel_shader_compile
Name Strings
GL_KHR_parallel_shader_compile
Contact
Geoff Lang, (geofflang 'at' google.com)
Contributors
Timothy Lottes, AMD
Graham Sellers, AMD
Eric Werness, NVIDIA
Geoff Lang, Google
Daniel Koch, NVIDIA
Notice
Copyright (c) 2015 The Khronos Group Inc. Copyright terms at
http://www.khronos.org/registry/speccopyright.html
Status
Complete
Version
Last Modified Date: 2017-04-24
Revision: 2
Number
ARB Extension #192
OpenGL ES Extension #288
Dependencies
This extension is written against OpenGL 4.5 (CoreProfile) dated
May 28 2015.
OpenGL ES 2.0 is required (for mobile).
Overview
Compiling GLSL into implementation-specific code can be a time consuming
process, so a GL implementation may wish to perform the compilation in a
separate CPU thread. This extension provides a mechanism for the application
to provide a hint to limit the number of threads it wants to be used to
compile shaders, as well as a query to determine if the compilation process
is complete.
New Procedures and Functions
void MaxShaderCompilerThreadsKHR(uint count);
New Tokens
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetInteger64v, GetFloatv, and GetDoublev:
MAX_SHADER_COMPILER_THREADS_KHR 0x91B0
Accepted as part of the <pname> parameter to GetShaderiv and
accepted as part of the <pname> parameter to GetProgramiv:
COMPLETION_STATUS_KHR 0x91B1
IP Status
None.
Additions to Chapter 7 "Programs and Shaders",
Append to the end of 7.1 "Shader Objects",
Applications may use the following to hint to the driver the maximum
number background threads it would like to be used in the process of
compiling shaders or linking programs,
void MaxShaderCompilerThreadsKHR(uint count);
where <count> is the number of background threads. A <count> of zero
specifies a request for no parallel compiling or linking and a <count> of
0xFFFFFFFF requests an implementation-specific maximum.
An implementation may combine the maximum compiler thread request from
multiple contexts in a share group in an implementation-specific way.
An application can query the current MaxShaderCompilerThreadsKHR <count>
by calling GetIntegerv with <pname> set to MAX_SHADER_COMPILER_THREADS_KHR,
which returns the value of the current state (Table 23.51).
Add to 7.13 "Shader, Program, and Program Pipeline Queries" under the
descriptions for "pname" for "GetShaderiv",
If <pname> is COMPLETION_STATUS_KHR, TRUE is returned if the shader
compilation has completed, FALSE otherwise.
Add to 7.13 "Shader, Program, and Program Pipeline Queries" under the
descriptions for "pname" for "GetProgramiv",
If <pname> is COMPLETION_STATUS_KHR, TRUE is returned if the program
linking has completed, FALSE otherwise.
New State
Add to Table 23.51: Hints
Get Value Type Get Command Initial Value Description Sec
------------------------------- ---- ------------ ------------- -------------------- ----
MAX_SHADER_COMPILER_THREADS_KHR Z+ GetIntegerv 0xFFFFFFFF Max compile threads 7.13
Add to Table 23.32: Program Object State
Get Value Type Get Command Initial Value Description Sec
---------------------- ---- ------------ ------------- -------------------- ----
COMPLETION_STATUS_KHR B GetProgramiv TRUE Program linking has 7.13
completed
Add to Table 23.30: Shader Object State
Get Value Type Get Command Initial Value Description Sec
--------------------- ---- ------------ ------------- -------------------- ----
COMPLETION_STATUS_KHR B GetShaderiv TRUE Shader compilation 7.13
has completed
Interactions with OpenGL ES
If implemented in OpenGL ES ignore all references to GetDoublev.
If the supported ES version is less than 3.0, ignore all references to
GetInteger64v.
Issues
1) Where should the hint state be stored?
UNRESOLVED: Each context has its own value which may be specified and
queried, but an implementation may choose to combine the hints from multiple
contexts in an implementation-specific manner. There isn't really any
precedent for per-share group state.
2) Can we make the requirements more strict?
RESOLVED: We could, but making sure all of the error behavior is correct and
fully specified would likely take more time than we have. This spec allows
an application to clearly request its intent even if there aren't guarantees
that the implementation will exactly obey the request.
3) Does glGetIntegerv(MAX_SHADER_COMPILER_THREADS_KHR) just return the
value set by MaxShaderCompilerThreadsKHR? Or, if the state is 0xFFFFFFFF
("do something implementation specific"), does it return the number of
threads the implementation has actually chosen to use?
RESOLVED: As with other state queries, this returns the value that was last
set, or if no value was set by the application it returns the default state
value (0xFFFFFFFF).
Revision History
Rev Date Author Changes
--- ---------- -------- ---------------------------------------------
1 2017-03-23 glang Cast as KHR based on v6 of
ARB_parallel_shader_compile.
2 2017-04-24 dgkoch Spec clarifications, add issue 3.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment