| Name |
| |
| EXT_geometry_shader4 |
| |
| Name String |
| |
| GL_EXT_geometry_shader4 |
| |
| Contact |
| |
| Pat Brown, NVIDIA (pbrown 'at' nvidia.com) |
| Barthold Lichtenbelt, NVIDIA (blichtenbelt 'at' nvidia.com) |
| |
| Status |
| |
| Multi-vendor extension |
| |
| Shipping for GeForce 8 Series (November 2006) |
| |
| Version |
| |
| Last Modified Date: 12/14/2009 |
| NVIDIA Revision: 22 |
| |
| Number |
| |
| 324 |
| |
| Dependencies |
| |
| OpenGL 1.1 is required. |
| |
| This extension is written against the OpenGL 2.0 specification. |
| |
| EXT_framebuffer_object interacts with this extension. |
| |
| EXT_framebuffer_blit interacts with this extension. |
| |
| EXT_texture_array interacts with this extension. |
| |
| ARB_texture_rectangle trivially affects the definition of this |
| extension. |
| |
| EXT_texture_buffer_object trivially affects the definition of this |
| extension. |
| |
| NV_primitive_restart trivially affects the definition of this |
| extension. |
| |
| This extension interacts with EXT_tranform_feedback. |
| |
| Overview |
| |
| EXT_geometry_shader4 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, flat shading 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 OpenGL primitive |
| specified by the application. |
| |
| Furthermore, EXT_geometry_shader4 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 |
| Begin() time, if a primitive mode of TRIANGLES is specified. |
| |
| New Procedures and Functions |
| |
| void ProgramParameteriEXT(uint program, enum pname, int value); |
| void FramebufferTextureEXT(enum target, enum attachment, |
| uint texture, int level); |
| void FramebufferTextureLayerEXT(enum target, enum attachment, |
| uint texture, int level, int layer); |
| void FramebufferTextureFaceEXT(enum target, enum attachment, |
| uint texture, int level, enum face); |
| |
| New Tokens |
| |
| Accepted by the <type> parameter of CreateShader and returned by the |
| <params> parameter of GetShaderiv: |
| |
| GEOMETRY_SHADER_EXT 0x8DD9 |
| |
| Accepted by the <pname> parameter of ProgramParameteriEXT and |
| GetProgramiv: |
| |
| GEOMETRY_VERTICES_OUT_EXT 0x8DDA |
| GEOMETRY_INPUT_TYPE_EXT 0x8DDB |
| GEOMETRY_OUTPUT_TYPE_EXT 0x8DDC |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT 0x8C29 |
| MAX_GEOMETRY_VARYING_COMPONENTS_EXT 0x8DDD |
| MAX_VERTEX_VARYING_COMPONENTS_EXT 0x8DDE |
| MAX_VARYING_COMPONENTS_EXT 0x8B4B |
| MAX_GEOMETRY_UNIFORM_COMPONENTS_EXT 0x8DDF |
| MAX_GEOMETRY_OUTPUT_VERTICES_EXT 0x8DE0 |
| MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_EXT 0x8DE1 |
| |
| Accepted by the <mode> parameter of Begin, DrawArrays, |
| MultiDrawArrays, DrawElements, MultiDrawElements, and |
| DrawRangeElements: |
| |
| LINES_ADJACENCY_EXT 0xA |
| LINE_STRIP_ADJACENCY_EXT 0xB |
| TRIANGLES_ADJACENCY_EXT 0xC |
| TRIANGLE_STRIP_ADJACENCY_EXT 0xD |
| |
| Returned by CheckFramebufferStatusEXT: |
| |
| FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT 0x8DA8 |
| FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_EXT 0x8DA9 |
| |
| Accepted by the <pname> parameter of GetFramebufferAttachment- |
| ParameterivEXT: |
| |
| FRAMEBUFFER_ATTACHMENT_LAYERED_EXT 0x8DA7 |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4 |
| |
| Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, |
| and by the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev, |
| and GetBooleanv: |
| |
| PROGRAM_POINT_SIZE_EXT 0x8642 |
| |
| (Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is simply an alias for the |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in |
| EXT_framebuffer_object. This extension generalizes the notion of |
| "<zoffset>" to include layers of an array texture.) |
| |
| (Note: PROGRAM_POINT_SIZE_EXT is simply an alias for the |
| VERTEX_PROGRAM_POINT_SIZE token provided in OpenGL 2.0, which is itself an |
| alias for VERTEX_PROGRAM_POINT_SIZE_ARB provided by |
| ARB_vertex_program. Program-computed point sizes can be enabled if |
| geometry shaders are enabled.) |
| |
| Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL |
| Operation) |
| |
| Modify Section 2.6.1 (Begin and End Objects), p. 13 |
| |
| (Add to end of section, p. 18) |
| |
| (add figure on discussions of lines and line strips with adjacency) |
| |
| 1 - - - 2----->3 - - - 4 1 - - - 2--->3--->4--->5 - - - 6 |
| |
| 5 - - - 6----->7 - - - 8 |
| |
| (a) (b) |
| |
| Figure 2.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 |
| |
| Lines with adjacency are independent line segments where each endpoint has |
| a corresponding "adjacent" vertex that can be accessed by a geometry |
| shader (Section 2.16). 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 between the |
| Begin and End. 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 2.X1. |
| |
| Lines with adjacency are generated by calling Begin with the argument |
| value LINES_ADJACENCY_EXT. |
| |
| Line Strips with Adjacency |
| |
| Line strips with adjacency are similar to line strips, except that each |
| line segment has a pair of adjacent vertices that can be accessed by a |
| geometry shader (Section 2.15). 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 between the Begin |
| and End. If there are fewer than four vertices between a Begin and End, |
| 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 2.X1. |
| |
| Line strips with adjacency are generated by calling Begin with the |
| argument value LINE_STRIP_ADJACENCY_EXT. |
| |
| -------------------------------------------------------------------- |
| |
| (add figure and discussion of triangles with adjacency) |
| |
| 2 - - - 3 - - - 4 8 - - - 9 - - - 10 |
| ^\ ^\ |
| \ | \ | \ | \ | |
| | \ | \ |
| \ | \ | \ | \ | |
| | \ | \ |
| \ | \ | \ | \ | |
| | v | v |
| 1<------5 7<------11 |
| |
| \ | \ | |
| |
| \ | \ | |
| |
| \ | \ | |
| |
| 6 12 |
| |
| Figure 2.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 |
| |
| Triangles with adjacency are similar to separate triangles, except that |
| each triangle edge has an adjacent vertex that can be accessed by a |
| geometry shader (Section 2.15). 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 |
| between the Begin and End. 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 2.X2. |
| |
| Triangles with adjacency are generated by calling Begin with the argument |
| value TRIANGLES_ADJACENCY_EXT. |
| |
| -------------------------------------------------------------------- |
| |
| (add figure and discussion of triangle strips with adjacency) |
| |
| 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 2.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 |
| |
| Triangle strips with adjacency are similar to triangle strips, except that |
| each triangle edge has an adjacent vertex that can be accessed by a |
| geometry shader (Section 2.15). If a geometry shader is not active, the |
| "adjacent" vertices are ignored. |
| |
| In triangle strips with adjacency, n triangles are drawn using 2 * (n+2) + |
| k vertices between the Begin and End. k is either 0 or 1; if k is 1, the |
| final vertex is ignored. If fewer than 6 vertices are specified between |
| the Begin and End, the entire primitive is ignored. Table 2.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 2.X3. |
| |
| (add table) |
| 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 2.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 inside the |
| Begin/End, when i is either even or odd. For the purposes of this |
| table, the first vertex specified after Begin is numbered "1" and the |
| first triangle is numbered "0". |
| |
| Triangle strips with adjacency are generated by calling Begin with the |
| argument value TRIANGLE_STRIP_ADJACENCY_EXT. |
| |
| Modify Section 2.14.1, Lighting (p. 59) |
| |
| (modify fourth paragraph, p. 63) Additionally, vertex and geometry shaders |
| can operate in two-sided color mode, which is enabled and disabled by |
| calling Enable or Disable with the symbolic value VERTEX_PROGRAM_TWO_SIDE. |
| When a vertex or geometry shader is active, the shaders can write front |
| and back color values to the gl_FrontColor, gl_BackColor, |
| gl_FrontSecondaryColor and gl_BackSecondaryColor outputs. When a vertex or |
| geometry shader is active and two-sided color mode is enabled, the GL |
| chooses between front and back colors, as described below. If two-sided |
| color mode is disabled, the front color output is always selected. |
| |
| Modify Section 2.15.2 Program Objects, p. 73 |
| |
| Change the first paragraph on p. 74 as follows: |
| |
| Program objects are empty when they are created. Default values for |
| program object parameters are discussed in section 2.15.5, Required |
| State. A non-zero name that can be used to reference the program object is |
| returned. |
| |
| Change the language below the LinkProgram command on p. 74 as follows: |
| |
| ... Linking can fail for a variety of reasons as specified in the OpenGL |
| Shading Language Specification. Linking will also fail if one or more of |
| the shader objects, attached to <program> are not compiled successfully, |
| or if more active uniform or active sampler variables are used in |
| <program> than allowed (see sections 2.15.3 and 2.16.3). Linking will also |
| fail if the program object contains objects to form a geometry shader (see |
| section 2.16), but no objects to form a vertex shader or if the program |
| object contains objects to form a geometry shader, and the value of |
| GEOMETRY_VERTICES_OUT_EXT is zero. If LinkProgram failed, .. |
| |
| Add the following paragraphs above the description of |
| DeleteProgram, p. 75: |
| |
| To set a program object parameter, call |
| |
| void ProgramParameteriEXT(uint program, enum pname, int value) |
| |
| <param> identifies which parameter to set for <program>. <value> holds the |
| value being set. Legal values for <param> and <value> are discussed in |
| section 2.16. |
| |
| Modify Section 2.15.3, Shader Variables, p. 75 |
| |
| Modify the first paragraph of section 'Varying Variables' p. 83 as |
| follows: |
| |
| A vertex shader may define one or more varying variables (see the OpenGL |
| Shading Language specification). Varying variables are outputs of a vertex |
| shader. They are either used as the mechanism to communicate values to a |
| geometry shader, if one is active, or to communicate values to the |
| fragment shader. The OpenGL Shading Language specification also defines a |
| set of built-in varying variables that vertex shaders can write to (see |
| section 7.6 of the OpenGL Shading Language Specification). These variables |
| can also be used to communicate values to a geometry shader, if one is |
| active, or to communicate values to the fragment shader and to the fixed- |
| function processing that occurs after vertex shading. |
| |
| If a geometry shader is not active, the values of all varying variables, |
| including built-in variables, are expected to be interpolated across the |
| primitive being rendered, unless flat shaded. The number of interpolators |
| available for processing varying variables is given by the |
| implementation-dependent constant MAX_VARYING_COMPONENTS_EXT. This value |
| represents the number of individual components that can be interpolated; |
| varying variables declared as vectors, matrices, and arrays will all |
| consume multiple interpolators. When a program is linked, all components |
| of any varying variable written by a vertex shader, or read by a fragment |
| shader, will count against this limit. The transformed vertex position |
| (gl_Position) does not count against this limit. A program whose vertex |
| and/or fragment shaders access more than MAX_VARYING_COMPONENTS_EXT |
| components worth of varying variables may fail to link, unless |
| device-dependent optimizations are able to make the program fit within |
| available hardware resources. |
| |
| Note that the two values MAX_VARYING_FLOATS and MAX_VARYING_COMPONENTS_EXT |
| are aliases of each other. The use of MAX_VARYING_FLOATS however is |
| discouraged; varying variables can be declared as integers as well. |
| |
| If a geometry shader is active, the values of varying variables are |
| collected by the primitive assembly stage and passed on to the geometry |
| shader once enough data for one primitive has been collected (see also |
| section 2.16). The OpenGL Shading Language specification also defines a |
| set of built-in varying and built-in special variables that vertex shaders |
| can write to (see sections 7.1 and 7.6 of the OpenGL Shading Language |
| Specification). These variables are also collected and passed on to the |
| geometry shader once enough data has been collected. The number of |
| components of varying and special variables that can be collected per |
| vertex by the primitive assembly stage is given by the implementation |
| dependent constant MAX_VERTEX_VARYING_COMPONENTS_EXT. This value |
| represents the number of individual components that can be collected; |
| varying variables declared as vectors, matrices, and arrays will all |
| consume multiple components. When a program is linked, all components of |
| any varying variable written by a vertex shader, or read by a geometry |
| shader, will count against this limit. A program whose vertex and/or |
| geometry shaders access more than MAX_VERTEX_VARYING_COMPONENTS_EXT |
| components worth of varying variables may fail to link, unless |
| device-dependent optimizations are able to make the program fit within |
| available hardware resources. |
| |
| Modify Section 2.15.4 Shader Execution, p. 84 |
| |
| Change the following sentence: |
| |
| "The following operations are applied to vertex values that are the result |
| of executing the vertex shader:" |
| |
| As follows: |
| |
| If no geometry shader (see section 2.16) is present in the program object, |
| the following operations are applied to vertex values that are the result |
| of executing the vertex shader: |
| |
| [bulleted list of operations] |
| |
| On page 85, below the list of bullets, add the following: |
| |
| If a geometry shader is present in the program object, geometry shading |
| (section 2.16) is applied to vertex values that are the result of |
| executing the vertex shader. |
| |
| Modify the first paragraph of the section 'Texture Access', p. 85, |
| as follows: |
| |
| Vertex shaders have the ability to do a lookup into a texture map, if |
| supported by the GL implementation. The maximum number of texture image |
| units available to a vertex shader is MAX_VERTEX_TEXTURE_IMAGE_UNITS; a |
| maximum number of zero indicates that the GL implementation does not |
| support texture accesses in vertex shaders. The vertex shader, geometry |
| shader, if exists, and fragment processing combined cannot use more than |
| MAX_COMBINED_TEXTURE_IMAGE_UNITS texture image units. If the vertex |
| shader, geometry shader and the fragment processing stage access the same |
| texture image unit, then that counts as using three texture image units |
| against the MAX_COMBINED_TEXTURE_IMAGE_UNITS limit. |
| |
| Modify Section 2.15.5, Required State, p. 88 |
| |
| Add the following bullets to the state required per program object: |
| |
| * One integer to store the value of GEOMETRY_VERTICES_OUT_EXT, initially |
| zero. |
| |
| * One integer to store the value of GEOMETRY_INPUT_TYPE_EXT, initially |
| set to TRIANGLES. |
| |
| * One integer to store the value of GEOMETRY_OUTPUT_TYPE_EXT, initially |
| set to TRIANGLE_STRIP. |
| |
| Insert New Section 2.16, Geometry Shaders after p. 89 |
| |
| After vertices are processed, they are arranged into primitives, as |
| described in section 2.6.1 (Begin/End Objects). This section described a |
| new pipeline stage that processes those primitives. A geometry shader |
| defines the operations that are performed in this new pipeline stage. A |
| geometry shader is an array of strings containing source code. The source |
| code language used is described in the OpenGL Shading Language |
| specification. A geometry shader operates on a single primitive at a time |
| and emits one or more output primitives, all of the same type, which are |
| then processed like an equivalent OpenGL primitive specified by the |
| application. The original primitive is discarded after the geometry |
| shader completes. 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. |
| |
| This new geometry shader pipeline stage is inserted after primitive |
| assembly, right before color clamping (section 2.14.6), flat shading |
| (section 2.14.7) and clipping (sections 2.12 and 2.14.8). |
| |
| A geometry shader only applies when the GL is in RGB mode. Its operation |
| in color index mode is undefined. |
| |
| Geometry shaders are created as described in section 2.15.1 using a type |
| parameter of GEOMETRY_SHADER_EXT. They are attached to and used in program |
| objects as described in section 2.15.2. 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, or no program object is in use, this new primitive |
| processing pipeline stage is bypassed. |
| |
| A program object that includes a geometry shader must also include a |
| vertex shader; otherwise a link error will occur. |
| |
| Section 2.16.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. If a geometry shader is |
| active, Begin, or any function that implicitly calls Begin, will produce |
| an INVALID_OPERATION error if the <mode> parameter is incompatible with |
| the input primitive type of the currently active program object, as |
| discussed below. |
| |
| The input primitive type is a parameter of the program object, and must be |
| set before linking by calling ProgramParameteriEXT with <pname> set to |
| GEOMETRY_INPUT_TYPE_EXT and <value> set to one of POINTS, LINES, |
| LINES_ADJACENCY_EXT, TRIANGLES or TRIANGLES_ADJACENCY_EXT. This setting |
| will not be in effect until the next time LinkProgram has been called |
| successfully. Note that queries of GEOMETRY_INPUT_TYPE_EXT will return the |
| last value set. This is not necessarily the value used to generate the |
| executable code in the program object. After a program object has been |
| created it will have a default value for GEOMETRY_INPUT_TYPE_EXT, as |
| discussed in section 2.15.5, Required State. |
| |
| Note that 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 access |
| more input vertices than are available for the input primitive type of the |
| program object, will not link. |
| |
| The supported input primitive types 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 |
| 2.16.4. |
| |
| Lines with Adjacency (LINES_ADJACENCY_EXT) |
| |
| 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_EXT) |
| |
| 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 2.16.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 decomposed into points, lines, or triangles |
| based on the output primitive type in the manner described in section |
| 2.6.1. The resulting primitives are then further processed as shown in |
| figure 2.16.xxx. If the number of vertices emitted by the geometry shader |
| is not sufficient to produce a single primitive, nothing is drawn. |
| |
| The output primitive type is a parameter of the program object, and can be |
| set by calling ProgramParameteriEXT with <pname> set to |
| GEOMETRY_OUTPUT_TYPE_EXT and <value> set to one of POINTS, LINE_STRIP or |
| TRIANGLE_STRIP. This setting will not be in effect until the next time |
| LinkProgram has been called successfully. Note that queries of |
| GEOMETRY_OUTPUT_TYPE_EXT will return the last value set; which is not |
| necessarily the value used to generate the executable code in the program |
| object. After a program object has been created it will have a default |
| value for GEOMETRY_OUTPUT_TYPE_EXT, as discussed in section 2.15.5, |
| Required State. . |
| |
| Section 2.16.3 Geometry Shader Variables |
| |
| Geometry shaders can access uniforms belonging to the current program |
| object. The amount of storage available for geometry shader uniform |
| variables is specified by the implementation dependent constant |
| MAX_GEOMETRY_UNIFORM_COMPONENTS_EXT. This value represents the number of |
| individual floating-point, integer, or Boolean values that can be held in |
| uniform variable storage for a geometry shader. A link error will be |
| generated if an attempt is made to utilize more than the space available |
| for geometry shader uniform variables. Uniforms are manipulated as |
| described in section 2.15.3. Geometry shaders also have access to |
| samplers, to perform texturing operations, as described in sections 2.15.3 |
| and 3.8. |
| |
| Geometry shaders can access the transformed attributes of all vertices for |
| its input primitive type through input varying variables. A vertex shader, |
| writing to output varying variables, generates the values of these input |
| varying variables. This includes values for built-in as well as |
| user-defined varying variables. Values for any varying variables 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, varying |
| variables for each primitive it outputs. These values are optionally flat |
| shaded (using the OpenGL Shading Language varying qualifier "flat") and |
| clipped, then the clipped values interpolated across the primitive (if not |
| flat shaded). The results of these interpolations are available to a |
| fragment shader, if one is active. Furthermore, geometry shaders can write |
| to a set of built- in varying variables, defined in the OpenGL Shading |
| Language, that correspond to the values required for the fixed-function |
| processing that occurs after geometry processing. |
| |
| Section 2.16.4, Geometry Shader Execution Environment |
| |
| If a successfully linked program object that contains a geometry shader is |
| made current by calling UseProgram, the executable version of the geometry |
| shader is used to process primitives resulting from the primitive assembly |
| stage. |
| |
| The following operations are applied to the primitives that are the result |
| of executing a geometry shader: |
| |
| * color clamping or masking (section 2.14.6), |
| |
| * flat shading (section 2.14.7), |
| |
| * clipping, including client-defined clip planes (section 2.12), |
| |
| * front face determination (section 2.14.1), |
| |
| * color and associated data clipping (section 2.14.8), |
| |
| * perspective division on clip coordinates (section 2.11), |
| |
| * final color processing (section 2.14.9), and |
| |
| * viewport transformation, including depth-range scaling (section |
| 2.11.1). |
| |
| There are several special considerations for geometry shader execution |
| described in the following sections. |
| |
| Texture Access |
| |
| Geometry shaders have the ability to do a lookup into a texture map, if |
| supported by the GL implementation. The maximum number of texture image |
| units available to a geometry shader is |
| MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT; a maximum number of zero indicates |
| that the GL implementation does not support texture accesses in geometry |
| shaders. |
| |
| The vertex shader, geometry shader and fragment processing combined cannot |
| use more than MAX_COMBINED_TEXTURE_IMAGE_UNITS texture image units. If the |
| vertex shader, geometry shader and the fragment processing stage access |
| the same texture image unit, then that counts as using three texture image |
| units against the MAX_COMBINED_TEXTURE_IMAGE_UNITS limit. |
| |
| When a texture lookup is performed in a geometry shader, the filtered |
| texture value tau is computed in the manner described in sections 3.8.8 |
| and 3.8.9, and converted to a texture source color Cs according to table |
| 3.21 (section 3.8.13). A four component vector (Rs,Gs,Bs,As) is returned |
| to the geometry shader. In a geometry shader it is not possible to perform |
| automatic level-of- detail calculations using partial derivatives of the |
| texture coordinates with respect to window coordinates as described in |
| section 3.8.8. Hence, there is no automatic selection of an image array |
| level. Minification or magnification of a texture map is controlled by a |
| level-of-detail value optionally passed as an argument in the texture |
| lookup functions. If the texture lookup function supplies an explicit |
| level-of-detail value lambda, then the pre-bias level-of-detail value |
| LAMBDAbase(x, y) = lambda (replacing equation 3.18). If the texture lookup |
| function does not supply an explicit level-of-detail value, then |
| LAMBDAbase(x, y) = 0. The scale factor Rho(x, y) and its approximation |
| function f(x, y) (see equation 3.21) are ignored. |
| |
| Texture lookups involving textures with depth component data can either |
| return the depth data directly or return the results of a comparison with |
| the R value (see section 3.8.14) used to perform the lookup. The |
| comparison operation is requested in the shader by using any of the shadow |
| sampler and in the texture using the TEXTURE COMPARE MODE parameter. These |
| requests must be consistent; the results of a texture lookup are undefined |
| if: |
| |
| * the sampler used in a texture lookup function is not one of the shadow |
| sampler types, and the texture object's internal format is DEPTH |
| COMPONENT, and the TEXTURE COMPARE MODE is not NONE; |
| |
| * the sampler used in a texture lookup function is one of the shadow |
| sampler types, and the texture object's internal format is DEPTH |
| COMPONENT, and the TEXTURE COMPARE MODE is NONE; or |
| |
| * the sampler used in a texture lookup function is one of the shadow |
| sampler types, and the texture object's internal format is not DEPTH |
| COMPONENT. |
| |
| If a geometry shader uses a sampler where the associated texture object is |
| not complete as defined in section 3.8.10, the texture image unit will |
| return (R,G,B,A) = (0, 0, 0, 1). |
| |
| Geometry Shader Inputs |
| |
| The OpenGL Shading Language specification describes the set of built-in |
| variables that are available as inputs to the geometry shader. This set |
| receives the values from the equivalent built-in output variables written |
| by the vertex shader. These built-in variables are arrays; each element in |
| the array holds the value for a specific vertex of the input |
| primitive. The length of each array depends on the value of the input |
| primitive type, as determined by the program object value |
| GEOMETRY_INPUT_TYPE_EXT, and is set by the GL during link. Each built-in |
| variable is a one-dimensional array, except for the built-in texture |
| coordinate variable, which is a two- dimensional array. The vertex shader |
| built-in output gl_TexCoord[] is a one-dimensional array. Therefore, the |
| geometry shader equivalent input variable gl_TexCoordIn[][] becomes a two- |
| dimensional array. See the OpenGL Shading Language Specification, sections |
| 4.3.6 and 7.6 for more information. |
| |
| The built-in varying variables gl_FrontColorIn[], gl_BackColorIn[], |
| gl_FrontSecondaryColorIn[] and gl_BackSecondaryColorIn[] hold the |
| per-vertex front and back colors of the primary and secondary colors, as |
| written by the vertex shader to its equivalent built-in output variables. |
| |
| The built-in varying variable gl_TexCoordIn[][] holds the per- vertex |
| values of the array of texture coordinates, as written by the vertex |
| shader to its built-in output array gl_TexCoord[]. |
| |
| The built-in varying variable gl_FogFragCoordIn[] holds the per- vertex |
| fog coordinate, as written by the vertex shader to its built- in output |
| variable gl_FogFragCoord. |
| |
| The built-in varying variable gl_PositionIn[] holds the per-vertex |
| position, as written by the vertex shader to its output variable |
| gl_Position. Note that writing to gl_Position from either the vertex or |
| fragment shader is optional. See also section 7.1 "Vertex and Geometry |
| Shader Special Variables" of the OpenGL Shading Language specification. |
| |
| The built-in varying variable gl_ClipVertexIn[] holds the per-vertex |
| position in clip coordinates, as written by the vertex shader to its |
| output variable gl_ClipVertex. |
| |
| The built-in varying variable gl_PointSizeIn[] holds the per-vertex point |
| size written by the vertex shader to its built-in output varying variable |
| gl_PointSize. If the vertex shader does not write gl_PointSize, the value |
| of gl_PointSizeIn[] is undefined, regardless of the value of the enable |
| VERTEX_PROGRAM_POINT_SIZE. |
| |
| The built-in special variable gl_PrimitiveIDIn is not an array and has no |
| vertex shader equivalent. It is filled with the number of primitives |
| processed since the last time Begin was called (directly or indirectly via |
| vertex array functions). The first primitive generated after a Begin 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 be drawn. Restarting a |
| primitive topology using the primitive restart index has no effect on the |
| primitive ID counter. |
| |
| Similarly to the built-in varying variables, user-defined input varying |
| variables need to be declared as arrays. Declaring a 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 has to be of the size matching |
| the number of vertices of the input primitive type, otherwise a link error |
| will occur. The built-in variable gl_VerticesIn, if so desired, can be |
| used to size the array correctly for each input primitive |
| type. User-defined varying variables can be declared as arrays in the |
| vertex shader. This means that those, on input to the geometry shader, |
| must be declared as two-dimensional arrays. See sections 4.3.6 and 7.6 of |
| the OpenGL Shading Language Specification for more information. |
| |
| Using any of the built-in or user-defined input varying variables can |
| count against the limit MAX_VERTEX_VARYING_COMPONENTS_EXT as discussed in |
| section 2.15.3. |
| |
| 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 needs to be set as a parameter of the program object that contains |
| the geometry shader. To do so, call ProgramParameteriEXT with <pname> set |
| to GEOMETRY_VERTICES_OUT_EXT and <value> set to the maximum number of |
| vertices the geometry shader will emit in one invocation. This setting |
| will not be guaranteed to be in effect until the next time LinkProgram has |
| been called successfully. If a geometry shader, in one invocation, emits |
| more vertices than the value GEOMETRY_VERTICES_OUT_EXT, these emits may |
| have no effect. |
| |
| There are two implementation-dependent limits on the value of |
| GEOMETRY_VERTICES_OUT_EXT. First, the error INVALID_VALUE will be |
| generated by ProgramParameteriEXT if the number of vertices specified |
| exceeds the value of MAX_GEOMETRY_OUTPUT_VERTICES_EXT. Second, the |
| product of the total number of vertices and the sum of all components of |
| all active varying 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 varying |
| variables. These values are expected to be interpolated across the |
| primitive it outputs, unless they are specified to be flat shaded. In |
| order to seamlessly be able to insert or remove a geometry shader from a |
| program object, the rules, names and types of the output built-in varying |
| variables and user-defined varying variables are the same as for the |
| vertex shader. Refer to section 2.15.3 and the OpenGL Shading Language |
| specification sections 4.3.6, 7.1 and 7.6 for more detail. |
| |
| The built-in output variables gl_FrontColor, gl_BackColor, |
| gl_FrontSecondaryColor, and gl_BackSecondaryColor hold the front and back |
| colors for the primary and secondary colors for the current vertex. |
| |
| The built-in output variable gl_TexCoord[] is an array and holds the set |
| of texture coordinates for the current vertex. |
| |
| The built-in output variable gl_FogFragCoord is used as the "c" value, as |
| described in section 3.10 "Fog" of the OpenGL 2.0 specification. |
| |
| The built-in special variable gl_Position is intended to hold the |
| homogeneous vertex position. Writing gl_Position is optional. |
| |
| The built-in special variable gl_ClipVertex holds the vertex coordinate |
| used in the clipping stage, as described in section 2.12 "Clipping" of the |
| OpenGL 2.0 specification. |
| |
| The built-in special variable gl_PointSize, if written, holds the size of |
| the point to be rasterized, measured in pixels. |
| |
| Additionally, a geometry shader can write to the built-in special |
| variables gl_PrimitiveID and gl_Layer, whereas a vertex shader cannot. The |
| built-in gl_PrimitiveID provides a single integer that serves as a |
| primitive identifier. This written primitive ID is available to fragment |
| shaders. If a fragment shader using primitive IDs is active and a |
| geometry shader is also active, the geometry shader must write to |
| gl_PrimitiveID or the primitive ID number is undefined. The built-in |
| variable gl_Layer is used in layered rendering, and discussed in the next |
| section. |
| |
| The number of components available for varying variables is given by the |
| implementation-dependent constant |
| MAX_GEOMETRY_VARYING_COMPONENTS_EXT. This value represents the number of |
| individual components of a varying variable; varying variables declared as |
| vectors, matrices, and arrays will all consume multiple components. When a |
| program is linked, all components of any varying variable written by a |
| geometry shader, or read by a fragment shader, will count against this |
| limit. The transformed vertex position (gl_Position) does not count |
| against this limit. A program whose geometry and/or fragment shaders |
| access more than MAX_GEOMETRY_VARYING_COMPONENTS_EXT worth of varying |
| variable components may fail to link, unless device-dependent |
| optimizations are able to make the program fit within available hardware |
| resources. |
| |
| Layered rendering |
| |
| Geometry shaders can be used to render to one of several different layers |
| of cube map textures, three-dimensional textures, plus one- dimensional |
| and 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 cubemap 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. Refer to the section |
| 'Dependencies on EXT_framebuffer_object' for details. |
| |
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) |
| |
| Modify Section 3.3, Points (p. 95) |
| |
| (replace all Section 3.3 text on p. 95) |
| |
| A point is drawn by generating a set of fragments in the shape of a square |
| or circle centered around the vertex of the point. Each vertex has an |
| associated point size that controls the size of that square or circle. |
| |
| If no vertex or geometry shader is active, the size of the point is |
| controlled by |
| |
| void PointSize(float size); |
| |
| <size> specifies the requested size of a point. The default value is |
| 1.0. A value less than or equal to zero results in the error |
| INVALID_VALUE. |
| |
| The requested point size is multiplied with a distance attenuation factor, |
| clamped to a specified point size range, and further clamped to the |
| implementation-dependent point size range to produce the derived point |
| size: |
| |
| derived size = clamp(size * sqrt(1/(a+b*d+c*d^2))) |
| |
| where d is the eye-coordinate distance from the eye, (0,0,0,1) in eye |
| coordinates, to the vertex, and a, b, and c are distance attenuation |
| function coefficients. |
| |
| If a vertex or geometry shader is active, the derived size depends on the |
| per-vertex point size mode enable. Per-vertex point size mode is enabled |
| or disabled by calling Enable or Disable with the symbolic value |
| PROGRAM_POINT_SIZE_EXT. If per-vertex point size is enabled and a |
| geometry shader is active, the derived point size is taken from the |
| (potentially clipped) point size variable gl_PointSize written by the |
| geometry shader. If per-vertex point size is enabled and no geometry |
| shader is active, the derived point size is taken from the (potentially |
| clipped) point size variable gl_PointSize written by the vertex shader. If |
| per-vertex point size is disabled and a geometry and/or vertex shader is |
| active, the derived point size is taken from the <size> value provided to |
| PointSize, with no distance attenuation applied. In all cases, the |
| derived point size is clamped to the implementation-dependent point size |
| range. |
| |
| If multisampling is not enabled, the derived size is passed on to |
| rasterization as the point width. ... |
| |
| Modify section 3.10 "Fog", p. 191 |
| |
| Modify the third paragraph of this section as follows. |
| |
| If a vertex or geometry shader is active, or if the fog source, as defined |
| below, is FOG_COORD, then c is the interpolated value of the fog |
| coordinate for this fragment. Otherwise, ... |
| |
| Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| None. |
| |
| Additions to Chapter 5 of the OpenGL 2.0 Specification (Special |
| Functions) |
| |
| Change section 5.4 Display Lists, p. 237 |
| |
| Add the command ProgramParameteriEXT to the list of commands that are not |
| compiled into a display list, but executed immediately, under "Program and |
| Shader Objects", p. 241 |
| |
| Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State |
| Requests) |
| |
| Modify section 6.1.14, Shader and Program Objects, p. 256 |
| |
| Add to the second paragraph on p. 257: |
| |
| ... if <shader> is a fragment shader object, and GEOMETRY_SHADER_EXT is |
| returned if <shader> is a geometry shader object. |
| |
| Add to the end of the description of GetProgramiv, p. 257: |
| |
| If <pname> is GEOMETRY_VERTICES_OUT_EXT, the current value of the maximum |
| number of vertices the geometry shader will output is returned. If <pname> |
| is GEOMETRY_INPUT_TYPE_EXT, the current geometry shader input type is |
| returned and can be one of POINTS, LINES, LINES_ADJACENCY_EXT, TRIANGLES |
| or TRIANGLES_ADJACENCY_EXT. If <pname> is GEOMETRY_OUTPUT_TYPE_EXT, the |
| current geometry shader output type is returned and can be one of POINTS, |
| LINE_STRIP or TRIANGLE_STRIP. |
| |
| Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) |
| |
| None. |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None. |
| |
| Dependencies on NV_primitive_restart |
| |
| The spec describes the behavior that primitive restart does not affect the |
| primitive ID counter gl_PrimitiveIDIn. If NV_primitive_restart is not |
| supported, references to that extension in the discussion of the primitive |
| ID should be removed. |
| |
| Dependencies on EXT_framebuffer_object |
| |
| If EXT_framebuffer_object (or similar functionality) is not supported, the |
| gl_Layer output has no effect. "FramebufferTextureEXT" and |
| "FramebufferTextureLayerEXT" should be removed from "New Procedures and |
| Functions", and FRAMEBUFFER_ATTACHMENT_LAYERED_EXT, |
| FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT, and |
| FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_EXT should be removed from "New |
| Tokens". |
| |
| Otherwise, this extension modifies EXT_framebuffer_object to add 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 one- or two-dimensional array texture. The layer used for rendering |
| can be selected by the geometry shader at run time. |
| |
| (insert before the end of Section 4.4.2, Attaching Images to Framebuffer |
| Objects) |
| |
| There are several types of framebuffer-attachable images: |
| |
| * the image of a renderbuffer object, which is always two-dimensional, |
| |
| * a single level of a one-dimensional texture, which is treated as a |
| two-dimensional image with a height of one, |
| |
| * a single level of a two-dimensional or rectangle texture, |
| |
| * a single face of a cube map texture level, which is treated as a |
| two-dimensional image, or |
| |
| * a single layer of a one- or two-dimensional array texture or |
| three-dimensional texture, which is treated as a two-dimensional |
| image. |
| |
| Additionally, an entire level of a three-dimensional texture, cube map |
| texture, or one- or two-dimensional 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. |
| |
| (replace section 4.4.2.3, "Attaching Texture Images to a Framebuffer") |
| |
| GL supports copying the rendered contents of the framebuffer into the |
| images of a texture object through the use of the routines |
| CopyTexImage{1D|2D}, and CopyTexSubImage{1D|2D|3D}. Additionally, 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 FRAMEBUFFER_EXT. <attachment> must be one of the |
| attachment points of the framebuffer listed in table 1.nnn. |
| |
| If <texture> is zero, any image or array of images attached to the |
| attachment point named by <attachment> is detached, and the state of the |
| attachment point is reset to its initial values. <level> is ignored if |
| <texture> is zero. |
| |
| If <texture> is non-zero, FramebufferTextureEXT attaches level <level> of |
| the texture object named <texture> to the framebuffer attachment point |
| named by <attachment>. The error INVALID_VALUE is generated if <texture> |
| is not the name of a texture object, or if <level> is not a supported |
| texture level number for textures of the type corresponding to <target>. |
| The error INVALID_OPERATION is generated if <texture> is the name of a |
| buffer texture. |
| |
| If <texture> is the name of a three-dimensional texture, cube map texture, |
| or one- or two-dimensional array texture, the texture level attached to |
| the framebuffer attachment point is an array of images, and the |
| framebuffer attachment is considered layered. |
| |
| The command |
| |
| void FramebufferTextureLayerEXT(enum target, enum attachment, |
| uint texture, int level, int layer); |
| |
| operates like FramebufferTextureEXT, except that only a single layer of |
| the texture level, numbered <layer>, is attached to the attachment point. |
| If <texture> is non-zero, the error INVALID_VALUE is generated if <layer> |
| is negative, or if <texture> is not the name of a texture object. The |
| error INVALID_OPERATION is generated unless <texture> is zero or the name |
| of a three-dimensional or one- or two-dimensional array texture. |
| |
| The command |
| |
| void FramebufferTextureFaceEXT(enum target, enum attachment, |
| uint texture, int level, enum face); |
| |
| operates like FramebufferTextureEXT, except that only a single face of a |
| cube map texture, given by <face>, is attached to the attachment point. |
| <face> is one of TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X, |
| TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y, |
| TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_Z. If <texture> is |
| non-zero, the error INVALID_VALUE is generated if <texture> is not the |
| name of a texture object. The error INVALID_OPERATION is generated unless |
| <texture> is zero or the name of a cube map texture. |
| |
| The command |
| |
| void FramebufferTexture1DEXT(enum target, enum attachment, |
| enum textarget, uint texture, int level); |
| |
| operates identically to FramebufferTextureEXT, except for two additional |
| restrictions. If <texture> is non-zero, the error INVALID_ENUM is |
| generated if <textarget> is not TEXTURE_1D and the error INVALID_OPERATION |
| is generated unless <texture> is the name of a one-dimensional texture. |
| |
| The command |
| |
| void FramebufferTexture2DEXT(enum target, enum attachment, |
| enum textarget, uint texture, int level); |
| |
| operates similarly to FramebufferTextureEXT. If <textarget> is TEXTURE_2D |
| or TEXTURE_RECTANGLE_ARB, <texture> must be zero or the name of a |
| two-dimensional or rectangle texture. If <textarget> is |
| TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X, |
| TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y, |
| TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, <texture> |
| must be zero or the name of a cube map texture. For cube map textures, |
| only the single face of the cube map texture level given by <textarget> is |
| attached. The error INVALID_ENUM is generated if <texture> is not zero |
| and <textarget> is not one of the values enumerated above. The error |
| INVALID_OPERATION is generated if <texture> is the name of a texture whose |
| type does not match the texture type required by <textarget>. |
| |
| The command |
| |
| void FramebufferTexture3DEXT(enum target, enum attachment, |
| enum textarget, uint texture, |
| int level, int zoffset); |
| |
| behaves identically to FramebufferTextureLayerEXT, with the <layer> |
| parameter set to the value of <zoffset>. The error INVALID_ENUM is |
| generated if <textarget> is not TEXTURE_3D. The error INVALID_OPERATION |
| is generated unless <texture> is zero or the name of a three-dimensional |
| texture. |
| |
| For all FramebufferTexture commands, if <texture> is non-zero and the |
| command does not result in an error, the framebuffer attachment state |
| corresponding to <attachment> is updated based on the new attachment. |
| FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is set to TEXTURE, |
| FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is set to <texture>, and |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL is set to <level>. |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_FACE is set to <textarget> if |
| FramebufferTexture2DEXT is called and <texture> is the name of a cubemap |
| texture; otherwise, it is set to TEXTURE_CUBE_MAP_POSITIVE_X. |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer> or <zoffset> if |
| FramebufferTextureLayerEXT or FramebufferTexture3DEXT is called; |
| otherwise, it is set to zero. FRAMEBUFFER_ATTACHMENT_LAYERED_EXT is set |
| to TRUE if FramebufferTextureEXT is called and <texture> is the name of a |
| three-dimensional texture, cube map texture, or one- or two-dimensional |
| array texture; otherwise it is set to FALSE. |
| |
| (modify Section 4.4.4.1, Framebuffer Attachment Completeness -- add to the |
| conditions necessary for attachment completeness) |
| |
| The framebuffer attachment point <attachment> is said to be "framebuffer |
| attachment complete" if ...: |
| |
| * If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and |
| FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a three-dimensional |
| texture, FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than |
| the depth of the texture. |
| |
| * If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and |
| FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or two-dimensional |
| array texture, FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be |
| smaller than the number of layers in the texture. |
| |
| (modify section 4.4.4.2, Framebuffer Completeness -- add to the list of |
| conditions necessary for completeness) |
| |
| * 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, or one- or two-dimensional array textures). |
| { FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT } |
| |
| * If any framebuffer attachment is layered, all attachments must have |
| the same layer count. For three-dimensional textures, the layer count |
| is the depth of the attached volume. For cube map textures, the layer |
| count is always six. For one- and two-dimensional array textures, the |
| layer count is simply the number of layers in the array texture. |
| { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_EXT } |
| |
| The enum in { brackets } after each clause of the framebuffer completeness |
| rules specifies the return value of CheckFramebufferStatusEXT (see below) |
| that is generated when that clause is violated. ... |
| |
| (add section 4.4.7, 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 |
| |
| * the fragment is generated by DrawPixels, CopyPixels, or Bitmap, |
| |
| * geometry shaders are disabled, or |
| |
| * the current geometry shader does not contain an instruction that |
| statically assigns 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 layer output of one of the vertices of |
| the primitive. The vertex used is implementation-dependent. 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 (section 4.1.5), depth buffer test |
| (section 4.1.6), and for blending and color buffer writes (section 4.1.8). |
| If the fragment's layer number is negative or greater than the number of |
| layers attached, the effects of the fragment on the framebuffer contents |
| are undefined. |
| |
| When the Clear command is used to clear a layered framebuffer attachment, |
| all layers of the attachment are cleared. |
| |
| When commands such as ReadPixels or CopyPixels 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 X.4. |
| |
| layer number cube map face |
| ------------ --------------------------- |
| 0 TEXTURE_CUBE_MAP_POSITIVE_X |
| 1 TEXTURE_CUBE_MAP_NEGATIVE_X |
| 2 TEXTURE_CUBE_MAP_POSITIVE_Y |
| 3 TEXTURE_CUBE_MAP_NEGATIVE_Y |
| 4 TEXTURE_CUBE_MAP_POSITIVE_Z |
| 5 TEXTURE_CUBE_MAP_NEGATIVE_Z |
| |
| Table X.4, Layer numbers for cube map texture faces. The layers are |
| numbered in the same sequence as the cube map face token values. |
| |
| (modify Section 6.1.3, Enumerated Queries -- Modify/add to list of <pname> |
| values for GetFramebufferAttachmentParameterivEXT if |
| FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE) |
| |
| If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the attached |
| image is a layer of a three-dimensional texture or one- or |
| two-dimensional array texture, then <params> will contain the specified |
| layer number. Otherwise, <params> will contain the value zero. |
| |
| If <pname> is FRAMEBUFFER_ATTACHMENT_LAYERED_EXT, then <params> will |
| contain TRUE if an entire level of a three-dimesional texture, cube map |
| texture, or one- or two-dimensional array texture is attached to the |
| <attachment>. Otherwise, <params> will contain FALSE. |
| |
| (Modify the Additions to Chapter 5, section 5.4) |
| |
| Add the commands FramebufferTextureEXT, FramebufferTextureLayerEXT, and |
| FramebufferTextureFaceEXT to the list of commands that are not compiled |
| into a display list, but executed immediately. |
| |
| Dependencies on EXT_framebuffer_blit |
| |
| If EXT_framebuffer_blit is supported, the EXT_framebuffer_object language |
| should be further amended so that <target> values passed to |
| FramebufferTextureEXT and FramebufferTextureLayerEXT can be |
| DRAW_FRAMEBUFFER_EXT or READ_FRAMEBUFFER_EXT, and that those functions |
| set/query state for the draw framebuffer if <target> is FRAMEBUFFER_EXT. |
| |
| If BlitFramebufferEXT() is called with a layered read framebuffer, pixel |
| values are obtained from layer zero from the read framebuffer. If the |
| draw framebuffer is layered, pixel values are written to layer zero of the |
| draw framebuffer. If both framebuffers are layered, the two-dimensional |
| blit operation is still performed only on layer zero. |
| |
| Dependencies on EXT_texture_array |
| |
| If EXT_texture_array is not supported, the discussion array textures the |
| layered rendering edits to EXT_framebuffer_object should be |
| removed. Layered rendering to cube map and 3D textures would still be |
| supported. |
| |
| If EXT_texture_array is supported, the edits to EXT_framebuffer_object |
| supersede those made in EXT_texture_array, except for language pertaining |
| to mipmap generation of array textures. |
| |
| There are no functional incompatibilities between the FBO support in these |
| two specifications. The only differences are that this extension supports |
| layered rendering and also rewrites certain sections of the core FBO |
| specification more aggressively. |
| |
| Dependencies on ARB_texture_rectangle |
| |
| If ARB_texture_rectangle is not supported, all references to rectangle |
| textures in the EXT_framebuffer_object spec language should be removed. |
| |
| Dependencies on EXT_texture_buffer_object |
| |
| If EXT_buffer_object is not supported, the reference to an |
| INVALID_OPERATION error if a buffer texture is passed to |
| FramebufferTextureEXT should be removed. |
| |
| GLX Protocol |
| |
| The following rendering command is sent to the server as part of a |
| glXRender request: |
| |
| ProgramParameteriEXT |
| 2 16 rendering command length |
| 2 266 rendering command opcode |
| 4 CARD32 program |
| 4 ENUM pname |
| 4 INT32 value |
| |
| FramebufferTextureEXT |
| |
| 2 20 rendering command length |
| 2 267 rendering command opcode |
| 4 ENUM target |
| 4 ENUM attachment |
| 4 CARD32 texture |
| 4 INT32 level |
| |
| FramebufferTextureLayerEXT |
| |
| 2 24 rendering command length |
| 2 237 rendering command opcode |
| 4 ENUM target |
| 4 ENUM attachment |
| 4 CARD32 texture |
| 4 INT32 level |
| 4 INT32 layer |
| |
| FramebufferTextureFaceEXT |
| |
| 2 24 rendering command length |
| 2 268 rendering command opcode |
| 4 ENUM target |
| 4 ENUM attachment |
| 4 CARD32 texture |
| 4 INT32 level |
| 4 ENUM face |
| |
| Errors |
| |
| The error INVALID_VALUE is generated by ProgramParameteriEXT if <pname> is |
| GEOMETRY_INPUT_TYPE_EXT and <value> is not one of POINTS, LINES, |
| LINES_ADJACENCY_EXT, TRIANGLES or TRIANGLES_ADJACENCY_EXT. |
| |
| The error INVALID_VALUE is generated by ProgramParameteriEXT if <pname> is |
| GEOMETRY_OUTPUT_TYPE_EXT and <value> is not one of POINTS, LINE_STRIP or |
| TRIANGLE_STRIP. |
| |
| The error INVALID_VALUE is generated by ProgramParameteriEXT if <pname> is |
| GEOMETRY_VERTICES_OUT_EXT and <value> is negative. |
| |
| The error INVALID_VALUE is generated by ProgramParameteriEXT if <pname> is |
| GEOMETRY_VERTICES_OUT_EXT and <value> exceeds |
| MAX_GEOMETRY_OUTPUT_VERTICES_EXT. |
| |
| The error INVALID_VALUE is generated by ProgramParameteriEXT if <pname> is |
| set to GEOMETRY_VERTICES_OUT_EXT and the product of <value> and the sum of |
| all components of all active varying variables exceeds |
| MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_EXT. |
| |
| The error INVALID_OPERATION is generated if Begin, or any command that |
| implicitly calls Begin, is called when a geometry shader is active and: |
| |
| * 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. |
| |
| New State |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| ------------------------- ---- ----------- ------- ---------------------- ------ ---------- |
| FRAMEBUFFER_ATTACHMENT_ nxB GetFramebuffer- FALSE Framebuffer attachment 4.4.2.3 - |
| LAYERED_EXT Attachment- is layered |
| ParameterivEXT |
| |
| Modify the following state value in Table 6.28, Shader Object State, |
| p. 289. |
| |
| Get Value Type Get Command Value Description Sec. Attribute |
| ------------------ ---- ----------- ------- ---------------------- ------ --------- |
| SHADER_TYPE Z2 GetShaderiv - Type of shader (vertex, 2.15.1 - |
| Fragment, geometry) |
| |
| Add the following state to Table 6.29, Program Object State, p. 290 |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| ------------------------- ---- ------------ ------- ----------------- ------ ------- |
| GEOMETRY_VERTICES_OUT_EXT Z+ GetProgramiv 0 max # of output vertices 2.16.4 - |
| GEOMETRY_INPUT_TYPE_EXT Z5 GetProgramiv TRIANGLES Primitive input type 2.16.1 - |
| GEOMETRY_OUTPUT_TYPE_EXT Z3 GetProgramiv TRIANGLE_ Primitive output type 2.16.2 - |
| STRIP |
| |
| New Implementation Dependent State |
| |
| Min. |
| Get Value Type Get Command Value Description Sec. Attrib |
| ---------------------- ---- ----------- ----- -------------------- -------- ------ |
| MAX_GEOMETRY_TEXTURE_ Z+ GetIntegerv 0 maximum number of 2.16.4 - |
| IMAGE_UNITS_EXT texture image units |
| accessible in a |
| geometry shader |
| MAX_GEOMETRY_OUTPUT_ Z+ GetIntegerv 256 maximum number of 2.16.4 - |
| VERTICES_EXT vertices that any |
| geometry shader can |
| can emit |
| MAX_GEOMETRY_TOTAL_ Z+ GetIntegerv 1024 maximum number of 2.16.4 - |
| OUTPUT_COMPONENTS_EXT total components (all |
| vertices) of active |
| varyings that a |
| geometry shader can |
| emit |
| MAX_GEOMETRY_UNIFORM_ Z+ GetIntegerv 512 Number of words for 2.16.3 - |
| COMPONENTS_EXT geometry shader |
| uniform variables |
| MAX_GEOMETRY_VARYING_ Z+ GetIntegerv 32 Number of components 2.16.4 - |
| COMPONENTS_EXT for varying variables |
| between geometry and |
| fragment shaders |
| MAX_VERTEX_VARYING_ Z+ GetIntegerv 32 Number of components 2.15.3 - |
| COMPONENTS_EXT for varying variables |
| between Vertex and |
| geometry shaders |
| MAX_VARYING_ Z+ GetIntegerv 32 Alias for 2.15.3 - |
| COMPONENTS_EXT MAX_VARYING_FLOATS |
| |
| Modifications to the OpenGL Shading Language Specification version |
| 1.10.59 |
| |
| Including the following line in a shader can be used to control the |
| language features described in this extension: |
| |
| #extension GL_EXT_geometry_shader4 : <behavior> |
| |
| where <behavior> is as specified in section 3.3. |
| |
| A new preprocessor #define is added to the OpenGL Shading Language: |
| |
| #define GL_EXT_geometry_shader4 1 |
| |
| Change the introduction to Chapter 2 "Overview of OpenGL Shading" as |
| follows: |
| |
| The OpenGL Shading Language is actually three closely related |
| languages. These languages are used to create shaders for the programmable |
| processors contained in the OpenGL processing pipeline. The precise |
| definition of these programmable units is left to separate |
| specifications. In this document, we define them only well enough to |
| provide a context for defining these languages. Unless otherwise noted in |
| this paper, 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: vertex, |
| geometry or fragment. |
| |
| Change the last sentence of the first paragraph of section 3.2 |
| "Source Strings" to: |
| |
| Multiple shaders of the same language (vertex, geometry or fragment) can |
| be linked together to form a single program. |
| |
| Change the first paragraph of section 4.1.3, "Integers" as follows: |
| |
| ... integers are limited to 16 bits of precision, plus a sign |
| representation in the vertex, geometry and fragment languages.. |
| |
| Change the first paragraph of section 4.1.9, "Arrays", as follows: |
| |
| Variables of the same type can be aggregated into one- and two- |
| dimensional arrays by declaring a name followed by brackets ( [ ] for |
| one-dimensional arrays and [][] for two-dimensional arrays) enclosing an |
| optional size. When an array size is specified in a declaration, it must |
| be an integral constant expression (see Section 4.3.3 "Integral Constant |
| Expressions") greater than zero. If an array is indexed with an |
| expression that is not an integral constant expression or passed as an |
| argument to a function, then its size must be declared before any such |
| use. It is legal to declare an array without a size and then later |
| re-declare the same name as an array of the same type and specify a |
| size. It is illegal to declare an array with a size, and then later (in |
| the same shader) index the same array with an integral constant expression |
| greater than or equal to the declared size. It is also illegal to index an |
| array with a negative constant expression. Arrays declared as formal |
| parameters in a function declaration must specify a size. Undefined |
| behavior results from indexing an array with a non-constant expression |
| that's greater than or equal to the array's size or less than 0. All basic |
| types and structures can be formed into arrays. |
| |
| Two-dimensional arrays can only be declared as "varying in" variables in a |
| geometry shader. See section 4.3.6 for details. All other declarations of |
| two-dimensional arrays are illegal. |
| |
| Change the fourth paragraph of section 4.2 "Scoping", as follows: |
| |
| Shared globals are global variables declared with the same name in |
| independently compiled units (shaders) of the same language (vertex, |
| geometry or fragment) that are linked together . |
| |
| Change section 4.3 "Type Qualifiers" |
| |
| Change the "varying", "in" and "out" qualifiers as follows: |
| |
| varying - linkage between a vertex shader and geometry shader, or between |
| a geometry shader and a fragment shader, or between a vertex shader and a |
| fragment shader. |
| |
| in - for function parameters passed into a function or for input varying |
| variables (geometry only) |
| |
| out - for function parameters passed back out of a function, but not |
| initialized for use when passed in. Also for output varying variables |
| (geometry only). |
| |
| Change section 4.3.6 "Varying" as follows: |
| |
| Varying variables provide the interface between the vertex shader and |
| geometry shader and also between the geometry shader and fragment shader |
| and the fixed functionality between them. If no geometry shader is |
| present, varying variables also provide the interface between the vertex |
| shader and fragment shader. |
| |
| The vertex, or geometry shader will compute values per vertex (such |
| as color, texture coordinates, etc) and write them to output variables |
| declared with the "varying" qualifier (vertex or geometry) or "varying |
| out" qualifiers (geometry only). A vertex or geometry shader may also |
| read these output varying variables, getting back the same values it has |
| written. Reading an output varying variable in a vertex or geometry shader |
| returns undefined results if it is read before being written. |
| |
| A geometry shader may also read from an input varying variable declared |
| with the "varying in" qualifiers. The value read will be the same value as |
| written by the vertex shader for that varying variable. Since a geometry |
| shader operates on primitives, each input varying variable needs to be |
| declared as an array. Each element of such an array corresponds to a |
| vertex of the primitive being processed. If the varying variable is |
| declared as a scalar or matrix in the vertex shader, it will be a |
| one-dimensional array in the geometry shader. Each array can optionally |
| have a size declared. If a size is not specified, it inferred by the |
| linker and depends on the value of the input primitive type. See table |
| 4.3.xxx to determine the exact size. The read-only built-in constant |
| gl_VerticesIn will be set to this value by the linker. If a size is |
| specified, it has to be the size as given by table 4.3.xxx, otherwise a |
| link error will occur. The built-in constant gl_VerticesIn, if so desired, |
| can be used to size the array correctly for each input primitive |
| type. Varying variables can also be declared as arrays in the vertex |
| shader. This means that those, on input to the geometry shader, must be |
| declared as two- dimensional arrays. The first index to the |
| two-dimensional array holds the vertex number. Declaring a size for the |
| first range of the array is optional, just as it is for one-dimensional |
| arrays. The second index holds the per-vertex array data. Declaring a |
| size for the second range of the array is not optional, and has to match |
| the declaration in the vertex shader. |
| |
| Value of built-in |
| Input primitive type gl_VerticesIn |
| ----------------------- ----------------- |
| POINTS 1 |
| LINES 2 |
| LINES_ADJACENCY_EXT 4 |
| TRIANGLES 3 |
| TRIANGLES_ADJACENCY_EXT 6 |
| |
| Table 4.3.xxxx The value of the built-in variable gl_VerticesIn is |
| determined at link time, based on the input primitive type. |
| |
| It is illegal to index these varying arrays, or in the case of two- |
| dimensional arrays, the first range of the array, with a negative integral |
| constant expression or an integral constant expression greater than or |
| equal to gl_VerticesIn. A link error will occur in these cases. |
| |
| Varying variables that are part of the interface to the fragment shader |
| are set per vertex and interpolated in a perspective correct manner, |
| unless flat shaded, over the primitive being rendered. If single-sampling, |
| the interpolated value is for the fragment center. If multi-sampling, the |
| interpolated value can be anywhere within the pixel, including the |
| fragment center or one of the fragment samples. |
| |
| A fragment shader may read from varying variables and the value read will |
| be the interpolated value, as a function of the fragment's position within |
| the primitive, unless the varying variable is flat shaded. A fragment |
| shader cannot write to a varying variable. |
| |
| If a geometry shader is present, the type of the varying variables with |
| the same name declared in the vertex shader and the input varying |
| variables in the geometry shader must match, otherwise the link command |
| will fail. Likewise, the type of the output varying variables with the |
| same name declared in the geometry shader and the varying variables in the |
| fragment shader must match. |
| |
| If a geometry shader is not present, the type of the varying variables |
| with the same name declared in both the vertex and fragment shaders must |
| match, otherwise the link command will fail. |
| |
| Only those varying variables used (i.e. read) in the geometry or fragment |
| shader must be written to by the vertex or geometry shader; declaring |
| superfluous varying variables in the vertex shader or declaring |
| superfluous output varying variables in the geometry shader is |
| permissible. |
| |
| Varying variables are declared as in the following example: |
| |
| varying in float foo[]; // geometry shader input. Size of the |
| // array set as a result of link, based |
| // on the input primitive type. |
| |
| varying in float foo[gl_VerticesIn]; // geometry shader input |
| |
| varying in float foo[3]; // geometry shader input. Only legal for |
| // the TRIANGLES input primitive type |
| |
| varying in float foo[][5]; // Size of the first range set as a |
| // result of link. Each vertex holds an |
| // array of 5 floats. |
| |
| varying out vec4 bar; // geometry output |
| varying vec3 normal; // vertex shader output or fragment |
| // shader input |
| |
| The varying qualifier can be used only with the data types float, vec2, |
| vec3, vec4, mat2, mat3 and mat4 or arrays of these. Structures cannot be |
| varying. Additionally, the "varying in" and "varying out" qualifiers can |
| only be used in a geometry shader. |
| |
| If no vertex shader is active, the fixed functionality pipeline of OpenGL |
| will compute values for the built-in varying variables that will be |
| consumed by the fragment shader. Similarly, if no fragment shader is |
| active, the vertex shader or geometry shader is responsible for computing |
| and writing to the built-in varying variables that are needed for OpenGL's |
| fixed functionality fragment pipeline. |
| |
| Varying variables are required to have global scope, and must be declared |
| outside of function bodies, before their first use. |
| |
| Change section 7.1 "Vertex Shader Special Variables" |
| |
| Rename this section to "Vertex and Geometry Shader Special Variables" |
| |
| Anywhere in this section where it reads "vertex language" replace it with |
| "vertex and geometry language". |
| |
| Anywhere in this section where it reads "vertex shader" replace it with |
| "vertex shader or geometry shader". |
| |
| Change the second paragraph to: |
| |
| The variable gl_Position is available only in the vertex and geometry |
| language and is intended for writing the homogeneous vertex position. It |
| can be written at any time during shader execution. It may also be read |
| back by the shader after being written. This value will be used by |
| primitive assembly, clipping, culling, and other fixed functionality |
| operations that operate on primitives after vertex or geometry processing |
| has occurred. Compilers may generate a diagnostic message if they detect |
| gl_Position is read before being written, but not all such cases are |
| detectable. Writing to gl_Position is optional. If gl_Position is not |
| written but subsequent stages of the OpenGL pipeline consume gl_Position, |
| then results are undefined. |
| |
| Change the last sentence of this section into the following: |
| |
| The read-only built-in gl_PrimitiveIDIn is available only in the geometry |
| language and is filled with the number of primitives processed by the |
| geometry shader since the last time Begin was called (directly or |
| indirectly via vertex array functions). See section 2.16.4 for more |
| information. |
| |
| This variable is intrinsically declared as: |
| |
| int gl_PrimitiveIDIn; // read only |
| |
| The built-in output variable gl_PrimitiveID is available only in the |
| geometry language and provides a single integer that serves as a primitive |
| identifier. This written primitive ID is available to fragment shaders. |
| If a fragment shader using primitive IDs is active and a geometry shader |
| is also active, the geometry shader must write to gl_PrimitiveID or the |
| primitive ID in the fragment shader number is undefined. |
| |
| The built-in output variable gl_Layer is available only in the geometry |
| language, and provides the number of the layer of textures attached to a |
| FBO to direct rendering to. If a shader statically assigns a value to |
| gl_Layer, layered rendering mode is enabled. See section 2.16.4 for a |
| detailed explanation. 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 may be undefined for executions of |
| the shader that take that path. |
| |
| These variables area intrinsically declared as: |
| |
| int gl_PrimitiveID; |
| int gl_Layer; |
| |
| These variables can be read back by the shader after writing to them, to |
| retrieve what was written. Reading the variable before writing it results |
| in undefined behavior. If it is written more than once, the last value |
| written is consumed by the subsequent operations. |
| |
| All built-in variables discussed in this section have global scope. |
| |
| Change section 7.2 "Fragment Shader Special Variables" |
| |
| Change the first paragraph on p. 44 as follows: |
| |
| The fragment shader has access to the read-only built-in variable |
| gl_FrontFacing whose value 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 the vertex shader or geometry |
| shader. |
| |
| Change the first sentence of section 7.4 "Built-in Constants" |
| |
| The following built-in constant is provided to geometry shaders. |
| |
| const int gl_VerticesIn; // Value set at link time |
| |
| The following built-in constants are provided to the vertex, geometry and |
| fragment shaders: |
| |
| Change section 7.6 "Varing Variables" |
| |
| Unlike user-defined varying variables, the built-in varying variables |
| don't have a strict one-to-one correspondence between the vertex language, |
| geometry language and the fragment language. Four sets are provided, one |
| set for the vertex language output, one set for the geometry language |
| output, one set for the fragment language input and another set for the |
| geometry language input. Their relationship is described below. |
| |
| The following built-in varying variables are available to write to in a |
| vertex shader or geometry shader. A particular one should be written to if |
| any functionality in a corresponding geometry shader or fragment shader or |
| fixed pipeline uses it or state derived from it. Otherwise, behavior is |
| undefined. |
| |
| Vertex language built-in outputs: |
| |
| varying vec4 gl_FrontColor; |
| varying vec4 gl_BackColor; |
| varying vec4 gl_FrontSecondaryColor; |
| varying vec4 gl_BackSecondaryColor; |
| varying vec4 gl_TexCoord[]; // at most will be gl_MaxTextureCoords |
| varying float gl_FogFragCoord; |
| |
| Geometry language built-in outputs: |
| |
| varying out vec4 gl_FrontColor; |
| varying out vec4 gl_BackColor; |
| varying out vec4 gl_FrontSecondaryColor; |
| varying out vec4 gl_BackSecondaryColor; |
| varying out vec4 gl_TexCoord[]; // at most gl_MaxTextureCoords |
| varying out float gl_FogFragCoord; |
| |
| For gl_FogFragCoord, the value written will be used as the "c" value on |
| page 160 of the OpenGL 1.4 Specification by the fixed functionality |
| pipeline. For example, if the z-coordinate of the fragment in eye space is |
| desired as "c", then that's what the vertex or geometry shader should |
| write into gl_FogFragCoord. |
| |
| Indices used to subscript gl_TexCoord must either be an integral constant |
| expressions, or this array must be re-declared by the shader with a |
| size. The size can be at most gl_MaxTextureCoords. Using indexes close to |
| 0 may aid the implementation in preserving varying resources. |
| |
| The following input varying variables are available to read from in a |
| geometry shader. |
| |
| varying in vec4 gl_FrontColorIn[gl_VerticesIn]; |
| varying in vec4 gl_BackColorIn[gl_VerticesIn]; |
| varying in vec4 gl_FrontSecondaryColorIn[gl_VerticesIn]; |
| varying in vec4 gl_BackSecondaryColorIn[gl_VerticesIn]; |
| varying in vec4 gl_TexCoordIn[gl_VerticesIn][]; // at most will be |
| // gl_MaxTextureCoords |
| varying in float gl_FogFragCoordIn[gl_VerticesIn]; |
| varying in vec4 gl_PositionIn[gl_VerticesIn]; |
| varying in float gl_PointSizeIn[gl_VerticesIn]; |
| varying in vec4 gl_ClipVertexIn[gl_VerticesIn]; |
| |
| All built-in variables are one-dimensional arrays, except for |
| gl_TexCoordIn, which is a two-dimensional array. Each element of a |
| one-dimensional array, or the first index of a two-dimensional array, |
| corresponds to a vertex of the primitive being processed and receives |
| their value from the equivalent vertex output varying variables. See also |
| section 4.3.6. |
| |
| The following varying variables are available to read from in a fragment |
| shader. The gl_Color and gl_SecondaryColor names are the same names as |
| attributes passed to the vertex shader. However, there is no name |
| conflict, because attributes are visible only in vertex shaders and the |
| following are only visible in a fragment shader. |
| |
| varying vec4 gl_Color; |
| varying vec4 gl_SecondaryColor; |
| varying vec4 gl_TexCoord[]; // at most will be gl_MaxTextureCoords |
| varying float gl_FogFragCoord; |
| |
| The values in gl_Color and gl_SecondaryColor will be derived automatically |
| by the system from gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, |
| and gl_BackSecondaryColor. This selection process is described in section |
| 2.14.1 of the OpenGL 2.0 Specification. If fixed functionality is used for |
| vertex processing, then gl_FogFragCoord will either be the z-coordinate of |
| the fragment in eye space, or the interpolation of the fog coordinate, as |
| described in section 3.10 of the OpenGL 1.4 Specification. The |
| gl_TexCoord[] values are the interpolated gl_TexCoord[] values from a |
| vertex or geometry shader or the texture coordinates of any fixed pipeline |
| based vertex functionality. |
| |
| Indices to the fragment shader gl_TexCoord array are as described above in |
| the vertex and geometry shader text. |
| |
| Change section 8.7 "Texture Lookup Functions" |
| |
| Change the first paragraph to: |
| |
| Texture lookup functions are available to vertex, geometry and fragment |
| shaders. However, level of detail is not computed by fixed functionality |
| for vertex or geometry shaders, so there are some differences in operation |
| between texture lookups. The functions. |
| |
| Change the third and fourth paragraphs to: |
| |
| In all functions below, the bias parameter is optional for fragment |
| shaders. The bias parameter is not accepted in a vertex or geometry |
| shader. For a fragment shader, if bias is present, it is added to the |
| calculated level of detail prior to performing the texture access |
| operation. If the bias parameter is not provided, then the implementation |
| automatically selects level of detail: For a texture that is not |
| mip-mapped, the texture is used directly. If it is mip- mapped and running |
| in a fragment shader, the LOD computed by the implementation is used to do |
| the texture lookup. If it is mip- mapped and running on the vertex or |
| geometry shader, then the base LOD of the texture is used. |
| |
| The built-ins suffixed with "Lod" are allowed only in a vertex or geometry |
| shader. For the "Lod" functions, lod is directly used as the level of |
| detail. |
| |
| Change section 8.9 Noise Functions |
| |
| Change the first paragraph to: |
| |
| Noise functions are available to the vertex, geometry and fragment |
| shaders. They are... |
| |
| Add a section 8.10 Geometry Shader Functions |
| |
| This section contains functions that are geometry language specific. |
| |
| Syntax: |
| |
| void EmitVertex(); // Geometry only |
| void EndPrimitive(); // Geometry only |
| |
| Description: |
| |
| The function EmitVertex() specifies that a vertex is completed. A vertex |
| is added to the current output primitive using the current values of the |
| varying output variables and the current values of the special built-in |
| output variables gl_PointSize, gl_ClipVertex, gl_Layer, gl_Position and |
| gl_PrimitiveID. The values of any unwritten output variables are |
| undefined. The values of all varying output variables and the special |
| built-in output variables are undefined after a call to EmitVertex(). If a |
| geometry shader, in one invocation, emits more vertices than the value |
| GEOMETRY_VERTICES_OUT_EXT, these emits may have no effect. |
| |
| The function EndPrimitive() specifies that the current output primitive is |
| completed and a new output primitive (of the same type) should be |
| started. This function does not emit a vertex. The effect of |
| EndPrimitive() is roughly equivalent to calling End followed by a new |
| Begin, where the primitive mode is taken from the program object parameter |
| GEOMETRY_OUTPUT_TYPE_EXT. If the output primitive type is 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. |
| |
| Add/Change section 9 (Shading language grammar): |
| |
| init_declarator_list: |
| single_declaration |
| init_declarator_list COMMA IDENTIFIER |
| init_declarator_list COMMA IDENTIFIER array_declarator_suffix |
| init_declarator_list COMMA IDENTIFIER EQUAL initializer |
| |
| single_declaration: |
| fully_specified_type |
| fully_specified_type IDENTIFIER |
| fully_specified_type IDENTIFIER array_declarator_suffix |
| fully_specified_type IDENTIFIER EQUAL initializer |
| |
| array_declarator_suffix: |
| LEFT_BRACKET RIGHT_BRACKET |
| LEFT_BRACKET constant_expression RIGHT_BRACKET |
| LEFT_BRACKET RIGHT_BRACKET array_declarator_suffix |
| LEFT_BRACKET constant_expression RIGHT_BRACKET |
| array_declarator_suffix |
| |
| type_qualifier: |
| CONST |
| ATTRIBUTE // Vertex only |
| VARYING |
| VARYING IN // Geometry only |
| VARYING OUT // Geometry only |
| UNIFORM |
| |
| NVIDIA Implementation Details |
| |
| Because of a hardware limitation, some GeForce 8 series chips use the |
| odd vertex of an incomplete TRIANGLE_STRIP_ADJACENCY_EXT primitive |
| as a replacement adjacency vertex rather than ignoring it. |
| |
| Issues |
| |
| 1. How do geometry shaders fit into the existing GL pipeline? |
| |
| RESOLVED: The following diagram illustrates how geometry shaders fit |
| into the "vertex processing" portion of the GL (Chapter 2 of the OpenGL |
| 2.0 Specification). |
| |
| First, vertex attributes are specified via immediate-mode commands or |
| through vertex arrays. They can be conventional attributes (e.g., |
| glVertex, glColor, glTexCoord) or generic (numbered) attributes. |
| |
| Vertices are then transformed, either using a vertex shader or |
| fixed-function vertex processing. Fixed-function vertex processing |
| includes position transformation (modelview and projection matrices), |
| lighting, texture coordinate generation, and other calculations. The |
| results of either method are a "transformed vertex", which has a |
| position (in clip coordinates), front and back colors, texture |
| coordinates, generic attributes (vertex shader only), and so on. Note |
| that on many current GL implementations, vertex processing is performed |
| by executing a "fixed function vertex shader" generated by the driver. |
| |
| After vertex transformation, vertices are assembled into primitives, |
| according to the topology (e.g., TRIANGLES, QUAD_STRIP) provided by the |
| call to glBegin(). Primitives are points, lines, triangles, quads, or |
| polygons. Many GL implementations do not directly support quads or |
| polygons, but instead decompose them into triangles as permitted by the |
| spec. |
| |
| After initial primitive assembly, a geometry shader is executed on each |
| individual point, line, or triangle primitive, if one is active. It can |
| read the attributes of each transformed vertex, perform arbitrary |
| computations, and emit new transformed vertices. These emitted vertices |
| are themselves assembled into primitives according to the output |
| primitive type of the geometry shader. |
| |
| Then, the colors of the vertices of each primitive are clamped to [0,1] |
| (if color clamping is enabled), and flat shading may be performed by |
| taking the color from the provoking vertex of the primitive. |
| |
| Each primitive is clipped to the view volume, and to any enabled |
| user-defined clip planes. Color, texture coordinate, and other |
| attribute values are computed for each new vertex introduced by |
| clipping. |
| |
| After clipping, the position of each vertex (in clip coordinates) is |
| converted to normalized device coordinates in the perspective division |
| (divide by w) step, and to window coordinates in the viewport |
| transformation step. |
| |
| At the same time, color values may be converted to normalized |
| fixed-point values according to the "Final Color Processing" portion of |
| the specification. |
| |
| After the vertices of the primitive are transformed to window |
| coordinate, the GL determines if the primitive is front- or back-facing. |
| That information is used for two-sided color selection, where a single |
| set of colors is selected from either the front or back colors |
| associated with each transformed vertex. |
| |
| When all this is done, the final transformed position, colors (primary |
| and secondary), and other attributes are used for rasterization (Chapter |
| 3 in the OpenGL 2.0 Specification). |
| |
| When the raster position is specified (via glRasterPos), it goes through |
| the entire vertex processing pipeline as though it were a point. |
| However, geometry shaders are never run on the raster position. |
| |
| |
| |generic |conventional |
| |vertex |vertex |
| |attributes |attributes |
| | | |
| | +-------------------+ |
| | | | |
| V V V |
| vertex fixed-function |
| shader vertex |
| | processing |
| | | |
| | | |
| +<-------------------+ |
| | Output |
| |position, color, Primitive |
| |other vertex data Type |
| | | |
| V | |
| Begin/ primitive geometry primitive | |
| End ------> assembly -----> shader ----> assembly <-+ |
| State | | |
| V | |
| +<------------------------------+ |
| | |
| | |
| | color flat |
| +----------> clamping ----> shading |
| | | |
| V | |
| +<------------------------------+ |
| | |
| | |
| clipping |
| | |
| | perspective viewport |
| +------> divide ----> transform |
| | | |
| | +---+-----+ |
| | V | |
| | final facing | |
| +------> color determination | |
| | processing | | |
| | | | | |
| | | | | |
| | +-----+ +----+ | |
| | | | | |
| | V V | |
| | two-sided | |
| | coloring | |
| | | | |
| | | | |
| +------------------+ | +-------------+ |
| | | | |
| V V V |
| rasterization |
| | |
| | |
| V |
| |
| 2. Why is this called GL_EXT_geometry_shader4? There aren't any previous |
| versions of this extension, let alone three? |
| |
| RESOLVED: To match its sibling, EXT_gpu_shader4 and the assembly |
| version NV_gpu_program4. This is the fourth generation of shading |
| functionality, hence the "4" in the name. |
| |
| 3. Should the GL produce errors at Begin time if an application specifies a |
| primitive mode that is "incompatible" with the geometry shader? For |
| example, if the geometry shader operates on triangles and the |
| application sends a POINTS primitive? |
| |
| RESOLVED: Yes. Mismatches of app-specified primitive types and |
| geometry shader input primitive types appear to be errors and would |
| produce weird and wonderful effects. |
| |
| 4. Can the input primitive type of a geometry shader be determined at run |
| time? |
| |
| RESOLVED: No. Each geometry shader has a single input primitive type, |
| and vertices are presented to the shader in a specific order based on |
| that type. |
| |
| 5. Can the input primitive type of a geometry shader be changed? |
| |
| DISCUSSION: The input primitive type is a property of the program |
| object. A change of the input primitive type means the program object |
| will need to be re-linked. It would be nice if the input primitive type |
| was known at compile time, so that the compiler can do error checking of |
| the type and the number of vertices being accessed by the shader. Since |
| we allow multiple compilation units to form one geometry shader, it is |
| not clear how to achieve that. Therefore, the input primitive type is a |
| property of the program object, and not of a shader object. |
| |
| RESOLVED: Yes, but each change means the program object will have to be |
| re-linked. |
| |
| 6. Can the output primitive type of a geometry shader be determined |
| at run time? |
| |
| RESOLVED: Not in this extension. |
| |
| 7. Can the output primitive type of a program object be changed? |
| |
| RESOLVED: Yes, but the program object will have to be re-linked in order |
| for the change to have effect on program execution. |
| |
| 8. Must the output primitive type of a geometry shader match the |
| input primitive type in any way? |
| |
| RESOLVED: No, you can have a geometry shader generate points out of |
| triangles or triangles out of points. Some combinations are analogous |
| to existing OpenGL operations: reading triangles and writing points or |
| line strips can be used to emulate a subset of PolygonMode |
| functionality. Reading points and writing triangle strips can be used |
| to emulate point sprites. |
| |
| 9. Are primitives emitted by a geometry shader processed like any other |
| OpenGL primitive? |
| |
| RESOLVED: Yes. Antialiasing, stippling, polygon offset, polygon mode, |
| culling, two-sided lighting and color selection, point sprite |
| operations, and fragment processing all work as expected. |
| |
| One limitation is that the only output primitive types supported are |
| points, line strips, and triangle strips, none of which meaningfully |
| support edge flags that are sometimes used in conjunction with the POINT |
| and LINE polygon modes. Edge flags are always ignored for line-mode |
| triangle strips. |
| |
| 10. Should geometry shaders support additional input primitive types? |
| |
| RESOLVED: Possibly in a future extension. It should be straightforward |
| to build a future extension to support geometry shaders that operate on |
| quads. Other primitive types might be more demanding on hardware. Quads |
| with adjacency would require 12 vertices per shader execution. General |
| polygons may require even more, since there is no fixed bound on the |
| number of vertices in a polygon. |
| |
| 11. Should geometry shaders support additional output primitive types? |
| |
| RESOLVED: Possibly in a future extension. Additional output types |
| (e.g., independent lines, line loops, triangle fans, polygons) may be |
| useful in the future; triangle fans/polygons seem particularly useful. |
| |
| 12. How are adjacency primitives processed by the GL? |
| |
| RESOLVED: The primitive type of an adjacent primitive is set as a Begin |
| mode parameter. Any vertex of an adjacency primitive will be treated as |
| a regular vertex, and processed by a vertex shader as well as the |
| geometry shader. The geometry shader cannot output adjacency primitives, |
| thus processing stops with the geometry shader. If a geometry shader is |
| not active, the GL ignores the "adjacent" vertices in the adjacency |
| primitive. |
| |
| 13. Should we provide additional adjacency primitive types that can be |
| used inside a Begin/End? |
| |
| RESOLVED: Not in this extension. It may be desirable to add new |
| primitive types (e.g., TRIANGLE_FAN_ADJACENCY) in a future extension. |
| |
| 14. How do geometry shaders interact with RasterPos? |
| |
| RESOLVED: Geometry shaders are ignored when specifying the raster |
| position. |
| |
| 15. How do geometry shaders interact with pixel primitives |
| (DrawPixels, Bitmap)? |
| |
| RESOLVED: They do not. |
| |
| 16. Is there a limit on the number of vertices that can be emitted by |
| a geometry shader? |
| |
| RESOLVED: Unfortunately, yes. Besides practical hardware limits, there |
| may also be practical performance advantages when applications guarantee |
| a tight upper bound on the number of vertices a geometry shader will |
| emit. GPUs frequently excecute programs in parallel, and there are |
| substantial implementation challenges to parallel execution of geometry |
| threads that can write an unbounded number of results, particular given |
| that all the primitives generated by the first geometry shader |
| invocation must be consumed before any of the primitives generated by |
| the second program invocation. Limiting the amount of data a geometry |
| shader can write substantially eases the implementation burden. |
| |
| A program object, holding a geometry shader, must declare a maximum |
| number of vertices that can be emitted. There is an |
| implementation-dependent limit on the total number of vertices a program |
| object can emit (256 minimum) and the product of the number of vertices |
| emitted and the number of components of all active varying variables |
| (1024 minimum). |
| |
| It would be ideal if the limit could be inferred from the instructions |
| in the shader itself, and that would be possible for many shaders, |
| particularly ones with straight-line flow control. For shaders with |
| more complicated flow control (subroutines, data- dependent looping, and |
| so on), it would be impossible to make such an inference and a "safe" |
| limit would have to be used with adverse and possibly unexpected |
| performance consequences. |
| |
| The limit on the number of EmitVertex() calls that can be issued can not |
| always be enforced at compile time, or even at Begin time. We specify |
| that if a shader tries to emit more vertices than allowed, emits that |
| exceed the limit may or may not have any effect. |
| |
| 17. Should it be possible to change the limit GEOMETRY_VERTICES_OUT_EXT, the |
| number of vertices emitted by a geometry shader, after the program |
| object, containing the shader, is linked? |
| |
| RESOLVED: NO. See also issue 31. Changing this limit might require a |
| re-compile and/or re-link of the shaders and program object on certain |
| implementations. Pretending that this limit can be changed without |
| re-linking does not reflect reality. |
| |
| 18. How do user clipping and geometry shaders interact? |
| |
| RESOLVED: Just like vertex shaders and user clipping interact. The |
| geometry shader needs to provide the (eye) position gl_ClipVertex. |
| Primitives are clipped after geometry shader execution, not before. |
| |
| 19. How do edge flags interact with adjacency primitives? |
| |
| RESOLVED: If geometry programs are disabled, adjacency primitives are |
| still supported. For TRIANGLES_ADJACENCY_EXT, edge flags will apply as |
| they do for TRIANGLES. Such primitives are rendered as independent |
| triangles as though the adjacency vertices were not provided. Edge |
| flags for the "real" vertices are supported. For all other adjacency |
| primitive types, edge flags are irrelevant. |
| |
| 20. Now that a third shader object type is added, what combinations of |
| GLSL, assembly (ARB or NV) low level and fixed-function do we want |
| to support? |
| |
| DISCUSSION: With the addition of the geometry shader, the number of |
| combinations the GL pipeline could support doubled (there is no |
| fixed-function geometry shading). Possible combinations now are: |
| |
| vertex geometry fragment |
| |
| ff/ASM/GLSL none/ASM/GLSL ff/ASM/GLSL |
| |
| for a total of 3 x 3 x 3 is 27 combinations. Before the geometry shader |
| was added, the number of combinations was 9, and those we need to |
| support. We have a choice on the other 18. |
| |
| RESOLUTION: It makes sense to draw a line at raster in the GL |
| pipeline. The 'north' side of this line covers vertex and geometry |
| shaders, the 'south' side fragment shaders. We now add a simple rule |
| that states that if a program object contains anything north of this |
| line, the north side will be 100% GLSL. This means that: |
| |
| a) GLSL program objects with a vertex shader can only use a geometry |
| shader and not an assembly geometry program. If an assembly geometry |
| program is enabled, it is bypassed. This also avoids a tricky case -- a |
| GLSL program object with a vertex and a fragment program linked |
| together. Injecting an assembly geometry shader in the middle at run |
| time won't work well. |
| |
| b) GLSL program objects with a geometry shader must have a vertex shader |
| (cannot be ARB/NV or fixed-function vertex shading). |
| |
| The 'south' side in this program object still can be any of |
| ff/ARB/NV/GLSL. |
| |
| 21. How do geometry shaders interact with color clamping? |
| |
| RESOLVED: Geometry shader execution occurs prior to color clamping in |
| the pipeline. This means the colors written by vertex shaders are not |
| clamped to [0,1] before they are read by geometry shaders. If color |
| clamping is enabled, any vertex colors written by the geometry shader |
| will have their components clamped to [0,1]. |
| |
| 22. What is a primitive ID and a vertex ID? I am confused. |
| |
| DISCUSSION: A vertex shader can read a built-in attribute that holds the |
| ID of the current vertex it is processing. See the EXT_gpu_shader4 spec |
| for more information on vertex ID. If the geometry shader needs access |
| to a vertex ID as well, it can be passed as a user-defined varying |
| variable. A geometry shader can read a built-in varying variable that |
| holds the ID of the current primitive it is processing. It also has the |
| ability to write to a built-in output primitive ID variable, to |
| communicate the primitive ID to a fragment shader. A fragment shader |
| can read a built-in attribute that holds the ID of the current primitive |
| it is processing. A primitive ID will be generated even if no geometry |
| shader is active. |
| |
| 23. After a call to EmitVertex(), should the values of the output varying |
| variables be retained or be undefined? |
| |
| DISCUSSION: There is not a clear answer to this question .The underlying |
| HW mechanism is as follows. An array of output registers is set aside to |
| store vertices that make up primitives. After each EmitVertex() a |
| pointer into that array is incremented. The shader no longer has access |
| to the previous set of values. This argues that the values of output |
| varying variables should be undefined after an EmitVertex() call. The |
| shader is responsible for writing values to all varying variables it |
| wants to emit, for each emit. The counter argument to this is that this |
| is not a nice model for GLSL to program in. The compiler can store |
| varying outputs in a temp register and preserve their values across |
| EmitVertex() calls, at the cost of increased register pressure. |
| |
| RESOLUTION: For now, without being a clear winner, we've decided to go |
| with the undefined option. The shader is responsible for writng values |
| to all varying variabvles it wants to emit, for each emit. |
| |
| 24. How to distinguish between input and output "varying" variables? |
| |
| DISCUSSION: Geometry shader outputs are varying variables consistent |
| with the existing definition of varying (used to communicate to the |
| fragment processing stage). Geometry inputs are received from a vertex |
| shader writing to its varying variable outputs. The inputs could be |
| called "varying", to match with the vertex shader, or could be called |
| "attributes" to match the vertex shader inputs (which are called |
| attributes). |
| |
| RESOLUTION: We'll call input variables "varying", and not |
| "attributes". To distinguish between input and output, they will be |
| further qualified with the words "in" and "out" resulting in, for |
| example: |
| |
| varying in float foo; |
| varying out vec4 bar[]; |
| |
| 25. What is the syntax for declaring varying input variables? |
| |
| DISCUSSION: We need a way to distinguish between the vertices of the |
| input primitive. Suggestions: |
| |
| 1. Declare each input varying variable as an unsized array. Its size |
| is inferred by the linker based on the output primitive type. |
| |
| 2. Declare each input varying variable as a sized array. If the size |
| does not match the output primitive type, a link error occurs. |
| |
| 3. Have an array of structures, where the structure contains the |
| attributes for each vertex. |
| |
| RESOLUTION: Option 1 seems simple and solves the problem, but it is not |
| a clear winner over the other two. To aid the shader writer in figuring |
| out the size of each array, a new built-in constant, gl_VerticesIn, is |
| defined that holds the number of vertices for the current input |
| primitive type. |
| |
| 26. Does gl_PointSize, gl_Layer, gl_ClipVertex count agains the |
| MAX_GEOMETRY_VARYING_COMPONENTS limit? |
| |
| RESOLUTION: Core OpenGL 2.0 makes a distinction between varying |
| variables, output from a vertex shader and interpolated over a |
| primitive, and 'special built-in variables' that are outputs, but not |
| interpolated across a primitive. Only varying variables do count against |
| the MAX_VERTEX_VARYING_COMPONENTS limit. gl_PointSize, gl_Layer, |
| gl_ClipVertex and gl_Position are 'special built-in' variables, and |
| therefore should not count against the limit. If HW does need to take |
| components away to support those, that is ok. The actual spec language |
| does mention possible implementation dependencies. |
| |
| 27. Should writing to gl_Position be optional? |
| |
| DISCUSSION: Before this extensions, the OpenGL Shading Language required |
| that gl_Position be written to in a vertex shader. With the addition of |
| geometry shaders, it is not necessary anymore for a vertex shader to |
| output gl_Position. The geometry shader can do so. With the addition of |
| transform-feedback (see the transform feedback specification) it is not |
| necessary useful for the geometry shader to write out gl_Position |
| either. |
| |
| RESOLUTION: Yes, this should be optional. |
| |
| 28. Should geometry shaders be able to select a layer of a 3D texture, cube |
| map texture, or array texture at run time? If so, how? |
| |
| RESOLVED: See also issue 32. This extension provides a per-vertex output |
| called "gl_Layer", which is an integer specifying the layer to render |
| to. In order to get defined results, the value of gl_Layer needs to be |
| constant for each primitive (point, line or triangle) being emitted by a |
| geometry shader. This layer value is used for all fragments generated by |
| that primitive. |
| |
| The EXT_framebuffer_object (FBO) extension is used for rendering to |
| textures, but for cube maps and 3D textures, it only provides the |
| ability to attach a single face or layer of such textures. |
| |
| This extension generalizes FBO by creates new entry points to bind an |
| entire texture level (FramebufferTextureEXT) or a single layer of a |
| texture level (FramebufferTextureLayerEXT) or a single face of a level |
| of a cube map texture (FramebufferTextureFaceEXT) to an attachment |
| point. The existing FBO binding functions, FramebufferTexture[123]DEXT |
| are retained, and are defined in terms of the more general new |
| functions. |
| |
| The new functions do not have a dimension in the function name or a |
| <textarget> parameter, which can be inferred from the provided |
| texture. |
| |
| When an entire texel level of a cube map, 3D, or array texture is |
| attached, that attachment is considered layered. The framebuffer is |
| considered layered if any attachment is layered. When the framebuffer |
| is layered, there are three additional completeness requirements: |
| |
| * all attachments must be layered |
| * all color attachments must be from textures of identical type |
| * all attachments must have the same number of layers |
| |
| We expect subsequent versions of the FBO spec to relax the requirement |
| that all attachments must have the same width and height, and plan to |
| relax the similar requirement for layer count at that time. |
| |
| When rendering to a layered framebuffer, layer zero is used unless a |
| geometry shader that writes (statically assings, to be precise) to |
| gl_Layer. When rendering to a non-layered framebuffer, the value of |
| gl_Layer is ignored and the set of single-image attachments are used. |
| When reading from a layered framebuffer (e.g., ReadPixels), layer zero |
| is always used. When clearing a layered framebuffer, all layers are |
| cleared to the corresponding clear values. |
| |
| Several other approaches were considered, including leveraging existing |
| FBO attachment functions and requiring the use of FramebufferTexture3D |
| with a <zoffset> of zero to make a framebuffer attachment "layerable" |
| (attaching layer zero means that the attachment could be used for either |
| layered- or non- layered rendering). Whether rendering was layered or |
| not could either be inferred from the active geometry shader, or set as |
| a new property of the framebuffer object. There is presently no |
| FramebufferParameter API to set a property of a framebuffer, so it would |
| have been necessary to create new set/query APIs if this approach were |
| chosen. |
| |
| 29. How should per-vertex point size work with geometry shaders? |
| |
| RESOLVED: The value of the existing VERTEX_PROGRAM_POINT_SIZE enable, to |
| control the point size behavior of a vertex shader, does not affect |
| geometry shaders. Specifically, If a geometry shader is active, the |
| point size is taken from the point size output gl_PointSize of the |
| vertex shader, regardless of the value of VERTEX_PROGRAM_POINT_SIZE. |
| |
| 30. Geometry shaders don't provide a QUADS or generic POLYGON input |
| primitive type. In this extension, what happens if an application |
| provides QUADS, QUAD_STRIP, or POLYGON primitives? |
| |
| RESOLVED: Not all vendors supporting this extension were able to accept |
| quads and polygon primitives as input, so such functionality was not |
| provided in this extension. This extension requires that primitives |
| provided to the GL must match the input primitive type of the active |
| geometry shader (if any). QUADS, QUAD_STRIP, and POLYGON primitives are |
| considered not to match any input primitive type, so an |
| INVALID_OPERATION error will result. |
| |
| The NV_geometry_shader4 extension (built on top of this one) allows |
| applications to provide quads or general polygon primitives to a |
| geometry shader with an input primitive type of TRIANGLES. Such |
| primitives are decomposed into triangles, and a geometry shader is run |
| on each triangle independently. |
| |
| 31. Geometry shaders provide a limit on the number of vertices that can be |
| emitted. Can this limit be changed at dynamically? |
| |
| RESOLVED: See also issue 17. Not in this extension. This functionality |
| was not provided because it would be an expensive operation on some |
| implementations of this extension. The NV_geometry_shader4 extension |
| (layered on top of this one) does allow applications to change this |
| limit dynamically. |
| |
| An application can change the vertex output limit at any time. To allow |
| for the possibility of dynamic changes (as in NV_geometry_shader4) but |
| not require it, a limit change is not guaranteed to take effect unless |
| the program object is re-linked. However, there is no guarantee that |
| such limit changes will not take effect immediately. |
| |
| 32. See also issue 28. Each vertex emitted by a geometry shader can specify |
| a layer to render to using the output variable "gl_Layer". For |
| LINE_STRIP and TRIANGLE_STRIP output primitive types, which vertex's |
| layer is used? |
| |
| RESOLVED: The vertex from which the layer is extracted is unfortunately |
| undefined. In practice, some implementations of this extension will |
| extract the layer number from the first vertex of the output primitive; |
| others will extract it from the last (provoking) vertex. A future |
| geometry shader extension may choose to define this behavior one way or |
| the other. |
| |
| To get portable results, the layer number should be the same for all |
| vertices in any single primitive emitted by the geometry shader. The |
| EndPrimitive() built-in function available in a geometry shader starts a |
| new primitive, and the layer number emitted can be safely changed after |
| EndPrimitive() is called. |
| |
| 33. The grammar allows "varying", "varying out", and "varying in" as |
| type-qualifiers for geometry shaders. What does "varying" without "in" |
| or "out" mean for a geometry shader? |
| |
| RESOLVED: The "varying" type qualifier in a geometry shader not |
| followed by "in" or "out" means the same as "varying out". |
| |
| This is consistent with the specification saying: "In order to seamlessly |
| be able to insert or remove a geometry shader from a program object, |
| the rules, names and types of the output built-in varying variables and |
| user-defined varying variables are the same as for the vertex shader." |
| |
| 34. What happens if you try to do a framebuffer blit (EXT_framebuffer_blit) |
| to/from a layered framebuffer? |
| |
| RESOLVED: BlitFramebufferEXT() is a two-dimensional operation (only has |
| a width and height), so only reads/writes layer zero. The framebuffer |
| blit operation is defined partially in terms of CopyPixels, which itself |
| is defined in terms of ReadPixels and DrawPixels. This spec defines |
| both operations to use layer zero when a layered framebuffer is |
| involved. |
| |
| It may be desirable to provide a three-dimensional framebuffer blit |
| operation or an explicit copy single-step operation between two |
| three-dimensional, cube map, or array textures. That functionality is |
| left for a future extension or OpenGL version. |
| |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- ----------------------------------------- |
| 22 12/14/09 mgodse Added GLX protocol. |
| |
| 21 07/21/09 pbrown Clarify that when doing layered rendering, |
| a layer specified in the shader is used to |
| select the depth and stencil layers accessed. |
| |
| 20 07/29/08 pbrown Minor typo fix. |
| |
| 19 04/04/08 pbrown Changed MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT |
| minimum value to zero, to match discussion (from |
| aeddy). Added separators to group pictures and |
| discussions of each of the new primitive types |
| together. |
| |
| 18 03/15/08 pbrown Additional dependency on EXT_framebuffer_blit; |
| blits to/from layered targets affect only |
| layer zero. |
| |
| 17 05/22/07 mjk Clarify that "varying" means the same as |
| "varying out" in a geometry shader. |
| |
| 16 01/10/07 pbrown Specify that the total component limit is |
| enforced at LinkProgram time. |
| |
| 15 12/15/06 pbrown Documented that the '#extension' token |
| for this extension should begin with "GL_", |
| as apparently called for per convention. |
| |
| 14 -- Pre-release revisions. |