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