1Name 2 3 ARB_ES2_compatibility 4 5Name Strings 6 7 GL_ARB_ES2_compatibility 8 9Contact 10 11 Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com) 12 13Contributors 14 15 Acorn Pooley, NVIDIA 16 Bruce Merry, ARM 17 Greg Roth, NVIDIA 18 Pat Brown, NVIDIA 19 20Notice 21 22 Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at 23 http://www.khronos.org/registry/speccopyright.html 24 25Status 26 27 Complete. Approved by the ARB on June 9, 2010. 28 Approved by the Khronos Board of Promoters on July 23, 2010. 29 30Version 31 32 Last Modified Date: March 12, 2012 33 Revision: 7 34 35Number 36 37 ARB Extension #95 38 39Dependencies 40 41 Written based on the wording of the OpenGL 4.0 Compatibility 42 Profile (March 11, 2010) specification. 43 44 This extension interacts with ARB_tessellation_shader or OpenGL 4.0. 45 46Overview 47 48 This extension adds support for features of OpenGL ES 2.0 that are 49 missing from OpenGL 3.x. Enabling these features will ease the process 50 of porting applications from OpenGL ES 2.0 to OpenGL. 51 52IP Status 53 54 No known IP claims. 55 56New Procedures and Functions 57 58 void ReleaseShaderCompiler(void); 59 void ShaderBinary(sizei count, const uint *shaders, 60 enum binaryformat, const void *binary, sizei length); 61 void GetShaderPrecisionFormat(enum shadertype, 62 enum precisiontype, 63 int *range, int *precision); 64 65 void DepthRangef(clampf n, clampf f); 66 void ClearDepthf(clampf d); 67 68New Tokens 69 70 Accepted by the <value> parameter of GetBooleanv, GetIntegerv, 71 GetInteger64v, GetFloatv, and GetDoublev: 72 73 SHADER_COMPILER 0x8DFA 74 SHADER_BINARY_FORMATS 0x8DF8 75 NUM_SHADER_BINARY_FORMATS 0x8DF9 76 MAX_VERTEX_UNIFORM_VECTORS 0x8DFB 77 MAX_VARYING_VECTORS 0x8DFC 78 MAX_FRAGMENT_UNIFORM_VECTORS 0x8DFD 79 IMPLEMENTATION_COLOR_READ_TYPE 0x8B9A 80 IMPLEMENTATION_COLOR_READ_FORMAT 0x8B9B 81 82 Accepted by the <type> parameter of VertexAttribPointer: 83 84 FIXED 0x140C 85 86 Accepted by the <precisiontype> parameter of 87 GetShaderPrecisionFormat: 88 89 LOW_FLOAT 0x8DF0 90 MEDIUM_FLOAT 0x8DF1 91 HIGH_FLOAT 0x8DF2 92 LOW_INT 0x8DF3 93 MEDIUM_INT 0x8DF4 94 HIGH_INT 0x8DF5 95 96 Accepted by the <format> parameter of most commands taking sized 97 internal formats: 98 99 RGB565 0x8D62 100 101Additions to Chapter 2 of the OpenGL 4.0 Specification (OpenGL Operation) 102 103 Add a new Section 2.1.5 (Fixed-Point Computation) and renumber later 104 sections: 105 106 Fixed-Point Computation 107 108 Vertex attributes may be specified using a 32-bit two's-complement signed 109 representation with 16 bits to the right of the binary point (fraction 110 bits). 111 112 113 Add to Table 2.2, p. 16 (GL data types) 114 115 GL Type | Minimum | Description 116 | Bit Width | 117 ----------------------------------- 118 fixed | 32 | Signed 2's complement 16.16 scaled integer 119 120 121 Section 2.8, p.36 (Vertex Arrays) 122 123 Adjust the sentence in the first paragraph on p. 37: 124 125 For type the values BYTE, SHORT, INT, FLOAT, HALF_FLOAT, DOUBLE, and 126 FIXED indicate types byte, short, int, float, half, double, and fixed 127 respectively;... 128 129 130 Modify the descripion of the pseudocode explaining 131 ArrayElementInstanced as follows (p.42): 132 133 ... VertexAttrib[size]N[type]v will be called. When a generic vertex 134 attribute array contains fixed-point data, the generic vertex 135 attribute values are specified using a fixed-point signed 2's 136 complement 16.16 scaled integer format. 137 138 Section 2.8.2, p.43 (Drawing Commands) 139 140 Modify the paragraphs that begin with "with one exception" (page 44): 141 142 with one exception: the current normal coordinate, color, secondary 143 color, color index, edge flag, fog coordinate, texture coordinates, 144 and generic attribute values are not modified by the execution of 145 DrawArraysOneInstance. 146 147 ... 148 149 with one exception: the current normal coordinate, color, secondary 150 color, color index, edge flag, fog coordinate, texture coordinates, and 151 generic attribute values are not modified by the execution of 152 DrawElements. 153 154 155 Table 2.5, p. 39 (Vertex array sizes (values per vertex) and data types.) 156 157 Add "fixed" as a legal type for VertexAttribPointer 158 159 160 Section 2.14, p. 89 (Vertex Shaders) 161 162 Modify the third paragraph: 163 164 To use a vertex shader, shader source code is first loaded into a shader 165 object and then compiled. Alternatively, pre-compiled shader binary code 166 may be directly loaded into a shader object. An OpenGL implementation 167 must support shader compilation (the boolean value SHADER_COMPILER must 168 be TRUE). If the integer value NUM_SHADER_BINARY_FORMATS is greater than 169 zero, then shader binary loading is supported. One or more vertex shader 170 objects are then attached to a program object.... 171 172 173 Section 2.14.1, p. 89 (Shader Objects) 174 175 Add before the description of DeleteShader: 176 177 Resources allocated by the shader compiler may be released with the 178 command 179 180 void ReleaseShaderCompiler(void); 181 182 This is a hint from the application, and does not prevent later use 183 of the shader compiler. If shader source is loaded and compiled after 184 ReleaseShaderCompiler has been called, CompileShader must succeed 185 provided there are no errors in the shader source. 186 187 The range and precision for different numeric formats supported by the 188 shader compiler may be determined with the command 189 GetShaderPrecisionFormat (see section 6.1.16) 190 191 192 Add a new Section 2.14.2 (Loading Shader Binaries) and shift other 193 section numbers. 194 195 Precompiled shader binaries may be loaded with the command 196 197 void ShaderBinary(sizei count, const uint *shaders, 198 enum binaryformat, const void *binary, 199 sizei length); 200 201 <shaders> contains a list of <count> shader object handles. Each 202 handle refers to a unique shader type (vertex shader or fragment 203 shader). <binary> points to <length> bytes of pre-compiled binary 204 shader code in client memory, and <binaryformat> denotes the format 205 of the pre-compiled code. 206 207 The binary image will be decoded according to the extension 208 specification defining the specified <binaryformat>. OpenGL defines 209 no specific binary formats, but does provide a mechanism to obtain 210 token values for such formats provided by extensions. The number of 211 shader binary formats supported can be obtained by querying the 212 value of NUM_SHADER_BINARY_FORMATS. The list of specific binary 213 formats supported can be obtained by querying the value of 214 SHADER_BINARY_FORMATS. 215 216 Depending on the types of the shader objects in <shaders>, 217 ShaderBinary will individually load binary vertex or fragment 218 shaders, or load an executable binary that contains an optimized 219 pair of vertex and fragment shaders stored in the same binary. 220 221 An INVALID_ENUM error is generated if <binaryformat> is not a 222 supported format returned in SHADER_BINARY_FORMATS. An INVALID_VALUE 223 error is generated if the data pointed to by binary does not match 224 the specified <binaryformat>. Additional errors corresponding to 225 specific binary formats may be generated as specified by the 226 extensions defining those formats. An INVALID_OPERATION error is 227 generated if more than one of the handles refers to the same type of 228 shader (vertex or fragment shader.) 229 230 If ShaderBinary fails, the old state of shader objects for which the 231 binary was being loaded will not be restored. Note that if shader 232 binary interfaces are supported, then an OpenGL implementation may 233 require that an optimized pair of vertex and fragment shader binaries 234 that were compiled together be specified to LinkProgram. Not 235 specifying an optimized pair may cause LinkProgram to fail. 236 237 Section 2.14.4, p. 97 (Uniform Variables) 238 239 Add after the definition of MAX_VERTEX_UNIFORM_COMPONENTS: 240 241 The implementation-dependent constant MAX_VERTEX_UNIFORM_VECTORS has 242 a value equal to the value of MAX_VERTEX_UNIFORM_COMPONENTS divided 243 by four. 244 245 246 Section 2.14.7, p. 118 (Varying Variables) 247 248 Add after the definition of MAX_VARYING_COMPONENTS: 249 250 The implementation-dependent constant MAX_VARYING_VECTORS has a 251 value equal to the value of MAX_VARYING_COMPONENTS divided by four. 252 253 254 Section 2.16.1, p. 164 (Controlling the Viewport) 255 256 Change the second paragraph: 257 258 The factor and offset applied to zd encoded by n and f are set using 259 260 void DepthRange(clampd n, clampd f); 261 void DepthRangef(clampf n, clampf f); 262 263 ... 264 265Additions to Chapter 3 of the OpenGL 4.0 Specification (Rasterization) 266 267 Section 3.9.3 (Texture Image Specification) 268 269 Add to the list of required texture and renderbuffer color formats on 270 page 262, on the same line as R11F_G11F_B10F: 271 272 - RGB565 273 274 Add to Table 3.17 (Correspondance of sized ...) on page 265, following 275 the row for format RGB5: 276 277 Sized Internal Format Base Internal Format R bits G bits B bits A bits Shared bits 278 --------------------- -------------------- ------ ------ ------ ------ ----------- 279 RGB565 RGB 5 6 5 280 281 282 Section 3.12.1, p. 323 (Shader Variables) 283 284 Add after the definition of MAX_FRAGMENT_UNIFORM_COMPONENTS: 285 286 The implementation-dependent constant MAX_FRAGMENT_UNIFORM_VECTORS 287 has a value equal to the value of MAX_FRAGMENT_UNIFORM_COMPONENTS 288 divided by four. 289 290 291Additions to Chapter 4 of the OpenGL 4.0 Specification (Per-Fragment Operations 292and the Frame Buffer) 293 294 Section 4.2.1, p. 352 (Selecting a Buffer for Writing) 295 296 Extend this paragraph: 297 298 Indicating a buffer or buffers using DrawBuffer or DrawBuffers causes 299 subsequent pixel color value writes to affect the indicated buffers. If 300 the GL is bound to a framebuffer object and a draw buffer selects an 301 attachment that has no image attached, then that fragment color is not 302 written to any buffer. 303 304 305 Section 4.2.3, p. 358 (Clearing the Buffers) 306 307 Change the third paragraph 308 309 The commands 310 311 void ClearDepth(clampd d); 312 void ClearDepthf(clampf d); 313 314 set the depth value used when clearing the depth buffer. 315 316 317 Section 4.3.2, p. 363 (Reading Pixels) 318 319 Add after the description of ReadPixels: 320 321 If the current read buffer is neither floating point nor integer, 322 calling GetIntegerv with the symbolic constants 323 IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_COLOR_READ_TYPE will 324 return RGBA and UNSIGNED_BYTE respectively; otherwise it will generate 325 an INVALID_OPERATION error. 326 327 Extend this sentence: 328 329 ReadPixels generates an INVALID_OPERATION error if it attempts to 330 select a color buffer while READ_BUFFER is NONE or if the GL is 331 using a framebuffer object (i.e. READ_FRAMEBUFFER_BINDING is 332 non-zero) and the read buffer selects an attachment that has no 333 image attached. 334 335 336 Section 4.4.4, p. 390 (Framebuffer Completeness) 337 338 Remove all references to draw/read buffers affecting completeness. In 339 particular, delete: 340 341 - The value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE must not be NONE 342 for any color attachment point(s) named by DRAW_BUFFERi. 343 344 { FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER } 345 346 - If READ_BUFFER is not NONE, then the value of 347 FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE must not be NONE for the 348 color attachment point named by READ_BUFFER. 349 350 { FRAMEBUFFER_INCOMPLETE_READ_BUFFER } 351 352 - Changing the read buffer or one of the draw buffers. 353 354 355Additions to Chapter 5 of the OpenGL 4.0 Specification (Special Functions) 356 357 None 358 359Additions to Chapter 6 of the OpenGL 4.0 Specification (State and 360State Requests) 361 362 Section 6.1.18 (Shader and Program Queries) 363 364 Add after the description of GetShaderSource: 365 366 The command 367 368 void GetShaderPrecisionFormat(enum shadertype, 369 enum precisiontype, 370 int *range, int *precision); 371 372 returns the range and precision for different numeric formats 373 supported by the shader compiler. <shadertype> must be VERTEX_SHADER 374 or FRAGMENT_SHADER. <precisiontype> must be one of LOW_FLOAT, 375 MEDIUM_FLOAT, HIGH_FLOAT, LOW_INT, MEDIUM_INT or HIGH_INT. <range> 376 points to an array of two integers in which encodings of the 377 format's numeric range are returned. If min and max are the smallest 378 and largest values representable in the format, then the values 379 returned are defined to be 380 381 <range>[0] = floor(log2(|min|)) 382 <range>[1] = floor(log2(|max|)) 383 384 <precision> points to an integer in which the log2 value of the 385 number of bits of precision of the format is returned. If the 386 smallest representable value greater than 1 is 1 + <eps>, then 387 *<precision> will contain floor(-log2(eps)), and every value in the 388 range 389 390 [-2^<range>[0], 2^<range>[1]] 391 392 can be represented to at least one part in 2^*<precision>. For 393 example, an IEEE single-precision floating-point format would return 394 <range>[0] = 127, <range>[1] = 127, and *<precision> = 23, while a 395 32-bit two's-complement integer format would return <range>[0] = 31, 396 <range>[1] = 30, and *<precision> = 0. 397 398 The minimum required precision and range for formats corresponding 399 to the different values of <precisiontype> are described in section 400 4.5 of the OpenGL Shading Language specification. 401 402 403Additions to the OpenGL Shading Language Specification, version 4.00.8 404 405 Section 3.3, p. 8 (Preprocessor) 406 407 ...Version 1.10 of the language does not require shaders to include this 408 directive, and shaders that do not include a #version directive will be 409 treated as targeting version 1.10. Shaders that specify #version 100 will 410 be treated as targeting version 1.00 of the OpenGL ES Shading Language, 411 which is a strict subset of version 1.50. 412 413 414 Section 7.3, p. 90 (Built-In Constants) 415 416 Add the following constants: 417 418 const int gl_MaxVertexUniformVectors = 256; 419 const int gl_MaxFragmentUniformVectors = 256; 420 const int gl_MaxVaryingVectors = 15; 421 422 423 Add a new Section X.Y (Counting of Varyings and Uniforms) 424 425 GLSL ES 1.00 specifies the storage available for varying variables in 426 terms of an array of 4-vectors. Similarly for uniform variables. The 427 assumption is that variables will be packed into these arrays without 428 wasting space. This places significant burden on implementations since 429 optimal packing is computationally intensive. Implementations may have 430 more internal resources than exposed to the application and so avoid the 431 need to perform packing but this is also considered an expensive 432 solution. 433 434 ES 2.0 therefore relaxes the requirements for packing by specifying a 435 simpler algorithm that may be used. This algorithm specifies a minimum 436 requirement for when a set of variables must be supported by an 437 implementation. The implementation is allowed to support more than the 438 minimum and so may use a more efficient algorithm and/or may support more 439 registers than the virtual target machine. 440 441 In all cases, failing resource allocation for variables must result in an 442 error. 443 444 The resource allocation of variables must succeed for all cases where the 445 following packing algorithm succeeds: 446 447 - The target architecture consists of a grid of registers, 448 gl_MaxVaryingVectors rows by 4 columns for varying variables and 449 gl_Max{Vertex,Fragment}UniformVectors rows by 4 columns for uniform 450 variables. Each register can contain a float value. 451 452 - Variables are packed into the registers one at a time so that they each 453 occupy a contiguous subrectangle. No splitting of variables is 454 permitted. 455 456 - The orientation of variables is fixed. Vectors always occupy registers 457 in a single row. Elements of an array must be in different rows. E.g. 458 vec4 will always occupy one row; float[8] will occupy one column. Since 459 it is not permitted to split a variable, large arrays e.g.. for 460 varyings, float[17] will always fail with this algorithm. 461 462 - Variables consume only the minimum space required with the exception 463 that mat2 occupies 2 complete rows. This is to allow implementations 464 more flexibility in how variables are stored. 465 466 - Arrays of size N are assumed to take N times the size of the base type. 467 468 - Variables are packed in the following order: 469 470 1. Arrays of mat4 and mat4 471 2. Arrays of mat2 and mat2 (since they occupy full rows) 472 3. Arrays of vec4 and vec4 473 4. Arrays of mat3 and mat3 474 5. Arrays of vec3 and vec3 475 6. Arrays of vec2 and vec2 476 7. Arrays of float and float 477 478 - For each of the above types, the arrays are processed in order of size, 479 largest first. Arrays of size 1 and the base type are considered 480 equivalent. In the case of varyings, the first type to be packed 481 (successfully) is mat4[2] followed by mat4, mat2[2], mat2, vec4[8], 482 vec4[7],...vec4[1], vec4, mat3[2], mat3 and so on. The last variables 483 to be packed will be float (and float[1]). 484 485 - For 2,3 and 4 component variables packing is started using the 1st 486 column of the 1st row. Variables are then allocated to successive rows, 487 aligning them to the 1st column. 488 489 - For 2 component variables, when there are no spare rows, the strategy 490 is switched to using the highest numbered row and the lowest numbered 491 column where the variable will fit. (In practice, this means they will 492 be aligned to the x or z component.) Packing of any further 3 or 4 493 component variables will fail at this point. 494 495 - 1 component variables (i.e. floats and arrays of floats) have their own 496 packing rule. They are packed in order of size, largest first. Each 497 variable is placed in the column that leaves the least amount of space 498 in the column and aligned to the lowest available rows within that 499 column. During this phase of packing, space will be available in up to 500 4 columns. The space within each column is always contiguous. 501 502 - If at any time the packing of a variable fails, the compiler or linker 503 must report an error. 504 505 Example: pack the following types, if gl_MaxVaryingVectors were equal to 506 eight: 507 508 varying vec4 a; // top left 509 varying mat3 b; // align to left, lowest numbered rows 510 varying vec2 c[3]; // align to left, lowest numbered rows 511 varying vec2 d[2]; // Cannot align to left so align to z column, 512 // highest numbered rows 513 varying vec2 e; // Align to left, lowest numbered rows. 514 varying float f[3] // Column with minimum space 515 varying float g[2]; // Column with minimum space (choice of 2, 516 // either one can be used) 517 varying float h; // Column with minimum space 518 519 In this example, the varyings happen to be listed in the order in which 520 they are packed. Packing is independent of the order of declaration. 521 522 x y z w 523 0 a a a a 524 1 b b b f 525 2 b b b f 526 3 b b b f 527 4 c c g h 528 5 c c g 529 6 c c d d 530 7 e e d d 531 532 Some varyings e.g. mat4[8] will be too large to fit. These always fail 533 with this algorithm. 534 535 If referenced in the fragment shader (after preprocessing), the built-in 536 special variables (gl_FragCoord, gl_FrontFacing and gl_PointCoord) are 537 included when calculating the storage requirements of varyings. 538 539 Only varyings statically used in both shaders are counted. 540 541 When calculating the number of uniform variables used, any literal 542 constants present in the shader source after preprocessing are included 543 when calculating the storage requirements. Multiple instances of 544 identical constants should count multiple times. 545 546 Part of the storage may be reserved by an implementation for its own use 547 e.g. for computation of transcendental functions. This reduces the number 548 of uniforms available to the shader. The size of this reduction is 549 undefined but should be minimized. 550 551 552Additions to the AGL/GLX/WGL Specifications 553 554 None 555 556Errors 557 558 ShaderBinary generates an INVALID_ENUM error if <binaryformat> is 559 not a supported format returned in SHADER_BINARY_FORMATS. 560 561 ShaderBinary generates an INVALID_VALUE error if the data pointed to 562 by binary does not match the specified <binaryformat>. 563 564 ShaderBinary generates an INVALID_OPERATION error if more than one 565 of the handles refers to the same type of shader (vertex or fragment 566 shader.) 567 568 GetIntegerv, GetBooleanv, and GetFloatv generate an INVALID_OPERATION 569 error if <pname> is IMPLEMENTATION_COLOR_READ_TYPE or 570 IMPLEMENTATION_COLOR_READ_FORMAT and the current read buffer is floating 571 point or integer format. 572 573 ReadPixels generates an INVALID_OPERATION error if it attempts to 574 select a color buffer while READ_BUFFER is NONE or if the GL is 575 using a framebuffer object (i.e. READ_FRAMEBUFFER_BINDING is 576 non-zero) and the read buffer selects an attachment that has no 577 image attached. 578 579New State 580 581 None 582 583New Implementation Dependent State 584 585 Minimum 586 Get Value Type Get Command Value Description Sec. 587 ------------------------- ------- ------------ ------- ------------------------ ------ 588 SHADER_BINARY_FORMATS 0* x Z GetIntegerv - Enumerated shader binary 2.14.2 589 formats 590 NUM_SHADER_BINARY_FORMATS Z+ GetIntegerv 0 Number of shader binary 2.14.2 591 formats 592 SHADER_COMPILER B GetBooleanv - Shader compiler supported 2.14 593 594 MAX_VERTEX_UNIFORM_VECTORS Z+ GetIntegerv 256 Number of vectors for 2.14.4 595 vertex shader uniform 596 variables 597 MAX_VARYING_VECTORS Z+ GetIntegerv 15 Number of vectors for 2.14.6 598 varying variables 599 MAX_FRAGMENT_UNIFORM_VECTORS Z+ GetIntegerv 256 Number of vectors for 3.12.1 600 fragment shader uniform 601 variables 602 IMPLEMENTATION_COLOR_READ_TYPE Z+ GetIntegerv - Implementation preferred 4.3.2 603 pixel type 604 IMPLEMENTATION_COLOR_READ_FORMAT Z+ GetIntegerv - Implementation preferred 4.3.2 605 pixel format 606 607 608Issues 609 610 (1) Should the uniform/varying limits MAX_*_COMPONENTS vs MAX_*_VECTORS 611 constants be allowed to take independent values, or are they tied 612 together? 613 614 UNRESOLVED: Currently MAX_*_VECTORS = MAX_*_COMPONENTS / 4. 615 616 (2) What should IMPLEMENTATION_COLOR_READ_FORMAT and 617 IMPLEMENTATION_COLOR_READ_TYPE do? OpenGL does not have the same 618 limitations of allowed format/type for ReadPixels that ES has. 619 620 RESOLVED: Always return RGBA/UNSIGNED_BYTE. 621 622 This query is in the weird situation where the application needs to know 623 how to compute a size based on the format/type combination that is 624 returned as well as how to interpret the data. So if the GL attempts to 625 return "something useful", it may cause an application to have 626 unpredictable behavior if it doesn't understand the values that are 627 returned. Given the wide variety of format/type conversions supported by 628 GL, this feature is not particularly useful - the app can simply use the 629 format it wants. 630 631 What's really required of this for compatibility is to return a valid 632 format for any legal renderable format in GL ES2.0. RGBA/UNSIGNED_BYTE 633 should be sufficient to accomplish that. Having these queries return 634 an error for float and integer formats discourages their use in the 635 future. 636 637 (3) The current GLSL ES packing rules hardcode 8 and 128 rather than 638 scaling with the limits exposed by the implementation. Should these 639 scale? 640 641 RESOLVED: Yes, replace references to 8 and 128 with gl_Max*Vectors. 642 643 (4) How can we deal with the conflicting behavior of current vertex 644 attribute state being made indeterminate by DrawArrays/DrawElements? 645 646 UNRESOLVED: GL behavior is currently undefined, so make it defined to 647 match ES behavior. Are there any performance concerns with this? 648 649 (5) Should the varying/uniform packing rules apply to double-precision 650 types in GL SM5? 651 652 UNRESOLVED: Yes. Need to insert these into the ordered list of types. 653 654 (6) What should we do about conflicting #version values? 655 656 RESOLVED: The original GLSL 1.00 spec did not include #version, it was 657 added in GLSL 1.10 and the first accepted value was "110". GLSL ES has 658 only one version and it is "100", so there is currently no overlap and 659 ambiguity. So GLSL can be extended to accept "100" and always interpret 660 it to mean "GLSL ES 1.00 functionality". 661 662 Future versions of the shading language specs should be modified to 663 require something in the shader text to indicate which type of GLSL is 664 being used. In GLSL 1.50, the #version command accepts 665 666 #version <number> <profile_opt> 667 668 where <profile_opt> can be either "core" or "compatibility". We could 669 require "es" for GLSL ES shaders and make the profile be required in 670 both GLSL and GLSL ES. 671 672 (7) Are there any existing packing rules that the ES packing rules may 673 conflict with? 674 675 UNRESOLVED: Named uniform blocks have extensive packing rules, but the ES 676 rules only apply to the default uniform block so those aren't in 677 conflict. The only mention of how things may be packed in the default 678 uniform block is that matrices consume no more than 4*min(r,c) 679 components. For both uniforms and varyings, the spec does not explicitly 680 guarantee that if a program is within the limit then linking will 681 succeed, but that guarantee may be reasonably inferred. 682 683 The ES rules guarantee that under certain circumstances linking is 684 guaranteed to succeed. Adopting these rules as *the* minimum guarantee 685 will weaken the desktop rules. However, it is likely that some vec4- 686 centric implementations may not be able to satisfy the inferred desktop 687 guarantee. For example, any time a single variable has more array 688 elements than MAX_*_UNIFORM_COMPONENTS/4 and is dynamically indexed. 689 690 Proposed resolution is to adopt the ES rules as the minimum guarnatee 691 for the default uniform block and for varyings. 692 693 (8) How should we handle draw buffer completeness? 694 695 RESOLVED: Remove draw/readbuffer completeness checks, and treat 696 drawbuffers referring to missing attachments as if they were NONE. 697 698 GL ES does not support MRT and the notions of DrawBuffers and ReadBuffer 699 were removed, including the FRAMEBUFFER_INCOMPLETE_{DRAW,READ}_BUFFER 700 checks. One consequence of this is that a GL ES application can render to 701 a depth-only FBO without calling DrawBuffer, whereas in Desktop GL an 702 application must call DrawBuffer(NONE). To make Desktop GL a superset, we 703 must remove the need to call DrawBuffer(NONE), and the most 704 straightforward way to do that is to remove these completeness checks. 705 706 (9) What divergent behaviors should this spec leave unaltered? 707 708 RESOLVED: There are various differing features that cannot be 709 resolved without breaking backward compatibility with desktop 710 applications. 711 712 * Framebuffer Objects are shared on desktop, but not in ES. 713 * Some textures are incomplete in ES that would be considered 714 complete on desktop. 715 * ES requires different version string formats for API and shading 716 language version queries. 717 718 719 (10) Which changes should be made to both the core and compatibility 720 profiles and which should be restricted to the core profile? 721 722 UNRESOLVED: We should probably decide what needs to go into core and 723 what into compatibility. In the cases that core has removed the 724 features being expanded, this decision is clear. Even where this is 725 not the case, it may make sense to limit certain features to 726 compatibility rather than clutter up core with features only present 727 for ES compatibility. 728 729 Bruce Merry's suggested division: 730 731 Core + compatibility: 732 ReleaseShaderCompiler 733 Relaxation of framebuffer completeness rules 734 Preserving current attributes after Draw* 735 736 Compatibility only: 737 Fixed-point vertex attributes 738 Float versions of DepthRange and ClearDepth 739 Binary shaders 740 #version 100 741 ES2 packing model 742 implementation read color format 743 vector-based resource-limits 744 GetShaderPrecisionFormat 745 746 (11) Are immediate mode vertex attrib calls that take fixed point 747 parameters required? 748 749 RESOLVED: No. The purpose of this extension is limited to 750 facilitating the porting of ES2 applications to the desktop. Adding 751 immediate mode VertexAttrib calls to promote internal consistency 752 with other desktop features is less important. 753 754 (12) Should RGB565 be added to the extension? 755 756 RESOLVED: Yes. The initial version of this extension did not include it, 757 as did OpenGL 4.1, which included functionality from this extension. 758 This was an oversight. RGB565 was added to the required format list in 759 the initial release of the OpenGL 4.2 spec, but it was not added to the 760 table of sized internal color formats. However, RGB565 761 compatibility is important to ES2 compatibility. 762 763 The ARB discussed this situation in February 2012 and agreed to revise 764 the extension spec and OpenGL 4.2 spec to fully support RGB565. While 765 some drivers may not support RGB565, we believe they will add support 766 quickly. 767 768 (13) OpenGL ES 2.0 may have some unavoidable differences from an OpenGL 769 context supporting ES2_compatibility, since this extension can't change 770 default GL state values or prevent behavior defined to work by the GL 771 specification. How do we deal with these differences? 772 773 RESOLVED: If the application needs a strict OpenGL ES 2.0 774 implementation, it should not attempt to use a desktop GL context 775 with the ES2_compatibility extension supported. Instead, use the 776 {GLX|WGL}_EXT_create_context_es_profile extensions to request an 777 actual OpenGL ES 2.0 context, which will not have these caveats. 778 779Revision History 780 781 Rev. Date Author Changes 782 ---- ---------- --------- ----------------------------------------- 783 7 03/12/2013 Jon Leech Add issue 13 and copy resolution from 784 ES3_compatibility spec. 785 6 04/13/2012 Jon Leech Add RGB565 to required texture & renderbuffer 786 formats and to the table of sized internal 787 formats (Bug 8530). 788 5 08/04/2010 Jon Leech Add SHADER_BINARY_FORMATS to new tokens 789 section. 790 4 05/26/2010 Jon Leech Add missing tokens, make language more 791 consistent with GL core spec in some places, 792 and reflow paragraphs. 793 3 05/21/2010 groth limit features to the minimum for portability 794 purge VertexAttrib*. limit shaderbinary to V&F 795 adjust page/section numbers and text to 4.0 796 2 05/19/2010 groth respond to bmerry's feedback 797 1 12/28/2009 jbolz Internal revisions. 798