| Name |
| |
| ARB_ES2_compatibility |
| |
| Name Strings |
| |
| GL_ARB_ES2_compatibility |
| |
| Contact |
| |
| Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com) |
| |
| Contributors |
| |
| Acorn Pooley, NVIDIA |
| Bruce Merry, ARM |
| Greg Roth, NVIDIA |
| Pat Brown, NVIDIA |
| |
| Notice |
| |
| Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Specification Update Policy |
| |
| Khronos-approved extension specifications are updated in response to |
| issues and bugs prioritized by the Khronos OpenGL Working Group. For |
| extensions which have been promoted to a core Specification, fixes will |
| first appear in the latest version of that core Specification, and will |
| eventually be backported to the extension document. This policy is |
| described in more detail at |
| https://www.khronos.org/registry/OpenGL/docs/update_policy.php |
| |
| Status |
| |
| Complete. Approved by the ARB on June 9, 2010. |
| Approved by the Khronos Board of Promoters on July 23, 2010. |
| |
| Version |
| |
| Last Modified Date: March 12, 2012 |
| Revision: 7 |
| |
| Number |
| |
| ARB Extension #95 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 4.0 Compatibility |
| Profile (March 11, 2010) specification. |
| |
| This extension interacts with ARB_tessellation_shader or OpenGL 4.0. |
| |
| Overview |
| |
| This extension adds support for features of OpenGL ES 2.0 that are |
| missing from OpenGL 3.x. Enabling these features will ease the process |
| of porting applications from OpenGL ES 2.0 to OpenGL. |
| |
| IP Status |
| |
| No known IP claims. |
| |
| New Procedures and Functions |
| |
| void ReleaseShaderCompiler(void); |
| void ShaderBinary(sizei count, const uint *shaders, |
| enum binaryformat, const void *binary, sizei length); |
| void GetShaderPrecisionFormat(enum shadertype, |
| enum precisiontype, |
| int *range, int *precision); |
| |
| void DepthRangef(clampf n, clampf f); |
| void ClearDepthf(clampf d); |
| |
| New Tokens |
| |
| Accepted by the <value> parameter of GetBooleanv, GetIntegerv, |
| GetInteger64v, GetFloatv, and GetDoublev: |
| |
| SHADER_COMPILER 0x8DFA |
| SHADER_BINARY_FORMATS 0x8DF8 |
| NUM_SHADER_BINARY_FORMATS 0x8DF9 |
| MAX_VERTEX_UNIFORM_VECTORS 0x8DFB |
| MAX_VARYING_VECTORS 0x8DFC |
| MAX_FRAGMENT_UNIFORM_VECTORS 0x8DFD |
| IMPLEMENTATION_COLOR_READ_TYPE 0x8B9A |
| IMPLEMENTATION_COLOR_READ_FORMAT 0x8B9B |
| |
| Accepted by the <type> parameter of VertexAttribPointer: |
| |
| FIXED 0x140C |
| |
| Accepted by the <precisiontype> parameter of |
| GetShaderPrecisionFormat: |
| |
| LOW_FLOAT 0x8DF0 |
| MEDIUM_FLOAT 0x8DF1 |
| HIGH_FLOAT 0x8DF2 |
| LOW_INT 0x8DF3 |
| MEDIUM_INT 0x8DF4 |
| HIGH_INT 0x8DF5 |
| |
| Accepted by the <format> parameter of most commands taking sized |
| internal formats: |
| |
| RGB565 0x8D62 |
| |
| Additions to Chapter 2 of the OpenGL 4.0 Specification (OpenGL Operation) |
| |
| Add a new Section 2.1.5 (Fixed-Point Computation) and renumber later |
| sections: |
| |
| Fixed-Point Computation |
| |
| Vertex attributes may be specified using a 32-bit two's-complement signed |
| representation with 16 bits to the right of the binary point (fraction |
| bits). |
| |
| |
| Add to Table 2.2, p. 16 (GL data types) |
| |
| GL Type | Minimum | Description |
| | Bit Width | |
| ----------------------------------- |
| fixed | 32 | Signed 2's complement 16.16 scaled integer |
| |
| |
| Section 2.8, p.36 (Vertex Arrays) |
| |
| Adjust the sentence in the first paragraph on p. 37: |
| |
| For type the values BYTE, SHORT, INT, FLOAT, HALF_FLOAT, DOUBLE, and |
| FIXED indicate types byte, short, int, float, half, double, and fixed |
| respectively;... |
| |
| |
| Modify the descripion of the pseudocode explaining |
| ArrayElementInstanced as follows (p.42): |
| |
| ... VertexAttrib[size]N[type]v will be called. When a generic vertex |
| attribute array contains fixed-point data, the generic vertex |
| attribute values are specified using a fixed-point signed 2's |
| complement 16.16 scaled integer format. |
| |
| Section 2.8.2, p.43 (Drawing Commands) |
| |
| Modify the paragraphs that begin with "with one exception" (page 44): |
| |
| with one exception: the current normal coordinate, color, secondary |
| color, color index, edge flag, fog coordinate, texture coordinates, |
| and generic attribute values are not modified by the execution of |
| DrawArraysOneInstance. |
| |
| ... |
| |
| with one exception: the current normal coordinate, color, secondary |
| color, color index, edge flag, fog coordinate, texture coordinates, and |
| generic attribute values are not modified by the execution of |
| DrawElements. |
| |
| |
| Table 2.5, p. 39 (Vertex array sizes (values per vertex) and data types.) |
| |
| Add "fixed" as a legal type for VertexAttribPointer |
| |
| |
| Section 2.14, p. 89 (Vertex Shaders) |
| |
| Modify the third paragraph: |
| |
| To use a vertex shader, shader source code is first loaded into a shader |
| object and then compiled. Alternatively, pre-compiled shader binary code |
| may be directly loaded into a shader object. An OpenGL implementation |
| must support shader compilation (the boolean value SHADER_COMPILER must |
| be TRUE). If the integer value NUM_SHADER_BINARY_FORMATS is greater than |
| zero, then shader binary loading is supported. One or more vertex shader |
| objects are then attached to a program object.... |
| |
| |
| Section 2.14.1, p. 89 (Shader Objects) |
| |
| Add before the description of DeleteShader: |
| |
| Resources allocated by the shader compiler may be released with the |
| command |
| |
| void ReleaseShaderCompiler(void); |
| |
| This is a hint from the application, and does not prevent later use |
| of the shader compiler. If shader source is loaded and compiled after |
| ReleaseShaderCompiler has been called, CompileShader must succeed |
| provided there are no errors in the shader source. |
| |
| The range and precision for different numeric formats supported by the |
| shader compiler may be determined with the command |
| GetShaderPrecisionFormat (see section 6.1.16) |
| |
| |
| Add a new Section 2.14.2 (Loading Shader Binaries) and shift other |
| section numbers. |
| |
| Precompiled shader binaries may be loaded with the command |
| |
| void ShaderBinary(sizei count, const uint *shaders, |
| enum binaryformat, const void *binary, |
| sizei length); |
| |
| <shaders> contains a list of <count> shader object handles. Each |
| handle refers to a unique shader type (vertex shader or fragment |
| shader). <binary> points to <length> bytes of pre-compiled binary |
| shader code in client memory, and <binaryformat> denotes the format |
| of the pre-compiled code. |
| |
| The binary image will be decoded according to the extension |
| specification defining the specified <binaryformat>. OpenGL defines |
| no specific binary formats, but does provide a mechanism to obtain |
| token values for such formats provided by extensions. The number of |
| shader binary formats supported can be obtained by querying the |
| value of NUM_SHADER_BINARY_FORMATS. The list of specific binary |
| formats supported can be obtained by querying the value of |
| SHADER_BINARY_FORMATS. |
| |
| Depending on the types of the shader objects in <shaders>, |
| ShaderBinary will individually load binary vertex or fragment |
| shaders, or load an executable binary that contains an optimized |
| pair of vertex and fragment shaders stored in the same binary. |
| |
| An INVALID_ENUM error is generated if <binaryformat> is not a |
| supported format returned in SHADER_BINARY_FORMATS. An INVALID_VALUE |
| error is generated if the data pointed to by binary does not match |
| the specified <binaryformat>. Additional errors corresponding to |
| specific binary formats may be generated as specified by the |
| extensions defining those formats. An INVALID_OPERATION error is |
| generated if more than one of the handles refers to the same type of |
| shader (vertex or fragment shader.) |
| |
| If ShaderBinary fails, the old state of shader objects for which the |
| binary was being loaded will not be restored. Note that if shader |
| binary interfaces are supported, then an OpenGL implementation may |
| require that an optimized pair of vertex and fragment shader binaries |
| that were compiled together be specified to LinkProgram. Not |
| specifying an optimized pair may cause LinkProgram to fail. |
| |
| Section 2.14.4, p. 97 (Uniform Variables) |
| |
| Add after the definition of MAX_VERTEX_UNIFORM_COMPONENTS: |
| |
| The implementation-dependent constant MAX_VERTEX_UNIFORM_VECTORS has |
| a value equal to the value of MAX_VERTEX_UNIFORM_COMPONENTS divided |
| by four. |
| |
| |
| Section 2.14.7, p. 118 (Varying Variables) |
| |
| Add after the definition of MAX_VARYING_COMPONENTS: |
| |
| The implementation-dependent constant MAX_VARYING_VECTORS has a |
| value equal to the value of MAX_VARYING_COMPONENTS divided by four. |
| |
| |
| Section 2.16.1, p. 164 (Controlling the Viewport) |
| |
| Change the second paragraph: |
| |
| The factor and offset applied to zd encoded by n and f are set using |
| |
| void DepthRange(clampd n, clampd f); |
| void DepthRangef(clampf n, clampf f); |
| |
| ... |
| |
| Additions to Chapter 3 of the OpenGL 4.0 Specification (Rasterization) |
| |
| Section 3.9.3 (Texture Image Specification) |
| |
| Add to the list of required texture and renderbuffer color formats on |
| page 262, on the same line as R11F_G11F_B10F: |
| |
| - RGB565 |
| |
| Add to Table 3.17 (Correspondance of sized ...) on page 265, following |
| the row for format RGB5: |
| |
| Sized Internal Format Base Internal Format R bits G bits B bits A bits Shared bits |
| --------------------- -------------------- ------ ------ ------ ------ ----------- |
| RGB565 RGB 5 6 5 |
| |
| |
| Section 3.12.1, p. 323 (Shader Variables) |
| |
| Add after the definition of MAX_FRAGMENT_UNIFORM_COMPONENTS: |
| |
| The implementation-dependent constant MAX_FRAGMENT_UNIFORM_VECTORS |
| has a value equal to the value of MAX_FRAGMENT_UNIFORM_COMPONENTS |
| divided by four. |
| |
| |
| Additions to Chapter 4 of the OpenGL 4.0 Specification (Per-Fragment Operations |
| and the Frame Buffer) |
| |
| Section 4.2.1, p. 352 (Selecting a Buffer for Writing) |
| |
| Extend this paragraph: |
| |
| Indicating a buffer or buffers using DrawBuffer or DrawBuffers causes |
| subsequent pixel color value writes to affect the indicated buffers. If |
| the GL is bound to a framebuffer object and a draw buffer selects an |
| attachment that has no image attached, then that fragment color is not |
| written to any buffer. |
| |
| |
| Section 4.2.3, p. 358 (Clearing the Buffers) |
| |
| Change the third paragraph |
| |
| The commands |
| |
| void ClearDepth(clampd d); |
| void ClearDepthf(clampf d); |
| |
| set the depth value used when clearing the depth buffer. |
| |
| |
| Section 4.3.2, p. 363 (Reading Pixels) |
| |
| Add after the description of ReadPixels: |
| |
| If the current read buffer is neither floating point nor integer, |
| calling GetIntegerv with the symbolic constants |
| IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_COLOR_READ_TYPE will |
| return RGBA and UNSIGNED_BYTE respectively; otherwise it will generate |
| an INVALID_OPERATION error. |
| |
| Extend this sentence: |
| |
| ReadPixels generates an INVALID_OPERATION error if it attempts to |
| select a color buffer while READ_BUFFER is NONE or if the GL is |
| using a framebuffer object (i.e. READ_FRAMEBUFFER_BINDING is |
| non-zero) and the read buffer selects an attachment that has no |
| image attached. |
| |
| |
| Section 4.4.4, p. 390 (Framebuffer Completeness) |
| |
| Remove all references to draw/read buffers affecting completeness. In |
| particular, delete: |
| |
| - The value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE must not be NONE |
| for any color attachment point(s) named by DRAW_BUFFERi. |
| |
| { FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER } |
| |
| - If READ_BUFFER is not NONE, then the value of |
| FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE must not be NONE for the |
| color attachment point named by READ_BUFFER. |
| |
| { FRAMEBUFFER_INCOMPLETE_READ_BUFFER } |
| |
| - Changing the read buffer or one of the draw buffers. |
| |
| |
| Additions to Chapter 5 of the OpenGL 4.0 Specification (Special Functions) |
| |
| None |
| |
| Additions to Chapter 6 of the OpenGL 4.0 Specification (State and |
| State Requests) |
| |
| Section 6.1.18 (Shader and Program Queries) |
| |
| Add after the description of GetShaderSource: |
| |
| The command |
| |
| void GetShaderPrecisionFormat(enum shadertype, |
| enum precisiontype, |
| int *range, int *precision); |
| |
| returns the range and precision for different numeric formats |
| supported by the shader compiler. <shadertype> must be VERTEX_SHADER |
| or FRAGMENT_SHADER. <precisiontype> must be one of LOW_FLOAT, |
| MEDIUM_FLOAT, HIGH_FLOAT, LOW_INT, MEDIUM_INT or HIGH_INT. <range> |
| points to an array of two integers in which encodings of the |
| format's numeric range are returned. If min and max are the smallest |
| and largest values representable in the format, then the values |
| returned are defined to be |
| |
| <range>[0] = floor(log2(|min|)) |
| <range>[1] = floor(log2(|max|)) |
| |
| <precision> points to an integer in which the log2 value of the |
| number of bits of precision of the format is returned. If the |
| smallest representable value greater than 1 is 1 + <eps>, then |
| *<precision> will contain floor(-log2(eps)), and every value in the |
| range |
| |
| [-2^<range>[0], 2^<range>[1]] |
| |
| can be represented to at least one part in 2^*<precision>. For |
| example, an IEEE single-precision floating-point format would return |
| <range>[0] = 127, <range>[1] = 127, and *<precision> = 23, while a |
| 32-bit two's-complement integer format would return <range>[0] = 31, |
| <range>[1] = 30, and *<precision> = 0. |
| |
| The minimum required precision and range for formats corresponding |
| to the different values of <precisiontype> are described in section |
| 4.5 of the OpenGL Shading Language specification. |
| |
| |
| Additions to the OpenGL Shading Language Specification, version 4.00.8 |
| |
| Section 3.3, p. 8 (Preprocessor) |
| |
| ...Version 1.10 of the language does not require shaders to include this |
| directive, and shaders that do not include a #version directive will be |
| treated as targeting version 1.10. Shaders that specify #version 100 will |
| be treated as targeting version 1.00 of the OpenGL ES Shading Language, |
| which is a strict subset of version 1.50. |
| |
| |
| Section 7.3, p. 90 (Built-In Constants) |
| |
| Add the following constants: |
| |
| const int gl_MaxVertexUniformVectors = 256; |
| const int gl_MaxFragmentUniformVectors = 256; |
| const int gl_MaxVaryingVectors = 15; |
| |
| |
| Add a new Section X.Y (Counting of Varyings and Uniforms) |
| |
| GLSL ES 1.00 specifies the storage available for varying variables in |
| terms of an array of 4-vectors. Similarly for uniform variables. The |
| assumption is that variables will be packed into these arrays without |
| wasting space. This places significant burden on implementations since |
| optimal packing is computationally intensive. Implementations may have |
| more internal resources than exposed to the application and so avoid the |
| need to perform packing but this is also considered an expensive |
| solution. |
| |
| ES 2.0 therefore relaxes the requirements for packing by specifying a |
| simpler algorithm that may be used. This algorithm specifies a minimum |
| requirement for when a set of variables must be supported by an |
| implementation. The implementation is allowed to support more than the |
| minimum and so may use a more efficient algorithm and/or may support more |
| registers than the virtual target machine. |
| |
| In all cases, failing resource allocation for variables must result in an |
| error. |
| |
| The resource allocation of variables must succeed for all cases where the |
| following packing algorithm succeeds: |
| |
| - The target architecture consists of a grid of registers, |
| gl_MaxVaryingVectors rows by 4 columns for varying variables and |
| gl_Max{Vertex,Fragment}UniformVectors rows by 4 columns for uniform |
| variables. Each register can contain a float value. |
| |
| - Variables are packed into the registers one at a time so that they each |
| occupy a contiguous subrectangle. No splitting of variables is |
| permitted. |
| |
| - The orientation of variables is fixed. Vectors always occupy registers |
| in a single row. Elements of an array must be in different rows. E.g. |
| vec4 will always occupy one row; float[8] will occupy one column. Since |
| it is not permitted to split a variable, large arrays e.g.. for |
| varyings, float[17] will always fail with this algorithm. |
| |
| - Variables consume only the minimum space required with the exception |
| that mat2 occupies 2 complete rows. This is to allow implementations |
| more flexibility in how variables are stored. |
| |
| - Arrays of size N are assumed to take N times the size of the base type. |
| |
| - Variables are packed in the following order: |
| |
| 1. Arrays of mat4 and mat4 |
| 2. Arrays of mat2 and mat2 (since they occupy full rows) |
| 3. Arrays of vec4 and vec4 |
| 4. Arrays of mat3 and mat3 |
| 5. Arrays of vec3 and vec3 |
| 6. Arrays of vec2 and vec2 |
| 7. Arrays of float and float |
| |
| - For each of the above types, the arrays are processed in order of size, |
| largest first. Arrays of size 1 and the base type are considered |
| equivalent. In the case of varyings, the first type to be packed |
| (successfully) is mat4[2] followed by mat4, mat2[2], mat2, vec4[8], |
| vec4[7],...vec4[1], vec4, mat3[2], mat3 and so on. The last variables |
| to be packed will be float (and float[1]). |
| |
| - For 2,3 and 4 component variables packing is started using the 1st |
| column of the 1st row. Variables are then allocated to successive rows, |
| aligning them to the 1st column. |
| |
| - For 2 component variables, when there are no spare rows, the strategy |
| is switched to using the highest numbered row and the lowest numbered |
| column where the variable will fit. (In practice, this means they will |
| be aligned to the x or z component.) Packing of any further 3 or 4 |
| component variables will fail at this point. |
| |
| - 1 component variables (i.e. floats and arrays of floats) have their own |
| packing rule. They are packed in order of size, largest first. Each |
| variable is placed in the column that leaves the least amount of space |
| in the column and aligned to the lowest available rows within that |
| column. During this phase of packing, space will be available in up to |
| 4 columns. The space within each column is always contiguous. |
| |
| - If at any time the packing of a variable fails, the compiler or linker |
| must report an error. |
| |
| Example: pack the following types, if gl_MaxVaryingVectors were equal to |
| eight: |
| |
| varying vec4 a; // top left |
| varying mat3 b; // align to left, lowest numbered rows |
| varying vec2 c[3]; // align to left, lowest numbered rows |
| varying vec2 d[2]; // Cannot align to left so align to z column, |
| // highest numbered rows |
| varying vec2 e; // Align to left, lowest numbered rows. |
| varying float f[3] // Column with minimum space |
| varying float g[2]; // Column with minimum space (choice of 2, |
| // either one can be used) |
| varying float h; // Column with minimum space |
| |
| In this example, the varyings happen to be listed in the order in which |
| they are packed. Packing is independent of the order of declaration. |
| |
| x y z w |
| 0 a a a a |
| 1 b b b f |
| 2 b b b f |
| 3 b b b f |
| 4 c c g h |
| 5 c c g |
| 6 c c d d |
| 7 e e d d |
| |
| Some varyings e.g. mat4[8] will be too large to fit. These always fail |
| with this algorithm. |
| |
| If referenced in the fragment shader (after preprocessing), the built-in |
| special variables (gl_FragCoord, gl_FrontFacing and gl_PointCoord) are |
| included when calculating the storage requirements of varyings. |
| |
| Only varyings statically used in both shaders are counted. |
| |
| When calculating the number of uniform variables used, any literal |
| constants present in the shader source after preprocessing are included |
| when calculating the storage requirements. Multiple instances of |
| identical constants should count multiple times. |
| |
| Part of the storage may be reserved by an implementation for its own use |
| e.g. for computation of transcendental functions. This reduces the number |
| of uniforms available to the shader. The size of this reduction is |
| undefined but should be minimized. |
| |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None |
| |
| Errors |
| |
| ShaderBinary generates an INVALID_ENUM error if <binaryformat> is |
| not a supported format returned in SHADER_BINARY_FORMATS. |
| |
| ShaderBinary generates an INVALID_VALUE error if the data pointed to |
| by binary does not match the specified <binaryformat>. |
| |
| ShaderBinary generates an INVALID_OPERATION error if more than one |
| of the handles refers to the same type of shader (vertex or fragment |
| shader.) |
| |
| GetIntegerv, GetBooleanv, and GetFloatv generate an INVALID_OPERATION |
| error if <pname> is IMPLEMENTATION_COLOR_READ_TYPE or |
| IMPLEMENTATION_COLOR_READ_FORMAT and the current read buffer is floating |
| point or integer format. |
| |
| ReadPixels generates an INVALID_OPERATION error if it attempts to |
| select a color buffer while READ_BUFFER is NONE or if the GL is |
| using a framebuffer object (i.e. READ_FRAMEBUFFER_BINDING is |
| non-zero) and the read buffer selects an attachment that has no |
| image attached. |
| |
| New State |
| |
| None |
| |
| New Implementation Dependent State |
| |
| Minimum |
| Get Value Type Get Command Value Description Sec. |
| ------------------------- ------- ------------ ------- ------------------------ ------ |
| SHADER_BINARY_FORMATS 0* x Z GetIntegerv - Enumerated shader binary 2.14.2 |
| formats |
| NUM_SHADER_BINARY_FORMATS Z+ GetIntegerv 0 Number of shader binary 2.14.2 |
| formats |
| SHADER_COMPILER B GetBooleanv - Shader compiler supported 2.14 |
| |
| MAX_VERTEX_UNIFORM_VECTORS Z+ GetIntegerv 256 Number of vectors for 2.14.4 |
| vertex shader uniform |
| variables |
| MAX_VARYING_VECTORS Z+ GetIntegerv 15 Number of vectors for 2.14.6 |
| varying variables |
| MAX_FRAGMENT_UNIFORM_VECTORS Z+ GetIntegerv 256 Number of vectors for 3.12.1 |
| fragment shader uniform |
| variables |
| IMPLEMENTATION_COLOR_READ_TYPE Z+ GetIntegerv - Implementation preferred 4.3.2 |
| pixel type |
| IMPLEMENTATION_COLOR_READ_FORMAT Z+ GetIntegerv - Implementation preferred 4.3.2 |
| pixel format |
| |
| |
| Issues |
| |
| (1) Should the uniform/varying limits MAX_*_COMPONENTS vs MAX_*_VECTORS |
| constants be allowed to take independent values, or are they tied |
| together? |
| |
| UNRESOLVED: Currently MAX_*_VECTORS = MAX_*_COMPONENTS / 4. |
| |
| (2) What should IMPLEMENTATION_COLOR_READ_FORMAT and |
| IMPLEMENTATION_COLOR_READ_TYPE do? OpenGL does not have the same |
| limitations of allowed format/type for ReadPixels that ES has. |
| |
| RESOLVED: Always return RGBA/UNSIGNED_BYTE. |
| |
| This query is in the weird situation where the application needs to know |
| how to compute a size based on the format/type combination that is |
| returned as well as how to interpret the data. So if the GL attempts to |
| return "something useful", it may cause an application to have |
| unpredictable behavior if it doesn't understand the values that are |
| returned. Given the wide variety of format/type conversions supported by |
| GL, this feature is not particularly useful - the app can simply use the |
| format it wants. |
| |
| What's really required of this for compatibility is to return a valid |
| format for any legal renderable format in GL ES2.0. RGBA/UNSIGNED_BYTE |
| should be sufficient to accomplish that. Having these queries return |
| an error for float and integer formats discourages their use in the |
| future. |
| |
| (3) The current GLSL ES packing rules hardcode 8 and 128 rather than |
| scaling with the limits exposed by the implementation. Should these |
| scale? |
| |
| RESOLVED: Yes, replace references to 8 and 128 with gl_Max*Vectors. |
| |
| (4) How can we deal with the conflicting behavior of current vertex |
| attribute state being made indeterminate by DrawArrays/DrawElements? |
| |
| UNRESOLVED: GL behavior is currently undefined, so make it defined to |
| match ES behavior. Are there any performance concerns with this? |
| |
| (5) Should the varying/uniform packing rules apply to double-precision |
| types in GL SM5? |
| |
| UNRESOLVED: Yes. Need to insert these into the ordered list of types. |
| |
| (6) What should we do about conflicting #version values? |
| |
| RESOLVED: The original GLSL 1.00 spec did not include #version, it was |
| added in GLSL 1.10 and the first accepted value was "110". GLSL ES has |
| only one version and it is "100", so there is currently no overlap and |
| ambiguity. So GLSL can be extended to accept "100" and always interpret |
| it to mean "GLSL ES 1.00 functionality". |
| |
| Future versions of the shading language specs should be modified to |
| require something in the shader text to indicate which type of GLSL is |
| being used. In GLSL 1.50, the #version command accepts |
| |
| #version <number> <profile_opt> |
| |
| where <profile_opt> can be either "core" or "compatibility". We could |
| require "es" for GLSL ES shaders and make the profile be required in |
| both GLSL and GLSL ES. |
| |
| (7) Are there any existing packing rules that the ES packing rules may |
| conflict with? |
| |
| UNRESOLVED: Named uniform blocks have extensive packing rules, but the ES |
| rules only apply to the default uniform block so those aren't in |
| conflict. The only mention of how things may be packed in the default |
| uniform block is that matrices consume no more than 4*min(r,c) |
| components. For both uniforms and varyings, the spec does not explicitly |
| guarantee that if a program is within the limit then linking will |
| succeed, but that guarantee may be reasonably inferred. |
| |
| The ES rules guarantee that under certain circumstances linking is |
| guaranteed to succeed. Adopting these rules as *the* minimum guarantee |
| will weaken the desktop rules. However, it is likely that some vec4- |
| centric implementations may not be able to satisfy the inferred desktop |
| guarantee. For example, any time a single variable has more array |
| elements than MAX_*_UNIFORM_COMPONENTS/4 and is dynamically indexed. |
| |
| Proposed resolution is to adopt the ES rules as the minimum guarnatee |
| for the default uniform block and for varyings. |
| |
| (8) How should we handle draw buffer completeness? |
| |
| RESOLVED: Remove draw/readbuffer completeness checks, and treat |
| drawbuffers referring to missing attachments as if they were NONE. |
| |
| GL ES does not support MRT and the notions of DrawBuffers and ReadBuffer |
| were removed, including the FRAMEBUFFER_INCOMPLETE_{DRAW,READ}_BUFFER |
| checks. One consequence of this is that a GL ES application can render to |
| a depth-only FBO without calling DrawBuffer, whereas in Desktop GL an |
| application must call DrawBuffer(NONE). To make Desktop GL a superset, we |
| must remove the need to call DrawBuffer(NONE), and the most |
| straightforward way to do that is to remove these completeness checks. |
| |
| (9) What divergent behaviors should this spec leave unaltered? |
| |
| RESOLVED: There are various differing features that cannot be |
| resolved without breaking backward compatibility with desktop |
| applications. |
| |
| * Framebuffer Objects are shared on desktop, but not in ES. |
| * Some textures are incomplete in ES that would be considered |
| complete on desktop. |
| * ES requires different version string formats for API and shading |
| language version queries. |
| |
| |
| (10) Which changes should be made to both the core and compatibility |
| profiles and which should be restricted to the core profile? |
| |
| UNRESOLVED: We should probably decide what needs to go into core and |
| what into compatibility. In the cases that core has removed the |
| features being expanded, this decision is clear. Even where this is |
| not the case, it may make sense to limit certain features to |
| compatibility rather than clutter up core with features only present |
| for ES compatibility. |
| |
| Bruce Merry's suggested division: |
| |
| Core + compatibility: |
| ReleaseShaderCompiler |
| Relaxation of framebuffer completeness rules |
| Preserving current attributes after Draw* |
| |
| Compatibility only: |
| Fixed-point vertex attributes |
| Float versions of DepthRange and ClearDepth |
| Binary shaders |
| #version 100 |
| ES2 packing model |
| implementation read color format |
| vector-based resource-limits |
| GetShaderPrecisionFormat |
| |
| (11) Are immediate mode vertex attrib calls that take fixed point |
| parameters required? |
| |
| RESOLVED: No. The purpose of this extension is limited to |
| facilitating the porting of ES2 applications to the desktop. Adding |
| immediate mode VertexAttrib calls to promote internal consistency |
| with other desktop features is less important. |
| |
| (12) Should RGB565 be added to the extension? |
| |
| RESOLVED: Yes. The initial version of this extension did not include it, |
| as did OpenGL 4.1, which included functionality from this extension. |
| This was an oversight. RGB565 was added to the required format list in |
| the initial release of the OpenGL 4.2 spec, but it was not added to the |
| table of sized internal color formats. However, RGB565 |
| compatibility is important to ES2 compatibility. |
| |
| The ARB discussed this situation in February 2012 and agreed to revise |
| the extension spec and OpenGL 4.2 spec to fully support RGB565. While |
| some drivers may not support RGB565, we believe they will add support |
| quickly. |
| |
| (13) OpenGL ES 2.0 may have some unavoidable differences from an OpenGL |
| context supporting ES2_compatibility, since this extension can't change |
| default GL state values or prevent behavior defined to work by the GL |
| specification. How do we deal with these differences? |
| |
| RESOLVED: If the application needs a strict OpenGL ES 2.0 |
| implementation, it should not attempt to use a desktop GL context |
| with the ES2_compatibility extension supported. Instead, use the |
| {GLX|WGL}_EXT_create_context_es_profile extensions to request an |
| actual OpenGL ES 2.0 context, which will not have these caveats. |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- ---------- --------- ----------------------------------------- |
| 7 03/12/2013 Jon Leech Add issue 13 and copy resolution from |
| ES3_compatibility spec. |
| 6 04/13/2012 Jon Leech Add RGB565 to required texture & renderbuffer |
| formats and to the table of sized internal |
| formats (Bug 8530). |
| 5 08/04/2010 Jon Leech Add SHADER_BINARY_FORMATS to new tokens |
| section. |
| 4 05/26/2010 Jon Leech Add missing tokens, make language more |
| consistent with GL core spec in some places, |
| and reflow paragraphs. |
| 3 05/21/2010 groth limit features to the minimum for portability |
| purge VertexAttrib*. limit shaderbinary to V&F |
| adjust page/section numbers and text to 4.0 |
| 2 05/19/2010 groth respond to bmerry's feedback |
| 1 12/28/2009 jbolz Internal revisions. |
