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