| Name |
| |
| EXT_geometry_shader |
| |
| Name String |
| |
| GL_EXT_geometry_shader |
| GL_EXT_geometry_point_size |
| |
| Contact |
| |
| Jon Leech (oddhack 'at' sonic.net) |
| Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) |
| |
| Contributors |
| |
| Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) |
| Pat Brown, NVIDIA (pbrown 'at' nvidia.com) |
| Slawomir Grajewski, Intel |
| Dominik Witczak, Mobica |
| Jesse Hall, Google |
| Maurice Ribble, Qualcomm |
| Bill Licea-Kane, Qualcomm |
| Graham Connor, Imagination |
| Ben Bowman, Imagination |
| Jonathan Putsman, Imagination |
| Contributors to ARB_geometry_shader4 |
| |
| Notice |
| |
| Copyright (c) 2008-2016 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Portions Copyright (c) 2013-2014 NVIDIA Corporation. |
| |
| Status |
| |
| Complete. |
| |
| Version |
| |
| Last Modified Date: May 31, 2016 |
| Revision: 21 |
| |
| Number |
| |
| OpenGL ES Extension #177 |
| |
| Dependencies |
| |
| OpenGL ES 3.1 and OpenGL ES Shading Language 3.10 are required. |
| |
| This specification is written against the OpenGL ES 3.1 (March 17, 2014) |
| and OpenGL ES 3.10 Shading Language (March 17, 2014) Specifications. |
| |
| EXT_shader_io_blocks is required. |
| |
| OES_sample_variables trivially affects the definition of this extension. |
| |
| OES_texture_storage_multisample_2d_array affects the definition of this |
| extension. |
| |
| OES_shader_multisample_interpolation trivially affects the definition of |
| this extension. |
| |
| EXT_texture_buffer trivially affects the definition of this extension. |
| |
| Overview |
| |
| EXT_geometry_shader defines a new shader type available to be run on the |
| GPU, called a geometry shader. Geometry shaders are run after vertices are |
| transformed, but prior to color clamping, flatshading and clipping. |
| |
| A geometry shader begins with a single primitive (point, line, |
| triangle). It can read the attributes of any of the vertices in the |
| primitive and use them to generate new primitives. A geometry shader has a |
| fixed output primitive type (point, line strip, or triangle strip) and |
| emits vertices to define a new primitive. A geometry shader can emit |
| multiple disconnected primitives. The primitives emitted by the geometry |
| shader are clipped and then processed like an equivalent primitive |
| specified by the application. |
| |
| Furthermore, EXT_geometry_shader provides four additional primitive |
| types: lines with adjacency, line strips with adjacency, separate |
| triangles with adjacency, and triangle strips with adjacency. Some of the |
| vertices specified in these new primitive types are not part of the |
| ordinary primitives, instead they represent neighboring vertices that are |
| adjacent to the two line segment end points (lines/strips) or the three |
| triangle edges (triangles/tstrips). These vertices can be accessed by |
| geometry shaders and used to match up the vertices emitted by the geometry |
| shader with those of neighboring primitives. |
| |
| Since geometry shaders expect a specific input primitive type, an error |
| will occur if the application presents primitives of a different type. |
| For example, if a geometry shader expects points, an error will occur at |
| drawing time if a primitive mode of TRIANGLES is specified. |
| |
| This extension also adds the notion of layered framebuffer attachments |
| and framebuffers that can be used in conjunction with geometry shaders |
| to allow programs to direct primitives to a face of a cube map or layer |
| of a three-dimensional texture or two-dimensional array texture. The |
| layer used for rendering can be selected by the geometry shader at run |
| time. The framebuffer layer count present in GL 4.x and removed from |
| ES 3.1 is restored. |
| |
| Not all geometry shader implementations have the ability to write the |
| point size from a geometry shader. Thus a second extension string and |
| shading language enable are provided for implementations which do |
| support geometry shader point size. |
| |
| This extension relies on the EXT_shader_io_blocks extension to provide |
| the required functionality for declaring input and output blocks and |
| interfacing between shaders. |
| |
| New Procedures and Functions |
| |
| void FramebufferTextureEXT(enum target, enum attachment, |
| uint texture, int level); |
| |
| New Tokens |
| |
| Accepted by the <type> parameter of CreateShader and |
| CreateShaderProgramv, by the <pname> parameter of |
| GetProgramPipelineiv and returned in the <params> parameter of |
| GetShaderiv when <pname> is SHADER_TYPE: |
| |
| GEOMETRY_SHADER_EXT 0x8DD9 |
| |
| Accepted by the <stages> parameter of UseProgramStages: |
| |
| GEOMETRY_SHADER_BIT_EXT 0x00000004 |
| |
| Accepted by the <pname> parameter of GetProgramiv: |
| |
| GEOMETRY_LINKED_VERTICES_OUT_EXT 0x8916 |
| GEOMETRY_LINKED_INPUT_TYPE_EXT 0x8917 |
| GEOMETRY_LINKED_OUTPUT_TYPE_EXT 0x8918 |
| GEOMETRY_SHADER_INVOCATIONS_EXT 0x887F |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetInteger64v: |
| |
| LAYER_PROVOKING_VERTEX_EXT 0x825E |
| MAX_GEOMETRY_UNIFORM_COMPONENTS_EXT 0x8DDF |
| MAX_GEOMETRY_UNIFORM_BLOCKS_EXT 0x8A2C |
| MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS_EXT 0x8A32 |
| MAX_GEOMETRY_INPUT_COMPONENTS_EXT 0x9123 |
| MAX_GEOMETRY_OUTPUT_COMPONENTS_EXT 0x9124 |
| MAX_GEOMETRY_OUTPUT_VERTICES_EXT 0x8DE0 |
| MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_EXT 0x8DE1 |
| MAX_GEOMETRY_SHADER_INVOCATIONS_EXT 0x8E5A |
| MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT 0x8C29 |
| MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_EXT 0x92CF |
| MAX_GEOMETRY_ATOMIC_COUNTERS_EXT 0x92D5 |
| MAX_GEOMETRY_IMAGE_UNIFORMS_EXT 0x90CD |
| MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_EXT 0x90D7 |
| |
| Returned in the <data> parameter from a Get query with a <pname> of |
| LAYER_PROVOKING_VERTEX_EXT: |
| |
| FIRST_VERTEX_CONVENTION_EXT 0x8E4D |
| LAST_VERTEX_CONVENTION_EXT 0x8E4E |
| UNDEFINED_VERTEX_EXT 0x8260 |
| |
| Accepted by the <target> parameter of BeginQuery, EndQuery, |
| GetQueryiv, and GetQueryObjectuiv: |
| |
| PRIMITIVES_GENERATED_EXT 0x8C87 |
| |
| Accepted by the <mode> parameter of DrawArrays, DrawElements, |
| and other commands which draw primitives: |
| |
| LINES_ADJACENCY_EXT 0xA |
| LINE_STRIP_ADJACENCY_EXT 0xB |
| TRIANGLES_ADJACENCY_EXT 0xC |
| TRIANGLE_STRIP_ADJACENCY_EXT 0xD |
| |
| Accepted by the <pname> parameter of FramebufferParameteri, |
| and GetFramebufferParameteriv: |
| |
| FRAMEBUFFER_DEFAULT_LAYERS_EXT 0x9312 |
| |
| Accepted by the <pname> parameter of GetIntegerv, GetBooleanv, |
| GetInteger64v, and GetFloatv: |
| |
| MAX_FRAMEBUFFER_LAYERS_EXT 0x9317 |
| |
| Returned by CheckFramebufferStatus: |
| |
| FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT 0x8DA8 |
| |
| Accepted by the <pname> parameter of |
| GetFramebufferAttachmentParameteriv: |
| |
| FRAMEBUFFER_ATTACHMENT_LAYERED_EXT 0x8DA7 |
| |
| Accepted by the <props> parameter of |
| GetProgramResourceiv: |
| |
| REFERENCED_BY_GEOMETRY_SHADER_EXT 0x9309 |
| |
| Additions to the OpenGL ES 3.1 Specification |
| |
| Modify chapter 3 "Dataflow Model" |
| |
| Change the second paragraph, on p. 28: |
| |
| ... In the next stage vertices may be transformed, followed by assembly |
| into geometric primitives. Geometry shaders may then optionally generate |
| multiple new primitives from single input primitives. Optionally, the |
| results ... |
| |
| |
| Modify figure 3.1 "Block diagram of the OpenGL ES pipeline" to insert a |
| new box "Geometry Shader" following "Vertex Shader" and preceding |
| "Rasterization". Connect the Geometry Shader box to Transform Feedback |
| and Rasterization boxes, and remove the connection from Vertex Shader to |
| Transform Feedback. Extend the arrows from the boxes "Image Load/Store" |
| .. "Uniform Block" to the right of "Vertex Shader" to connect to the new |
| "Geometry Shader" box. |
| |
| |
| Modify section 4.2, "Query Objects and Asynchronous Queries" on p. 36 |
| to add to the bullet list of supported query types |
| |
| * Primitive queries with a target of PRIMITIVES_GENERATED_EXT (see |
| section 12.2) return information on the number of primitives processed |
| by the GL. |
| |
| |
| Replace the two paragraphs of chapter 7, "Programs and Shaders" |
| on p. 64 starting "Shader stages including ..." with: |
| |
| Shader stages including vertex, geometry, fragment, and compute shaders |
| can be created, compiled, and linked into program objects. |
| |
| Vertex shaders describe the operations that occur on vertex attributes. |
| Geometry shaders affect the processing of primitives assembled from |
| vertices (see section 11.1gs). Fragment shaders affect the processing of |
| fragments during rasterization (see chapter 14). A single program |
| object can contain all of these shaders, or any subset thereof. |
| |
| Compute shaders ... |
| |
| |
| Add to table 7.1 "CreateShader <type> values" on p. 65: |
| |
| <type> Shader Stage |
| ------------------- --------------- |
| GEOMETRY_SHADER_EXT Geometry shader |
| |
| |
| Change bullet list describing reasons for link failure below the |
| LinkProgram command on p. 70: |
| |
| ... Linking can fail for a variety of reasons as specified in the OpenGL |
| ES Shading Language Specification, as well as any of the following |
| reasons: |
| |
| * One or more of the shader objects attached to <program> are not |
| compiled successfully. |
| * More active uniform or active sampler variables are used in <program> |
| than allowed (see sections 7.6 and 7.9). |
| * The shaders do not use the same shader language version. |
| * <program> contains objects to form a geometry shader (see section |
| 11.1gs), and |
| - <program> is not separable and contains no objects to form a |
| vertex shader; or |
| - the input primitive type, output primitive type, or maximum output |
| vertex count is not specified in the compiled geometry shader |
| object. |
| * <program> contains objects to form a compute shader (see section 17) |
| and |
| - <program> also contains objects to form any other type of shader. |
| |
| If LinkProgram failed, ... |
| |
| |
| Modify section 7.3, "Program Objects": |
| |
| Add to the second paragraph after UseProgram on p. 71: |
| |
| The executable code ... the results of vertex and/or fragment processing |
| will be undefined. However, this is not an error. If there is no active |
| program for the geometry shader stage, that stage is ignored. If there |
| is no active program for the compute shader stage ... |
| |
| |
| Modify section 7.3.1, "Program Interfaces": |
| |
| Modify table 7.2 "GetProgramResourceiv properties and supported |
| interfaces" on p. 81 to add "REFERENCED_BY_GEOMETRY_SHADER_EXT" to the |
| "Property" cell already containing REFERENCED_BY_<stage>_SHADER for |
| VERTEX, FRAGMENT, and COMPUTE stages, with the same supported |
| interfaces. |
| |
| |
| Add geometry shaders to the paragraph describing the REFERENCED_BY |
| properties, on p. 83: |
| |
| For the properties REFERENCED_BY_VERTEX_SHADER, |
| REFERENCED_BY_GEOMETRY_SHADER_EXT, REFERENCED_BY_FRAGMENT_SHADER, and |
| REFERENCED_BY_COMPUTE_SHADER, a single integer is written to <params>, |
| identifying whether the active resource is referenced by the vertex, |
| geometry, fragment, or compute shaders, respectively, in the program |
| object. ... |
| |
| |
| Modify section 7.4, "Program Pipeline Objects" in the first paragraph |
| paragraph after UseProgramStages on p. 89: |
| |
| ... These stages may include vertex, geometry, fragment, or compute, |
| indicated respectively by VERTEX_SHADER_BIT, GEOMETRY_SHADER_BIT_EXT, |
| FRAGMENT_SHADER_BIT, or COMPUTE_SHADER_BIT. ... |
| |
| |
| Modify section 7.4.1, "Shader Interface Matching" on p. 91, changing |
| the second paragraph and adding a new paragraph: |
| |
| Variables and block members declared as structures ... in the OpenGL ES |
| Shading Language Specification. |
| |
| Geometry shader per-vertex input variables and blocks are required to be |
| declared as arrays, with each element representing input or output |
| values for a single vertex of a multi-vertex primitive. For the purposes |
| of interface matching, such variables and blocks are treated as though |
| they were not declared as arrays. |
| |
| For program objects containing multiple shaders... |
| |
| |
| Modify section 7.4.2 "Program Pipeline Object State" on p. 92, |
| replacing the first bullet point: |
| |
| * Unsigned integers are required to hold the names of the active program |
| and each of the current vertex, geometry, fragment, and compute stage |
| programs. Each integer is initially zero. |
| |
| |
| Modify section 7.6, "Uniform Variables" |
| |
| Add to table 7.4 "Query targets for default uniform block storage ..." |
| on p. 96: |
| |
| Shader Stage <pname> for querying default uniform block |
| storage, in components |
| ---------------------------- ------------------------------------------- |
| Geometry (see sec. 11.1gs.3) MAX_GEOMETRY_UNIFORM_COMPONENTS_EXT |
| |
| |
| Add to table 7.5 "Query targets for combined uniform block storage ..." |
| on p. 97: |
| |
| |
| Shader Stage <pname> for querying combined uniform block |
| storage, in components |
| ---------------------------- -------------------------------------------- |
| Geometry MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS_EXT |
| |
| |
| Modify section 7.6.2, "Uniform Blocks" on p. 104, changing the second |
| paragraph of the section: |
| |
| There is a set of implementation-dependent maximums for the number of |
| active uniform blocks used by each shader. If the number of uniform |
| blocks used by any shader in the program exceeds its corresponding |
| limit, the program will fail to link. The limits for vertex, geometry, |
| fragment, and compute shaders can be obtained by calling GetIntegerv |
| with <pname> values of MAX_VERTEX_UNIFORM_BLOCKS, |
| MAX_GEOMETRY_UNIFORM_BLOCKS_EXT, MAX_FRAGMENT_UNIFORM_BLOCKS, and |
| MAX_COMPUTE_UNIFORM_BLOCKS, respectively. |
| |
| |
| Modify section 7.7, "Atomic Counter Buffers" on p. 108, changing the |
| second paragraph of the section: |
| |
| There is a set of implementation-dependent maximums for the number of |
| active atomic counter buffers referenced by each shader. If the number |
| of atomic counter buffers referenced by any shader in the program |
| exceeds its corresponding limit, the program will fail to link. The |
| limits for vertex, geometry, fragment, and compute shaders can be |
| obtained by calling GetIntegerv with <pname> values of |
| MAX_VERTEX_ATOMIC_COUNTER_BUFFERS, |
| MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_EXT, |
| MAX_FRAGMENT_ATOMIC_COUNTER_BUFFERS, or |
| MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS, respectively. |
| |
| |
| Modify section 7.8, "Shader Buffer Variables and Shader Storage Blocks" |
| on p. 110, changing the fourth paragraph: |
| |
| If the number of active shader storage blocks referenced by the shaders |
| in a program exceeds implementation-dependent limits, the program will |
| fail to link. The limits for vertex, geometry, fragment, and compute |
| shaders can be obtained by calling GetIntegerv with pname values of |
| MAX_VERTEX_SHADER_STORAGE_BLOCKS, |
| MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_EXT, |
| MAX_FRAGMENT_SHADER_STORAGE_BLOCKS, and |
| MAX_COMPUTE_SHADER_STORAGE_BLOCKS, respectively. Additionally, a ... |
| |
| |
| Modify section 7.11.1 "Shader Memory Access Ordering" on p. 113 to add |
| to the list of ordering rules: |
| |
| * The relative order of invocations of different shader types is largely |
| undefined. However, when executing a shader whose inputs are generated |
| from a previous programmable stage, the shader invocations from the |
| previous stage are guaranteed to have executed far enough to generate |
| final values for all next-stage inputs. That implies shader completion |
| for all stages except geometry; geometry shaders are guaranteed only |
| to have executed far enough to emit all needed vertices. |
| |
| |
| Modify section 7.12, "Shader, Program, and Program Pipeline Queries" |
| to add to the list of valid <pname>s for GetProgramiv on p. 121: |
| |
| If <pname> is GEOMETRY_LINKED_VERTICES_OUT_EXT, the maximum number of |
| vertices the geometry shader will output is returned. |
| |
| If <pname> is GEOMETRY_LINKED_INPUT_TYPE_EXT, the geometry shader input |
| type, which must be one of POINTS, LINES, LINES_ADJACENCY_EXT, TRIANGLES |
| or TRIANGLES_ADJACENCY_EXT, is returned. |
| |
| If <pname> is GEOMETRY_LINKED_OUTPUT_TYPE_EXT, the current geometry shader |
| output type, which must be one of POINTS, LINE_STRIP or TRIANGLE_STRIP, |
| is returned. |
| |
| If <pname> is GEOMETRY_SHADER_INVOCATIONS_EXT, the number of geometry |
| shader invocations per primitive will be returned. |
| |
| |
| Add to the Errors for GetProgramiv on p. 121: |
| |
| An INVALID_OPERATION error is generated if |
| GEOMETRY_LINKED_VERTICES_OUT_EXT, GEOMETRY_LINKED_INPUT_TYPE_EXT, |
| GEOMETRY_LINKED_OUTPUT_TYPE_EXT, or GEOMETRY_SHADER_INVOCATIONS_EXT are |
| queried for a program which has not been linked successfully, or which |
| does not contain objects to form a geometry shader, |
| |
| |
| Modify section 7.13 "Required State" to change the last two paragraphs |
| of the section on p. 127: |
| |
| This list of program object state is not complete. Tables 20.20-20.28 |
| describe additional program object state specific to program binaries, |
| geometry shaders, and uniform blocks. |
| |
| Table 20.29 describes state related to vertex and geometry shaders that |
| is not program object state. |
| |
| |
| Modify section 9.2, "Binding and Managing Framebuffer Objects" to add to |
| the list of bullet points for BindFramebuffer on p. 205: |
| |
| * If the number of layers of each attachment are not all identical, |
| rendering will be limited to the smallest number of layers of any |
| attachment. If there are no attachments, the number of layers will be |
| taken from the framebuffer object's default layer count. |
| |
| |
| Modify section 9.2.1, "Framebuffer Object Parameters" to replace the |
| second and third paragraphs of the section, adding default and maximum |
| layer counts to FramebufferParameteri, on p. 206 and p. 207: |
| |
| When a framebuffer has one or more attachments, the width, height, layer |
| count (section 9.7gs), sample count, and sample location pattern of the |
| framebuffer are derived from the properties of the framebuffer |
| attachments. When the framebuffer has no attachments, these properties |
| are taken from framebuffer parameters. When <pname> is |
| FRAMEBUFFER_DEFAULT_WIDTH, FRAMEBUFFER_DEFAULT_HEIGHT, |
| FRAMEBUFFER_DEFAULT_LAYERS_EXT, FRAMEBUFFER_DEFAULT_SAMPLES, or |
| FRAMEBUFFER_DEFAULT_FIXED_SAMPLE_LOCATIONS, the value in <param> |
| specifies the width, height, layer count, sample count, or sample |
| location pattern, respectively, used when the framebuffer has no |
| attachments. |
| |
| When a framebuffer has no attachments, it is considered layered (section |
| 9.7gs) if and only if the value of FRAMEBUFFER_DEFAULT_LAYERS_EXT is |
| non-zero. It is considered to have sample buffers ... |
| |
| |
| Modify the error for invalid parameter values on p. 207 to add |
| layer counts: |
| |
| An INVALID_VALUE error is generated if <pname> is |
| FRAMEBUFFER_DEFAULT_WIDTH, FRAMEBUFFER_DEFAULT_HEIGHT, |
| FRAMEBUFFER_DEFAULT_LAYERS_EXT, or FRAMEBUFFER_DEFAULT_SAMPLES, and |
| <param> is either negative or greater than the value of the |
| corresponding implementation-dependent limits MAX_FRAMEBUFFER_WIDTH, |
| MAX_FRAMEBUFFER_HEIGHT, MAX_FRAMEBUFFER_LAYERS_EXT, or |
| MAX_FRAMEBUFFER_SAMPLES, respectively. |
| |
| |
| Replace the bullet list in section 9.2.2, "Attaching Images to |
| Framebuffer Objects" on p. 208: |
| |
| There are several types of framebuffer-attachable images: |
| |
| * The image of a renderbuffer object, which is always two-dimensional. |
| * A single level of a two-dimensional or two-dimensional multisample |
| texture. |
| * A single face of a cube map texture level, which is treated as a |
| two-dimensional image. |
| * A single layer of a two-dimensional array texture, two-dimensional |
| multidimensional array texture, or three-dimensional texture, which is |
| treated as a two-dimensional image. |
| |
| Additionally, an entire level of a three-dimensional, cube map, |
| two-dimensional array, or two-dimensional multisample array texture can |
| be attached to an attachment point. Such attachments are treated as an |
| array of two-dimensional images, arranged in layers, and the |
| corresponding attachment point is considered to be <layered> (also see |
| section 9.7gs) |
| |
| |
| Modify section 9.2.3, "Framebuffer Object Queries" |
| |
| In the description of GetFramebufferAttachmentParameteriv for texture |
| attachments, replace the bullet point for |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER on p. 210: |
| |
| * If <pname> is FRAMEBUFFER_ATTACHMENT_LAYERED_EXT then <params> will |
| contain TRUE if an entire level of a three-dimensional, cube map, |
| two-dimensional array, or two-dimensional multisample array texture is |
| attached. Otherwise, <params> will contain FALSE. |
| * If pname is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER; the value of |
| FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is the name of a three-dimensional, |
| or a two-dimensional array texture; and the value of |
| FRAMEBUFFER_ATTACHMENT_LAYERED_EXT is FALSE, then <params> will |
| contain the value of the texture layer which contains the attached |
| image. |
| |
| |
| Modify section 9.2.8, "Attaching Texture Images to a Framebuffer" on |
| p. 217: |
| |
| The GL supports copying the rendered contents of the framebuffer into |
| the images of a texture object through the use of the routines |
| CopyTexImage* and CopyTexSubImage*. Additionally, the GL supports |
| rendering directly into the images of a texture object. |
| |
| To render directly into a texture image, a specified level of a texture |
| object can be attached as one of the logical buffers of the currently |
| bound framebuffer object by calling |
| |
| void FramebufferTextureEXT(enum target, enum attachment, |
| uint texture, int level); |
| |
| <target> must be DRAW_FRAMEBUFFER, READ_FRAMEBUFFER, or FRAMEBUFFER. |
| FRAMEBUFFER is equivalent to DRAW_FRAMEBUFFER. <attachment> must be one |
| of the attachment points of the framebuffer listed in table 9.1. |
| |
| If <texture> is non-zero, the specified mipmap <level> of the texture |
| object named <texture> is attached to the framebuffer attachment point |
| named by <attachment>. |
| |
| If <texture> is the name of a three-dimensional texture, cube map |
| texture, two-dimensional array, or two-dimensional multisample array |
| texture, the texture level attached to the framebuffer attachment point |
| is an array of images, and the framebuffer attachment is considered |
| <layered>. |
| |
| Errors |
| |
| An INVALID_ENUM error is generated if <target> is not DRAW_FRAMEBUFFER, |
| READ_FRAMEBUFFER, or FRAMEBUFFER. |
| |
| An INVALID_ENUM error is generated if <attachment> is not one of the |
| attachments in table 9.1. |
| |
| An INVALID_OPERATION error is generated if zero is bound to <target>. |
| |
| An INVALID_VALUE error is generated if <texture> is not the name of a |
| texture object, or if <level> is not a supported texture level for |
| <texture>. |
| |
| An INVALID_OPERATION error is generated if <texture> is the name of a |
| buffer texture. |
| |
| |
| Additionally, a specified image from a texture object can be attached as |
| one of the logical buffers of a currently bound framebuffer object by |
| calling |
| |
| void FramebufferTexture2D |
| |
| ... |
| |
| The command |
| |
| void FramebufferTextureLayer(enum target, enum attachment, |
| uint texture, int level, int layer); |
| |
| operates similarly to FramebufferTexture2D, except that it attaches a |
| single layer of a three-dimensional, two-dimensional array, or |
| two-dimensional multisample array texture level. |
| |
| <target> and <attachment> are specified with the same values, and have |
| the same meanings as the corresponding arguments of |
| FramebufferTexture2D. |
| |
| <level> specifies the mipmap level of the texture image to be attached |
| to the framebuffer. |
| |
| If <texture> is a three-dimensional texture, then <level> must be |
| greater than or equal to zero and less than or equal to log2 of the |
| value of MAX_3D_TEXTURE_SIZE. If <texture> is a two-dimensional array |
| texture, then <level> must be greater than or equal to zero and no |
| larger than log2 of the value of MAX_TEXTURE_SIZE. If <texture> is a |
| two-dimensional multisample array texture, then <level> must be zero. |
| |
| <layer> specifies the layer of a two-dimensional image within <texture>. |
| |
| Unlike FramebufferTexture2D, no <textarget> parameter is accepted. |
| |
| If <texture> is non-zero and the command does not result in an error, |
| the framebuffer attachment state corresponding to <attachment> is |
| updated as in the other FramebufferTexture commands, except that the |
| value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is set to <layer>. |
| |
| Errors |
| |
| An INVALID_ENUM error is generated if <target> is not DRAW_FRAMEBUFFER, |
| READ_FRAMEBUFFER, or FRAMEBUFFER. |
| |
| An INVALID_ENUM error is generated if <attachment> is not one of the |
| attachments in table 9.1. |
| |
| An INVALID_VALUE error is generated if texture is non-zero and <level> |
| is not a supported texture level for <texture>, as described above. |
| |
| An INVALID_VALUE error is generated if <texture> is non-zero and <layer> |
| is larger than the value of MAX_3D_TEXTURE_SIZE minus one (for |
| three-dimensional textures), or larger than the value of |
| MAX_ARRAY_TEXTURE_LAYERS minus one (for array textures). |
| |
| An INVALID_VALUE error is generated if <texture> is non-zero and <layer> |
| is negative. |
| |
| An INVALID_OPERATION error is generated if <texture> is non-zero and is |
| not the name of a three dimensional, two-dimensional multisample array, |
| or two-dimensional array texture. |
| |
| |
| Modify section 9.2.8.1, "Effects of Attaching a Texture Image" to add |
| to the list of bullet points on p. 220: |
| |
| * If FramebufferTextureEXT is called and <texture> is the name of a |
| three-dimensional, cube map, two-dimensional multisample array, or |
| two-dimensional array texture, the value of |
| FRAMEBUFFER_ATTACHMENT_LAYERED_EXT is set to TRUE; otherwise it is set |
| to FALSE. |
| |
| |
| Modify section 9.4.1, "Framebuffer Completeness" to replace the bullet |
| point starting "If <image> is a three-dimensional texture" on p. 223: |
| |
| * If <image> is a three-dimensional texture or a two-dimensional array |
| texture and the attachment is not layered, the selected layer is less |
| than the depth or layer count, respectively, of the texture. |
| |
| * If <image> is a three-dimensional texture or a two-dimensional array |
| texture and the attachment is layered, the depth or layer count, |
| respectively, of the texture is less than or equal to the value of |
| MAX_FRAMEBUFFER_LAYERS_EXT. |
| |
| |
| Modify section 9.4.2 "Whole Framebuffer Completeness" to add to the list |
| of bullet points on p. 224: |
| |
| * If any framebuffer attachment is layered, all populated attachments |
| must be layered. Additionally, all populated color attachments must be |
| from textures of the same target (i.e., three-dimensional, cube map, |
| two-dimensional array, or two-dimensional multisample array textures). |
| |
| { FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT } |
| |
| |
| Add new section 9.7gs on p. 229, following existing section 9.7 |
| "Conversion to RGBA Values": |
| |
| Section 9.7gs Layered Framebuffers |
| |
| A framebuffer is considered to be layered if it is complete and all of |
| its populated attachments are layered. When rendering to a layered |
| framebuffer, each fragment generated by the GL is assigned a layer |
| number. The layer number for a fragment is zero if |
| |
| * geometry shaders are disabled, or |
| |
| * the current geometry shader does not statically assign a value to |
| the built-in output variable "gl_Layer". |
| |
| Otherwise, the layer for each point, line, or triangle emitted by the |
| geometry shader is taken from the "gl_Layer" output of one of the |
| vertices of the primitive. The vertex used is implementation-dependent |
| and may be queried as described in section 11.1gs.4. |
| To get defined results, all vertices of each primitive emitted should |
| set the same value for "gl_Layer". Since the "EndPrimitive" built-in |
| function starts a new output primitive, defined results can be achieved |
| if "EndPrimitive" is called between two vertices emitted with different |
| layer numbers. A layer number written by a geometry shader has no effect |
| if the framebuffer is not layered. |
| |
| When fragments are written to a layered framebuffer, the fragment's |
| layer number selects a single image from the array of images at each |
| attachment point to use for the stencil test (see section 4.1.4), depth |
| buffer test (see section 4.1.5), and for blending and color buffer |
| writes (see section 4.1.7). If the fragment's layer number is negative, |
| or greater than or equal to the minimum number of layers of any |
| attachment, the effects of the fragment on the framebuffer contents are |
| undefined. |
| |
| When the Clear or ClearBuffer* commands are used to clear a layered |
| framebuffer attachment, all layers of the attachment are cleared. |
| |
| When commands such as ReadPixels read from a layered framebuffer, the |
| image at layer zero of the selected attachment is always used to obtain |
| pixel values. |
| |
| When cube map texture levels are attached to a layered framebuffer, there |
| are six layers attached, numbered zero through five. Each layer number is |
| mapped to a cube map face, as indicated in table 8.25. |
| |
| |
| Modify section 10.1, "Primitive Types" to add new figure 10.X1 and new |
| sections 10.1.7la, 10.1.7lsa, 10.1.7ta, and 10.1.7tsa following section |
| 10.1.7, "Separate Triangles", on p. 234: |
| |
| |
| Section 10.1.7la Lines with Adjacency |
| |
| Add figure 10.X1: |
| |
| 1 - - - 2----->3 - - - 4 1 - - - 2--->3--->4--->5 - - - 6 |
| |
| 5 - - - 6----->7 - - - 8 |
| |
| (a) (b) |
| |
| Figure 10.X1 (a) Lines with adjacency, (b) Line strip with adjacency. |
| The vertices connected with solid lines belong to the main primitives; |
| the vertices connected by dashed lines are the adjacent vertices that |
| may be used in a geometry shader. |
| |
| Lines with adjacency are specified with <mode> LINES_ADJACENCY_EXT, and |
| are independent line segments where each endpoint has a corresponding |
| "adjacent" vertex that can be accessed by a geometry shader (see section |
| 11.1gs). If a geometry shader is not active, the "adjacent" vertices are |
| ignored. |
| |
| A line segment is drawn from the 4i + 2nd vertex to the 4i + 3rd vertex |
| for each i = 0, 1, ... , n-1, where there are 4n+k vertices passed. k is |
| either 0, 1, 2, or 3; if k is not zero, the final k vertices are |
| ignored. For line segment i, the 4i + 1st and 4i + 4th vertices are |
| considered adjacent to the 4i + 2nd and 4i + 3rd vertices, respectively. |
| See Figure 10.X1. |
| |
| |
| Section 10.1.7lsa Line Strips with Adjacency |
| |
| Line strips with adjacency are specified with <mode> |
| LINE_STRIP_ADJACENCY_EXT and are similar to line strips, except that |
| each line segment has a pair of adjacent vertices that can be accessed |
| by a geometry shader. If a geometry shader is not active, the "adjacent" |
| vertices are ignored. |
| |
| A line segment is drawn from the i + 2nd vertex to the i + 3rd vertex |
| for each i = 0, 1, ..., n-1, where there are n+3 vertices passed. If |
| there are fewer than four vertices, all vertices are ignored. For line |
| segment i, the i + 1st and i + 4th vertex are considered adjacent to the |
| i + 2nd and i + 3rd vertices, respectively. See Figure 10.X1. |
| |
| |
| Section 10.1.7ta Triangles with Adjacency |
| |
| Add new figure 10.X2: |
| |
| 2 - - - 3 - - - 4 8 - - - 9 - - - 10 |
| ^\ ^\ |
| \ | \ | \ | \ | |
| | \ | \ |
| \ | \ | \ | \ | |
| | \ | \ |
| \ | \ | \ | \ | |
| | v | v |
| 1<------5 7<------11 |
| |
| \ | \ | |
| |
| \ | \ | |
| |
| \ | \ | |
| |
| 6 12 |
| |
| Figure 10.X2 Triangles with adjacency. The vertices connected with solid |
| lines belong to the main primitive; the vertices connected by dashed |
| lines are the adjacent vertices that may be used in a geometry shader. |
| |
| |
| Triangles with adjacency are specified with <mode> TRIANGLES_ADJACENCY_EXT, |
| and are similar to separate triangles except that |
| each triangle edge has an adjacent vertex that can be accessed by a |
| geometry shader. If a geometry shader is not active, the |
| "adjacent" vertices are ignored. |
| |
| The 6i + 1st, 6i + 3rd, and 6i + 5th vertices (in that order) determine a |
| triangle for each i = 0, 1, ..., n-1, where there are 6n+k vertices |
| passed. k is either 0, 1, 2, 3, 4, or 5; if k is |
| non-zero, the final k vertices are ignored. For triangle i, the i + 2nd, |
| i + 4th, and i + 6th vertices are considered adjacent to edges from the i |
| + 1st to the i + 3rd, from the i + 3rd to the i + 5th, and from the i + |
| 5th to the i + 1st vertices, respectively. See Figure 10.X2. |
| |
| |
| Section 10.1.7 tsa Triangle Strips with Adjacency |
| |
| Add figure 10.X3: |
| |
| 6 6 |
| |
| | \ | \ |
| |
| | \ | \ |
| |
| | \ | \ |
| |
| 2 - - - 3- - - >6 2 - - - 3------>7 2 - - - 3------>7- - - 10 |
| ^\ ^^ | ^^ ^^ | |
| \ | \ | \ | \ | \ \ | \ | \ |
| | \ | \ | | \ | \ | |
| \ | \ | \ | \ | \ \ | \ | \ |
| | \ | \ | | \ | \ | |
| \ | \ | \ | \ | \ \ | \ | \ |
| | v | vv | vv v| |
| 1<------5 1<------5 - - - 8 1<------5<------9 |
| |
| \ | \ | \ | \ | |
| |
| \ | \ | \ | \ | |
| |
| \ | \ | \ | \ | |
| |
| 4 4 4 8 |
| |
| |
| 6 10 |
| |
| | \ | \ |
| |
| | \ | \ |
| |
| | \ | \ |
| 2 - - - 3------>7------>11 |
| ^^ ^^ | |
| \ | \ | \ | \ |
| | \ | \ | |
| \ | \ | \ | \ |
| | \ | \ | |
| \ | \ | \ | \ |
| | vv vv |
| 1<------5<------9 - - - 12 |
| |
| \ | \ | |
| |
| \ | \ | |
| |
| \ | \ | |
| |
| 4 8 |
| |
| Figure 10.X3 Triangle strips with adjacency. The vertices connected with |
| solid lines belong to the main primitives; the vertices connected by |
| dashed lines are the adjacent vertices that may be used in a geometry |
| shader. |
| |
| Triangle strips with adjacency are specified with <mode> |
| TRIANGLE_STRIP_ADJACENCY_EXT and are similar to triangle strips except that |
| each line triangle edge has an adjacent vertex that can be accessed by a |
| geometry shader (see section 11.1gs). If a geometry shader is not |
| active, the "adjacent" vertices are ignored. |
| |
| In triangle strips with adjacency, n triangles are drawn where there are |
| 2 * (n+2) + k vertices passed. k is either 0 or 1; if k is 1, the |
| final vertex is ignored. If there are fewer than 6 vertices, |
| the entire primitive is ignored. Table 10.X1 describes |
| the vertices and order used to draw each triangle, and which vertices are |
| considered adjacent to each edge of the triangle. See Figure 10.X3. |
| |
| |
| Add table 10.X1: |
| |
| primitive adjacent |
| vertices vertices |
| primitive 1st 2nd 3rd 1/2 2/3 3/1 |
| --------------- ---- ---- ---- ---- ---- ---- |
| only (i==0, n==1) 1 3 5 2 6 4 |
| first (i==0) 1 3 5 2 7 4 |
| middle (i odd) 2i+3 2i+1 2i+5 2i-1 2i+4 2i+7 |
| middle (i even) 2i+1 2i+3 2i+5 2i-1 2i+7 2i+4 |
| last (i==n-1, i odd) 2i+3 2i+1 2i+5 2i-1 2i+4 2i+6 |
| last (i==n-1, i even) 2i+1 2i+3 2i+5 2i-1 2i+6 2i+4 |
| |
| Table 10.X1: Triangles generated by triangle strips with adjacency. |
| Each triangle is drawn using the vertices in the "1st", "2nd", and "3rd" |
| columns under "primitive vertices", in that order. The vertices in the |
| "1/2", "2/3", and "3/1" columns under "adjacent vertices" are considered |
| adjacent to the edges from the first to the second, from the second to |
| the third, and from the third to the first vertex of the triangle, |
| respectively. The six rows correspond to the six cases: the first and |
| only triangle (i=0, n=1), the first triangle of several (i=0, n>0), |
| "odd" middle triangles (i=1,3,5...), "even" middle triangles |
| (i=2,4,6,...), and special cases for the last triangle, |
| when i is either even or odd. For the purposes of this |
| table, the first vertex passed is numbered "1" and the |
| first triangle is numbered "0". |
| |
| |
| Modify section 10.5, "Drawing Commands using Vertex Arrays" |
| |
| On p. 250 in the errors section for the DrawArraysIndirect command, |
| and on p. 254 in the errors section for the DrawElementsIndirect command, |
| delete the errors which state: |
| |
| "An INVALID_OPERATION error is generated if transform feedback is |
| active and not paused." |
| |
| (thus allowing transform feedback to work with indirect draw commands). |
| |
| |
| Modify section 11.1.2.1, "Output Variables" on p. 262, starting with the |
| second paragraph of the section: |
| |
| The OpenGL ES Shading Language specification also defines a |
| set of built-in outputs that vertex shaders can write to (see |
| section 7.1 ("Built-In Language Variables") of the OpenGL ES Shading |
| Language Specification). These output variables |
| are used to communicate values to the next active stage in the |
| vertex processing pipeline; either the geometry shader, or the |
| fixed-function vertex processing stages leading to rasterization. |
| |
| If the output variables are passed directly to the vertex processing |
| stages leading to rasterization, the values of all outputs are expected |
| to be interpolated across the primitive being rendered, unless |
| flatshaded. Otherwise the values of all outputs are collected by the |
| primitive assembly stage and passed on to the subsequent pipeline stage |
| once enough data for one primitive has been collected. |
| |
| The number of components (individual scalar numeric values) of output |
| variables that can be written by the vertex shader, whether or not a |
| geometry shader is active, is given by the value of the |
| implementation-dependent constant MAX_VERTEX_OUTPUT_COMPONENTS. |
| For the purposes of counting input and output components |
| consumed by a shader, variables declared as vectors, matrices, and |
| arrays will all consume multiple components. |
| |
| When a program is linked... |
| |
| Additionally, when linking a program containing only a vertex and |
| fragment shader, there is a limit on the total number of components... |
| |
| Each program object can specify a set of output variables from one |
| shader to be recorded in transform feedback mode (see section 12.1). |
| The variables that can be recorded are those emitted by the first active |
| shader, in order, from the following list: |
| |
| * geometry shader |
| * vertex shader |
| |
| The set of variables to record is specified with the command |
| |
| void TransformFeedbackVaryings ... |
| |
| |
| Modify starting with the list of TransformFeedbackVaryings link failures |
| on p. 263: |
| |
| ... A program will fail to link if: |
| |
| * the <count> specified by TransformFeedbackVaryings is non-zero, but |
| the program object has no vertex or geometry shader; |
| * any variable name specified in the <varyings> array is not declared as |
| a built-in or user-defined output variable in the shader stage whose |
| outputs can be recorded; |
| * any two entries in the <varyings> array specify the same output |
| variable; |
| * the total number of components to capture in any output in <varyings> |
| is greater than the value of |
| MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS and the buffer mode is |
| SEPARATE_ATTRIBS; or |
| * the total number of components to capture is greater than the value of |
| MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS and the buffer mode is |
| INTERLEAVED_ATTRIBS. |
| |
| When a program is linked ... |
| |
| |
| Modify section 11.1.3 "Shader Execution" |
| |
| Change the first paragraph of the section on p. 264: |
| |
| If there is an active program object present for the vertex or geometry |
| shader stages, the executable code for those active programs is used to |
| process incoming vertex values. The following sequence of operations is |
| performed: |
| |
| * Vertices are processed by the vertex shader (see section 11.1) and |
| assembled into primitives as described in sections 10.1 through 10.3. |
| * If the current program contains a geometry shader, each individual |
| primitive is processed by the geometry shader (see section 11.1gs). |
| Otherwise, primitives are passed through unmodified. If active, the |
| geometry shader consumes its input primitive. However, each geometry |
| shader invocation may emit new vertices, which are arranged into |
| primitives and passed to subsequent pipeline stages. |
| |
| Following shader execution, the fixed-function operations described in |
| chapter 12 are applied. |
| |
| Special considerations for ... |
| |
| |
| Rename section 11.1.3.1 "Shader Texturing" to "Shader Only Texturing" |
| on p. 264. |
| |
| |
| Modify the bullet list in section 11.1.3.5 "Texture Access" on p. 266 to |
| add a limit for geometry shaders: |
| |
| * MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT (for geometry shaders) |
| |
| |
| Modify the bullet list in section 11.1.3.6 "Atomic Counter Access" on p. |
| 268 to add a limit for geometry shaders: |
| |
| * MAX_GEOMETRY_ATOMIC_COUNTERS_EXT (for geometry shaders) |
| |
| |
| Modify the bullet list in section 11.1.3.7 "Image Access" on p. 268 to |
| add a limit for geometry shaders: |
| |
| * MAX_GEOMETRY_IMAGE_UNIFORMS_EXT (for geometry shaders) |
| |
| |
| Modify the bullet list in section 11.1.3.8 "Shader Storage Buffer |
| Access" on p. 268 to add a limit for geometry shaders: |
| |
| * MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_EXT (for geometry shaders) |
| |
| |
| |
| Modify section 11.1.3.11 "Validation" to add to the list of validation |
| errors on p. 270: |
| |
| * One program object is active for at least two shader stages and a |
| second program is active for a shader stage between two stages for |
| which the first program was active. |
| |
| * There is an active program for the geometry stage with corresponding |
| executable shader, but there is no active program with an executable |
| vertex shader. |
| |
| |
| Add new section 11.1gs, "Geometry Shaders" on p. 272, following |
| section 11.1, "Vertex Shaders" |
| |
| Section 11.1.gs Geometry Shaders |
| |
| After vertices are processed, they are arranged into primitives, as |
| described in section 10.1 (Primitive Types). This section describes |
| <geometry shaders>, an additional pipeline stage defining operations to |
| further process those primitives. Geometry shaders are defined by source |
| code in the OpenGL ES Shading Language, in the same manner as vertex |
| shaders. They operate on a single primitive at a time and emit one or |
| more output primitives, all of the same type, which are then processed |
| like an equivalent GL primitive specified by the application. The |
| original primitive is discarded after geometry shader execution. The |
| inputs available to a geometry shader are the transformed attributes of |
| all the vertices that belong to the primitive. Additional <adjacency |
| primitives> are available which also make the transformed attributes of |
| neighboring vertices available to the shader. The results of the shader |
| are a new set of transformed vertices, arranged into primitives by the |
| shader. |
| |
| The geometry shader pipeline stage is inserted after primitive assembly, |
| prior to transform feedback (see section 12.1), as discussed in section |
| 11.1.3. |
| |
| Geometry shaders are created as described in section 7.1 using a <type> |
| of GEOMETRY_SHADER_EXT. They are attached to and used in program objects |
| as described in section 7.3. When the program object currently in use |
| includes a geometry shader, its geometry shader is considered active, |
| and is used to process primitives. If the program object has no geometry |
| shader, this stage is bypassed. |
| |
| A non-separable program object or program pipeline object that includes |
| a geometry shader must also include a vertex shader. |
| |
| Errors |
| |
| An INVALID_OPERATION error is generated by any command that transfers |
| vertices to the GL if the current program state has a geometry shader |
| but no vertex shader. |
| |
| |
| Section 11.1gs.1, Geometry Shader Input Primitives |
| |
| A geometry shader can operate on one of five input primitive types. |
| Depending on the input primitive type, one to six input vertices are |
| available when the shader is executed. Each input primitive type |
| supports a subset of the primitives provided by the GL. |
| |
| An INVALID_OPERATION error is generated by any command that transfers |
| vertices to the GL if a geometry shader is active and the primitive |
| <mode> parameter is incompatible with the input primitive type of the |
| geometry shader of the active geometry program object, as discussed |
| below. |
| |
| A geometry shader that accesses more input vertices than are available |
| for a given input primitive type can be successfully compiled, because |
| the input primitive type is not part of the shader object. However, a |
| program object containing a shader object that accesses more input |
| vertices than are available for the input primitive type of the program |
| object will not link. |
| |
| The input primitive type is specified in the geometry shader source code |
| using an input layout qualifier, as described in the OpenGL ES Shading |
| Language Specification. A program will fail to link if the input |
| primitive type is not specified by the geometry shader object attached |
| to the program. The input primitive type may be queried by calling |
| GetProgramiv with the symbolic constant GEOMETRY_LINKED_INPUT_TYPE_EXT. |
| The supported types and the corresponding OpenGL ES Shading Language |
| input layout qualifier keywords are: |
| |
| Points (points) |
| |
| Geometry shaders that operate on points are valid only for the POINTS |
| primitive type. There is only a single vertex available for each |
| geometry shader invocation. |
| |
| Lines (lines) |
| |
| Geometry shaders that operate on line segments are valid only for the |
| LINES, LINE_STRIP, and LINE_LOOP primitive types. There are two vertices |
| available for each geometry shader invocation. The first vertex refers |
| to the vertex at the beginning of the line segment and the second vertex |
| refers to the vertex at the end of the line segment. See also section |
| 11.1gs.4. |
| |
| Lines with Adjacency (lines_adjacency) |
| |
| Geometry shaders that operate on line segments with adjacent vertices |
| are valid only for the LINES_ADJACENCY_EXT and LINE_STRIP_ADJACENCY_EXT |
| primitive types. There are four vertices available for each program |
| invocation. The second vertex refers to attributes of the vertex at the |
| beginning of the line segment and the third vertex refers to the vertex |
| at the end of the line segment. The first and fourth vertices refer to |
| the vertices adjacent to the beginning and end of the line segment, |
| respectively. |
| |
| Triangles (triangles) |
| |
| Geometry shaders that operate on triangles are valid for the TRIANGLES, |
| TRIANGLE_STRIP and TRIANGLE_FAN primitive types. There are three |
| vertices available for each program invocation. The first, second and |
| third vertices refer to attributes of the first, second and third vertex |
| of the triangle, respectively. |
| |
| Triangles with Adjacency (triangles_adjacency) |
| |
| Geometry shaders that operate on triangles with adjacent vertices are |
| valid for the TRIANGLES_ADJACENCY_EXT and TRIANGLE_STRIP_ADJACENCY_EXT |
| primitive types. There are six vertices available for each program |
| invocation. The first, third and fifth vertices refer to attributes of |
| the first, second and third vertex of the triangle, respectively. The |
| second, fourth and sixth vertices refer to attributes of the vertices |
| adjacent to the edges from the first to the second vertex, from the |
| second to the third vertex, and from the third to the first vertex, |
| respectively. |
| |
| |
| Section 11.1gs.2, Geometry Shader Output Primitives |
| |
| A geometry shader can generate primitives of one of three types. The |
| supported output primitive types are points (POINTS), line strips |
| (LINE_STRIP), and triangle strips (TRIANGLE_STRIP). The vertices output |
| by the geometry shader are assembled into points, lines, or triangles |
| based on the output primitive type in the manner described in section |
| 10.5. The resulting primitives are then further processed as described |
| in section 11.1gs.4. If the number of vertices emitted by the geometry |
| shader is not sufficient to produce a single primitive, nothing is |
| drawn. The number of vertices output by the geometry shader is limited |
| to a maximum count specified in the shader. |
| |
| The output primitive type and maximum output vertex count are specified |
| in the geometry shader source code using an output layout qualifier, as |
| described in section 4.4.2.gs ("Geometry Outputs") of the OpenGL ES |
| Shading Language Specification. A program will fail to link if either |
| the output primitive type or maximum output vertex count are not |
| specified by the geometry shader object attached to the program. The |
| output primitive type and maximum output vertex count of a linked |
| program may be queried by calling GetProgramiv with the symbolic |
| constants GEOMETRY_LINKED_OUTPUT_TYPE_EXT and |
| GEOMETRY_LINKED_VERTICES_OUT_EXT, respectively. |
| |
| |
| Section 11.1gs.3 Geometry Shader Variables |
| |
| Geometry shaders can access uniforms belonging to the current program |
| object. Limits on uniform storage and methods for manipulating uniforms |
| are described in section 7.6. |
| |
| Geometry shaders also have access to samplers to perform texturing |
| operations, as described in section 7.9. |
| |
| Geometry shaders can access the transformed attributes of all vertices |
| for their input primitive type using input variables. A vertex shader |
| writing to output variables generates the values of these input |
| variables. Values for any inputs that are not written by a vertex shader |
| are undefined. Additionally, a geometry shader has access to a built-in |
| variable that holds the ID of the current primitive. This ID is |
| generated by the primitive assembly stage that sits in between the |
| vertex and geometry shader. |
| |
| Additionally, geometry shaders can write to one or more output variables |
| for each vertex they output. These values are optionally flatshaded |
| (using the OpenGL ES Shading Language varying qualifier "flat") and |
| clipped, then the clipped values interpolated across the primitive (if |
| not flatshaded). The results of these interpolations are available to |
| the fragment shader. |
| |
| |
| Section 11.1gs.4, Geometry Shader Execution Environment |
| |
| If there is an active program for the geometry stage, the executable |
| version of the program's geometry shader is used to process primitives |
| resulting from the primitive assembly stage. |
| |
| There are several special considerations for geometry shader execution |
| described in the following sections. |
| |
| |
| Section 11.1gs.4.1 Texture Access |
| |
| Section 11.1.3.1 describes texture lookup functionality accessible to a |
| vertex shader. The texel fetch and texture size query functionality |
| described there also applies to geometry shaders. |
| |
| |
| Section 11.1gs.4.2 Instanced Geometry Shaders |
| |
| For each input primitive received by the geometry shader pipeline stage, |
| the geometry shader may be run once or multiple times. The number of |
| times a geometry shader should be executed for each input primitive may |
| be specified using a layout qualifier in a geometry shader of a linked |
| program. If the invocation count is not specified in any layout |
| qualifier, the invocation count will be one. |
| |
| Each separate geometry shader invocation is assigned a unique invocation |
| number. For a geometry shader with <N> invocations, each input primitive |
| spawns <N> invocations, numbered 0 through <N>-1. The built-in uniform |
| gl_InvocationID may be used by a geometry shader invocation to determine |
| its invocation number. |
| |
| When executing instanced geometry shaders, the output primitives |
| generated from each input primitive are passed to subsequent pipeline |
| stages using the shader invocation number to order the output. The first |
| primitives received by the subsequent pipeline stages are those emitted |
| by the shader invocation numbered zero, followed by those from the |
| shader invocation numbered one, and so forth. Additionally, all output |
| primitives generated from a given input primitive are passed to |
| subsequent pipeline stages before any output primitives generated from |
| subsequent input primitives. |
| |
| |
| Section 11.1gs.4.3 Geometry Shader Inputs |
| |
| Section 7.1 ("Built-In Language Variables") of the OpenGL ES Shading |
| Language Specification describes the built-in variable array gl_in[] |
| available as input to a geometry shader. gl_in[] receives values from |
| the equivalent built-in output variables written by the vertex shader. |
| Each array element of gl_in[] is a structure holding values for a |
| specific vertex of the input primitive. The length of gl_in[] is |
| determined by the geometry shader input type (see section 11.1gs.1). The |
| members of each element of the gl_in[] array are: |
| |
| [[ If EXT_geometry_point_size is supported: ]] |
| * structure member gl_PointSize holds the per-vertex point size written |
| by the previous shader to its built-in output variable gl_PointSize. |
| If the previous shader does not write gl_PointSize, the value of |
| gl_PointSize is undefined. |
| |
| * structure member gl_Position holds the per-vertex position, as written |
| by the previous shader to its built-in output variable gl_Position. |
| Note that writing to gl_Position from either the vertex or geometry |
| shader is optional (also see section 7.1 ("Built-In Language |
| Variables") of the OpenGL ES Shading Language Specification) |
| |
| Geometry shaders also have available the built-in input variable |
| gl_PrimitiveIDIn, which is not an array and has no vertex shader |
| equivalent. It is filled with the number of primitives processed by the |
| drawing command which generated the input vertices. The first primitive |
| generated by a drawing command is numbered zero, and the primitive ID |
| counter is incremented after every individual point, line, or triangle |
| primitive is processed. For triangles drawn in point or line mode, the |
| primitive ID counter is incremented only once, even though multiple |
| points or lines may eventually be drawn. The counter is reset to zero |
| between each instance drawn. Restarting a primitive topology using the |
| primitive restart index has no effect on the primitive ID counter. |
| |
| Similarly to the built-in inputs, each user-defined input has a value |
| for each vertex and thus needs needs to be declared as arrays or inside |
| input blocks declared as arrays. Declaring an array size is optional. If |
| no size is specified, it will be inferred by the linker from the input |
| primitive type. If a size is specified, it must match the number of |
| vertices for the input primitive type; otherwise a link error will |
| occur. The OpenGL ES Shading Language doesn't support multi-dimensional |
| arrays as shader inputs or outputs; therefore, user-defined geometry |
| shader inputs corresponding to vertex shader outputs declared as arrays |
| must be declared as array members of an input block that is itself |
| declared as an array. See section 4.3.6 ("Output Variables") of the |
| OpenGL ES Shading Language Specification for more information. |
| |
| Similarly to the limit on vertex shader output components (see section |
| 11.1.2.1), there is a limit on the number of components of input |
| variables that can be read by the geometry shader, given by the value of |
| the implementation-dependent constant MAX_GEOMETRY_INPUT_COMPONENTS_EXT. |
| |
| When a program is linked, all components of any input read by a geometry |
| shader will count against this limit. A program whose geometry shader |
| exceeds this limit may fail to link, unless device-dependent |
| optimizations are able to make the program fit within available hardware |
| resources. |
| |
| Component counting rules for different variable types and variable |
| declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see |
| section 11.1.2.1). |
| |
| |
| Section 11.1gs.4.4 Geometry Shader Outputs |
| |
| A geometry shader is limited in the number of vertices it may emit per |
| invocation. The maximum number of vertices a geometry shader can |
| possibly emit is specified in the geometry shader source and may be |
| queried after linking by calling GetProgramiv with the symbolic constant |
| GEOMETRY_LINKED_VERTICES_OUT_EXT. If a single invocation of a geometry |
| shader emits more vertices than this value, the emitted vertices may |
| have no effect. |
| |
| There are two implementation-dependent limits on the value of |
| GEOMETRY_LINKED_VERTICES_OUT_EXT; it may not exceed the value of |
| MAX_GEOMETRY_OUTPUT_VERTICES_EXT, and the product of the total number of |
| vertices and the sum of all components of all active output variables |
| may not exceed the value of MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_EXT. |
| LinkProgram will fail if it determines that the total component limit |
| would be violated. |
| |
| A geometry shader can write to built-in as well as user-defined output |
| variables. These values are expected to be interpolated across the |
| primitive it outputs, unless they are specified to be flatshaded. To |
| enable seamlessly inserting or removing a geometry shader from a program |
| object, the rules, names and types of the built-in and user-defined |
| output variables are the same as for the vertex shader. Refer to section |
| 11.1.2.1, and to sections 4.3.6 ("Output Variables") and 7.1 ("Built-In |
| Language Variables") of the the OpenGL ES Shading Language Specification |
| for more detail. |
| |
| After a geometry shader emits a vertex, all output variables are |
| undefined, as described in section 8.12gs ("Geometry Shader Functions") |
| of the OpenGL Shading Language Specification. |
| |
| The built-in output gl_Position is intended to hold the homogeneous |
| vertex position. Writing gl_Position is optional. |
| |
| [[ If EXT_geometry_point_size is supported: ]] |
| The built-in output gl_PointSize, if written, holds the size of the |
| point to be rasterized, measured in pixels. |
| |
| The built-in output gl_PrimitiveID holds the primitive ID counter read |
| by the fragment shader, replacing the value of gl_PrimitiveID generated |
| by drawing commands when no geometry shader is active. The geometry |
| shader must write to gl_PrimitiveID for the provoking vertex (see |
| section 12.3) of a primitive being generated, or the primitive ID |
| counter read by the fragment shader for that primitive is undefined. |
| |
| The built-in output gl_Layer is used in layered rendering, and discussed |
| further in the next section. |
| |
| Similarly to the limit on vertex shader output components (see section |
| 11.1.2.1), there is a limit on the number of components of output |
| variables that can be written by the geometry shader, given by the value |
| of the implementation-dependent constant |
| MAX_GEOMETRY_OUTPUT_COMPONENTS_EXT. |
| |
| When a program is linked, all components of any output variable written |
| by a geometry shader will count against this limit. A program whose |
| geometry shader exceeds this limit may fail to link, unless |
| device-dependent optimizations are able to make the program fit within |
| available hardware resources. |
| |
| Component counting rules for different variable types and variable |
| declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS. (see |
| section 11.1.2.1). |
| |
| |
| Section 11.1gs.4.5 Layer Selection |
| |
| Geometry shaders can be used to render to one of several different |
| layers of cube map textures, three-dimensional textures, or |
| two-dimensional texture arrays. This functionality allows an application |
| to bind an entire complex texture to a framebuffer object, and render |
| primitives to arbitrary layers computed at run time. For example, this |
| mechanism can be used to project and render a scene onto all six faces |
| of a cube map texture in one pass. The layer to render to is specified |
| by writing to the built-in output variable "gl_Layer". Layered rendering |
| requires the use of framebuffer objects (see section 9.7gs). |
| |
| The specific vertex of a primitive that is used to select the rendering |
| layer is implementation-dependent and thus portable applications will |
| assign the same layer for all vertices in a primitive. The vertex |
| convention followed for "gl_Layer" may be determined by calling |
| GetIntegerv with the symbolic constant LAYER_PROVOKING_VERTEX_EXT. If |
| the value returned is FIRST_VERTEX_CONVENTION_EXT, selection is always |
| taken from the first vertex of a primitive. If the value returned is |
| LAST_VERTEX_CONVENTION_EXT, the selection is always taken from the last |
| vertex of a primitive. If the value returned is UNDEFINED_VERTEX_EXT, |
| the selection is not guaranteed to be taken from any specific vertex in |
| the primitive. The vertex considered the provoking vertex for particular |
| primitive types is given in table 12.2. |
| |
| |
| Section 11.1gs.4.6 Primitive Type Mismatches and Drawing Commands |
| |
| An INVALID_OPERATION error is generated by any command that transfers |
| vertices to the GL, and no fragments will be rendered, if a mismatch |
| exists between the type of primitive being drawn and the input primitive |
| type of a geometry shader. A mismatch exists under any of the following |
| conditions: |
| |
| * the input primitive type of the current geometry shader is |
| POINTS and <mode> is not POINTS, |
| |
| * the input primitive type of the current geometry shader is |
| LINES and <mode> is not LINES, LINE_STRIP, or LINE_LOOP, |
| |
| * the input primitive type of the current geometry shader is |
| TRIANGLES and <mode> is not TRIANGLES, TRIANGLE_STRIP or |
| TRIANGLE_FAN, |
| |
| * the input primitive type of the current geometry shader is |
| LINES_ADJACENCY_EXT and <mode> is not LINES_ADJACENCY_EXT or |
| LINE_STRIP_ADJACENCY_EXT, or |
| |
| * the input primitive type of the current geometry shader is |
| TRIANGLES_ADJACENCY_EXT and <mode> is not |
| TRIANGLES_ADJACENCY_EXT or TRIANGLE_STRIP_ADJACENCY_EXT. |
| |
| |
| Modify section 12.1, "Transform Feedback" |
| |
| Replace the second paragraph of the section on p. 274: |
| |
| The data captured in transform feedback mode depends on the active |
| programs on each of the shader stages. If a program is active for the |
| geometry shader stage, transform feedback captures the vertices of each |
| primitive emitted by the geometry shader. Otherwise, transform feedback |
| captures each primitive processed by the vertex shader. |
| |
| |
| Modify the second paragraph following ResumeTransformFeedback on p. 277 |
| |
| When transform feedback is active and not paused, all geometric |
| primitives generated must be compatible with the value of |
| <primitiveMode> passed to BeginTransformFeedback. If a geometry shader |
| is active, the type of primitive emitted by that shader is used instead |
| of the <mode> parameter passed to drawing commands for the purposes of |
| this error check. Any primitive type may be used while transform |
| feedback is paused. |
| |
| Add table 12.1gs: |
| |
| Transform Feedback Allowed render primitive |
| <primitiveMode> <modes> |
| -------------------+---------------------------------------- |
| POINTS | POINTS |
| LINES | LINES, LINE_LOOP, LINE_STRIP |
| TRIANGLES | TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN |
| ------------------------------------------------------------ |
| Table 12.1gs: Legal combinations of the transform feedback |
| primitive mode, as passed to BeginTransformFeedback, and the |
| current primitive mode. |
| |
| |
| In the Errors section, replace "An INVALID_OPERATION error is generate |
| by DrawArrays and DrawArraysInstanced if <mode> is not identical to |
| <primitiveMode>" with: |
| |
| An INVALID_OPERATION error is generated by any command that transfers |
| vertices to the GL if <mode> is not one of the allowed modes in table |
| 12.1gs. |
| |
| and delete the error condition which states: |
| |
| An INVALID_OPERATION error is generated by any drawing commands other |
| than DrawArrays and DrawArraysInstanced while transform feedback is |
| active and not paused, regardless of mode. |
| |
| Modify the last sentence of the second paragraph on p. 278: |
| |
| When writing output variables that are arrays ... The value for any |
| output variable specified to be streamed to a buffer object but not |
| actually written by a vertex or geometry shader is undefined. The |
| results of appending an output variable to a transform feedback buffer |
| are undefined if any component of that variable would be written at an |
| offset not aligned to the size of the component. |
| |
| |
| Modify the sixth paragraph on p. 278: |
| |
| In INTERLEAVED_ATTRIBS mode, the values of one or more output variables |
| written by a vertex or geometry shader are written, interleaved, ... |
| |
| |
| Modify the eighth paragraph on p. 278, describing errors on buffer |
| overflow: |
| |
| |
| The error INVALID_OPERATION ... as set by BindBufferRange. No vertices |
| of that primitive are recorded in any buffer object, and the counter |
| corresponding to the asynchronous query target |
| TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN (see section 12.2) is not |
| incremented. |
| |
| |
| Modify the second paragraph on p. 280: |
| |
| When BeginTransformFeedback is called with an active program object |
| containing a vertex or geometry shader, the set of output variables |
| captured ... |
| |
| |
| Replace section 12.2, "Primitive Queries" on p. 281: |
| |
| Primitive queries use query objects to track the number of primitives |
| that are generated by the GL and the number of primitives that are |
| written to buffer objects in transform feedback mode. |
| |
| When BeginQuery is called with a target of PRIMITIVES_GENERATED_EXT, the |
| primitives generated count maintained by the GL is set to zero. When a |
| generated primitive query is active, the primitives-generated count is |
| incremented every time an emitted primitive reaches the transform |
| feedback stage (see section 12.1), whether or not transform feedback is |
| active. This counter counts the number of primitives emitted by a |
| geometry shader, if active, possibly further tessellated into separate |
| primitives during the transform feedback stage, if active. |
| |
| When BeginQuery is called with a target of |
| TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN, the transform feedback primitives |
| written count maintained by the GL is set to zero. When the transform |
| feedback primitive written query is active, the transform feedback |
| primitives written count is incremented every time the vertices of a |
| primitive are recorded into a buffer object. If transform feedback is |
| not active or if a primitive to be recorded does not fit in a buffer |
| object, this counter is not incremented. |
| |
| These two types of queries can be used together to determine if all |
| primitives have been written to the bound feedback buffer; if both |
| queries are run simultaneously and the query results are equal, all |
| primitives have been written to the buffer. If the number of primitives |
| written is less than the number of primitives generated, the buffer |
| overflowed. |
| |
| |
| Modify section 12.5 "Coordinate Transformations" on p. 283: |
| |
| <Clip coordinates> for a vertex result from shader execution, which |
| yields ... |
| |
| |
| Modify section 13.3, "Points" |
| |
| Replace the second paragraph starting "The point size..." on p. 290: |
| |
| The point size is determined by the last active stage before the |
| rasterizer: |
| |
| * the geometry shader, if active; or |
| * the vertex shader, otherwise. |
| |
| If the last active stage is not a vertex shader and does not statically |
| assign a value to gl_PointSize, the point size is 1.0. Otherwise, the |
| point size is taken from the shader built-in gl_PointSize written by |
| that stage. |
| [[ Note that it is impossible to assign a value to gl_PointSize if |
| EXT_geometry_point_size is not supported and enabled in the |
| geometry shader stage. ]] |
| |
| If the last active stage is a vertex shader, the point size is taken |
| from the shader built-in gl_PointSize written by the vertex shader. |
| |
| In all cases, the point size is clamped to the implementation-dependent |
| point size range. If the value written to gl_PointSize is less than or |
| equal to zero, or if no value is written to gl_PointSize (except as |
| noted above) the point size is undefined. The supported range ... |
| |
| |
| Modify section 14.2.2, "Shader Inputs" |
| |
| Add a new paragraph following the paragraph starting "The built-in |
| variable gl_FrontFacing" on p. 305: |
| |
| If a geometry shader is active, the built-in variable gl_PrimitiveID |
| contains the ID value emitted by the geometry shader for the provoking |
| vertex. If no geometry shader is active, gl_PrimitiveID contains the |
| number of primitives processed by the rasterizer since the last drawing |
| command was called. The first primitive generated by a drawing command |
| is numbered zero, and the primitive ID counter is incremented after |
| every individual point, line, or polygon primitive is processed. |
| The counter is reset to zero between each instance drawn. |
| |
| Restarting a primitive using the primitive restart index (see section |
| 10.3.4) has no effect on the primitive ID counter. |
| |
| gl_PrimitiveID is only defined under the same conditions that |
| gl_VertexID is defined, as described under "Shader Inputs" in section |
| 11.1.3.9. |
| |
| Similarly to the limit on geometry shader output components (see section |
| 11.1gs.4), there is a limit on the number of components of built-in and |
| user-defined input variables that can be read by the fragment shader, |
| given by the value of the implementation-dependent constant |
| MAX_FRAGMENT_INPUT_COMPONENTS. |
| |
| When a program is linked ... |
| |
| |
| Modify section 16.2.1, "Blitting Pixel Rectangles" to add following the |
| paragraph starting "When values are written to the draw buffers" on p. |
| 337: |
| |
| If the read framebuffer is layered (see section 9.7gs), pixel values are |
| read from layer zero. If the draw framebuffer is layered, pixel values |
| are written to layer zero. If both read and draw framebuffers are |
| layered, the blit operation is still performed only on layer zero. |
| |
| |
| Modify the first sentence of chapter 17, "Compute Shaders" on p. 340: |
| |
| In addition to graphics-oriented shading operations such as vertex, |
| geometry, and fragment shading, generic computation ... |
| |
| |
| Dependencies on OES_sample_variables |
| |
| If OES_sample_variables is not supported, references to |
| the extension edits should be ignored. |
| |
| Dependencies on OES_texture_storage_multisample_2d_array |
| |
| If OES_texture_storage_multisample_2d_array is not supported, references |
| to two-dimensional multisample array textures should be ignored. |
| |
| Dependencies on OES_shader_multisample_interpolation |
| |
| If OES_shader_multisample_interpolation is not supported, references |
| to "sample in", "sample out" and the extension should be ignored. |
| |
| Dependencies on EXT_texture_buffer |
| |
| If EXT_texture_buffer is not supported, references to |
| buffer textures should be removed. |
| |
| New State |
| |
| Add to table 20.14, "Framebuffer (state per framebuffer object)": |
| Initial |
| Get Value Type Get Command Value Description Sec. |
| ------------------------------ ---- ------------------------- ------- ------------------------ ----- |
| FRAMEBUFFER_DEFAULT_LAYERS_EXT Z+ GetFramebufferParameteriv 0 default layer count of 9.2.1 |
| framebuffer w/o |
| attachments |
| |
| Add to table 20.15, "Framebuffer (state per attachment point)": |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. |
| ---------------------------------------- ---- ----------------------------------- ------- ---------------------- ------- |
| FRAMEBUFFER_ATTACHMENT_LAYERED_EXT B GetFramebufferAttachmentParameteriv FALSE Framebuffer attachment 9.2.8.1 |
| is layered |
| |
| Modify description of SHADER_TYPE in table 20.18, "Shader Object State": |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. |
| ----------- ---- ----------- ------- ----------------------------- ---- |
| SHADER_TYPE E GetShaderiv - Type of shader (shader stage) 7.1 |
| |
| Add to table 20.19, "Program Pipeline Object State": |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. |
| ------------------ ---- -------------------- ------- ------------------------ ---- |
| GEOMETRY_SHADER_EXT Z+ GetProgramPipelineiv 0 Name of current geometry 7.4 |
| shader program object |
| |
| |
| Add to table 20.22, "Program Object State (cont.)": |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. |
| ------------------------- ---- ------------ -------------- ------------------------ -------- |
| GEOMETRY_LINKED_VERTICES_OUT_EXT Z+ GetProgramiv 0 Max.# of output vertices 11.1gs.4 |
| GEOMETRY_LINKED_INPUT_TYPE_EXT E GetProgramiv TRIANGLES Primitive input type 11.1gs.1 |
| GEOMETRY_LINKED_OUTPUT_TYPE_EXT E GetProgramiv TRIANGLE_STRIP Primitive output type 11.1gs.2 |
| GEOMETRY_SHADER_INVOCATIONS_EXT Z+ GetProgramiv 1 # of times a geom. shader 7.12 |
| should be executed for |
| each input primitive |
| |
| Add to table 20.28, "Program Object Resource State (cont.)": |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. |
| --------------------------------- ---- -------------------- ------- ----------------------- ----- |
| REFERENCED_BY_GEOMETRY_SHADER_EXT Z+ GetProgramResourceiv - active resource used by 7.3.1 |
| geometry shader |
| |
| |
| Rename table 20.29, "Vertex Shader State (not part of program objects)" |
| to "Vertex and Geometry Shader State (not part of program objects)". |
| |
| |
| New Implementation Dependent State |
| |
| Add to table 20.40, "Implementation-Dependent Values (cont.)": |
| |
| Get Value Type Get Command Minimum Value Description Sec. |
| -------------------------- ---- ----------- ------------- -------------------------- -------- |
| MAX_FRAMEBUFFER_LAYERS_EXT Z+ GetIntegerv 256 maximum layer count for 9.2.1 |
| layered framebuffer object |
| LAYER_PROVOKING_VERTEX_EXT E GetIntegerv -- (*) vertex convention followed 11.1gs.4 |
| by the gl_Layer GLSL |
| variable |
| |
| Add new footnote: |
| (*) Note: Valid values are FIRST_VERTEX_CONVENTION_EXT, |
| LAST_VERTEX_CONVENTION_EXT, and UNDEFINED_VERTEX_EXT. |
| |
| |
| |
| Add new table 20.43gs "Implementation Dependent Geometry Shader Limits" |
| following table 20.43 "Implementation Dependent Vertex Shader Limits": |
| |
| Min. |
| Get Value Type Get Command Value Description Sec. |
| ---------------------------------------- ---- ----------- ----- ----------------------- -------- |
| MAX_GEOMETRY_UNIFORM_COMPONENTS_EXT Z+ GetIntegerv 1024 Number of comp. for 11.1gs.3 |
| geom. shader uniform |
| variables |
| MAX_GEOMETRY_UNIFORM_BLOCKS_EXT Z+ GetIntegerv 12 Max number of geom. 7.6.2 |
| uniform buffers per |
| program |
| MAX_GEOMETRY_INPUT_COMPONENTS_EXT Z+ GetIntegerv 64 Max number of comp. 11.1gs.4 |
| of inputs read by a |
| geom. shader |
| MAX_GEOMETRY_OUTPUT_COMPONENTS_EXT Z+ GetIntegerv 64 Max number of comp. 11.1gs.4 |
| of outputs written |
| by a geom. shader |
| MAX_GEOMETRY_OUTPUT_VERTICES_EXT Z+ GetIntegerv 256 Max number of vertices 11.1gs.4 |
| that any geom. shader |
| can emit |
| MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_EXT Z+ GetIntegerv 1024 Max number of total 11.1gs.4 |
| comp. (all vertices) of |
| active outputs that a |
| geom. shader can emit |
| MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT Z+ GetIntegerv 16 Number of texture 11.1.3.5 |
| image units accessible |
| by a geom. shader |
| MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_EXT Z+ GetIntegerv 0 Number of atom. counter 7.7 |
| buffers accessed |
| by a geom. shader |
| MAX_GEOMETRY_ATOMIC_COUNTERS_EXT Z+ GetIntegerv 0 Number of atomic 11.1.3.6 |
| counters accessed by a |
| geom. shader |
| MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_EXT Z+ GetIntegerv 0 Num. of shader storage 7.8 |
| blocks accessed by a |
| geom. shader |
| MAX_GEOMETRY_SHADER_INVOCATIONS_EXT Z+ GetIntegerv 32 Max supported geom. 11.1gs.4 |
| shader invocation count |
| |
| |
| |
| Add to table 20.46 "Implementation Dependent Aggregate Shader Limits" |
| ([fn] is a dagger mark referring to existing text in the table caption): |
| |
| Minimum |
| Get Value Type Get Command Value Description Sec. |
| -------------------------------------------- ---- ----------- -------- ------------------------- -------- |
| MAX_GEOMETRY_IMAGE_UNIFORMS_EXT Z+ GetIntegerv 0 Number of image variables 11.1.3.7 |
| in geometry shaders |
| MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS_EXT Z+ GetIntegerv [fn] No. of words for geom. 7.6.2 |
| shader uniform vars. in |
| all uniform blocks |
| (including default) |
| |
| Modify existing entries in table 20.46: |
| |
| Minimum |
| Get Value Type Get Command Value Description Sec. |
| -------------------------------------------- ---- ----------- -------- ------------------------- -------- |
| MAX_UNIFORM_BUFFER_BINDINGS Z+ GetIntegerv 48 Max no. of uniform buf. 7.6.2 |
| binding points |
| MAX_COMBINED_UNIFORM_BLOCKS Z+ GetIntegerv 36 Max. no. of uniform 7.6.2 |
| buffers per program |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS Z+ GetIntegerv 64 Total no. of tex. units 11.1.3.5 |
| accessible by the GL |
| |
| Additions to the OpenGL ES Shading Language 3.10 Specification |
| |
| Including the following line in a shader can be used to control the |
| language features described in this extension: |
| |
| #extension GL_EXT_geometry_shader : <behavior> |
| #extension GL_EXT_geometry_point_size : <behaviour> |
| |
| where <behavior> is as specified in section 3.4. |
| |
| A new preprocessor #define is added to the OpenGL ES Shading Language: |
| |
| #define GL_EXT_geometry_shader 1 |
| #define GL_EXT_geometry_point_size 1 |
| |
| If the EXT_geometry_shader extension is enabled, the |
| EXT_shader_io_blocks extension is also implicitly enabled. |
| |
| |
| Change the introduction to Chapter 2 "Overview of OpenGL ES Shading" as |
| follows: |
| |
| The OpenGL ES Shading Language is actually several closely related |
| languages. These languages are used to create shaders for each of the |
| programmable processors contained in the OpenGL ES processing pipeline. |
| Currently, these processors are the compute, vertex, geometry, and |
| fragment processors. |
| |
| Unless otherwise noted in this Specification, a language feature applies |
| to all languages, and common usage will refer to these languages as a |
| single language. The specific languages will be referred to by the name |
| of the processor they target: compute, vertex, geometry, or fragment. |
| |
| |
| Add new subsection 2.gs preceding subsection 2.2 "Fragment Processor": |
| |
| Section 2.gs, Geometry Processor |
| |
| The <geometry processor> is a programmable unit that operates on data |
| for incoming vertices for a primitive assembled after vertex processing |
| and outputs a sequence of vertices forming output primitives. |
| Compilation units written in the OpenGL ES Shading Language to run on |
| this processor are called <geometry shaders>. When a geometry shader is |
| compiled and linked, it results in a <geometry shader executable> that |
| runs on the geometry processor. |
| |
| A single invocation of the geometry shader executable on the geometry |
| processor will operate on a declared input primitive with a fixed number |
| of vertices. This single invocation can emit a variable number of |
| vertices that are assembled into primitives of a declared output |
| primitive type and passed to subsequent pipeline stages. |
| |
| |
| Modify section 4.3.4 "Input Variables", adding following the paragraph |
| starting "It is expected that ... columns in the matrix" on p. 40: |
| |
| Geometry shader input variables get the per-vertex values written out by |
| output variables of the same names in the previous active (vertex) |
| shader stage. For these inputs, "centroid in", "sample in", and |
| interpolation qualifiers are allowed, but are equivalent to "in". Since |
| geometry shaders operate on a set of vertices, each input variable or |
| input block (see section 4.3.9 "Interface Blocks") needs to be declared |
| as an array. For example, |
| |
| in float foo[]; // geometry shader input for vertex "out float foo" |
| |
| Each element of such an array corresponds to one vertex of the primitive |
| being processed. Each array can optionally have a size declared. The |
| array size will be set by (or if provided must be consistent with) the |
| input layout declaration(s) establishing the type of input primitive, as |
| described later in section 4.4.1 "Input Layout Qualifiers". |
| |
| Some inputs and outputs are <arrayed>, meaning that for an interface |
| between two shader stages either the input or output declaration |
| requires an extra level of array indexing for the declarations to match. |
| For example, with the interface between a vertex shader and a geometry |
| shader, vertex shader output variables and geometry shader input |
| variables of the same name must match in type and qualification (other |
| than precision and "out" matching to "in"), except that the geometry |
| shader will have one more array dimension than the vertex shader, to |
| allow for vertex indexing. If such an arrayed interface variable is not |
| declared with the necessary additional input or output array dimension, |
| a link-time error will result. |
| |
| For non-arrayed interfaces (meaning array dimensionally stays the same |
| between stages), it is a link-time error if the input variable is not |
| declared with the same type, including array dimensionality, and |
| qualification (other than precision and "out" matching to "in") as the |
| matching output variable. |
| |
| Fragment shader inputs get per-fragment values... |
| |
| |
| Modify section 4.3.6 "Output Variables" starting with the third |
| paragraph of the section, as modified by |
| OES_shader_multisample_interpolation, on p. 42: |
| |
| Vertex and geometry output variables output per-vertex data and are |
| declared using the "out", "centroid out", or "sample out" storage |
| qualifiers. ... |
| |
| Individual vertex and geometry outputs are declared as in the following |
| examples: ... |
| |
| ... |
| flat out vec3 myColor; |
| sample out vec4 perSampleColor; |
| |
| These can also appear in interface blocks, as described in section 4.3.9 |
| "Interface Blocks". Interface blocks allow simpler addition of arrays to |
| the interface from vertex to geometry shader. They also allow a fragment |
| shader to have the same input interface as a geometry shader for a given |
| vertex shader. |
| |
| Fragment outputs output per-fragment data ... |
| |
| |
| Modify section 4.3.9 "Interface Blocks" as modified by |
| EXT_shader_io_blocks, to add following the paragraph starting "When |
| using OpenGL ES API entry points to identify the name": |
| |
| Geometry shader input blocks must be declared as arrays and follow the |
| array declaration and linking rules for all geometry shader inputs. All |
| other input and output block arrays must specify an array size. |
| |
| |
| Modify section 4.4.1 "Input Layout Qualifiers" as modified |
| by EXT_shader_io_blocks: |
| |
| Insert a new section 4.4.1.gs, before section 4.4.1.fs: |
| |
| Section 4.4.1.gs, Geometry Shader Inputs |
| |
| Additional layout qualifier identifiers for geometry shader inputs |
| include primitive identifiers and an invocation count identifier: |
| |
| <layout-qualifier-id> |
| points |
| lines |
| lines_adjacency |
| triangles |
| triangles_adjacency |
| invocations = integer-constant |
| |
| The identifiers points, lines, lines_adjacency, triangles, and |
| triangles_adjacency are used to specify the type of input primitive |
| accepted by the geometry shader, and only one of these is accepted. The |
| geometry shader object in a program must declare this input primitive |
| layout, and all geometry shader input layout declarations in a program |
| must declare the same layout. |
| |
| The identifier invocations is used to specify the number of times the |
| geometry shader executable is invoked for each input primitive received. |
| Invocation count declarations are optional. If no invocation count is |
| declared in any geometry shader in a program, the geometry shader will |
| be run once for each input primitive. If an invocation count is |
| declared, all such declarations must specify the same count. If a shader |
| specifies an invocation count greater than the implementation-dependent |
| maximum, it will fail to compile. |
| |
| For example, |
| |
| layout(triangles, invocations = 6) in; |
| |
| will establish that all inputs to the geometry shader are triangles and |
| that the geometry shader executable is run six times for each triangle |
| processed. |
| |
| All geometry shader input unsized array declarations will be sized by an |
| earlier input primitive layout qualifier, when present, as per the |
| following table. |
| |
| Layout Size of Input Arrays |
| ------------------- -------------------- |
| points 1 |
| lines 2 |
| lines_adjacency 4 |
| triangles 3 |
| triangles_adjacency 6 |
| |
| The intrinsically declared input array gl_in[] will also be sized by any |
| input primitive-layout declaration. Hence, the expression |
| |
| gl_in.length() |
| |
| will return the value from the table above. |
| |
| For inputs declared without an array size, including intrinsically |
| declared inputs (i.e., gl_in), a layout must be declared before any use |
| of the method length or other any array use that requires the array size |
| to be known. |
| |
| It is a compile-time error if a layout declaration's array size (from |
| table above) does not match all the explicit array sizes specified in |
| declarations of an input variables in the same shader. The following |
| includes examples of compile-time errors: |
| |
| // code sequence within one shader... |
| in vec4 Color1[]; // legal, size still unknown |
| in vec4 Color2[2]; // legal, size is 2 |
| in vec4 Color3[3]; // illegal, input sizes are inconsistent |
| layout(lines) in; // legal for Color2, input size is 2, matching Color2 |
| in vec4 Color4[3]; // illegal, contradicts layout of lines |
| layout(lines) in; // legal, matches other layout() declaration |
| layout(triangles) in; // illegal, does not match earlier layout() declaration |
| |
| It is a link-time error if not all provided sizes (sized input arrays |
| and layout size) match in the geometry shader of a program. |
| |
| |
| Add new section 4.4.2.gs before section 4.4.2.fs, as added by |
| EXT_shader_io_blocks: |
| |
| |
| Section 4.4.2.gs Geometry Outputs |
| |
| Geometry shaders can have two additional types of output layout |
| identifiers: an output primitive type and a maximum output vertex count. |
| The primitive type and vertex count identifiers are allowed only on the |
| interface qualifier out, not on an output block, block member, or |
| variable declaration. |
| |
| The layout qualifier identifiers for geometry shader outputs are |
| |
| layout-qualifier-id |
| points |
| line_strip |
| triangle_strip |
| max_vertices = integer-constant |
| |
| The primitive type identifiers points, line_strip, and triangle_strip |
| are used to specify the type of output primitive produced by the |
| geometry shader, and only one of these is accepted. The geometry shader |
| object in a program must declare an output primitive type, and all |
| geometry shader output primitive type declarations in a program must |
| declare the same primitive type. |
| |
| The vertex count identifier max_vertices is used to specify the maximum |
| number of vertices the shader will ever emit in a single invocation. The |
| geometry shader object in a program must declare a maximum output vertex |
| count, and all geometry shader output vertex count declarations in a |
| program must declare the same count. |
| |
| In this example, |
| |
| layout(triangle_strip, max_vertices = 60) out; // order does not matter |
| layout(max_vertices = 60) out; // redeclaration okay |
| layout(triangle_strip) out; // redeclaration okay |
| layout(points) out; // error, contradicts triangle_strip |
| layout(max_vertices = 30) out; // error, contradicts 60 |
| |
| all outputs from the geometry shader are triangles and at most 60 |
| vertices will be emitted by the shader. It is an error for the maximum |
| number of vertices to be greater than gl_MaxGeometryOutputVertices. |
| |
| All geometry shader output layout declarations in a program must declare |
| the same layout and same value for max_vertices. If geometry shaders are |
| in a program, there must be at least one geometry output layout |
| declaration somewhere in that program. |
| |
| |
| Modify section 4.7.4, "Default Precision Qualifiers": |
| |
| Modify the third paragraph on p. 64: |
| |
| "All languages except for the fragment language have the following |
| predeclared globally scoped default precision statements: ..." |
| |
| |
| Add new section 7.1.1gs following section 7.1.1 "Vertex Shader Special |
| Variables": |
| |
| Section 7.1.1gs, Geometry Shader Special Variables |
| |
| In the geometry language, the built-in variables are intrinsically |
| declared as: |
| |
| [[ If EXT_geometry_point_size is supported and enabled: ]] |
| in gl_PerVertex { |
| highp vec4 gl_Position; |
| highp float gl_PointSize; |
| } gl_in[]; |
| |
| [[ Otherwise: ]] |
| in gl_PerVertex { |
| highp vec4 gl_Position; |
| } gl_in[]; |
| |
| in highp int gl_PrimitiveIDIn; |
| in highp int gl_InvocationID; |
| |
| [[ If EXT_geometry_point_size is supported and enabled: ]] |
| out gl_PerVertex { |
| highp vec4 gl_Position; |
| highp float gl_PointSize; |
| }; |
| |
| [[ Otherwise: ]] |
| out gl_PerVertex { |
| highp vec4 gl_Position; |
| }; |
| |
| out highp int gl_PrimitiveID; |
| out highp int gl_Layer; |
| |
| |
| Section 7.1.1gs.1, Geometry Shader Input Variables |
| |
| gl_Position contains the output written in the previous shader stage to |
| gl_Position. |
| |
| [[ If EXT_geometry_point_size is supported: ]] |
| gl_PointSize contains the output written in the previous shader stage to |
| gl_PointSize. |
| |
| gl_PrimitiveIDIn contains the number of primitives processed by the |
| shader since the current set of rendering primitives was started. |
| |
| gl_InvocationID contains the invocation number assigned to the geometry |
| shader invocation. It is assigned integer values in the range [0, N-1], |
| where N is the number of geometry shader invocations per primitive. |
| |
| |
| Section 7.1.1gs.2, Geometry Shader Output Variables |
| |
| gl_Position is used in the same fashion as the corresponding output |
| variable in the vertex shader. Its value is undefined after geometry |
| processing if the shader calls EmitVertex() without having written |
| gl_Position since the last EmitVertex(), or does not write it at all. |
| |
| [[ If EXT_geometry_point_size is supported: ]] |
| gl_PointSize is used in the same fashion as the corresponding output |
| variable in the vertex shader. |
| |
| gl_PrimitiveID is filled with a single integer that serves as a |
| primitive identifier to the fragment shader. This is then available to |
| fragment shaders, which will select the written primitive ID from the |
| provoking vertex of the primitive being shaded. If a fragment shader |
| using gl_PrimitiveID is active and a geometry shader is also active, the |
| geometry shader must write to gl_PrimitiveID or the fragment shader |
| input gl_PrimitiveID is undefined. See section 11.1gs.4 "Geometry Shader |
| Outputs" of the OpenGL ES Specification for more information. |
| |
| gl_Layer is used to select a specific layer (or face and layer of a cube |
| map) of a multi-layer framebuffer attachment. The actual layer used will |
| come from one of the vertices in the primitive being shaded. Which |
| vertex the layer comes from is determined as discussed in section |
| 11.1gs.4 of the OpenGL ES Specification but may be undefined, so it is |
| best to write the same layer value for all vertices of a primitive. If a |
| shader statically assigns a value to gl_Layer, layered rendering mode is |
| enabled. See section 11.1gs.4 "Geometry Shader Outputs"and section 9.7gs |
| "Layered Framebuffers" of the OpenGL ES Specification for more |
| information. If a shader statically assigns a value to gl_Layer, and |
| there is an execution path through the shader that does not set |
| gl_Layer, then the value of gl_Layer is undefined for executions of the |
| shader that take that path. |
| |
| |
| Modify section 7.1.2 "Fragment Shader Special Variables", as modified by |
| OES_sample_variables: |
| |
| Add to the list of built-in variables: |
| |
| in highp int gl_PrimitiveID; |
| in highp int gl_Layer; |
| |
| Add descriptions of these variables: |
| |
| The input variable gl_PrimitiveID is filled with the value written to |
| the gl_PrimitiveID geometry shader output, if a geometry shader is |
| present. Otherwise, it is filled with the number of primitives processed |
| by the shader since the current set of rendering primitives was started. |
| |
| The input variable gl_Layer is filled with the value written to the |
| gl_Layer geometry shader output, if a geometry shader is present. If the |
| geometry stage does not dynamically assign a value to gl_Layer, the |
| value of gl_Layer in the fragment stage will be undefined. If the |
| geometry stage makes no static assignment to gl_Layer, the input value |
| in the fragment stage will be zero. Otherwise, the fragment stage will |
| read the same value written by the geometry stage, even if that value is |
| out of range. If a fragment shader contains a static access to gl_Layer, |
| it will count against the implementation defined limit for the maximum |
| number of inputs to the fragment stage. |
| |
| Modify the description of gl_FrontFacing: |
| |
| The input variable gl_FrontFacing is true if the fragment belongs to a |
| front-facing primitive. One use of this is to emulate two-sided lighting |
| by selecting one of two colors calculated by a vertex or geometry |
| shader. |
| |
| |
| Add to Section 7.2 "Built-In Constants", matching the |
| corresponding API implementation-dependent limits: |
| |
| const mediump int gl_MaxGeometryInputComponents = 64; |
| const mediump int gl_MaxGeometryOutputComponents = 128; |
| const mediump int gl_MaxGeometryImageUniforms = 0; |
| const mediump int gl_MaxGeometryTextureImageUnits = 16; |
| const mediump int gl_MaxGeometryOutputVertices = 256; |
| const mediump int gl_MaxGeometryTotalOutputComponents = 1024; |
| const mediump int gl_MaxGeometryUniformComponents = 1024; |
| const mediump int gl_MaxGeometryAtomicCounters = 0; |
| const mediump int gl_MaxGeometryAtomicCounterBuffers = 0; |
| |
| Modify gl_MaxCombinedTextureImageUnits to match the API: |
| |
| const mediump int gl_MaxCombinedTextureImageUnits = 64; |
| |
| |
| Add new section 8.12gs preceding section 8.13 "Fragment Processing |
| Functions": |
| |
| Section 8.12gs, Geometry Shader Functions |
| |
| These functions are only available in geometry shaders. They are |
| described in more depth following the table. |
| |
| Syntax Description |
| ------------------- ----------------------------------------------- |
| void EmitVertex() Emits the current values of output variables to |
| the current output primitive. On return from |
| this call, the values of output variables are |
| undefined. |
| void EndPrimitive() Completes the current output primitive and |
| starts a new one. No vertex is emitted. |
| |
| The function EmitVertex() specifies that a vertex is completed. A vertex |
| is added to the current output primitive using the current values of all |
| built-in and user-defined output variables. The values of all output |
| variables are undefined after a call to EmitVertex(). If a geometry |
| shader invocation has emitted more vertices than permitted by the output |
| layout qualifier max_vertices, the results of calling EmitVertex() are |
| undefined. |
| |
| The function EndPrimitive() specifies that the current output primitive |
| is completed and a new output primitive (of the same type) will be |
| started by any subsequent EmitVertex(). This function does not emit a |
| vertex. If the output layout is declared to be "points", calling |
| EndPrimitive() is optional. |
| |
| A geometry shader starts with an output primitive containing no |
| vertices. When a geometry shader terminates, the current output |
| primitive is automatically completed. It is not necessary to call |
| EndPrimitive() if the geometry shader writes only a single primitive. |
| |
| |
| Modify section 8.16, "Shader Memory Control Functions" to change the |
| paragraph starting "When these functions return..." on p. 139: |
| |
| When these functions return ... the execution of the original shader |
| invocation (e.g., fragment shader invocations for a primitive resulting |
| from a particular vertex or geometry shader invocation). |
| |
| Issues |
| |
| Note: These issues apply specifically to the definition of the |
| EXT_geometry_shader specification, which is based on the OpenGL |
| extension ARB_geometry_shader4 as updated in OpenGL 4.x. Resolved issues |
| from ARB_geometry_shader4 have been removed, but remain largely |
| applicable to this extension. ARB_geometry_shader4 can be found in the |
| OpenGL Registry. |
| |
| (1) What functionality was removed from ARB_geometry_shader4 / GL 4.4? |
| |
| - Interactions with features not supported by the underlying |
| ES 3.1 API and Shading Language, including: |
| * one-dimensional, rectangular, and cube map array textures (cube |
| map array textures are restored in EXT_texture_cube_map_array). |
| * vertex program point size mode |
| * viewport arrays and other support for multiple viewports |
| * multiple vertex streams (these require ARB_transform_feedback3) |
| * gl_ClipDistance shader inputs and outputs. |
| * CopyPixels and Bitmap |
| * fixed-functionality vertex and fragment shader stages |
| * "component" layout |
| * Implicit references to glPolygonMode |
| * References allowing or assuming more than one shader object per |
| pipeline stage. |
| - FramebufferTexture3D (use FramebufferTextureLayer instead). |
| - gl_MaxGeometryVaryingComponents |
| - gl_VerticesIn |
| - FramebufferTextureFaceARB (also removed from GL core) |
| - The FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_EXT completeness condition, |
| also removed from desktop GL. |
| - Description of limitations of GeForce series 8 chips. |
| - GLSL two-dimensional arrays (already supported by GLSL-ES 3.10 in a |
| more general fashion). Note that while multi-dimensional arrays are |
| supported, they are explicitly not supported as shader inputs and |
| outputs, and that decision is respected here. |
| - multiple compilation units of the same shader type. |
| |
| (2) What functionality was changed and added relative to |
| ARB_geometry_shader4 and GL 4.4? |
| |
| - EXT_geometry_shader closely matches OpenGL 4.4 geometry shader |
| language, rather than ARB_geometry_shader language. |
| - In particular, input and output interface blocks were added from GL |
| 4.4 / GLSL 4.40, via the required EXT_shader_io_blocks extension. |
| - Interactions were added with OpenGL ES 3.1 functionality including |
| separate shader objects, shader atomic counters, shader storage |
| buffer objects, and shader image load/store. |
| - Geometry instancing was added from ARB_gpu_shader5. |
| - FRAMEBUFFER_DEFAULT_LAYERS_EXT and MAX_FRAMEBUFFER_LAYERS_EXT state |
| and related spec language from ARB_framebuffer_no_attachments (it |
| was removed from OpenGL ES 3.1). |
| - PRIMITIVES_GENERATED_EXT query from OpenGL 3.0, to count primitives |
| due to geometry amplification by geometry shaders. |
| - LAYER_PROVOKING_VERTEX_EXT query from ARB_provoking_vertex / |
| ARB_viewport_array (but did not add ProvokingVertex control, just |
| this query). |
| - Specify undefined behavior when appending outputs to XFB buffers if |
| any component would be written at a misaligned offset, from |
| ARB_enhanced_layouts. Bug 11191 is tracking this into ES 3.1, as |
| it's not specific to geometry shaders. |
| - Writing point size from geometry shaders is optional functionality. |
| If it's not supported or written, the point size of 1.0 is used. |
| - Added precision qualifiers to builtins. |
| - Clarification from Bug 11508. |
| - Added program interface query properties relevant to geometry |
| shaders. |
| |
| (3) Should GetActiveUniformBlockiv support queries for uniform blocks |
| and atomic counter buffers referenced by geometry shaders? |
| |
| RESOLVED: No. Use the new generic program interface query supported by |
| OpenGL ES 3.1, following the behavior of features added to 3.1 such as |
| compute shaders, which also dropped these legacy tokens / queries. |
| |
| (4) How are aggregate shader limits computed? |
| |
| RESOLVED: Following the GL 4.4 model, but we restrict uniform |
| buffer bindings to 12/stage instead of 14, this results in |
| |
| MAX_UNIFORM_BUFFER_BINDINGS = 48 |
| This is 12 bindings/stage * 4 shader stages, allowing a static |
| partitioning of the bindings even though at most 5 stages can |
| appear in a program object). |
| MAX_COMBINED_UNIFORM_BLOCKS = 36 |
| This is 12 blocks/stage * 3 stages, since compute shaders can't |
| be mixed with other stages. |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS = 64 |
| This is 16 textures/stage * 4 stages. |
| |
| Khronos internal bugs 5870, 8891, and 9424 cover the ARB's thinking on |
| these limits for GL 4.0 and beyond. |
| |
| (5) Are arrays supported as shader inputs and outputs? |
| |
| RESOLVED: No. In several places in the tessellation and geometry API |
| language based on GL 4.4, it says that "the OpenGL ES Shading Language |
| doesn't support multi-dimensional arrays" and restricts declarations of |
| inputs and outputs which are array members to blocks themselves declared |
| as arrays. |
| |
| Strictly speaking this is no longer true. GLSL-ES 3.10 supports |
| multi-dimensional arrays, but arrays of |
| arrays are not allowed as shader inputs or outputs. |
| |
| Given this constraint, and since the same constraint is in OpenGL 4.4, |
| I've resolved this by continuing to limit array inputs and outputs |
| in this fashion, and change the language to "...doesn't support |
| multi-dimensional arrays as shader inputs or outputs". |
| |
| (6) What component counting rules are used for inputs and outputs? |
| |
| RESOLVED: In several places I've inserted language from OpenGL 4.4 to |
| the effect of |
| |
| "Component counting rules for different variable types and variable |
| declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see |
| section 11.1.2.1)." |
| |
| I think this is essentially cleaning up an oversight in the earlier ARB |
| extension language but it is a bit orthogonal to the extension |
| functionality and I'm bringing it up in case this is a potential issue. |
| |
| (7) What component counting rules are used for the default |
| uniform block? |
| |
| RESOLVED: In several places I've inserted language from OpenGL 4.2 to |
| the effect of |
| |
| "A uniform matrix in the default uniform block with single-precision |
| components will consume no more than 4 x min(r,c) uniform |
| components." |
| |
| This is based on bug 5432 and is language that was later expanded in |
| OpenGL 4.4 and refactored into the generic "Uniform Variables" section, |
| which is something we should consider in the EXT extensions as well to |
| avoid duplication. I believe it is what we want but am noting it for the |
| same reason as the language in issue (7). I'm hoping to be able to |
| include this refactored language into the OpenGL ES 3.1 Specification, |
| so we can refer to it more easily here. Tracking bug 11192 has been |
| opened for this and this language was approved there. |
| |
| (8) What should the minimum value of MAX_GEOMETRY_UNIFORM_COMPONENTS_EXT |
| be? |
| |
| RESOLVED: GL 4.4 has 512, but we use 1024 to match the ES vertex |
| shader limit. |
| |
| (9) What should the minimum value of MAX_GEOMETRY_OUTPUT_COMPONENTS_EXT |
| be? |
| |
| RESOLVED: This was reduced to 64 in revision 20, from an initial value |
| of 128 (matching GL 4.4), to match the limits on vertex shader outputs |
| and fragment shader inputs (Bug 12823). |
| |
| (10) What naming and token values should we use for |
| GEOMETRY_VERTICES_OUT_EXT, GEOMETRY_INPUT_TYPE_EXT, and |
| GEOMETRY_OUTPUT_TYPE_EXT? |
| |
| DISCUSSION: In EXT_geometry_shader4 and ARB_geometry_shader4, the |
| vertice and input and output type are specified by a program parameter |
| state. OpenGL 3.2 requires this to be provided in the shader text and |
| provided a query for these values after linking. Since this was a |
| functionality change the similarly named enumerants were given different |
| values. Thus we have the following token names and enumerants in GL: |
| |
| (from EXT_geometry_shader4) |
| GEOMETRY_VERTICES_OUT_EXT 0x8DDA |
| GEOMETRY_INPUT_TYPE_EXT 0x8DDB |
| GEOMETRY_OUTPUT_TYPE_EXT 0x8DDC |
| |
| (from ARB_geometry_shader4) |
| GEOMETRY_VERTICES_OUT_ARB 0x8DDA |
| GEOMETRY_INPUT_TYPE_ARB 0x8DDB |
| GEOMETRY_OUTPUT_TYPE_ARB 0x8DDC |
| |
| (from OpenGL 3.2) |
| GEOMETRY_VERTICES_OUT 0x8916 |
| GEOMETRY_INPUT_TYPE 0x8917 |
| GEOMETRY_OUTPUT_TYPE 0x8918 |
| |
| Now for this extensions we are providing the GL 3.2-type functionality |
| and thus we should use the token *values* from GL core. However, |
| it is expected that this extension will ship as an EXT, so we would |
| end up with: |
| GEOMETRY_VERTICES_OUT_EXT 0x8916 |
| GEOMETRY_INPUT_TYPE_EXT 0x8917 |
| GEOMETRY_OUTPUT_TYPE_EXT 0x8918 |
| which gives us the same token names as the EXT_geometry_shader4 but |
| the same token values as OpenGL 3.2. This would potentially be |
| quite confusing if headers are mix and matched. |
| |
| OPTIONS: If this extension ships as an EXT, |
| a) invent a new suffix. Ideally we'd have a different EXT-like suffix |
| to disambiguate between GL and ES multivendor extensions. However this |
| has not happened yet. |
| b) we use a _VENDOR suffix for these 3 enumerants to disambiguate them |
| c) change the tokens to GEOMETRY_LINKED_*_EXT, with the expectation that |
| we'd rename them back if this becomes core functionality. |
| |
| RESOLVED. Pick c). We will include the "_LINKED" term in the tokens |
| to indicate that they represent the values generated at link time. At |
| such a time as this becomes core functionality in ES, they should |
| be renamed back to be the same as the GL tokens (possibly with an |
| alias for compatibility with this extension). |
| |
| (11) How should we handle the enablement of input/output blocks in |
| non-geometry stages? |
| |
| RESOLVED: Early drafts of this extension added a number |
| of capabilities that were not specific to geometry shaders, namely: |
| * allowed the declaration and use of input and output blocks |
| * moved the built-in "per-vertex" in/out variables into the |
| built-in gl_PerVertex block |
| * allowed the redeclaration of the gl_PerVertex block. |
| |
| In OpenGL these capabilities are provided by the GLSL 1.50 version. |
| Furthermore, when separable programs are in use, OpenGL *requires* |
| that the gl_PerVertex block be declared in any shader which uses any of |
| its members (including vertex and fragment shaders). |
| |
| Since this capability is being added as an extension to OpenGL ES 3.1 |
| we don't have a core shading language version to hang this feature |
| off of and thus we need an extension to enable this. |
| |
| Using the earlier drafts, we would have needed to use the |
| EXT_geometry_shader #extension in vertex or fragment shaders to enable |
| this functionality. Since this was rather unintuitive and this |
| functionality does have utility on it's own, we opted instead to pull |
| this out to a separate extension that is a required dependency |
| (EXT_shader_io_blocks). |
| |
| The geometry (and tessellation) extensions will automatically imply |
| that the EXT_shader_io_blocks functionality is enabled, since it is |
| impossible to use them in a useful manner without accessing |
| gl_PerVertex input/output blocks. |
| |
| (12) Due to HW limitations, some vendors may not be able |
| to support writing gl_PointSize from geometry shaders, how should we |
| accomodate this? |
| |
| RESOLVED: There are two extensions described in this document. The |
| base extension does not support writing to gl_PointSize from geometry |
| shaders and the gl_PerVertex block does not include gl_PointSize. |
| Additionally there is a layered extension which provides the ability |
| to write to gl_PointSize from geometry shaders. When this extension |
| is enabled, the gl_PerVertex block does include gl_PointSize and it |
| can be written from geometry shaders as normal. |
| |
| If the point-size extension is not supported, all points written |
| from a geometry shader will have size of one. If the point-size |
| extension is supported but not enabled, or if it's enabled but |
| gl_PointSize is not written, it as if a point size of one was written. |
| Otherwise, if you statically assign gl_PointSize in the last stage |
| before the rasterizer, the (potentially clamped) value written will |
| determine the size of the point for rasterization. |
| |
| (13) Does this extension change how transform feedback operates |
| compared to unextended OpenGL ES 3.0 or 3.1? |
| |
| RESOLVED: Yes. Because dynamic geometry amplification in a geometry |
| shader can make it difficult if not impossible to predict the amount |
| of geometry that may be generated in advance of executing the shader, |
| the draw-time error for transform feedback buffer overflow conditions |
| is removed and replaced with the GL behavior (primitives are not written |
| and the corresponding counter is not updated). Since we no longer |
| require being able to predict how much geometry will be generated, we |
| also lift the restriction that only DrawArray* commands are supported |
| and also support the DrawElements* commands for transform feedback. |
| We also allow Draw*Indirect to be used with transform feedback. |
| |
| (14) Should GetShaderPrecisionFormat support the new GEOMETRY_SHADER_EXT |
| stage? |
| |
| RESOLVED: No. Following the precedence of OpenGL ES 3.1 which did not |
| extend this query to COMPUTE_SHADERS due to the following reason: |
| GetShaderPrecisionFormat is listed in ES 3.0 appendix F.1 Legacy Features |
| whose use is not recommended. Adding new capabilities to a feature that |
| is effectively deprecated seems silly (Bug 11464). |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- --------- ------------------------------------------------- |
| 21 05/31/16 Jon Leech Note that primitive ID counters are reset to zero |
| after each instance drawn (Bug 14024). |
| 20 07/23/15 Jon Leech Reduce minimum value of |
| MAX_GEOMETRY_OUTPUT_COMPONENTS_EXT to 64 (Bug |
| 12823). |
| 19 10/08/14 dkoch change max_vertices identifier to integer-constant |
| to match rest of ES layout-qualifier-id's |
| (Bug 12878) |
| 18 04/23/14 dkoch Add GetProgramPipelineiv to the list of functions |
| which accept GEOMETRY_SHADER token. Add issue 14. |
| (Bug 12152) |
| 17 03/28/14 Jon Leech Sync with released ES 3.1 specs. Reflow text and |
| remove irrelevant footnote to table 20.40. |
| 16 03/26/14 dkoch Update contributors, update issue 14 and |
| allow XFB with draw indirect. |
| 15 03/10/14 Jon Leech Rebase on OpenGL ES 3.1 and change suffix to EXT. |
| Remove material now in the 3.1 spec and fix up |
| references between API and GLSL specs. |
| 14 02/27/14 dkoch Fix typo in issue 14. |
| 13 02/18/14 dkoch Resolve issues 5, 9, 10. |
| Resolve issue 11, by adding _LINKED to the |
| affected tokens. |
| Clarify XFB error relaxations and add issue 14 |
| explaining the difference from ES 3.0. |
| 12 02/12/14 dkoch Correct some entry points/token acceptance. |
| Explicitly delete error condition for non-arrayed |
| drawing commands with transform feedback. |
| 11 01/16/14 dkoch Clarification from Bug 11508 |
| Remove mention of multiple compilation units. |
| 10 12/19/13 dkoch Move input and output interface block and |
| related functionality to separate extension. |
| Rewrote / renumbered the issues. |
| Added missing enum. |
| Add geometry point size extension. |
| Added precision qualifiers to builtins. |
| Remove duplicated edits to Shader Memory Access |
| |
| 9 12/02/13 dkoch Add Issues 11-14 |
| |
| 8 11/21/13 dkoch Minor updates |
| - Remove DSA commands |
| - update MAX_FRAMEBUFFER_LAYERS_EXT to match MAX_ARRAY_TEXTURES (256) |
| |
| 7 11/20/13 Jon Leech Minor updates |
| - Sync with ES 3.1 spec language update. |
| - Refer to ES 3.1 instead of ES 3plus. |
| |
| 6 11/14/13 Jon Leech Minor updates |
| - Incorporate language tweak on output variables from bug 11100 |
| |
| 5 11/08/13 Jon Leech Minor updates |
| - Incorporate language tweak from bug 11102. |
| |
| 4 11/08/13 Jon Leech Minor updates |
| - Remove FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT (token and |
| language is already in ES 3.0). |
| - Reorganize errors for commands completely described in this |
| specification into separate "Errors" subsections like GL 4.4. |
| - Add complete set of error conditions for FramebufferTextureEXT. |
| |
| 3 11/06/13 Jon Leech Updates based on Daniel Koch's feedback |
| - Remove references from desktop language allowing multiple shader |
| objects per stage. |
| - Clean up typos identified by Daniel. |
| - Disallow multi-dimensional arrays as shader inputs & outputs, |
| consistent with ES 3.1 multidimensional arrays and geometry_shader |
| issue 7. |
| - Drop implicit reference to nonexistent glPolygonMode in section |
| 3.4. |
| - Drop FramebufferTexture3D in favor of FramebufferTextureLayer. |
| - Add trivial interactions with compute shaders. |
| - Drop gl_MaxGeometryVaryingComponents constant. |
| - Added FRAMEBUFFER_DEFAULT_LAYERS_EXT and |
| MAX_FRAMEBUFFER_LAYERS_EXT state, and related spec language from |
| ARB_framebuffer_no_attachments (it was removed from |
| ES 3.1). |
| - Added PRIMITIVES_GENERATED_EXT query from GL 3.0. |
| - Added LAYER_PROVOKING_VERTEX_EXT query from ARB_provoking_vertex / |
| ARB_viewport_array. |
| - Dropped reference to cube map array texture layer selection, this |
| will go in EXT_texture_cube_map_array. |
| |
| 2 11/03/13 Jon Leech |
| - Revisions based on NVIDIA feedback and first draft of |
| EXT_tessellation_shader. |
| - Rearrange descriptions of built-in variables in chapter 7 GLSL-ES |
| language. |
| - Fix minor inconsistencies and descriptions relative to GL 4.2/4.4 |
| and EXT_tessellation_shader. |
| - Expand Issues list with open issues. |
| |
| 1 10/20/13 Jon Leech Initial version based on ARB_geometry_shader4. |