1Name 2 3 OES_geometry_shader 4 5Name String 6 7 GL_OES_geometry_shader 8 GL_OES_geometry_point_size 9 10Contact 11 12 Jon Leech (oddhack 'at' sonic.net) 13 Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) 14 15Contributors 16 17 Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) 18 Pat Brown, NVIDIA (pbrown 'at' nvidia.com) 19 Slawomir Grajewski, Intel 20 Dominik Witczak, Mobica 21 Jesse Hall, Google 22 Maurice Ribble, Qualcomm 23 Bill Licea-Kane, Qualcomm 24 Graham Connor, Imagination 25 Ben Bowman, Imagination 26 Jonathan Putsman, Imagination 27 Contributors to ARB_geometry_shader4 28 29Notice 30 31 Copyright (c) 2008-2016 The Khronos Group Inc. Copyright terms at 32 http://www.khronos.org/registry/speccopyright.html 33 34Specification Update Policy 35 36 Khronos-approved extension specifications are updated in response to 37 issues and bugs prioritized by the Khronos OpenGL ES Working Group. For 38 extensions which have been promoted to a core Specification, fixes will 39 first appear in the latest version of that core Specification, and will 40 eventually be backported to the extension document. This policy is 41 described in more detail at 42 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 43 44 Portions Copyright (c) 2013-2014 NVIDIA Corporation. 45 46Status 47 48 Approved by the OpenGL ES Working Group 49 Ratified by the Khronos Board of Promoters on November 7, 2014 50 51Version 52 53 Last Modified Date: May 31, 2016 54 Revision: 4 55 56Number 57 58 OpenGL ES Extension #210 59 60Dependencies 61 62 OpenGL ES 3.1 and OpenGL ES Shading Language 3.10 are required. 63 64 This specification is written against the OpenGL ES 3.1 (March 17, 2014) 65 and OpenGL ES 3.10 Shading Language (March 17, 2014) Specifications. 66 67 OES_shader_io_blocks or EXT_shader_io_blocks is required. 68 69 OES_sample_variables trivially affects the definition of this extension. 70 71 OES_texture_storage_multisample_2d_array affects the definition of this 72 extension. 73 74 OES_shader_multisample_interpolation trivially affects the definition of 75 this extension. 76 77 OES_texture_buffer and EXT_texture_buffer trivially affect the definition 78 of this extension. 79 80Overview 81 82 OES_geometry_shader defines a new shader type available to be run on the 83 GPU, called a geometry shader. Geometry shaders are run after vertices are 84 transformed, but prior to color clamping, flatshading and clipping. 85 86 A geometry shader begins with a single primitive (point, line, 87 triangle). It can read the attributes of any of the vertices in the 88 primitive and use them to generate new primitives. A geometry shader has a 89 fixed output primitive type (point, line strip, or triangle strip) and 90 emits vertices to define a new primitive. A geometry shader can emit 91 multiple disconnected primitives. The primitives emitted by the geometry 92 shader are clipped and then processed like an equivalent primitive 93 specified by the application. 94 95 Furthermore, OES_geometry_shader provides four additional primitive 96 types: lines with adjacency, line strips with adjacency, separate 97 triangles with adjacency, and triangle strips with adjacency. Some of the 98 vertices specified in these new primitive types are not part of the 99 ordinary primitives, instead they represent neighboring vertices that are 100 adjacent to the two line segment end points (lines/strips) or the three 101 triangle edges (triangles/tstrips). These vertices can be accessed by 102 geometry shaders and used to match up the vertices emitted by the geometry 103 shader with those of neighboring primitives. 104 105 Since geometry shaders expect a specific input primitive type, an error 106 will occur if the application presents primitives of a different type. 107 For example, if a geometry shader expects points, an error will occur at 108 drawing time if a primitive mode of TRIANGLES is specified. 109 110 This extension also adds the notion of layered framebuffer attachments 111 and framebuffers that can be used in conjunction with geometry shaders 112 to allow programs to direct primitives to a face of a cube map or layer 113 of a three-dimensional texture or two-dimensional array texture. The 114 layer used for rendering can be selected by the geometry shader at run 115 time. The framebuffer layer count present in GL 4.x and removed from 116 ES 3.1 is restored. 117 118 Not all geometry shader implementations have the ability to write the 119 point size from a geometry shader. Thus a second extension string and 120 shading language enable are provided for implementations which do 121 support geometry shader point size. 122 123 This extension relies on the OES_shader_io_blocks extension to provide 124 the required functionality for declaring input and output blocks and 125 interfacing between shaders. 126 127New Procedures and Functions 128 129 void FramebufferTextureOES(enum target, enum attachment, 130 uint texture, int level); 131 132New Tokens 133 134 Accepted by the <type> parameter of CreateShader and 135 CreateShaderProgramv, by the <pname> parameter of 136 GetProgramPipelineiv and returned in the <params> parameter of 137 GetShaderiv when <pname> is SHADER_TYPE: 138 139 GEOMETRY_SHADER_OES 0x8DD9 140 141 Accepted by the <stages> parameter of UseProgramStages: 142 143 GEOMETRY_SHADER_BIT_OES 0x00000004 144 145 Accepted by the <pname> parameter of GetProgramiv: 146 147 GEOMETRY_LINKED_VERTICES_OUT_OES 0x8916 148 GEOMETRY_LINKED_INPUT_TYPE_OES 0x8917 149 GEOMETRY_LINKED_OUTPUT_TYPE_OES 0x8918 150 GEOMETRY_SHADER_INVOCATIONS_OES 0x887F 151 152 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 153 GetFloatv, and GetInteger64v: 154 155 LAYER_PROVOKING_VERTEX_OES 0x825E 156 MAX_GEOMETRY_UNIFORM_COMPONENTS_OES 0x8DDF 157 MAX_GEOMETRY_UNIFORM_BLOCKS_OES 0x8A2C 158 MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS_OES 0x8A32 159 MAX_GEOMETRY_INPUT_COMPONENTS_OES 0x9123 160 MAX_GEOMETRY_OUTPUT_COMPONENTS_OES 0x9124 161 MAX_GEOMETRY_OUTPUT_VERTICES_OES 0x8DE0 162 MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_OES 0x8DE1 163 MAX_GEOMETRY_SHADER_INVOCATIONS_OES 0x8E5A 164 MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_OES 0x8C29 165 MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_OES 0x92CF 166 MAX_GEOMETRY_ATOMIC_COUNTERS_OES 0x92D5 167 MAX_GEOMETRY_IMAGE_UNIFORMS_OES 0x90CD 168 MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_OES 0x90D7 169 170 Returned in the <data> parameter from a Get query with a <pname> of 171 LAYER_PROVOKING_VERTEX_OES: 172 173 FIRST_VERTEX_CONVENTION_OES 0x8E4D 174 LAST_VERTEX_CONVENTION_OES 0x8E4E 175 UNDEFINED_VERTEX_OES 0x8260 176 177 Accepted by the <target> parameter of BeginQuery, EndQuery, 178 GetQueryiv, and GetQueryObjectuiv: 179 180 PRIMITIVES_GENERATED_OES 0x8C87 181 182 Accepted by the <mode> parameter of DrawArrays, DrawElements, 183 and other commands which draw primitives: 184 185 LINES_ADJACENCY_OES 0xA 186 LINE_STRIP_ADJACENCY_OES 0xB 187 TRIANGLES_ADJACENCY_OES 0xC 188 TRIANGLE_STRIP_ADJACENCY_OES 0xD 189 190 Accepted by the <pname> parameter of FramebufferParameteri, 191 and GetFramebufferParameteriv: 192 193 FRAMEBUFFER_DEFAULT_LAYERS_OES 0x9312 194 195 Accepted by the <pname> parameter of GetIntegerv, GetBooleanv, 196 GetInteger64v, and GetFloatv: 197 198 MAX_FRAMEBUFFER_LAYERS_OES 0x9317 199 200 Returned by CheckFramebufferStatus: 201 202 FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_OES 0x8DA8 203 204 Accepted by the <pname> parameter of 205 GetFramebufferAttachmentParameteriv: 206 207 FRAMEBUFFER_ATTACHMENT_LAYERED_OES 0x8DA7 208 209 Accepted by the <props> parameter of 210 GetProgramResourceiv: 211 212 REFERENCED_BY_GEOMETRY_SHADER_OES 0x9309 213 214Additions to the OpenGL ES 3.1 Specification 215 216 Modify chapter 3 "Dataflow Model" 217 218 Change the second paragraph, on p. 28: 219 220 ... In the next stage vertices may be transformed, followed by assembly 221 into geometric primitives. Geometry shaders may then optionally generate 222 multiple new primitives from single input primitives. Optionally, the 223 results ... 224 225 226 Modify figure 3.1 "Block diagram of the OpenGL ES pipeline" to insert a 227 new box "Geometry Shader" following "Vertex Shader" and preceding 228 "Rasterization". Connect the Geometry Shader box to Transform Feedback 229 and Rasterization boxes, and remove the connection from Vertex Shader to 230 Transform Feedback. Extend the arrows from the boxes "Image Load/Store" 231 .. "Uniform Block" to the right of "Vertex Shader" to connect to the new 232 "Geometry Shader" box. 233 234 235 Modify section 4.2, "Query Objects and Asynchronous Queries" on p. 36 236 to add to the bullet list of supported query types 237 238 * Primitive queries with a target of PRIMITIVES_GENERATED_OES (see 239 section 12.2) return information on the number of primitives processed 240 by the GL. 241 242 243 Replace the two paragraphs of chapter 7, "Programs and Shaders" 244 on p. 64 starting "Shader stages including ..." with: 245 246 Shader stages including vertex, geometry, fragment, and compute shaders 247 can be created, compiled, and linked into program objects. 248 249 Vertex shaders describe the operations that occur on vertex attributes. 250 Geometry shaders affect the processing of primitives assembled from 251 vertices (see section 11.1gs). Fragment shaders affect the processing of 252 fragments during rasterization (see chapter 14). A single program 253 object can contain all of these shaders, or any subset thereof. 254 255 Compute shaders ... 256 257 258 Add to table 7.1 "CreateShader <type> values" on p. 65: 259 260 <type> Shader Stage 261 ------------------- --------------- 262 GEOMETRY_SHADER_OES Geometry shader 263 264 265 Change bullet list describing reasons for link failure below the 266 LinkProgram command on p. 70: 267 268 ... Linking can fail for a variety of reasons as specified in the OpenGL 269 ES Shading Language Specification, as well as any of the following 270 reasons: 271 272 * One or more of the shader objects attached to <program> are not 273 compiled successfully. 274 * More active uniform or active sampler variables are used in <program> 275 than allowed (see sections 7.6 and 7.9). 276 * The shaders do not use the same shader language version. 277 * <program> contains objects to form a geometry shader (see section 278 11.1gs), and 279 - <program> is not separable and contains no objects to form a 280 vertex shader; or 281 - the input primitive type, output primitive type, or maximum output 282 vertex count is not specified in the compiled geometry shader 283 object. 284 * <program> contains objects to form a compute shader (see section 17) 285 and 286 - <program> also contains objects to form any other type of shader. 287 288 If LinkProgram failed, ... 289 290 291 Modify section 7.3, "Program Objects": 292 293 Add to the second paragraph after UseProgram on p. 71: 294 295 The executable code ... the results of vertex and/or fragment processing 296 will be undefined. However, this is not an error. If there is no active 297 program for the geometry shader stage, that stage is ignored. If there 298 is no active program for the compute shader stage ... 299 300 301 Modify section 7.3.1, "Program Interfaces": 302 303 Modify table 7.2 "GetProgramResourceiv properties and supported 304 interfaces" on p. 81 to add "REFERENCED_BY_GEOMETRY_SHADER_OES" to the 305 "Property" cell already containing REFERENCED_BY_<stage>_SHADER for 306 VERTEX, FRAGMENT, and COMPUTE stages, with the same supported 307 interfaces. 308 309 310 Add geometry shaders to the paragraph describing the REFERENCED_BY 311 properties, on p. 83: 312 313 For the properties REFERENCED_BY_VERTEX_SHADER, 314 REFERENCED_BY_GEOMETRY_SHADER_OES, REFERENCED_BY_FRAGMENT_SHADER, and 315 REFERENCED_BY_COMPUTE_SHADER, a single integer is written to <params>, 316 identifying whether the active resource is referenced by the vertex, 317 geometry, fragment, or compute shaders, respectively, in the program 318 object. ... 319 320 321 Modify section 7.4, "Program Pipeline Objects" in the first paragraph 322 paragraph after UseProgramStages on p. 89: 323 324 ... These stages may include vertex, geometry, fragment, or compute, 325 indicated respectively by VERTEX_SHADER_BIT, GEOMETRY_SHADER_BIT_OES, 326 FRAGMENT_SHADER_BIT, or COMPUTE_SHADER_BIT. ... 327 328 329 Modify section 7.4.1, "Shader Interface Matching" on p. 91, changing 330 the second paragraph and adding a new paragraph: 331 332 Variables and block members declared as structures ... in the OpenGL ES 333 Shading Language Specification. 334 335 Geometry shader per-vertex input variables and blocks are required to be 336 declared as arrays, with each element representing input or output 337 values for a single vertex of a multi-vertex primitive. For the purposes 338 of interface matching, such variables and blocks are treated as though 339 they were not declared as arrays. 340 341 For program objects containing multiple shaders... 342 343 344 Modify section 7.4.2 "Program Pipeline Object State" on p. 92, 345 replacing the first bullet point: 346 347 * Unsigned integers are required to hold the names of the active program 348 and each of the current vertex, geometry, fragment, and compute stage 349 programs. Each integer is initially zero. 350 351 352 Modify section 7.6, "Uniform Variables" 353 354 Add to table 7.4 "Query targets for default uniform block storage ..." 355 on p. 96: 356 357 Shader Stage <pname> for querying default uniform block 358 storage, in components 359 ---------------------------- ------------------------------------------- 360 Geometry (see sec. 11.1gs.3) MAX_GEOMETRY_UNIFORM_COMPONENTS_OES 361 362 363 Add to table 7.5 "Query targets for combined uniform block storage ..." 364 on p. 97: 365 366 367 Shader Stage <pname> for querying combined uniform block 368 storage, in components 369 ---------------------------- -------------------------------------------- 370 Geometry MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS_OES 371 372 373 Modify section 7.6.2, "Uniform Blocks" on p. 104, changing the second 374 paragraph of the section: 375 376 There is a set of implementation-dependent maximums for the number of 377 active uniform blocks used by each shader. If the number of uniform 378 blocks used by any shader in the program exceeds its corresponding 379 limit, the program will fail to link. The limits for vertex, geometry, 380 fragment, and compute shaders can be obtained by calling GetIntegerv 381 with <pname> values of MAX_VERTEX_UNIFORM_BLOCKS, 382 MAX_GEOMETRY_UNIFORM_BLOCKS_OES, MAX_FRAGMENT_UNIFORM_BLOCKS, and 383 MAX_COMPUTE_UNIFORM_BLOCKS, respectively. 384 385 386 Modify section 7.7, "Atomic Counter Buffers" on p. 108, changing the 387 second paragraph of the section: 388 389 There is a set of implementation-dependent maximums for the number of 390 active atomic counter buffers referenced by each shader. If the number 391 of atomic counter buffers referenced by any shader in the program 392 exceeds its corresponding limit, the program will fail to link. The 393 limits for vertex, geometry, fragment, and compute shaders can be 394 obtained by calling GetIntegerv with <pname> values of 395 MAX_VERTEX_ATOMIC_COUNTER_BUFFERS, 396 MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_OES, 397 MAX_FRAGMENT_ATOMIC_COUNTER_BUFFERS, or 398 MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS, respectively. 399 400 401 Modify section 7.8, "Shader Buffer Variables and Shader Storage Blocks" 402 on p. 110, changing the fourth paragraph: 403 404 If the number of active shader storage blocks referenced by the shaders 405 in a program exceeds implementation-dependent limits, the program will 406 fail to link. The limits for vertex, geometry, fragment, and compute 407 shaders can be obtained by calling GetIntegerv with pname values of 408 MAX_VERTEX_SHADER_STORAGE_BLOCKS, 409 MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_OES, 410 MAX_FRAGMENT_SHADER_STORAGE_BLOCKS, and 411 MAX_COMPUTE_SHADER_STORAGE_BLOCKS, respectively. Additionally, a ... 412 413 414 Modify section 7.11.1 "Shader Memory Access Ordering" on p. 113 to add 415 to the list of ordering rules: 416 417 * The relative order of invocations of different shader types is largely 418 undefined. However, when executing a shader whose inputs are generated 419 from a previous programmable stage, the shader invocations from the 420 previous stage are guaranteed to have executed far enough to generate 421 final values for all next-stage inputs. That implies shader completion 422 for all stages except geometry; geometry shaders are guaranteed only 423 to have executed far enough to emit all needed vertices. 424 425 426 Modify section 7.12, "Shader, Program, and Program Pipeline Queries" 427 to add to the list of valid <pname>s for GetProgramiv on p. 121: 428 429 If <pname> is GEOMETRY_LINKED_VERTICES_OUT_OES, the maximum number of 430 vertices the geometry shader will output is returned. 431 432 If <pname> is GEOMETRY_LINKED_INPUT_TYPE_OES, the geometry shader input 433 type, which must be one of POINTS, LINES, LINES_ADJACENCY_OES, TRIANGLES 434 or TRIANGLES_ADJACENCY_OES, is returned. 435 436 If <pname> is GEOMETRY_LINKED_OUTPUT_TYPE_OES, the current geometry shader 437 output type, which must be one of POINTS, LINE_STRIP or TRIANGLE_STRIP, 438 is returned. 439 440 If <pname> is GEOMETRY_SHADER_INVOCATIONS_OES, the number of geometry 441 shader invocations per primitive will be returned. 442 443 444 Add to the Errors for GetProgramiv on p. 121: 445 446 An INVALID_OPERATION error is generated if 447 GEOMETRY_LINKED_VERTICES_OUT_OES, GEOMETRY_LINKED_INPUT_TYPE_OES, 448 GEOMETRY_LINKED_OUTPUT_TYPE_OES, or GEOMETRY_SHADER_INVOCATIONS_OES are 449 queried for a program which has not been linked successfully, or which 450 does not contain objects to form a geometry shader, 451 452 453 Modify section 7.13 "Required State" to change the last two paragraphs 454 of the section on p. 127: 455 456 This list of program object state is not complete. Tables 20.20-20.28 457 describe additional program object state specific to program binaries, 458 geometry shaders, and uniform blocks. 459 460 Table 20.29 describes state related to vertex and geometry shaders that 461 is not program object state. 462 463 464 Modify section 9.2, "Binding and Managing Framebuffer Objects" to add to 465 the list of bullet points for BindFramebuffer on p. 205: 466 467 * If the number of layers of each attachment are not all identical, 468 rendering will be limited to the smallest number of layers of any 469 attachment. If there are no attachments, the number of layers will be 470 taken from the framebuffer object's default layer count. 471 472 473 Modify section 9.2.1, "Framebuffer Object Parameters" to replace the 474 second and third paragraphs of the section, adding default and maximum 475 layer counts to FramebufferParameteri, on p. 206 and p. 207: 476 477 When a framebuffer has one or more attachments, the width, height, layer 478 count (section 9.7gs), sample count, and sample location pattern of the 479 framebuffer are derived from the properties of the framebuffer 480 attachments. When the framebuffer has no attachments, these properties 481 are taken from framebuffer parameters. When <pname> is 482 FRAMEBUFFER_DEFAULT_WIDTH, FRAMEBUFFER_DEFAULT_HEIGHT, 483 FRAMEBUFFER_DEFAULT_LAYERS_OES, FRAMEBUFFER_DEFAULT_SAMPLES, or 484 FRAMEBUFFER_DEFAULT_FIXED_SAMPLE_LOCATIONS, the value in <param> 485 specifies the width, height, layer count, sample count, or sample 486 location pattern, respectively, used when the framebuffer has no 487 attachments. 488 489 When a framebuffer has no attachments, it is considered layered (section 490 9.7gs) if and only if the value of FRAMEBUFFER_DEFAULT_LAYERS_OES is 491 non-zero. It is considered to have sample buffers ... 492 493 494 Modify the error for invalid parameter values on p. 207 to add 495 layer counts: 496 497 An INVALID_VALUE error is generated if <pname> is 498 FRAMEBUFFER_DEFAULT_WIDTH, FRAMEBUFFER_DEFAULT_HEIGHT, 499 FRAMEBUFFER_DEFAULT_LAYERS_OES, or FRAMEBUFFER_DEFAULT_SAMPLES, and 500 <param> is either negative or greater than the value of the 501 corresponding implementation-dependent limits MAX_FRAMEBUFFER_WIDTH, 502 MAX_FRAMEBUFFER_HEIGHT, MAX_FRAMEBUFFER_LAYERS_OES, or 503 MAX_FRAMEBUFFER_SAMPLES, respectively. 504 505 506 Replace the bullet list in section 9.2.2, "Attaching Images to 507 Framebuffer Objects" on p. 208: 508 509 There are several types of framebuffer-attachable images: 510 511 * The image of a renderbuffer object, which is always two-dimensional. 512 * A single level of a two-dimensional or two-dimensional multisample 513 texture. 514 * A single face of a cube map texture level, which is treated as a 515 two-dimensional image. 516 * A single layer of a two-dimensional array texture, two-dimensional 517 multidimensional array texture, or three-dimensional texture, which is 518 treated as a two-dimensional image. 519 520 Additionally, an entire level of a three-dimensional, cube map, 521 two-dimensional array, or two-dimensional multisample array texture can 522 be attached to an attachment point. Such attachments are treated as an 523 array of two-dimensional images, arranged in layers, and the 524 corresponding attachment point is considered to be <layered> (also see 525 section 9.7gs) 526 527 528 Modify section 9.2.3, "Framebuffer Object Queries" 529 530 In the description of GetFramebufferAttachmentParameteriv for texture 531 attachments, replace the bullet point for 532 FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER on p. 210: 533 534 * If <pname> is FRAMEBUFFER_ATTACHMENT_LAYERED_OES then <params> will 535 contain TRUE if an entire level of a three-dimensional, cube map, 536 two-dimensional array, or two-dimensional multisample array texture is 537 attached. Otherwise, <params> will contain FALSE. 538 * If pname is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER; the value of 539 FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is the name of a three-dimensional, 540 or a two-dimensional array texture; and the value of 541 FRAMEBUFFER_ATTACHMENT_LAYERED_OES is FALSE, then <params> will 542 contain the value of the texture layer which contains the attached 543 image. 544 545 546 Modify section 9.2.8, "Attaching Texture Images to a Framebuffer" on 547 p. 217: 548 549 The GL supports copying the rendered contents of the framebuffer into 550 the images of a texture object through the use of the routines 551 CopyTexImage* and CopyTexSubImage*. Additionally, the GL supports 552 rendering directly into the images of a texture object. 553 554 To render directly into a texture image, a specified level of a texture 555 object can be attached as one of the logical buffers of the currently 556 bound framebuffer object by calling 557 558 void FramebufferTextureOES(enum target, enum attachment, 559 uint texture, int level); 560 561 <target> must be DRAW_FRAMEBUFFER, READ_FRAMEBUFFER, or FRAMEBUFFER. 562 FRAMEBUFFER is equivalent to DRAW_FRAMEBUFFER. <attachment> must be one 563 of the attachment points of the framebuffer listed in table 9.1. 564 565 If <texture> is non-zero, the specified mipmap <level> of the texture 566 object named <texture> is attached to the framebuffer attachment point 567 named by <attachment>. 568 569 If <texture> is the name of a three-dimensional texture, cube map 570 texture, two-dimensional array, or two-dimensional multisample array 571 texture, the texture level attached to the framebuffer attachment point 572 is an array of images, and the framebuffer attachment is considered 573 <layered>. 574 575 Errors 576 577 An INVALID_ENUM error is generated if <target> is not DRAW_FRAMEBUFFER, 578 READ_FRAMEBUFFER, or FRAMEBUFFER. 579 580 An INVALID_ENUM error is generated if <attachment> is not one of the 581 attachments in table 9.1. 582 583 An INVALID_OPERATION error is generated if zero is bound to <target>. 584 585 An INVALID_VALUE error is generated if <texture> is not the name of a 586 texture object, or if <level> is not a supported texture level for 587 <texture>. 588 589 An INVALID_OPERATION error is generated if <texture> is the name of a 590 buffer texture. 591 592 593 Additionally, a specified image from a texture object can be attached as 594 one of the logical buffers of a currently bound framebuffer object by 595 calling 596 597 void FramebufferTexture2D 598 599 ... 600 601 The command 602 603 void FramebufferTextureLayer(enum target, enum attachment, 604 uint texture, int level, int layer); 605 606 operates similarly to FramebufferTexture2D, except that it attaches a 607 single layer of a three-dimensional, two-dimensional array, or 608 two-dimensional multisample array texture level. 609 610 <target> and <attachment> are specified with the same values, and have 611 the same meanings as the corresponding arguments of 612 FramebufferTexture2D. 613 614 <level> specifies the mipmap level of the texture image to be attached 615 to the framebuffer. 616 617 If <texture> is a three-dimensional texture, then <level> must be 618 greater than or equal to zero and less than or equal to log2 of the 619 value of MAX_3D_TEXTURE_SIZE. If <texture> is a two-dimensional array 620 texture, then <level> must be greater than or equal to zero and no 621 larger than log2 of the value of MAX_TEXTURE_SIZE. If <texture> is a 622 two-dimensional multisample array texture, then <level> must be zero. 623 624 <layer> specifies the layer of a two-dimensional image within <texture>. 625 626 Unlike FramebufferTexture2D, no <textarget> parameter is accepted. 627 628 If <texture> is non-zero and the command does not result in an error, 629 the framebuffer attachment state corresponding to <attachment> is 630 updated as in the other FramebufferTexture commands, except that the 631 value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is set to <layer>. 632 633 Errors 634 635 An INVALID_ENUM error is generated if <target> is not DRAW_FRAMEBUFFER, 636 READ_FRAMEBUFFER, or FRAMEBUFFER. 637 638 An INVALID_ENUM error is generated if <attachment> is not one of the 639 attachments in table 9.1. 640 641 An INVALID_VALUE error is generated if texture is non-zero and <level> 642 is not a supported texture level for <texture>, as described above. 643 644 An INVALID_VALUE error is generated if <texture> is non-zero and <layer> 645 is larger than the value of MAX_3D_TEXTURE_SIZE minus one (for 646 three-dimensional textures), or larger than the value of 647 MAX_ARRAY_TEXTURE_LAYERS minus one (for array textures). 648 649 An INVALID_VALUE error is generated if <texture> is non-zero and <layer> 650 is negative. 651 652 An INVALID_OPERATION error is generated if <texture> is non-zero and is 653 not the name of a three dimensional, two-dimensional multisample array, 654 or two-dimensional array texture. 655 656 657 Modify section 9.2.8.1, "Effects of Attaching a Texture Image" to add 658 to the list of bullet points on p. 220: 659 660 * If FramebufferTextureOES is called and <texture> is the name of a 661 three-dimensional, cube map, two-dimensional multisample array, or 662 two-dimensional array texture, the value of 663 FRAMEBUFFER_ATTACHMENT_LAYERED_OES is set to TRUE; otherwise it is set 664 to FALSE. 665 666 667 Modify section 9.4.1, "Framebuffer Completeness" to replace the bullet 668 point starting "If <image> is a three-dimensional texture" on p. 223: 669 670 * If <image> is a three-dimensional texture or a two-dimensional array 671 texture and the attachment is not layered, the selected layer is less 672 than the depth or layer count, respectively, of the texture. 673 674 * If <image> is a three-dimensional texture or a two-dimensional array 675 texture and the attachment is layered, the depth or layer count, 676 respectively, of the texture is less than or equal to the value of 677 MAX_FRAMEBUFFER_LAYERS_OES. 678 679 680 Modify section 9.4.2 "Whole Framebuffer Completeness" to add to the list 681 of bullet points on p. 224: 682 683 * If any framebuffer attachment is layered, all populated attachments 684 must be layered. Additionally, all populated color attachments must be 685 from textures of the same target (i.e., three-dimensional, cube map, 686 two-dimensional array, or two-dimensional multisample array textures). 687 688 { FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_OES } 689 690 691 Add new section 9.7gs on p. 229, following existing section 9.7 692 "Conversion to RGBA Values": 693 694 Section 9.7gs Layered Framebuffers 695 696 A framebuffer is considered to be layered if it is complete and all of 697 its populated attachments are layered. When rendering to a layered 698 framebuffer, each fragment generated by the GL is assigned a layer 699 number. The layer number for a fragment is zero if 700 701 * geometry shaders are disabled, or 702 703 * the current geometry shader does not statically assign a value to 704 the built-in output variable "gl_Layer". 705 706 Otherwise, the layer for each point, line, or triangle emitted by the 707 geometry shader is taken from the "gl_Layer" output of one of the 708 vertices of the primitive. The vertex used is implementation-dependent 709 and may be queried as described in section 11.1gs.4. 710 To get defined results, all vertices of each primitive emitted should 711 set the same value for "gl_Layer". Since the "EndPrimitive" built-in 712 function starts a new output primitive, defined results can be achieved 713 if "EndPrimitive" is called between two vertices emitted with different 714 layer numbers. A layer number written by a geometry shader has no effect 715 if the framebuffer is not layered. 716 717 When fragments are written to a layered framebuffer, the fragment's 718 layer number selects a single image from the array of images at each 719 attachment point to use for the stencil test (see section 4.1.4), depth 720 buffer test (see section 4.1.5), and for blending and color buffer 721 writes (see section 4.1.7). If the fragment's layer number is negative, 722 or greater than or equal to the minimum number of layers of any 723 attachment, the effects of the fragment on the framebuffer contents are 724 undefined. 725 726 When the Clear or ClearBuffer* commands are used to clear a layered 727 framebuffer attachment, all layers of the attachment are cleared. 728 729 When commands such as ReadPixels read from a layered framebuffer, the 730 image at layer zero of the selected attachment is always used to obtain 731 pixel values. 732 733 When cube map texture levels are attached to a layered framebuffer, there 734 are six layers attached, numbered zero through five. Each layer number is 735 mapped to a cube map face, as indicated in table 8.25. 736 737 738 Modify section 10.1, "Primitive Types" to add new figure 10.X1 and new 739 sections 10.1.7la, 10.1.7lsa, 10.1.7ta, and 10.1.7tsa following section 740 10.1.7, "Separate Triangles", on p. 234: 741 742 743 Section 10.1.7la Lines with Adjacency 744 745 Add figure 10.X1: 746 747 1 - - - 2----->3 - - - 4 1 - - - 2--->3--->4--->5 - - - 6 748 749 5 - - - 6----->7 - - - 8 750 751 (a) (b) 752 753 Figure 10.X1 (a) Lines with adjacency, (b) Line strip with adjacency. 754 The vertices connected with solid lines belong to the main primitives; 755 the vertices connected by dashed lines are the adjacent vertices that 756 may be used in a geometry shader. 757 758 Lines with adjacency are specified with <mode> LINES_ADJACENCY_OES, and 759 are independent line segments where each endpoint has a corresponding 760 "adjacent" vertex that can be accessed by a geometry shader (see section 761 11.1gs). If a geometry shader is not active, the "adjacent" vertices are 762 ignored. 763 764 A line segment is drawn from the 4i + 2nd vertex to the 4i + 3rd vertex 765 for each i = 0, 1, ... , n-1, where there are 4n+k vertices passed. k is 766 either 0, 1, 2, or 3; if k is not zero, the final k vertices are 767 ignored. For line segment i, the 4i + 1st and 4i + 4th vertices are 768 considered adjacent to the 4i + 2nd and 4i + 3rd vertices, respectively. 769 See Figure 10.X1. 770 771 772 Section 10.1.7lsa Line Strips with Adjacency 773 774 Line strips with adjacency are specified with <mode> 775 LINE_STRIP_ADJACENCY_OES and are similar to line strips, except that 776 each line segment has a pair of adjacent vertices that can be accessed 777 by a geometry shader. If a geometry shader is not active, the "adjacent" 778 vertices are ignored. 779 780 A line segment is drawn from the i + 2nd vertex to the i + 3rd vertex 781 for each i = 0, 1, ..., n-1, where there are n+3 vertices passed. If 782 there are fewer than four vertices, all vertices are ignored. For line 783 segment i, the i + 1st and i + 4th vertex are considered adjacent to the 784 i + 2nd and i + 3rd vertices, respectively. See Figure 10.X1. 785 786 787 Section 10.1.7ta Triangles with Adjacency 788 789 Add new figure 10.X2: 790 791 2 - - - 3 - - - 4 8 - - - 9 - - - 10 792 ^\ ^\ 793 \ | \ | \ | \ | 794 | \ | \ 795 \ | \ | \ | \ | 796 | \ | \ 797 \ | \ | \ | \ | 798 | v | v 799 1<------5 7<------11 800 801 \ | \ | 802 803 \ | \ | 804 805 \ | \ | 806 807 6 12 808 809 Figure 10.X2 Triangles with adjacency. The vertices connected with solid 810 lines belong to the main primitive; the vertices connected by dashed 811 lines are the adjacent vertices that may be used in a geometry shader. 812 813 814 Triangles with adjacency are specified with <mode> TRIANGLES_ADJACENCY_OES, 815 and are similar to separate triangles except that 816 each triangle edge has an adjacent vertex that can be accessed by a 817 geometry shader. If a geometry shader is not active, the 818 "adjacent" vertices are ignored. 819 820 The 6i + 1st, 6i + 3rd, and 6i + 5th vertices (in that order) determine a 821 triangle for each i = 0, 1, ..., n-1, where there are 6n+k vertices 822 passed. k is either 0, 1, 2, 3, 4, or 5; if k is 823 non-zero, the final k vertices are ignored. For triangle i, the i + 2nd, 824 i + 4th, and i + 6th vertices are considered adjacent to edges from the i 825 + 1st to the i + 3rd, from the i + 3rd to the i + 5th, and from the i + 826 5th to the i + 1st vertices, respectively. See Figure 10.X2. 827 828 829 Section 10.1.7 tsa Triangle Strips with Adjacency 830 831 Add figure 10.X3: 832 833 6 6 834 835 | \ | \ 836 837 | \ | \ 838 839 | \ | \ 840 841 2 - - - 3- - - >6 2 - - - 3------>7 2 - - - 3------>7- - - 10 842 ^\ ^^ | ^^ ^^ | 843 \ | \ | \ | \ | \ \ | \ | \ 844 | \ | \ | | \ | \ | 845 \ | \ | \ | \ | \ \ | \ | \ 846 | \ | \ | | \ | \ | 847 \ | \ | \ | \ | \ \ | \ | \ 848 | v | vv | vv v| 849 1<------5 1<------5 - - - 8 1<------5<------9 850 851 \ | \ | \ | \ | 852 853 \ | \ | \ | \ | 854 855 \ | \ | \ | \ | 856 857 4 4 4 8 858 859 860 6 10 861 862 | \ | \ 863 864 | \ | \ 865 866 | \ | \ 867 2 - - - 3------>7------>11 868 ^^ ^^ | 869 \ | \ | \ | \ 870 | \ | \ | 871 \ | \ | \ | \ 872 | \ | \ | 873 \ | \ | \ | \ 874 | vv vv 875 1<------5<------9 - - - 12 876 877 \ | \ | 878 879 \ | \ | 880 881 \ | \ | 882 883 4 8 884 885 Figure 10.X3 Triangle strips with adjacency. The vertices connected with 886 solid lines belong to the main primitives; the vertices connected by 887 dashed lines are the adjacent vertices that may be used in a geometry 888 shader. 889 890 Triangle strips with adjacency are specified with <mode> 891 TRIANGLE_STRIP_ADJACENCY_OES and are similar to triangle strips except that 892 each line triangle edge has an adjacent vertex that can be accessed by a 893 geometry shader (see section 11.1gs). If a geometry shader is not 894 active, the "adjacent" vertices are ignored. 895 896 In triangle strips with adjacency, n triangles are drawn where there are 897 2 * (n+2) + k vertices passed. k is either 0 or 1; if k is 1, the 898 final vertex is ignored. If there are fewer than 6 vertices, 899 the entire primitive is ignored. Table 10.X1 describes 900 the vertices and order used to draw each triangle, and which vertices are 901 considered adjacent to each edge of the triangle. See Figure 10.X3. 902 903 904 Add table 10.X1: 905 906 primitive adjacent 907 vertices vertices 908 primitive 1st 2nd 3rd 1/2 2/3 3/1 909 --------------- ---- ---- ---- ---- ---- ---- 910 only (i==0, n==1) 1 3 5 2 6 4 911 first (i==0) 1 3 5 2 7 4 912 middle (i odd) 2i+3 2i+1 2i+5 2i-1 2i+4 2i+7 913 middle (i even) 2i+1 2i+3 2i+5 2i-1 2i+7 2i+4 914 last (i==n-1, i odd) 2i+3 2i+1 2i+5 2i-1 2i+4 2i+6 915 last (i==n-1, i even) 2i+1 2i+3 2i+5 2i-1 2i+6 2i+4 916 917 Table 10.X1: Triangles generated by triangle strips with adjacency. 918 Each triangle is drawn using the vertices in the "1st", "2nd", and "3rd" 919 columns under "primitive vertices", in that order. The vertices in the 920 "1/2", "2/3", and "3/1" columns under "adjacent vertices" are considered 921 adjacent to the edges from the first to the second, from the second to 922 the third, and from the third to the first vertex of the triangle, 923 respectively. The six rows correspond to the six cases: the first and 924 only triangle (i=0, n=1), the first triangle of several (i=0, n>0), 925 "odd" middle triangles (i=1,3,5...), "even" middle triangles 926 (i=2,4,6,...), and special cases for the last triangle, 927 when i is either even or odd. For the purposes of this 928 table, the first vertex passed is numbered "1" and the 929 first triangle is numbered "0". 930 931 932 Modify section 10.5, "Drawing Commands using Vertex Arrays" 933 934 On p. 250 in the errors section for the DrawArraysIndirect command, 935 and on p. 254 in the errors section for the DrawElementsIndirect command, 936 delete the errors which state: 937 938 "An INVALID_OPERATION error is generated if transform feedback is 939 active and not paused." 940 941 (thus allowing transform feedback to work with indirect draw commands). 942 943 944 Modify section 11.1.2.1, "Output Variables" on p. 262, starting with the 945 second paragraph of the section: 946 947 The OpenGL ES Shading Language specification also defines a 948 set of built-in outputs that vertex shaders can write to (see 949 section 7.1 ("Built-In Language Variables") of the OpenGL ES Shading 950 Language Specification). These output variables 951 are used to communicate values to the next active stage in the 952 vertex processing pipeline; either the geometry shader, or the 953 fixed-function vertex processing stages leading to rasterization. 954 955 If the output variables are passed directly to the vertex processing 956 stages leading to rasterization, the values of all outputs are expected 957 to be interpolated across the primitive being rendered, unless 958 flatshaded. Otherwise the values of all outputs are collected by the 959 primitive assembly stage and passed on to the subsequent pipeline stage 960 once enough data for one primitive has been collected. 961 962 The number of components (individual scalar numeric values) of output 963 variables that can be written by the vertex shader, whether or not a 964 geometry shader is active, is given by the value of the 965 implementation-dependent constant MAX_VERTEX_OUTPUT_COMPONENTS. 966 For the purposes of counting input and output components 967 consumed by a shader, variables declared as vectors, matrices, and 968 arrays will all consume multiple components. 969 970 When a program is linked... 971 972 Additionally, when linking a program containing only a vertex and 973 fragment shader, there is a limit on the total number of components... 974 975 Each program object can specify a set of output variables from one 976 shader to be recorded in transform feedback mode (see section 12.1). 977 The variables that can be recorded are those emitted by the first active 978 shader, in order, from the following list: 979 980 * geometry shader 981 * vertex shader 982 983 The set of variables to record is specified with the command 984 985 void TransformFeedbackVaryings ... 986 987 988 Modify starting with the list of TransformFeedbackVaryings link failures 989 on p. 263: 990 991 ... A program will fail to link if: 992 993 * the <count> specified by TransformFeedbackVaryings is non-zero, but 994 the program object has no vertex or geometry shader; 995 * any variable name specified in the <varyings> array is not declared as 996 a built-in or user-defined output variable in the shader stage whose 997 outputs can be recorded; 998 * any two entries in the <varyings> array specify the same output 999 variable; 1000 * the total number of components to capture in any output in <varyings> 1001 is greater than the value of 1002 MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS and the buffer mode is 1003 SEPARATE_ATTRIBS; or 1004 * the total number of components to capture is greater than the value of 1005 MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS and the buffer mode is 1006 INTERLEAVED_ATTRIBS. 1007 1008 When a program is linked ... 1009 1010 1011 Modify section 11.1.3 "Shader Execution" 1012 1013 Change the first paragraph of the section on p. 264: 1014 1015 If there is an active program object present for the vertex or geometry 1016 shader stages, the executable code for those active programs is used to 1017 process incoming vertex values. The following sequence of operations is 1018 performed: 1019 1020 * Vertices are processed by the vertex shader (see section 11.1) and 1021 assembled into primitives as described in sections 10.1 through 10.3. 1022 * If the current program contains a geometry shader, each individual 1023 primitive is processed by the geometry shader (see section 11.1gs). 1024 Otherwise, primitives are passed through unmodified. If active, the 1025 geometry shader consumes its input primitive. However, each geometry 1026 shader invocation may emit new vertices, which are arranged into 1027 primitives and passed to subsequent pipeline stages. 1028 1029 Following shader execution, the fixed-function operations described in 1030 chapter 12 are applied. 1031 1032 Special considerations for ... 1033 1034 1035 Rename section 11.1.3.1 "Shader Texturing" to "Shader Only Texturing" 1036 on p. 264. 1037 1038 1039 Modify the bullet list in section 11.1.3.5 "Texture Access" on p. 266 to 1040 add a limit for geometry shaders: 1041 1042 * MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_OES (for geometry shaders) 1043 1044 1045 Modify the bullet list in section 11.1.3.6 "Atomic Counter Access" on p. 1046 268 to add a limit for geometry shaders: 1047 1048 * MAX_GEOMETRY_ATOMIC_COUNTERS_OES (for geometry shaders) 1049 1050 1051 Modify the bullet list in section 11.1.3.7 "Image Access" on p. 268 to 1052 add a limit for geometry shaders: 1053 1054 * MAX_GEOMETRY_IMAGE_UNIFORMS_OES (for geometry shaders) 1055 1056 1057 Modify the bullet list in section 11.1.3.8 "Shader Storage Buffer 1058 Access" on p. 268 to add a limit for geometry shaders: 1059 1060 * MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_OES (for geometry shaders) 1061 1062 1063 1064 Modify section 11.1.3.11 "Validation" to add to the list of validation 1065 errors on p. 270: 1066 1067 * One program object is active for at least two shader stages and a 1068 second program is active for a shader stage between two stages for 1069 which the first program was active. 1070 1071 * There is an active program for the geometry stage with corresponding 1072 executable shader, but there is no active program with an executable 1073 vertex shader. 1074 1075 1076 Add new section 11.1gs, "Geometry Shaders" on p. 272, following 1077 section 11.1, "Vertex Shaders" 1078 1079 Section 11.1.gs Geometry Shaders 1080 1081 After vertices are processed, they are arranged into primitives, as 1082 described in section 10.1 (Primitive Types). This section describes 1083 <geometry shaders>, an additional pipeline stage defining operations to 1084 further process those primitives. Geometry shaders are defined by source 1085 code in the OpenGL ES Shading Language, in the same manner as vertex 1086 shaders. They operate on a single primitive at a time and emit one or 1087 more output primitives, all of the same type, which are then processed 1088 like an equivalent GL primitive specified by the application. The 1089 original primitive is discarded after geometry shader execution. The 1090 inputs available to a geometry shader are the transformed attributes of 1091 all the vertices that belong to the primitive. Additional <adjacency 1092 primitives> are available which also make the transformed attributes of 1093 neighboring vertices available to the shader. The results of the shader 1094 are a new set of transformed vertices, arranged into primitives by the 1095 shader. 1096 1097 The geometry shader pipeline stage is inserted after primitive assembly, 1098 prior to transform feedback (see section 12.1), as discussed in section 1099 11.1.3. 1100 1101 Geometry shaders are created as described in section 7.1 using a <type> 1102 of GEOMETRY_SHADER_OES. They are attached to and used in program objects 1103 as described in section 7.3. When the program object currently in use 1104 includes a geometry shader, its geometry shader is considered active, 1105 and is used to process primitives. If the program object has no geometry 1106 shader, this stage is bypassed. 1107 1108 A non-separable program object or program pipeline object that includes 1109 a geometry shader must also include a vertex shader. 1110 1111 Errors 1112 1113 An INVALID_OPERATION error is generated by any command that transfers 1114 vertices to the GL if the current program state has a geometry shader 1115 but no vertex shader. 1116 1117 1118 Section 11.1gs.1, Geometry Shader Input Primitives 1119 1120 A geometry shader can operate on one of five input primitive types. 1121 Depending on the input primitive type, one to six input vertices are 1122 available when the shader is executed. Each input primitive type 1123 supports a subset of the primitives provided by the GL. 1124 1125 An INVALID_OPERATION error is generated by any command that transfers 1126 vertices to the GL if a geometry shader is active and the primitive 1127 <mode> parameter is incompatible with the input primitive type of the 1128 geometry shader of the active geometry program object, as discussed 1129 below. 1130 1131 A geometry shader that accesses more input vertices than are available 1132 for a given input primitive type can be successfully compiled, because 1133 the input primitive type is not part of the shader object. However, a 1134 program object containing a shader object that accesses more input 1135 vertices than are available for the input primitive type of the program 1136 object will not link. 1137 1138 The input primitive type is specified in the geometry shader source code 1139 using an input layout qualifier, as described in the OpenGL ES Shading 1140 Language Specification. A program will fail to link if the input 1141 primitive type is not specified by the geometry shader object attached 1142 to the program. The input primitive type may be queried by calling 1143 GetProgramiv with the symbolic constant GEOMETRY_LINKED_INPUT_TYPE_OES. 1144 The supported types and the corresponding OpenGL ES Shading Language 1145 input layout qualifier keywords are: 1146 1147 Points (points) 1148 1149 Geometry shaders that operate on points are valid only for the POINTS 1150 primitive type. There is only a single vertex available for each 1151 geometry shader invocation. 1152 1153 Lines (lines) 1154 1155 Geometry shaders that operate on line segments are valid only for the 1156 LINES, LINE_STRIP, and LINE_LOOP primitive types. There are two vertices 1157 available for each geometry shader invocation. The first vertex refers 1158 to the vertex at the beginning of the line segment and the second vertex 1159 refers to the vertex at the end of the line segment. See also section 1160 11.1gs.4. 1161 1162 Lines with Adjacency (lines_adjacency) 1163 1164 Geometry shaders that operate on line segments with adjacent vertices 1165 are valid only for the LINES_ADJACENCY_OES and LINE_STRIP_ADJACENCY_OES 1166 primitive types. There are four vertices available for each program 1167 invocation. The second vertex refers to attributes of the vertex at the 1168 beginning of the line segment and the third vertex refers to the vertex 1169 at the end of the line segment. The first and fourth vertices refer to 1170 the vertices adjacent to the beginning and end of the line segment, 1171 respectively. 1172 1173 Triangles (triangles) 1174 1175 Geometry shaders that operate on triangles are valid for the TRIANGLES, 1176 TRIANGLE_STRIP and TRIANGLE_FAN primitive types. There are three 1177 vertices available for each program invocation. The first, second and 1178 third vertices refer to attributes of the first, second and third vertex 1179 of the triangle, respectively. 1180 1181 Triangles with Adjacency (triangles_adjacency) 1182 1183 Geometry shaders that operate on triangles with adjacent vertices are 1184 valid for the TRIANGLES_ADJACENCY_OES and TRIANGLE_STRIP_ADJACENCY_OES 1185 primitive types. There are six vertices available for each program 1186 invocation. The first, third and fifth vertices refer to attributes of 1187 the first, second and third vertex of the triangle, respectively. The 1188 second, fourth and sixth vertices refer to attributes of the vertices 1189 adjacent to the edges from the first to the second vertex, from the 1190 second to the third vertex, and from the third to the first vertex, 1191 respectively. 1192 1193 1194 Section 11.1gs.2, Geometry Shader Output Primitives 1195 1196 A geometry shader can generate primitives of one of three types. The 1197 supported output primitive types are points (POINTS), line strips 1198 (LINE_STRIP), and triangle strips (TRIANGLE_STRIP). The vertices output 1199 by the geometry shader are assembled into points, lines, or triangles 1200 based on the output primitive type in the manner described in section 1201 10.5. The resulting primitives are then further processed as described 1202 in section 11.1gs.4. If the number of vertices emitted by the geometry 1203 shader is not sufficient to produce a single primitive, nothing is 1204 drawn. The number of vertices output by the geometry shader is limited 1205 to a maximum count specified in the shader. 1206 1207 The output primitive type and maximum output vertex count are specified 1208 in the geometry shader source code using an output layout qualifier, as 1209 described in section 4.4.2.gs ("Geometry Outputs") of the OpenGL ES 1210 Shading Language Specification. A program will fail to link if either 1211 the output primitive type or maximum output vertex count are not 1212 specified by the geometry shader object attached to the program. The 1213 output primitive type and maximum output vertex count of a linked 1214 program may be queried by calling GetProgramiv with the symbolic 1215 constants GEOMETRY_LINKED_OUTPUT_TYPE_OES and 1216 GEOMETRY_LINKED_VERTICES_OUT_OES, respectively. 1217 1218 1219 Section 11.1gs.3 Geometry Shader Variables 1220 1221 Geometry shaders can access uniforms belonging to the current program 1222 object. Limits on uniform storage and methods for manipulating uniforms 1223 are described in section 7.6. 1224 1225 Geometry shaders also have access to samplers to perform texturing 1226 operations, as described in section 7.9. 1227 1228 Geometry shaders can access the transformed attributes of all vertices 1229 for their input primitive type using input variables. A vertex shader 1230 writing to output variables generates the values of these input 1231 variables. Values for any inputs that are not written by a vertex shader 1232 are undefined. Additionally, a geometry shader has access to a built-in 1233 variable that holds the ID of the current primitive. This ID is 1234 generated by the primitive assembly stage that sits in between the 1235 vertex and geometry shader. 1236 1237 Additionally, geometry shaders can write to one or more output variables 1238 for each vertex they output. These values are optionally flatshaded 1239 (using the OpenGL ES Shading Language varying qualifier "flat") and 1240 clipped, then the clipped values interpolated across the primitive (if 1241 not flatshaded). The results of these interpolations are available to 1242 the fragment shader. 1243 1244 1245 Section 11.1gs.4, Geometry Shader Execution Environment 1246 1247 If there is an active program for the geometry stage, the executable 1248 version of the program's geometry shader is used to process primitives 1249 resulting from the primitive assembly stage. 1250 1251 There are several special considerations for geometry shader execution 1252 described in the following sections. 1253 1254 1255 Section 11.1gs.4.1 Texture Access 1256 1257 Section 11.1.3.1 describes texture lookup functionality accessible to a 1258 vertex shader. The texel fetch and texture size query functionality 1259 described there also applies to geometry shaders. 1260 1261 1262 Section 11.1gs.4.2 Instanced Geometry Shaders 1263 1264 For each input primitive received by the geometry shader pipeline stage, 1265 the geometry shader may be run once or multiple times. The number of 1266 times a geometry shader should be executed for each input primitive may 1267 be specified using a layout qualifier in a geometry shader of a linked 1268 program. If the invocation count is not specified in any layout 1269 qualifier, the invocation count will be one. 1270 1271 Each separate geometry shader invocation is assigned a unique invocation 1272 number. For a geometry shader with <N> invocations, each input primitive 1273 spawns <N> invocations, numbered 0 through <N>-1. The built-in uniform 1274 gl_InvocationID may be used by a geometry shader invocation to determine 1275 its invocation number. 1276 1277 When executing instanced geometry shaders, the output primitives 1278 generated from each input primitive are passed to subsequent pipeline 1279 stages using the shader invocation number to order the output. The first 1280 primitives received by the subsequent pipeline stages are those emitted 1281 by the shader invocation numbered zero, followed by those from the 1282 shader invocation numbered one, and so forth. Additionally, all output 1283 primitives generated from a given input primitive are passed to 1284 subsequent pipeline stages before any output primitives generated from 1285 subsequent input primitives. 1286 1287 1288 Section 11.1gs.4.3 Geometry Shader Inputs 1289 1290 Section 7.1 ("Built-In Language Variables") of the OpenGL ES Shading 1291 Language Specification describes the built-in variable array gl_in[] 1292 available as input to a geometry shader. gl_in[] receives values from 1293 the equivalent built-in output variables written by the vertex shader. 1294 Each array element of gl_in[] is a structure holding values for a 1295 specific vertex of the input primitive. The length of gl_in[] is 1296 determined by the geometry shader input type (see section 11.1gs.1). The 1297 members of each element of the gl_in[] array are: 1298 1299 [[ If OES_geometry_point_size is supported: ]] 1300 * structure member gl_PointSize holds the per-vertex point size written 1301 by the previous shader to its built-in output variable gl_PointSize. 1302 If the previous shader does not write gl_PointSize, the value of 1303 gl_PointSize is undefined. 1304 1305 * structure member gl_Position holds the per-vertex position, as written 1306 by the previous shader to its built-in output variable gl_Position. 1307 Note that writing to gl_Position from either the vertex or geometry 1308 shader is optional (also see section 7.1 ("Built-In Language 1309 Variables") of the OpenGL ES Shading Language Specification) 1310 1311 Geometry shaders also have available the built-in input variable 1312 gl_PrimitiveIDIn, which is not an array and has no vertex shader 1313 equivalent. It is filled with the number of primitives processed by the 1314 drawing command which generated the input vertices. The first primitive 1315 generated by a drawing command is numbered zero, and the primitive ID 1316 counter is incremented after every individual point, line, or triangle 1317 primitive is processed. For triangles drawn in point or line mode, the 1318 primitive ID counter is incremented only once, even though multiple 1319 points or lines may eventually be drawn. The counter is reset to zero 1320 between each instance drawn. Restarting a primitive topology using the 1321 primitive restart index has no effect on the primitive ID counter. 1322 1323 Similarly to the built-in inputs, each user-defined input has a value 1324 for each vertex and thus needs needs to be declared as arrays or inside 1325 input blocks declared as arrays. Declaring an array size is optional. If 1326 no size is specified, it will be inferred by the linker from the input 1327 primitive type. If a size is specified, it must match the number of 1328 vertices for the input primitive type; otherwise a link error will 1329 occur. The OpenGL ES Shading Language doesn't support multi-dimensional 1330 arrays as shader inputs or outputs; therefore, user-defined geometry 1331 shader inputs corresponding to vertex shader outputs declared as arrays 1332 must be declared as array members of an input block that is itself 1333 declared as an array. See section 4.3.6 ("Output Variables") of the 1334 OpenGL ES Shading Language Specification for more information. 1335 1336 Similarly to the limit on vertex shader output components (see section 1337 11.1.2.1), there is a limit on the number of components of input 1338 variables that can be read by the geometry shader, given by the value of 1339 the implementation-dependent constant MAX_GEOMETRY_INPUT_COMPONENTS_OES. 1340 1341 When a program is linked, all components of any input read by a geometry 1342 shader will count against this limit. A program whose geometry shader 1343 exceeds this limit may fail to link, unless device-dependent 1344 optimizations are able to make the program fit within available hardware 1345 resources. 1346 1347 Component counting rules for different variable types and variable 1348 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see 1349 section 11.1.2.1). 1350 1351 1352 Section 11.1gs.4.4 Geometry Shader Outputs 1353 1354 A geometry shader is limited in the number of vertices it may emit per 1355 invocation. The maximum number of vertices a geometry shader can 1356 possibly emit is specified in the geometry shader source and may be 1357 queried after linking by calling GetProgramiv with the symbolic constant 1358 GEOMETRY_LINKED_VERTICES_OUT_OES. If a single invocation of a geometry 1359 shader emits more vertices than this value, the emitted vertices may 1360 have no effect. 1361 1362 There are two implementation-dependent limits on the value of 1363 GEOMETRY_LINKED_VERTICES_OUT_OES; it may not exceed the value of 1364 MAX_GEOMETRY_OUTPUT_VERTICES_OES, and the product of the total number of 1365 vertices and the sum of all components of all active output variables 1366 may not exceed the value of MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_OES. 1367 LinkProgram will fail if it determines that the total component limit 1368 would be violated. 1369 1370 A geometry shader can write to built-in as well as user-defined output 1371 variables. These values are expected to be interpolated across the 1372 primitive it outputs, unless they are specified to be flatshaded. To 1373 enable seamlessly inserting or removing a geometry shader from a program 1374 object, the rules, names and types of the built-in and user-defined 1375 output variables are the same as for the vertex shader. Refer to section 1376 11.1.2.1, and to sections 4.3.6 ("Output Variables") and 7.1 ("Built-In 1377 Language Variables") of the the OpenGL ES Shading Language Specification 1378 for more detail. 1379 1380 After a geometry shader emits a vertex, all output variables are 1381 undefined, as described in section 8.12gs ("Geometry Shader Functions") 1382 of the OpenGL Shading Language Specification. 1383 1384 The built-in output gl_Position is intended to hold the homogeneous 1385 vertex position. Writing gl_Position is optional. 1386 1387 [[ If OES_geometry_point_size is supported: ]] 1388 The built-in output gl_PointSize, if written, holds the size of the 1389 point to be rasterized, measured in pixels. 1390 1391 The built-in output gl_PrimitiveID holds the primitive ID counter read 1392 by the fragment shader, replacing the value of gl_PrimitiveID generated 1393 by drawing commands when no geometry shader is active. The geometry 1394 shader must write to gl_PrimitiveID for the provoking vertex (see 1395 section 12.3) of a primitive being generated, or the primitive ID 1396 counter read by the fragment shader for that primitive is undefined. 1397 1398 The built-in output gl_Layer is used in layered rendering, and discussed 1399 further in the next section. 1400 1401 Similarly to the limit on vertex shader output components (see section 1402 11.1.2.1), there is a limit on the number of components of output 1403 variables that can be written by the geometry shader, given by the value 1404 of the implementation-dependent constant 1405 MAX_GEOMETRY_OUTPUT_COMPONENTS_OES. 1406 1407 When a program is linked, all components of any output variable written 1408 by a geometry shader will count against this limit. A program whose 1409 geometry shader exceeds this limit may fail to link, unless 1410 device-dependent optimizations are able to make the program fit within 1411 available hardware resources. 1412 1413 Component counting rules for different variable types and variable 1414 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS. (see 1415 section 11.1.2.1). 1416 1417 1418 Section 11.1gs.4.5 Layer Selection 1419 1420 Geometry shaders can be used to render to one of several different 1421 layers of cube map textures, three-dimensional textures, or 1422 two-dimensional texture arrays. This functionality allows an application 1423 to bind an entire complex texture to a framebuffer object, and render 1424 primitives to arbitrary layers computed at run time. For example, this 1425 mechanism can be used to project and render a scene onto all six faces 1426 of a cube map texture in one pass. The layer to render to is specified 1427 by writing to the built-in output variable "gl_Layer". Layered rendering 1428 requires the use of framebuffer objects (see section 9.7gs). 1429 1430 The specific vertex of a primitive that is used to select the rendering 1431 layer is implementation-dependent and thus portable applications will 1432 assign the same layer for all vertices in a primitive. The vertex 1433 convention followed for "gl_Layer" may be determined by calling 1434 GetIntegerv with the symbolic constant LAYER_PROVOKING_VERTEX_OES. If 1435 the value returned is FIRST_VERTEX_CONVENTION_OES, selection is always 1436 taken from the first vertex of a primitive. If the value returned is 1437 LAST_VERTEX_CONVENTION_OES, the selection is always taken from the last 1438 vertex of a primitive. If the value returned is UNDEFINED_VERTEX_OES, 1439 the selection is not guaranteed to be taken from any specific vertex in 1440 the primitive. The vertex considered the provoking vertex for particular 1441 primitive types is given in table 12.2. 1442 1443 1444 Section 11.1gs.4.6 Primitive Type Mismatches and Drawing Commands 1445 1446 An INVALID_OPERATION error is generated by any command that transfers 1447 vertices to the GL, and no fragments will be rendered, if a mismatch 1448 exists between the type of primitive being drawn and the input primitive 1449 type of a geometry shader. A mismatch exists under any of the following 1450 conditions: 1451 1452 * the input primitive type of the current geometry shader is 1453 POINTS and <mode> is not POINTS, 1454 1455 * the input primitive type of the current geometry shader is 1456 LINES and <mode> is not LINES, LINE_STRIP, or LINE_LOOP, 1457 1458 * the input primitive type of the current geometry shader is 1459 TRIANGLES and <mode> is not TRIANGLES, TRIANGLE_STRIP or 1460 TRIANGLE_FAN, 1461 1462 * the input primitive type of the current geometry shader is 1463 LINES_ADJACENCY_OES and <mode> is not LINES_ADJACENCY_OES or 1464 LINE_STRIP_ADJACENCY_OES, or 1465 1466 * the input primitive type of the current geometry shader is 1467 TRIANGLES_ADJACENCY_OES and <mode> is not 1468 TRIANGLES_ADJACENCY_OES or TRIANGLE_STRIP_ADJACENCY_OES. 1469 1470 1471 Modify section 12.1, "Transform Feedback" 1472 1473 Replace the second paragraph of the section on p. 274: 1474 1475 The data captured in transform feedback mode depends on the active 1476 programs on each of the shader stages. If a program is active for the 1477 geometry shader stage, transform feedback captures the vertices of each 1478 primitive emitted by the geometry shader. Otherwise, transform feedback 1479 captures each primitive processed by the vertex shader. 1480 1481 1482 Modify the second paragraph following ResumeTransformFeedback on p. 277 1483 1484 When transform feedback is active and not paused, all geometric 1485 primitives generated must be compatible with the value of 1486 <primitiveMode> passed to BeginTransformFeedback. If a geometry shader 1487 is active, the type of primitive emitted by that shader is used instead 1488 of the <mode> parameter passed to drawing commands for the purposes of 1489 this error check. Any primitive type may be used while transform 1490 feedback is paused. 1491 1492 Add table 12.1gs: 1493 1494 Transform Feedback Allowed render primitive 1495 <primitiveMode> <modes> 1496 -------------------+---------------------------------------- 1497 POINTS | POINTS 1498 LINES | LINES, LINE_LOOP, LINE_STRIP 1499 TRIANGLES | TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN 1500 ------------------------------------------------------------ 1501 Table 12.1gs: Legal combinations of the transform feedback 1502 primitive mode, as passed to BeginTransformFeedback, and the 1503 current primitive mode. 1504 1505 1506 In the Errors section, replace "An INVALID_OPERATION error is generate 1507 by DrawArrays and DrawArraysInstanced if <mode> is not identical to 1508 <primitiveMode>" with: 1509 1510 An INVALID_OPERATION error is generated by any command that transfers 1511 vertices to the GL if <mode> is not one of the allowed modes in table 1512 12.1gs. 1513 1514 and delete the error condition which states: 1515 1516 An INVALID_OPERATION error is generated by any drawing commands other 1517 than DrawArrays and DrawArraysInstanced while transform feedback is 1518 active and not paused, regardless of mode. 1519 1520 Modify the last sentence of the second paragraph on p. 278: 1521 1522 When writing output variables that are arrays ... The value for any 1523 output variable specified to be streamed to a buffer object but not 1524 actually written by a vertex or geometry shader is undefined. The 1525 results of appending an output variable to a transform feedback buffer 1526 are undefined if any component of that variable would be written at an 1527 offset not aligned to the size of the component. 1528 1529 1530 Modify the sixth paragraph on p. 278: 1531 1532 In INTERLEAVED_ATTRIBS mode, the values of one or more output variables 1533 written by a vertex or geometry shader are written, interleaved, ... 1534 1535 1536 Modify the eighth paragraph on p. 278, describing errors on buffer 1537 overflow: 1538 1539 1540 The error INVALID_OPERATION ... as set by BindBufferRange. No vertices 1541 of that primitive are recorded in any buffer object, and the counter 1542 corresponding to the asynchronous query target 1543 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN (see section 12.2) is not 1544 incremented. 1545 1546 1547 Modify the second paragraph on p. 280: 1548 1549 When BeginTransformFeedback is called with an active program object 1550 containing a vertex or geometry shader, the set of output variables 1551 captured ... 1552 1553 1554 Replace section 12.2, "Primitive Queries" on p. 281: 1555 1556 Primitive queries use query objects to track the number of primitives 1557 that are generated by the GL and the number of primitives that are 1558 written to buffer objects in transform feedback mode. 1559 1560 When BeginQuery is called with a target of PRIMITIVES_GENERATED_OES, the 1561 primitives generated count maintained by the GL is set to zero. When a 1562 generated primitive query is active, the primitives-generated count is 1563 incremented every time an emitted primitive reaches the transform 1564 feedback stage (see section 12.1), whether or not transform feedback is 1565 active. This counter counts the number of primitives emitted by a 1566 geometry shader, if active, possibly further tessellated into separate 1567 primitives during the transform feedback stage, if active. 1568 1569 When BeginQuery is called with a target of 1570 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN, the transform feedback primitives 1571 written count maintained by the GL is set to zero. When the transform 1572 feedback primitive written query is active, the transform feedback 1573 primitives written count is incremented every time the vertices of a 1574 primitive are recorded into a buffer object. If transform feedback is 1575 not active or if a primitive to be recorded does not fit in a buffer 1576 object, this counter is not incremented. 1577 1578 These two types of queries can be used together to determine if all 1579 primitives have been written to the bound feedback buffer; if both 1580 queries are run simultaneously and the query results are equal, all 1581 primitives have been written to the buffer. If the number of primitives 1582 written is less than the number of primitives generated, the buffer 1583 overflowed. 1584 1585 1586 Modify section 12.5 "Coordinate Transformations" on p. 283: 1587 1588 <Clip coordinates> for a vertex result from shader execution, which 1589 yields ... 1590 1591 1592 Modify section 13.3, "Points" 1593 1594 Replace the second paragraph starting "The point size..." on p. 290: 1595 1596 The point size is determined by the last active stage before the 1597 rasterizer: 1598 1599 * the geometry shader, if active; or 1600 * the vertex shader, otherwise. 1601 1602 If the last active stage is not a vertex shader and does not statically 1603 assign a value to gl_PointSize, the point size is 1.0. Otherwise, the 1604 point size is taken from the shader built-in gl_PointSize written by 1605 that stage. 1606 [[ Note that it is impossible to assign a value to gl_PointSize if 1607 OES_geometry_point_size is not supported and enabled in the 1608 geometry shader stage. ]] 1609 1610 If the last active stage is a vertex shader, the point size is taken 1611 from the shader built-in gl_PointSize written by the vertex shader. 1612 1613 In all cases, the point size is clamped to the implementation-dependent 1614 point size range. If the value written to gl_PointSize is less than or 1615 equal to zero, or if no value is written to gl_PointSize (except as 1616 noted above) the point size is undefined. The supported range ... 1617 1618 1619 Modify section 14.2.2, "Shader Inputs" 1620 1621 Add a new paragraph following the paragraph starting "The built-in 1622 variable gl_FrontFacing" on p. 305: 1623 1624 If a geometry shader is active, the built-in variable gl_PrimitiveID 1625 contains the ID value emitted by the geometry shader for the provoking 1626 vertex. If no geometry shader is active, gl_PrimitiveID contains the 1627 number of primitives processed by the rasterizer since the last drawing 1628 command was called. The first primitive generated by a drawing command 1629 is numbered zero, and the primitive ID counter is incremented after 1630 every individual point, line, or polygon primitive is processed. 1631 The counter is reset to zero between each instance drawn. 1632 1633 Restarting a primitive using the primitive restart index (see section 1634 10.3.4) has no effect on the primitive ID counter. 1635 1636 gl_PrimitiveID is only defined under the same conditions that 1637 gl_VertexID is defined, as described under "Shader Inputs" in section 1638 11.1.3.9. 1639 1640 Similarly to the limit on geometry shader output components (see section 1641 11.1gs.4), there is a limit on the number of components of built-in and 1642 user-defined input variables that can be read by the fragment shader, 1643 given by the value of the implementation-dependent constant 1644 MAX_FRAGMENT_INPUT_COMPONENTS. 1645 1646 When a program is linked ... 1647 1648 1649 Modify section 16.2.1, "Blitting Pixel Rectangles" to add following the 1650 paragraph starting "When values are written to the draw buffers" on p. 1651 337: 1652 1653 If the read framebuffer is layered (see section 9.7gs), pixel values are 1654 read from layer zero. If the draw framebuffer is layered, pixel values 1655 are written to layer zero. If both read and draw framebuffers are 1656 layered, the blit operation is still performed only on layer zero. 1657 1658 1659 Modify the first sentence of chapter 17, "Compute Shaders" on p. 340: 1660 1661 In addition to graphics-oriented shading operations such as vertex, 1662 geometry, and fragment shading, generic computation ... 1663 1664 1665Dependencies on OES_sample_variables 1666 1667 If OES_sample_variables is not supported, references to 1668 the extension edits should be ignored. 1669 1670Dependencies on OES_texture_storage_multisample_2d_array 1671 1672 If OES_texture_storage_multisample_2d_array is not supported, references 1673 to two-dimensional multisample array textures should be ignored. 1674 1675Dependencies on OES_shader_multisample_interpolation 1676 1677 If OES_shader_multisample_interpolation is not supported, references 1678 to "sample in", "sample out" and the extension should be ignored. 1679 1680Dependencies on OES_texture_buffer and EXT_texture_buffer 1681 1682 If OES_texture_buffer or EXT_texture_buffer is not supported, references 1683 to buffer textures should be removed. 1684 1685Dependencies on OES_shader_io_blocks 1686 1687 If OES_shader_io_blocks is not supported, replace all references to 1688 it with references to EXT_shader_io_blocks instead. 1689 1690New State 1691 1692 Add to table 20.14, "Framebuffer (state per framebuffer object)": 1693 Initial 1694 Get Value Type Get Command Value Description Sec. 1695 ------------------------------ ---- ------------------------- ------- ------------------------ ----- 1696 FRAMEBUFFER_DEFAULT_LAYERS_OES Z+ GetFramebufferParameteriv 0 default layer count of 9.2.1 1697 framebuffer w/o 1698 attachments 1699 1700 Add to table 20.15, "Framebuffer (state per attachment point)": 1701 1702 Initial 1703 Get Value Type Get Command Value Description Sec. 1704 ---------------------------------------- ---- ----------------------------------- ------- ---------------------- ------- 1705 FRAMEBUFFER_ATTACHMENT_LAYERED_OES B GetFramebufferAttachmentParameteriv FALSE Framebuffer attachment 9.2.8.1 1706 is layered 1707 1708 Modify description of SHADER_TYPE in table 20.18, "Shader Object State": 1709 1710 Initial 1711 Get Value Type Get Command Value Description Sec. 1712 ----------- ---- ----------- ------- ----------------------------- ---- 1713 SHADER_TYPE E GetShaderiv - Type of shader (shader stage) 7.1 1714 1715 Add to table 20.19, "Program Pipeline Object State": 1716 1717 Initial 1718 Get Value Type Get Command Value Description Sec. 1719 ------------------ ---- -------------------- ------- ------------------------ ---- 1720 GEOMETRY_SHADER_OES Z+ GetProgramPipelineiv 0 Name of current geometry 7.4 1721 shader program object 1722 1723 1724 Add to table 20.22, "Program Object State (cont.)": 1725 1726 Initial 1727 Get Value Type Get Command Value Description Sec. 1728 ------------------------- ---- ------------ -------------- ------------------------ -------- 1729 GEOMETRY_LINKED_VERTICES_OUT_OES Z+ GetProgramiv 0 Max.# of output vertices 11.1gs.4 1730 GEOMETRY_LINKED_INPUT_TYPE_OES E GetProgramiv TRIANGLES Primitive input type 11.1gs.1 1731 GEOMETRY_LINKED_OUTPUT_TYPE_OES E GetProgramiv TRIANGLE_STRIP Primitive output type 11.1gs.2 1732 GEOMETRY_SHADER_INVOCATIONS_OES Z+ GetProgramiv 1 # of times a geom. shader 7.12 1733 should be executed for 1734 each input primitive 1735 1736 Add to table 20.28, "Program Object Resource State (cont.)": 1737 1738 Initial 1739 Get Value Type Get Command Value Description Sec. 1740 --------------------------------- ---- -------------------- ------- ----------------------- ----- 1741 REFERENCED_BY_GEOMETRY_SHADER_OES Z+ GetProgramResourceiv - active resource used by 7.3.1 1742 geometry shader 1743 1744 1745 Rename table 20.29, "Vertex Shader State (not part of program objects)" 1746 to "Vertex and Geometry Shader State (not part of program objects)". 1747 1748 1749New Implementation Dependent State 1750 1751 Add to table 20.40, "Implementation-Dependent Values (cont.)": 1752 1753 Get Value Type Get Command Minimum Value Description Sec. 1754 -------------------------- ---- ----------- ------------- -------------------------- -------- 1755 MAX_FRAMEBUFFER_LAYERS_OES Z+ GetIntegerv 256 maximum layer count for 9.2.1 1756 layered framebuffer object 1757 LAYER_PROVOKING_VERTEX_OES E GetIntegerv -- (*) vertex convention followed 11.1gs.4 1758 by the gl_Layer GLSL 1759 variable 1760 1761 Add new footnote: 1762 (*) Note: Valid values are FIRST_VERTEX_CONVENTION_OES, 1763 LAST_VERTEX_CONVENTION_OES, and UNDEFINED_VERTEX_OES. 1764 1765 1766 1767 Add new table 20.43gs "Implementation Dependent Geometry Shader Limits" 1768 following table 20.43 "Implementation Dependent Vertex Shader Limits": 1769 1770 Min. 1771 Get Value Type Get Command Value Description Sec. 1772 ---------------------------------------- ---- ----------- ----- ----------------------- -------- 1773 MAX_GEOMETRY_UNIFORM_COMPONENTS_OES Z+ GetIntegerv 1024 Number of comp. for 11.1gs.3 1774 geom. shader uniform 1775 variables 1776 MAX_GEOMETRY_UNIFORM_BLOCKS_OES Z+ GetIntegerv 12 Max number of geom. 7.6.2 1777 uniform buffers per 1778 program 1779 MAX_GEOMETRY_INPUT_COMPONENTS_OES Z+ GetIntegerv 64 Max number of comp. 11.1gs.4 1780 of inputs read by a 1781 geom. shader 1782 MAX_GEOMETRY_OUTPUT_COMPONENTS_OES Z+ GetIntegerv 64 Max number of comp. 11.1gs.4 1783 of outputs written 1784 by a geom. shader 1785 MAX_GEOMETRY_OUTPUT_VERTICES_OES Z+ GetIntegerv 256 Max number of vertices 11.1gs.4 1786 that any geom. shader 1787 can emit 1788 MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_OES Z+ GetIntegerv 1024 Max number of total 11.1gs.4 1789 comp. (all vertices) of 1790 active outputs that a 1791 geom. shader can emit 1792 MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_OES Z+ GetIntegerv 16 Number of texture 11.1.3.5 1793 image units accessible 1794 by a geom. shader 1795 MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_OES Z+ GetIntegerv 0 Number of atom. counter 7.7 1796 buffers accessed 1797 by a geom. shader 1798 MAX_GEOMETRY_ATOMIC_COUNTERS_OES Z+ GetIntegerv 0 Number of atomic 11.1.3.6 1799 counters accessed by a 1800 geom. shader 1801 MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_OES Z+ GetIntegerv 0 Num. of shader storage 7.8 1802 blocks accessed by a 1803 geom. shader 1804 MAX_GEOMETRY_SHADER_INVOCATIONS_OES Z+ GetIntegerv 32 Max supported geom. 11.1gs.4 1805 shader invocation count 1806 1807 1808 1809 Add to table 20.46 "Implementation Dependent Aggregate Shader Limits" 1810 ([fn] is a dagger mark referring to existing text in the table caption): 1811 1812 Minimum 1813 Get Value Type Get Command Value Description Sec. 1814 -------------------------------------------- ---- ----------- -------- ------------------------- -------- 1815 MAX_GEOMETRY_IMAGE_UNIFORMS_OES Z+ GetIntegerv 0 Number of image variables 11.1.3.7 1816 in geometry shaders 1817 MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS_OES Z+ GetIntegerv [fn] No. of words for geom. 7.6.2 1818 shader uniform vars. in 1819 all uniform blocks 1820 (including default) 1821 1822 Modify existing entries in table 20.46: 1823 1824 Minimum 1825 Get Value Type Get Command Value Description Sec. 1826 -------------------------------------------- ---- ----------- -------- ------------------------- -------- 1827 MAX_UNIFORM_BUFFER_BINDINGS Z+ GetIntegerv 48 Max no. of uniform buf. 7.6.2 1828 binding points 1829 MAX_COMBINED_UNIFORM_BLOCKS Z+ GetIntegerv 36 Max. no. of uniform 7.6.2 1830 buffers per program 1831 MAX_COMBINED_TEXTURE_IMAGE_UNITS Z+ GetIntegerv 64 Total no. of tex. units 11.1.3.5 1832 accessible by the GL 1833 1834Additions to the OpenGL ES Shading Language 3.10 Specification 1835 1836 Including the following line in a shader can be used to control the 1837 language features described in this extension: 1838 1839 #extension GL_OES_geometry_shader : <behavior> 1840 #extension GL_OES_geometry_point_size : <behaviour> 1841 1842 where <behavior> is as specified in section 3.4. 1843 1844 A new preprocessor #define is added to the OpenGL ES Shading Language: 1845 1846 #define GL_OES_geometry_shader 1 1847 #define GL_OES_geometry_point_size 1 1848 1849 If the OES_geometry_shader extension is enabled, the 1850 OES_shader_io_blocks extension is also implicitly enabled. 1851 1852 1853 Change the introduction to Chapter 2 "Overview of OpenGL ES Shading" as 1854 follows: 1855 1856 The OpenGL ES Shading Language is actually several closely related 1857 languages. These languages are used to create shaders for each of the 1858 programmable processors contained in the OpenGL ES processing pipeline. 1859 Currently, these processors are the compute, vertex, geometry, and 1860 fragment processors. 1861 1862 Unless otherwise noted in this Specification, a language feature applies 1863 to all languages, and common usage will refer to these languages as a 1864 single language. The specific languages will be referred to by the name 1865 of the processor they target: compute, vertex, geometry, or fragment. 1866 1867 1868 Add new subsection 2.gs preceding subsection 2.2 "Fragment Processor": 1869 1870 Section 2.gs, Geometry Processor 1871 1872 The <geometry processor> is a programmable unit that operates on data 1873 for incoming vertices for a primitive assembled after vertex processing 1874 and outputs a sequence of vertices forming output primitives. 1875 Compilation units written in the OpenGL ES Shading Language to run on 1876 this processor are called <geometry shaders>. When a geometry shader is 1877 compiled and linked, it results in a <geometry shader executable> that 1878 runs on the geometry processor. 1879 1880 A single invocation of the geometry shader executable on the geometry 1881 processor will operate on a declared input primitive with a fixed number 1882 of vertices. This single invocation can emit a variable number of 1883 vertices that are assembled into primitives of a declared output 1884 primitive type and passed to subsequent pipeline stages. 1885 1886 1887 Modify section 4.3.4 "Input Variables", adding following the paragraph 1888 starting "It is expected that ... columns in the matrix" on p. 40: 1889 1890 Geometry shader input variables get the per-vertex values written out by 1891 output variables of the same names in the previous active (vertex) 1892 shader stage. For these inputs, "centroid in", "sample in", and 1893 interpolation qualifiers are allowed, but are equivalent to "in". Since 1894 geometry shaders operate on a set of vertices, each input variable or 1895 input block (see section 4.3.9 "Interface Blocks") needs to be declared 1896 as an array. For example, 1897 1898 in float foo[]; // geometry shader input for vertex "out float foo" 1899 1900 Each element of such an array corresponds to one vertex of the primitive 1901 being processed. Each array can optionally have a size declared. The 1902 array size will be set by (or if provided must be consistent with) the 1903 input layout declaration(s) establishing the type of input primitive, as 1904 described later in section 4.4.1 "Input Layout Qualifiers". 1905 1906 Some inputs and outputs are <arrayed>, meaning that for an interface 1907 between two shader stages either the input or output declaration 1908 requires an extra level of array indexing for the declarations to match. 1909 For example, with the interface between a vertex shader and a geometry 1910 shader, vertex shader output variables and geometry shader input 1911 variables of the same name must match in type and qualification (other 1912 than precision and "out" matching to "in"), except that the geometry 1913 shader will have one more array dimension than the vertex shader, to 1914 allow for vertex indexing. If such an arrayed interface variable is not 1915 declared with the necessary additional input or output array dimension, 1916 a link-time error will result. 1917 1918 For non-arrayed interfaces (meaning array dimensionally stays the same 1919 between stages), it is a link-time error if the input variable is not 1920 declared with the same type, including array dimensionality, and 1921 qualification (other than precision and "out" matching to "in") as the 1922 matching output variable. 1923 1924 Fragment shader inputs get per-fragment values... 1925 1926 1927 Modify section 4.3.6 "Output Variables" starting with the third 1928 paragraph of the section, as modified by 1929 OES_shader_multisample_interpolation, on p. 42: 1930 1931 Vertex and geometry output variables output per-vertex data and are 1932 declared using the "out", "centroid out", or "sample out" storage 1933 qualifiers. ... 1934 1935 Individual vertex and geometry outputs are declared as in the following 1936 examples: ... 1937 1938 ... 1939 flat out vec3 myColor; 1940 sample out vec4 perSampleColor; 1941 1942 These can also appear in interface blocks, as described in section 4.3.9 1943 "Interface Blocks". Interface blocks allow simpler addition of arrays to 1944 the interface from vertex to geometry shader. They also allow a fragment 1945 shader to have the same input interface as a geometry shader for a given 1946 vertex shader. 1947 1948 Fragment outputs output per-fragment data ... 1949 1950 1951 Modify section 4.3.9 "Interface Blocks" as modified by 1952 OES_shader_io_blocks, to add following the paragraph starting "When 1953 using OpenGL ES API entry points to identify the name": 1954 1955 Geometry shader input blocks must be declared as arrays and follow the 1956 array declaration and linking rules for all geometry shader inputs. All 1957 other input and output block arrays must specify an array size. 1958 1959 1960 Modify section 4.4.1 "Input Layout Qualifiers" as modified 1961 by OES_shader_io_blocks: 1962 1963 Insert a new section 4.4.1.gs, before section 4.4.1.fs: 1964 1965 Section 4.4.1.gs, Geometry Shader Inputs 1966 1967 Additional layout qualifier identifiers for geometry shader inputs 1968 include primitive identifiers and an invocation count identifier: 1969 1970 <layout-qualifier-id> 1971 points 1972 lines 1973 lines_adjacency 1974 triangles 1975 triangles_adjacency 1976 invocations = integer-constant 1977 1978 The identifiers points, lines, lines_adjacency, triangles, and 1979 triangles_adjacency are used to specify the type of input primitive 1980 accepted by the geometry shader, and only one of these is accepted. The 1981 geometry shader object in a program must declare this input primitive 1982 layout, and all geometry shader input layout declarations in a program 1983 must declare the same layout. 1984 1985 The identifier invocations is used to specify the number of times the 1986 geometry shader executable is invoked for each input primitive received. 1987 Invocation count declarations are optional. If no invocation count is 1988 declared in any geometry shader in a program, the geometry shader will 1989 be run once for each input primitive. If an invocation count is 1990 declared, all such declarations must specify the same count. If a shader 1991 specifies an invocation count greater than the implementation-dependent 1992 maximum, it will fail to compile. 1993 1994 For example, 1995 1996 layout(triangles, invocations = 6) in; 1997 1998 will establish that all inputs to the geometry shader are triangles and 1999 that the geometry shader executable is run six times for each triangle 2000 processed. 2001 2002 All geometry shader input unsized array declarations will be sized by an 2003 earlier input primitive layout qualifier, when present, as per the 2004 following table. 2005 2006 Layout Size of Input Arrays 2007 ------------------- -------------------- 2008 points 1 2009 lines 2 2010 lines_adjacency 4 2011 triangles 3 2012 triangles_adjacency 6 2013 2014 The intrinsically declared input array gl_in[] will also be sized by any 2015 input primitive-layout declaration. Hence, the expression 2016 2017 gl_in.length() 2018 2019 will return the value from the table above. 2020 2021 For inputs declared without an array size, including intrinsically 2022 declared inputs (i.e., gl_in), a layout must be declared before any use 2023 of the method length or other any array use that requires the array size 2024 to be known. 2025 2026 It is a compile-time error if a layout declaration's array size (from 2027 table above) does not match all the explicit array sizes specified in 2028 declarations of an input variables in the same shader. The following 2029 includes examples of compile-time errors: 2030 2031 // code sequence within one shader... 2032 in vec4 Color1[]; // legal, size still unknown 2033 in vec4 Color2[2]; // legal, size is 2 2034 in vec4 Color3[3]; // illegal, input sizes are inconsistent 2035 layout(lines) in; // legal for Color2, input size is 2, matching Color2 2036 in vec4 Color4[3]; // illegal, contradicts layout of lines 2037 layout(lines) in; // legal, matches other layout() declaration 2038 layout(triangles) in; // illegal, does not match earlier layout() declaration 2039 2040 It is a link-time error if not all provided sizes (sized input arrays 2041 and layout size) match in the geometry shader of a program. 2042 2043 2044 Add new section 4.4.2.gs before section 4.4.2.fs, as added by 2045 OES_shader_io_blocks: 2046 2047 2048 Section 4.4.2.gs Geometry Outputs 2049 2050 Geometry shaders can have two additional types of output layout 2051 identifiers: an output primitive type and a maximum output vertex count. 2052 The primitive type and vertex count identifiers are allowed only on the 2053 interface qualifier out, not on an output block, block member, or 2054 variable declaration. 2055 2056 The layout qualifier identifiers for geometry shader outputs are 2057 2058 layout-qualifier-id 2059 points 2060 line_strip 2061 triangle_strip 2062 max_vertices = integer-constant 2063 2064 The primitive type identifiers points, line_strip, and triangle_strip 2065 are used to specify the type of output primitive produced by the 2066 geometry shader, and only one of these is accepted. The geometry shader 2067 object in a program must declare an output primitive type, and all 2068 geometry shader output primitive type declarations in a program must 2069 declare the same primitive type. 2070 2071 The vertex count identifier max_vertices is used to specify the maximum 2072 number of vertices the shader will ever emit in a single invocation. The 2073 geometry shader object in a program must declare a maximum output vertex 2074 count, and all geometry shader output vertex count declarations in a 2075 program must declare the same count. 2076 2077 In this example, 2078 2079 layout(triangle_strip, max_vertices = 60) out; // order does not matter 2080 layout(max_vertices = 60) out; // redeclaration okay 2081 layout(triangle_strip) out; // redeclaration okay 2082 layout(points) out; // error, contradicts triangle_strip 2083 layout(max_vertices = 30) out; // error, contradicts 60 2084 2085 all outputs from the geometry shader are triangles and at most 60 2086 vertices will be emitted by the shader. It is an error for the maximum 2087 number of vertices to be greater than gl_MaxGeometryOutputVertices. 2088 2089 All geometry shader output layout declarations in a program must declare 2090 the same layout and same value for max_vertices. If geometry shaders are 2091 in a program, there must be at least one geometry output layout 2092 declaration somewhere in that program. 2093 2094 2095 Modify section 4.7.4, "Default Precision Qualifiers": 2096 2097 Modify the third paragraph on p. 64: 2098 2099 "All languages except for the fragment language have the following 2100 predeclared globally scoped default precision statements: ..." 2101 2102 2103 Add new section 7.1.1gs following section 7.1.1 "Vertex Shader Special 2104 Variables": 2105 2106 Section 7.1.1gs, Geometry Shader Special Variables 2107 2108 In the geometry language, the built-in variables are intrinsically 2109 declared as: 2110 2111 [[ If OES_geometry_point_size is supported and enabled: ]] 2112 in gl_PerVertex { 2113 highp vec4 gl_Position; 2114 highp float gl_PointSize; 2115 } gl_in[]; 2116 2117 [[ Otherwise: ]] 2118 in gl_PerVertex { 2119 highp vec4 gl_Position; 2120 } gl_in[]; 2121 2122 in highp int gl_PrimitiveIDIn; 2123 in highp int gl_InvocationID; 2124 2125 [[ If OES_geometry_point_size is supported and enabled: ]] 2126 out gl_PerVertex { 2127 highp vec4 gl_Position; 2128 highp float gl_PointSize; 2129 }; 2130 2131 [[ Otherwise: ]] 2132 out gl_PerVertex { 2133 highp vec4 gl_Position; 2134 }; 2135 2136 out highp int gl_PrimitiveID; 2137 out highp int gl_Layer; 2138 2139 2140 Section 7.1.1gs.1, Geometry Shader Input Variables 2141 2142 gl_Position contains the output written in the previous shader stage to 2143 gl_Position. 2144 2145 [[ If OES_geometry_point_size is supported: ]] 2146 gl_PointSize contains the output written in the previous shader stage to 2147 gl_PointSize. 2148 2149 gl_PrimitiveIDIn contains the number of primitives processed by the 2150 shader since the current set of rendering primitives was started. 2151 2152 gl_InvocationID contains the invocation number assigned to the geometry 2153 shader invocation. It is assigned integer values in the range [0, N-1], 2154 where N is the number of geometry shader invocations per primitive. 2155 2156 2157 Section 7.1.1gs.2, Geometry Shader Output Variables 2158 2159 gl_Position is used in the same fashion as the corresponding output 2160 variable in the vertex shader. Its value is undefined after geometry 2161 processing if the shader calls EmitVertex() without having written 2162 gl_Position since the last EmitVertex(), or does not write it at all. 2163 2164 [[ If OES_geometry_point_size is supported: ]] 2165 gl_PointSize is used in the same fashion as the corresponding output 2166 variable in the vertex shader. 2167 2168 gl_PrimitiveID is filled with a single integer that serves as a 2169 primitive identifier to the fragment shader. This is then available to 2170 fragment shaders, which will select the written primitive ID from the 2171 provoking vertex of the primitive being shaded. If a fragment shader 2172 using gl_PrimitiveID is active and a geometry shader is also active, the 2173 geometry shader must write to gl_PrimitiveID or the fragment shader 2174 input gl_PrimitiveID is undefined. See section 11.1gs.4 "Geometry Shader 2175 Outputs" of the OpenGL ES Specification for more information. 2176 2177 gl_Layer is used to select a specific layer (or face and layer of a cube 2178 map) of a multi-layer framebuffer attachment. The actual layer used will 2179 come from one of the vertices in the primitive being shaded. Which 2180 vertex the layer comes from is determined as discussed in section 2181 11.1gs.4 of the OpenGL ES Specification but may be undefined, so it is 2182 best to write the same layer value for all vertices of a primitive. If a 2183 shader statically assigns a value to gl_Layer, layered rendering mode is 2184 enabled. See section 11.1gs.4 "Geometry Shader Outputs"and section 9.7gs 2185 "Layered Framebuffers" of the OpenGL ES Specification for more 2186 information. If a shader statically assigns a value to gl_Layer, and 2187 there is an execution path through the shader that does not set 2188 gl_Layer, then the value of gl_Layer is undefined for executions of the 2189 shader that take that path. 2190 2191 2192 Modify section 7.1.2 "Fragment Shader Special Variables", as modified by 2193 OES_sample_variables: 2194 2195 Add to the list of built-in variables: 2196 2197 in highp int gl_PrimitiveID; 2198 in highp int gl_Layer; 2199 2200 Add descriptions of these variables: 2201 2202 The input variable gl_PrimitiveID is filled with the value written to 2203 the gl_PrimitiveID geometry shader output, if a geometry shader is 2204 present. Otherwise, it is filled with the number of primitives processed 2205 by the shader since the current set of rendering primitives was started. 2206 2207 The input variable gl_Layer is filled with the value written to the 2208 gl_Layer geometry shader output, if a geometry shader is present. If the 2209 geometry stage does not dynamically assign a value to gl_Layer, the 2210 value of gl_Layer in the fragment stage will be undefined. If the 2211 geometry stage makes no static assignment to gl_Layer, the input value 2212 in the fragment stage will be zero. Otherwise, the fragment stage will 2213 read the same value written by the geometry stage, even if that value is 2214 out of range. If a fragment shader contains a static access to gl_Layer, 2215 it will count against the implementation defined limit for the maximum 2216 number of inputs to the fragment stage. 2217 2218 Modify the description of gl_FrontFacing: 2219 2220 The input variable gl_FrontFacing is true if the fragment belongs to a 2221 front-facing primitive. One use of this is to emulate two-sided lighting 2222 by selecting one of two colors calculated by a vertex or geometry 2223 shader. 2224 2225 2226 Add to Section 7.2 "Built-In Constants", matching the 2227 corresponding API implementation-dependent limits: 2228 2229 const mediump int gl_MaxGeometryInputComponents = 64; 2230 const mediump int gl_MaxGeometryOutputComponents = 128; 2231 const mediump int gl_MaxGeometryImageUniforms = 0; 2232 const mediump int gl_MaxGeometryTextureImageUnits = 16; 2233 const mediump int gl_MaxGeometryOutputVertices = 256; 2234 const mediump int gl_MaxGeometryTotalOutputComponents = 1024; 2235 const mediump int gl_MaxGeometryUniformComponents = 1024; 2236 const mediump int gl_MaxGeometryAtomicCounters = 0; 2237 const mediump int gl_MaxGeometryAtomicCounterBuffers = 0; 2238 2239 Modify gl_MaxCombinedTextureImageUnits to match the API: 2240 2241 const mediump int gl_MaxCombinedTextureImageUnits = 64; 2242 2243 2244 Add new section 8.12gs preceding section 8.13 "Fragment Processing 2245 Functions": 2246 2247 Section 8.12gs, Geometry Shader Functions 2248 2249 These functions are only available in geometry shaders. They are 2250 described in more depth following the table. 2251 2252 Syntax Description 2253 ------------------- ----------------------------------------------- 2254 void EmitVertex() Emits the current values of output variables to 2255 the current output primitive. On return from 2256 this call, the values of output variables are 2257 undefined. 2258 void EndPrimitive() Completes the current output primitive and 2259 starts a new one. No vertex is emitted. 2260 2261 The function EmitVertex() specifies that a vertex is completed. A vertex 2262 is added to the current output primitive using the current values of all 2263 built-in and user-defined output variables. The values of all output 2264 variables are undefined after a call to EmitVertex(). If a geometry 2265 shader invocation has emitted more vertices than permitted by the output 2266 layout qualifier max_vertices, the results of calling EmitVertex() are 2267 undefined. 2268 2269 The function EndPrimitive() specifies that the current output primitive 2270 is completed and a new output primitive (of the same type) will be 2271 started by any subsequent EmitVertex(). This function does not emit a 2272 vertex. If the output layout is declared to be "points", calling 2273 EndPrimitive() is optional. 2274 2275 A geometry shader starts with an output primitive containing no 2276 vertices. When a geometry shader terminates, the current output 2277 primitive is automatically completed. It is not necessary to call 2278 EndPrimitive() if the geometry shader writes only a single primitive. 2279 2280 2281 Modify section 8.16, "Shader Memory Control Functions" to change the 2282 paragraph starting "When these functions return..." on p. 139: 2283 2284 When these functions return ... the execution of the original shader 2285 invocation (e.g., fragment shader invocations for a primitive resulting 2286 from a particular vertex or geometry shader invocation). 2287 2288Issues 2289 2290 Note: These issues apply specifically to the definition of the 2291 OES_geometry_shader specification, which is based on the OpenGL 2292 extension ARB_geometry_shader4 as updated in OpenGL 4.x. Resolved issues 2293 from ARB_geometry_shader4 have been removed, but remain largely 2294 applicable to this extension. ARB_geometry_shader4 can be found in the 2295 OpenGL Registry. 2296 2297 (1) What functionality was removed from ARB_geometry_shader4 / GL 4.4? 2298 2299 - Interactions with features not supported by the underlying 2300 ES 3.1 API and Shading Language, including: 2301 * one-dimensional, rectangular, and cube map array textures (cube 2302 map array textures are restored in OES_texture_cube_map_array). 2303 * vertex program point size mode 2304 * viewport arrays and other support for multiple viewports 2305 * multiple vertex streams (these require ARB_transform_feedback3) 2306 * gl_ClipDistance shader inputs and outputs. 2307 * CopyPixels and Bitmap 2308 * fixed-functionality vertex and fragment shader stages 2309 * "component" layout 2310 * Implicit references to glPolygonMode 2311 * References allowing or assuming more than one shader object per 2312 pipeline stage. 2313 - FramebufferTexture3D (use FramebufferTextureLayer instead). 2314 - gl_MaxGeometryVaryingComponents 2315 - gl_VerticesIn 2316 - FramebufferTextureFaceARB (also removed from GL core) 2317 - The FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_OES completeness condition, 2318 also removed from desktop GL. 2319 - Description of limitations of GeForce series 8 chips. 2320 - GLSL two-dimensional arrays (already supported by GLSL-ES 3.10 in a 2321 more general fashion). Note that while multi-dimensional arrays are 2322 supported, they are explicitly not supported as shader inputs and 2323 outputs, and that decision is respected here. 2324 - multiple compilation units of the same shader type. 2325 2326 (2) What functionality was changed and added relative to 2327 ARB_geometry_shader4 and GL 4.4? 2328 2329 - OES_geometry_shader closely matches OpenGL 4.4 geometry shader 2330 language, rather than ARB_geometry_shader language. 2331 - In particular, input and output interface blocks were added from GL 2332 4.4 / GLSL 4.40, via the required OES_shader_io_blocks extension. 2333 - Interactions were added with OpenGL ES 3.1 functionality including 2334 separate shader objects, shader atomic counters, shader storage 2335 buffer objects, and shader image load/store. 2336 - Geometry instancing was added from ARB_gpu_shader5. 2337 - FRAMEBUFFER_DEFAULT_LAYERS_OES and MAX_FRAMEBUFFER_LAYERS_OES state 2338 and related spec language from ARB_framebuffer_no_attachments (it 2339 was removed from OpenGL ES 3.1). 2340 - PRIMITIVES_GENERATED_OES query from OpenGL 3.0, to count primitives 2341 due to geometry amplification by geometry shaders. 2342 - LAYER_PROVOKING_VERTEX_OES query from ARB_provoking_vertex / 2343 ARB_viewport_array (but did not add ProvokingVertex control, just 2344 this query). 2345 - Specify undefined behavior when appending outputs to XFB buffers if 2346 any component would be written at a misaligned offset, from 2347 ARB_enhanced_layouts. Bug 11191 is tracking this into ES 3.1, as 2348 it's not specific to geometry shaders. 2349 - Writing point size from geometry shaders is optional functionality. 2350 If it's not supported or written, the point size of 1.0 is used. 2351 - Added precision qualifiers to builtins. 2352 - Clarification from Bug 11508. 2353 - Added program interface query properties relevant to geometry 2354 shaders. 2355 2356 (3) Should GetActiveUniformBlockiv support queries for uniform blocks 2357 and atomic counter buffers referenced by geometry shaders? 2358 2359 RESOLVED: No. Use the new generic program interface query supported by 2360 OpenGL ES 3.1, following the behavior of features added to 3.1 such as 2361 compute shaders, which also dropped these legacy tokens / queries. 2362 2363 (4) How are aggregate shader limits computed? 2364 2365 RESOLVED: Following the GL 4.4 model, but we restrict uniform 2366 buffer bindings to 12/stage instead of 14, this results in 2367 2368 MAX_UNIFORM_BUFFER_BINDINGS = 48 2369 This is 12 bindings/stage * 4 shader stages, allowing a static 2370 partitioning of the bindings even though at most 5 stages can 2371 appear in a program object). 2372 MAX_COMBINED_UNIFORM_BLOCKS = 36 2373 This is 12 blocks/stage * 3 stages, since compute shaders can't 2374 be mixed with other stages. 2375 MAX_COMBINED_TEXTURE_IMAGE_UNITS = 64 2376 This is 16 textures/stage * 4 stages. 2377 2378 Khronos internal bugs 5870, 8891, and 9424 cover the ARB's thinking on 2379 these limits for GL 4.0 and beyond. 2380 2381 (5) Are arrays supported as shader inputs and outputs? 2382 2383 RESOLVED: No. In several places in the tessellation and geometry API 2384 language based on GL 4.4, it says that "the OpenGL ES Shading Language 2385 doesn't support multi-dimensional arrays" and restricts declarations of 2386 inputs and outputs which are array members to blocks themselves declared 2387 as arrays. 2388 2389 Strictly speaking this is no longer true. GLSL-ES 3.10 supports 2390 multi-dimensional arrays, but arrays of 2391 arrays are not allowed as shader inputs or outputs. 2392 2393 Given this constraint, and since the same constraint is in OpenGL 4.4, 2394 I've resolved this by continuing to limit array inputs and outputs 2395 in this fashion, and change the language to "...doesn't support 2396 multi-dimensional arrays as shader inputs or outputs". 2397 2398 (6) What component counting rules are used for inputs and outputs? 2399 2400 RESOLVED: In several places I've inserted language from OpenGL 4.4 to 2401 the effect of 2402 2403 "Component counting rules for different variable types and variable 2404 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see 2405 section 11.1.2.1)." 2406 2407 I think this is essentially cleaning up an oversight in the earlier ARB 2408 extension language but it is a bit orthogonal to the extension 2409 functionality and I'm bringing it up in case this is a potential issue. 2410 2411 (7) What component counting rules are used for the default 2412 uniform block? 2413 2414 RESOLVED: In several places I've inserted language from OpenGL 4.2 to 2415 the effect of 2416 2417 "A uniform matrix in the default uniform block with single-precision 2418 components will consume no more than 4 x min(r,c) uniform 2419 components." 2420 2421 This is based on bug 5432 and is language that was later expanded in 2422 OpenGL 4.4 and refactored into the generic "Uniform Variables" section, 2423 which is something we should consider in the EXT extensions as well to 2424 avoid duplication. I believe it is what we want but am noting it for the 2425 same reason as the language in issue (7). I'm hoping to be able to 2426 include this refactored language into the OpenGL ES 3.1 Specification, 2427 so we can refer to it more easily here. Tracking bug 11192 has been 2428 opened for this and this language was approved there. 2429 2430 (8) What should the minimum value of MAX_GEOMETRY_UNIFORM_COMPONENTS_OES 2431 be? 2432 2433 RESOLVED: GL 4.4 has 512, but we use 1024 to match the ES vertex 2434 shader limit. 2435 2436 (9) What should the minimum value of MAX_GEOMETRY_OUTPUT_COMPONENTS_OES 2437 be? 2438 2439 RESOLVED: This was reduced to 64 in revision 3, from an initial value of 2440 128 (matching GL 4.4), to match the limits on vertex shader outputs and 2441 fragment shader inputs (Bug 12823). 2442 2443 (10) What naming and token values should we use for 2444 GEOMETRY_VERTICES_OUT_OES, GEOMETRY_INPUT_TYPE_OES, and 2445 GEOMETRY_OUTPUT_TYPE_OES? 2446 2447 DISCUSSION: In EXT_geometry_shader4 and ARB_geometry_shader4, the 2448 vertice and input and output type are specified by a program parameter 2449 state. OpenGL 3.2 requires this to be provided in the shader text and 2450 provided a query for these values after linking. Since this was a 2451 functionality change the similarly named enumerants were given different 2452 values. Thus we have the following token names and enumerants in GL: 2453 2454 (from EXT_geometry_shader4) 2455 GEOMETRY_VERTICES_OUT_EXT 0x8DDA 2456 GEOMETRY_INPUT_TYPE_EXT 0x8DDB 2457 GEOMETRY_OUTPUT_TYPE_EXT 0x8DDC 2458 2459 (from ARB_geometry_shader4) 2460 GEOMETRY_VERTICES_OUT_ARB 0x8DDA 2461 GEOMETRY_INPUT_TYPE_ARB 0x8DDB 2462 GEOMETRY_OUTPUT_TYPE_ARB 0x8DDC 2463 2464 (from OpenGL 3.2) 2465 GEOMETRY_VERTICES_OUT 0x8916 2466 GEOMETRY_INPUT_TYPE 0x8917 2467 GEOMETRY_OUTPUT_TYPE 0x8918 2468 2469 Now for this extensions we are providing the GL 3.2-type functionality 2470 and thus we should use the token *values* from GL core. However, 2471 it is expected that this extension will ship as an EXT, so we would 2472 end up with: 2473 GEOMETRY_VERTICES_OUT_EXT 0x8916 2474 GEOMETRY_INPUT_TYPE_EXT 0x8917 2475 GEOMETRY_OUTPUT_TYPE_EXT 0x8918 2476 which gives us the same token names as the EXT_geometry_shader4 but 2477 the same token values as OpenGL 3.2. This would potentially be 2478 quite confusing if headers are mix and matched. 2479 2480 OPTIONS: If this extension ships as an EXT, 2481 a) invent a new suffix. Ideally we'd have a different EXT-like suffix 2482 to disambiguate between GL and ES multivendor extensions. However this 2483 has not happened yet. 2484 b) we use a _VENDOR suffix for these 3 enumerants to disambiguate them 2485 c) change the tokens to GEOMETRY_LINKED_*_EXT, with the expectation that 2486 we'd rename them back if this becomes core functionality. 2487 2488 RESOLVED. Pick c). We will include the "_LINKED" term in the tokens 2489 to indicate that they represent the values generated at link time. At 2490 such a time as this becomes core functionality in ES, they should 2491 be renamed back to be the same as the GL tokens (possibly with an 2492 alias for compatibility with this extension). 2493 2494 (11) How should we handle the enablement of input/output blocks in 2495 non-geometry stages? 2496 2497 RESOLVED: Early drafts of this extension added a number 2498 of capabilities that were not specific to geometry shaders, namely: 2499 * allowed the declaration and use of input and output blocks 2500 * moved the built-in "per-vertex" in/out variables into the 2501 built-in gl_PerVertex block 2502 * allowed the redeclaration of the gl_PerVertex block. 2503 2504 In OpenGL these capabilities are provided by the GLSL 1.50 version. 2505 Furthermore, when separable programs are in use, OpenGL *requires* 2506 that the gl_PerVertex block be declared in any shader which uses any of 2507 its members (including vertex and fragment shaders). 2508 2509 Since this capability is being added as an extension to OpenGL ES 3.1 2510 we don't have a core shading language version to hang this feature 2511 off of and thus we need an extension to enable this. 2512 2513 Using the earlier drafts, we would have needed to use the 2514 OES_geometry_shader #extension in vertex or fragment shaders to enable 2515 this functionality. Since this was rather unintuitive and this 2516 functionality does have utility on it's own, we opted instead to pull 2517 this out to a separate extension that is a required dependency 2518 (OES_shader_io_blocks). 2519 2520 The geometry (and tessellation) extensions will automatically imply 2521 that the OES_shader_io_blocks functionality is enabled, since it is 2522 impossible to use them in a useful manner without accessing 2523 gl_PerVertex input/output blocks. 2524 2525 (12) Due to HW limitations, some vendors may not be able 2526 to support writing gl_PointSize from geometry shaders, how should we 2527 accomodate this? 2528 2529 RESOLVED: There are two extensions described in this document. The 2530 base extension does not support writing to gl_PointSize from geometry 2531 shaders and the gl_PerVertex block does not include gl_PointSize. 2532 Additionally there is a layered extension which provides the ability 2533 to write to gl_PointSize from geometry shaders. When this extension 2534 is enabled, the gl_PerVertex block does include gl_PointSize and it 2535 can be written from geometry shaders as normal. 2536 2537 If the point-size extension is not supported, all points written 2538 from a geometry shader will have size of one. If the point-size 2539 extension is supported but not enabled, or if it's enabled but 2540 gl_PointSize is not written, it as if a point size of one was written. 2541 Otherwise, if you statically assign gl_PointSize in the last stage 2542 before the rasterizer, the (potentially clamped) value written will 2543 determine the size of the point for rasterization. 2544 2545 (13) Does this extension change how transform feedback operates 2546 compared to unextended OpenGL ES 3.0 or 3.1? 2547 2548 RESOLVED: Yes. Because dynamic geometry amplification in a geometry 2549 shader can make it difficult if not impossible to predict the amount 2550 of geometry that may be generated in advance of executing the shader, 2551 the draw-time error for transform feedback buffer overflow conditions 2552 is removed and replaced with the GL behavior (primitives are not written 2553 and the corresponding counter is not updated). Since we no longer 2554 require being able to predict how much geometry will be generated, we 2555 also lift the restriction that only DrawArray* commands are supported 2556 and also support the DrawElements* commands for transform feedback. 2557 We also allow Draw*Indirect to be used with transform feedback. 2558 2559 (14) Should GetShaderPrecisionFormat support the new GEOMETRY_SHADER_OES 2560 stage? 2561 2562 RESOLVED: No. Following the precedence of OpenGL ES 3.1 which did not 2563 extend this query to COMPUTE_SHADERS due to the following reason: 2564 GetShaderPrecisionFormat is listed in ES 3.0 appendix F.1 Legacy Features 2565 whose use is not recommended. Adding new capabilities to a feature that 2566 is effectively deprecated seems silly (Bug 11464). 2567 2568Revision History 2569 2570 Rev. Date Author Changes 2571 ---- -------- --------- ------------------------------------------------- 2572 4 05/31/16 Jon Leech Note that primitive ID counters are reset to zero 2573 after each instance drawn (Bug 14024). 2574 3 07/23/15 Jon Leech Reduce minimum value of 2575 MAX_GEOMETRY_OUTPUT_COMPONENTS_OES to 64 (Bug 2576 12823). 2577 2 10/08/14 Olson change max_vertices identifier to integer-constant 2578 to match other ES layout-qualifier-ids 2579 (Bug 12878) 2580 1 06/18/14 dkoch Initial OES version based on EXT. 2581 No functional changes. 2582