Google Git
Sign in
skia / external / github.com / KhronosGroup / OpenGL-Registry / 8e729daa702d45597ccffa0c964bba1eca10a9e6 / . / extensions / NV / NV_geometry_program4.txt
blob: 531e466871d212f3daa0fbf2082c07695be0f6f0 [file] [log] [blame]
Name
NV_geometry_program4
Name Strings
(none)
Contact
Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
Status
Shipping for GeForce 8 Series (November 2006)
Version
Last Modified Date: 12/14/09
NVIDIA Revision: 13
Number
323
Dependencies
OpenGL 1.1 is required.
This extension is written against the OpenGL 2.0 specification.
NV_gpu_program4 is required. This extension is supported if
"GL_NV_gpu_program4" is found in the extension string.
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.
Overview
NV_geometry_program4 defines a new type of program available to be run on
the GPU, called a geometry program. Geometry programs are run on full
primitives after vertices are transformed, but prior to flat shading and
clipping.
A geometry program begins with a single primitive - a point, line, or
triangle. Quads and polygons are allowed, but are decomposed into
individual triangles prior to geometry program execution. It can read the
attributes of any of the vertex in the primitive and use them to generate
new primitives. A geometry program has a fixed output primitive type,
either a point, a line strip, or a triangle strip. It emits vertices
(using the EMIT opcode) to define the output primitive. The attributes of
emitted vertices are specified by writing to the same set of result
bindings (e.g., "result.position") provided for vertex programs.
Additionally, a geometry program can emit multiple disconnected primitives
by using the ENDPRIM opcode, which is roughly equivalent to calling End
and then Begin again. The primitives emitted by the geometry program are
then clipped and then processed like an equivalent OpenGL primitive
specified by the application.
This extension 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 "adjacency" vertices can be accessed by
geometry programs and used to match up the outputs of the geometry program
with those of neighboring primitives.
Additionally, geometry programs allow for layered rendering, where entire
three-dimensional, cube map, or array textures (EXT_texture_array) can be
bound to the current framebuffer. Geometry programs can use the
"result.layer" binding to select a layer or cube map face to render to.
Each primitive emitted by such a geometry program is rendered to the layer
taken from its provoking vertex.
Since geometry programs expect a specific input primitive type, an error
will occur if the application presents primtives of a different type. For
example, if an enabled geometry program expects points, an error will
occur at Begin() time, if a primitive mode of TRIANGLES is specified.
New Procedures and Functions
void ProgramVertexLimitNV(enum target, int limit);
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 <cap> parameter of Disable, Enable, and IsEnabled, by
the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
GetDoublev, and by the <target> parameter of ProgramStringARB,
BindProgramARB, ProgramEnvParameter4[df][v]ARB,
ProgramLocalParameter4[df][v]ARB, GetProgramEnvParameter[df]vARB,
GetProgramLocalParameter[df]vARB, GetProgramivARB and
GetProgramStringARB:
GEOMETRY_PROGRAM_NV 0x8C26
Accepted by the <pname> parameter of GetProgramivARB:
MAX_PROGRAM_OUTPUT_VERTICES_NV 0x8C27
MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV 0x8C28
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
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
GetFramebufferAttachmentParameterivEXT:
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: The "EXT" tokens above are shared with the EXT_geometry_shader4
extension.)
(Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER 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 programs are
enabled, even if no vertex program is used.)
Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation)
Modify Section 2.6.1 (Begin and End Objects), p. 13
(Add to end of section, p. 18)
(add figure)
1 - - - 2----->3 - - - 4 1 - - - 2--->3--->4--->5 - - - 6
5 - - - 6----->7 - - - 8
(a) (b)
Figure X.1 (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 program.
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
program (Section 2.15). If geometry programs are disabled, 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 X.1.
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
geometry programs (Section 2.15). If geometry programs are disabled, 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
vertices are considered adjacent to the i + 2nd and i + 3rd vertices,
respectively. See Figure X.1.
Line strips with adjacency are generated by calling Begin with the
argument value LINE_STRIP_ADJACENCY_EXT.
(add figure)
2 - - - 3 - - - 4 8 - - - 9 - - - 10
^\ ^\
\ | \ | \ | \ |
| \ | \
\ | \ | \ | \ |
| \ | \
\ | \ | \ | \ |
| v | v
1<------5 7<------11
\ | \ |
\ | \ |
\ | \ |
6 12
Figure X.2 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 program.
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 geometry
programs (Section 2.15). If geometry programs are disabled, 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 X.2.
Triangles with adjacency are generated by calling Begin with the argument
value TRIANGLES_ADJACENCY_EXT.
(add figure)
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 X.3 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
program.
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 geometry
programs (Section 2.15). If geometry programs are disabled, 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 X.1 describes
the vertices and order used to draw each triangle, and which vertices are
considered adjacent to each edge of the triangle. See Figure X.3.
(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 X.1: 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
and programs 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 program is active, programs can write front and
back colors using the available color result bindings. When a vertex or
geometry shader or program 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.
Insert New Section 2.14.6, Geometry Programs (between 2.14.5, Color Index
Lighting and 2.14.6, Clamping and Masking, p. 69)
Section 2.14.6, Geometry Programs
Each primitive may be optionally transformed by a geometry program.
Geometry programs are enabled by calling Enable with the value
GEOMETRY_PROGRAM_NV. A geometry program takes a single input primitive
and generates vertices to be arranged into one or more output primitives.
The original input primitive is discarded, and the output primitives are
processed in order by the remainder of the GL pipeline.
Section 2.14.6.1, Geometry Program Input Primitives
A geometry program can operate on one of five input primitive types, as
specified by the mandatory "PRIMITIVE_IN" declaration. Depending on the
input primitive type, one to six vertices are available when the program
is executed. A geometry program will fail to load unless it contains
exactly one such declaration.
Each input primitive type supports only a subset of the primitives
provided by the GL. If geometry programs are enabled, 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 current geometry program.
The supported input primitive types are:
Points (POINTS)
Geometry programs that operate on points are valid only for the POINTS
primitive type. There is a only a single vertex available for each
program invocation: "vertex[0]" refers to the single point.
Lines (LINES)
Geometry programs 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 program invocation: "vertex[0]" and "vertex[1]" refer
to the beginning and end of the line segment.
Lines with Adjacency (LINES_ADJACENCY)
Geometry programs 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. "vertex[1]" and "vertex[2]" refer to the beginning and end of
the line segment. "vertex[0]" and "vertex[3]" refer to the vertices
adjacent to the beginning and end of the line segment, respectively.
Triangles (TRIANGLES)
Geometry programs that operate on triangles are valid for the TRIANGLES,
TRIANGLE_STRIP, TRIANGLE_FAN, QUADS, QUAD_STRIP, and POLYGON primitive
types.
When used with a geometry program that operates on triangles, QUADS,
QUAD_STRIP, and POLYGON primitives are decomposed into triangles in an
unspecified, implementation-dependent manner. For convex polygons
(already required in the core GL specification), this decomposition
satisfies three properties:
* the collection of triangles fully covers the area of the original
primitive,
* no two triangles in the decomposition overlap, and
* the orientation of each triangle is consistent with the orientation of
the original primitive.
For such primitives, the program is executed once for each triangle in the
decomposition.
There are three vertices available for each program invocation.
"vertex[0]", "vertex[1]", and "vertex[2]", refer to the first, second, and
third vertex of the triangle, respectively.
Triangles with Adjacency (TRIANGLES_ADJACENCY)
Geometry programs 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. "vertex[0]", "vertex[2]", and "vertex[4]" refer to the first,
second, and third vertex of the triangle respectively. "vertex[1]",
"vertex[3]", and "vertex[5]" refer to 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.14.6.2, Geometry Program Output Primitives
A geometry program can generate primitives of one of three types, as
specified by the mandatory "PRIMITIVE_OUT" declaration. A geometry
program will fail to load unless it contains exactly one such declaration.
The supported output primitive types are points (POINTS), line strips
(LINE_STRIP), and triangle strips (TRIANGLE_STRIP). The vertices output
by the geometry program are decomposed into points, lines, or triangles
based on the output primitive type in the manner described in section
2.6.1.
Section 2.14.6.3, Geometry Program Execution Environment
Geometry programs execute using the instruction set documented in the
GL_NV_gpu_program4 extension specification and in a manner similar to
vertex programs. Each vertex attribute access must identify the vertex
number being accessed. For example, "vertex[1].position" identifies the
transformed position of "vertex[1]" as specified in teh description of the
input primitive type. Output vertices are specified by writing to vertex
result variables in the same manner as done by vertex programs.
The special instruction "EMIT" specifies that a vertex is completed. A
vertex is added to the current output primitive using the current values
of the vertex result variables. The values of any unwritten result
variables (or components) are undefined.
After an EMIT instruction is completed, the current values of all vertex
result variables become undefined. If a program wants to ensure that the
same result is used for every vertex written by the program, it is
necessary to write the corresponding value once per vertex.
The special instruction "ENDPRIM" specifies that the current output
primitive should be completed and a new output primitive should be
started. A geometry program starts with an output primitive containing no
vertices. When a geometry program terminates, the current output
primitive is automatically completed. ENDPRIM has no effect if the
geometry program's output primitive type is POINTS.
When a primitive generated by a geometry program is completed, the
vertices added by the EMIT instruction are decomposed into points, lines,
or triangles according to the output primitive type in the manner
described in Section 2.8.1. The resulting primitives are then clipped and
rasterized. If the number of vertices emitted by the geometry program is
not sufficient to produce a single primitive, nothing is drawn.
Like vertex and fragment programs, geometry programs can access textures.
The maximum number of texture image units that can be accessed by a
geometry program is given by the value of
MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT.
Section 2.14.6.4, Geometry Program Output Limits
A geometry program may not emit an unlimited number of vertices per
invocation. Each geometry program must declare a vertex limit, which is
the maximum number of vertices that the program can ever produce. The
vertex limit is specified using the "VERTICES_OUT" declaration. A
geometry program will fail to load unless it contains exactly one such
declaration.
There are two implementation-dependent limits that limit the total number
of vertices that a program can emit. First, the vertex limit may not
exceed the value of MAX_PROGRAM_OUTPUT_VERTICES_NV. Second, product of
the vertex limit and the number of result variable components written by
the program (PROGRAM_RESULT_COMPONENTS_NV, as described in section 2.X.3.5
of NV_gpu_program4) may not exceed the value of
MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV. A geometry program will fail to
load if its maximum vertex count or maximum total component count exceeds
the implementation-dependent limit. The limits may be queried by calling
GetProgramiv with a <target> of GEOMETRY_PROGRAM_NV. Note that the
maximum number of vertices that a geometry program can emit may be much
lower than MAX_PROGRAM_OUTPUT_VERTICES_NV if the program writes a large
number of result variable components.
After a geometry program is compiled, the vertex limit may be changed
using the command
void ProgramVertexLimitNV(enum target, int limit);
<target> must be GEOMETRY_PROGRAM_NV. <limit> is the new vertex limit,
which must satisfy the two rules described above. The error INVALID_VALUE
is generated if <limit> is less than or equal to zero, <limit> is greater
than or equal to MAX_PROGRAM_OUTPUT_VERTICES_NV, or if the total number of
components emitted would exceed MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV.
The error INVALID_OPERATION is generated if the current geometry program
has not been successfully loaded.
When a program executes, the number of vertices it emits should not exceed
the vertex limit. Once a geometry program emits a number of vertices
equal to the vertex limit, subsequent EMIT instructions may or may not
have any effect.
Modify Section 2.X.2, Program Grammar
(replace third paragraph)
Geometry programs are required to begin with the header string
"!!NVgp4.0". This header string identifies the subsequent program body as
being a geometry program and indicates that it should be parsed according
to the base NV_gpu_program4 grammar plus the additions below. Program
string parsing begins with the character immediately following the header
string.
(add the following grammar rules to the NV_gpu_program4 base grammar)
<declSequence> ::= <declaration> <declSequence>
<instruction> ::= <SpecialInstruction>
<attribUseV> ::= <attribVarName> <arrayMem> <arrayMem>
<swizzleSuffix>
<attribUseS> ::= <attribVarName> <arrayMem> <arrayMem>
<scalarSuffix>
<attribUseVNS> ::= <attribVarName> <arrayMem> <arrayMem>
<resultUseW> ::= <resultVarName> <arrayMem> <optWriteMask>
| <resultColor> <optWriteMask>
| <resultColor> "." <colorType> <optWriteMask>
| <resultColor> "." <faceType> <optWriteMask>
| <resultColor> "." <faceType> "." <colorType>
"." <optWriteMask>
<resultUseD> ::= <resultColor>
| <resultColor> "." <colorType>
| <resultMulti>
<declaration> ::= "PRIMITIVE_IN" <declPrimInType>
| "PRIMITIVE_OUT" <declPrimOutType>
| "VERTICES_OUT" <int>
<declPrimInType> ::= "POINTS"
| "LINES"
| "LINES_ADJACENCY"
| "TRIANGLES"
| "TRIANGLES_ADJACENCY"
<declPrimOutType> ::= "POINTS"
| "LINE_STRIP"
| "TRIANGLE_STRIP"
<SpecialInstruction> ::= "EMIT"
| "ENDPRIM"
<attribBasic> ::= <vtxPrefix> "position"
| <vtxPrefix> "fogcoord"
| <vtxPrefix> "pointsize"
| <vtxPrefix> "id"
| <attribTexCoord> <optArrayMemAbs>
| <attribClip> <arrayMemAbs>
| <attribGeneric> <arrayMemAbs>
| "primitive" "." "id"
<attribColor> ::= <vtxPrefix> "color"
<attribMulti> ::= <attribTexCoord> <arrayRange>
| <attribClip> <arrayRange>
| <attribGeneric> <arrayRange>
<attribTexCoord> ::= <vtxPrefix> "texcoord"
<attribClip> ::= <vtxPrefix> "clip"
<attribGeneric> ::= <vtxPrefix> "attrib"
<vtxPrefix> ::= "vertex" <optArrayMemAbs>
<resultBasic> ::= <resPrefix> "position"
| <resPrefix> "fogcoord"
| <resPrefix> "pointsize"
| <resPrefix> "primid"
| <resPrefix> "layer"
| <resultTexCoord> <optArrayMemAbs>
| <resultClip> <arrayMemAbs>
| <resultGeneric> <arrayMemAbs>
<resultColor> ::= <resPrefix> "color"
<resultMulti> ::= <resultTexCoord> <arrayRange>
| <resultClip> <arrayRange>
| <resultGeneric> <arrayRange>
<resultTexCoord> ::= <resPrefix> "texcoord"
<resultClip> ::= <resPrefix> "clip"
<resultGeneric> ::= <resPrefix> "attrib"
<resPrefix> ::= "result" "."
(add the following subsection to section 2.X.3.2, Program Attribute
Variables)
Geometry program attribute variables describe the attributes of each
transformed vertex accessible to the geometry program. Most attributes
correspond to the per-vertex results generated by vertex program execution
or fixed-function vertex processing. The "primitive.id" attribute is
generated specially, as described below.
If vertex programs are enabled, attributes will be obtained from the
per-vertex outputs of the vertex program used to generate the vertex in
question. Geometry program attributes should be read using the same
component data type used to write the corresponding vertex program
results. The value of any attribute corresponding to a vertex output not
written by the vertex program is undefined.
If vertex programs are disabled, attributes will be obtained from the
values computed by fixed-function vertex processing. All attributes,
except for the primitive ID should be read as floating-point values in
this case.
Geometry Vertex Binding Components Description
----------------------------- ---------- ----------------------------
vertex[m].position (x,y,z,w) clip coordinates
vertex[m].color (r,g,b,a) front primary color
vertex[m].color.primary (r,g,b,a) front primary color
vertex[m].color.secondary (r,g,b,a) front secondary color
vertex[m].color.front (r,g,b,a) front primary color
vertex[m].color.front.primary (r,g,b,a) front primary color
vertex[m].color.front.secondary (r,g,b,a) front secondary color
vertex[m].color.back (r,g,b,a) back primary color
vertex[m].color.back.primary (r,g,b,a) back primary color
vertex[m].color.back.secondary (r,g,b,a) back secondary color
vertex[m].fogcoord (f,-,-,-) fog coordinate
vertex[m].pointsize (s,-,-,-) point size
vertex[m].texcoord (s,t,r,q) texture coordinate, unit 0
vertex[m].texcoord[n] (s,t,r,q) texture coordinate, unit n
vertex[m].attrib[n] (x,y,z,w) generic interpolant n
vertex[m].clip[n] (d,-,-,-) clip plane distance
vertex[m].texcoord[n..o] (s,t,r,q) array of texture coordinates
vertex[m].attrib[n..o] (x,y,z,w) array of generic interpolants
vertex[m].clip[n..o] (d,-,-,-) array of clip distances
vertex[m].id (id,-,-,-) vertex id
primitive.id (id,-,-,-) primitive number
Table X.2, Geometry Program Attribute Bindings. <m> refers to a vertex
number, while <n>, and <o> refer to integer constants. Only the
"vertex[m].texcoord" and "vertex.attrib" bindings are available in
arrays.
For bindings that include "vertex[m]", <m> identifies the vertex number
whose attributes are used for the binding. For bindings in explicit
variable declarations, "[m]" is optional. If "[m]" is specified, <m> must
be an integer constant and must be in the valid range of vertices
supported for the input primitive type. If "[m]" is not specified, the
declared variable is accessed as an array, with the first array index
specifying the vertex number. If such a variable is declared an array, it
must have a second array index to identify the individual array element.
For bindings used directly in instructions, "[m]" is required and must be
an integer constant specifying a vertex number. The following examples
illustrate various legal and illegal geometry program bindings and their
meanings.
ATTRIB pos = vertex.position;
ATTRIB pos2 = vertex[2].position;
ATTRIB texcoords[] = { vertex.texcoord[0..3] };
ATTRIB tcoords1[4] = { vertex[1].texcoord[1..4] };
INT TEMP A0;
...
MOV R0, pos[1]; # position of vertex 1
MOV R0, vertex[1].position; # position of vertex 1
MOV R0, pos2; # position of vertex 2
MOV R0, texcoords[A0.x][1]; # texcoord 1 of vertex A0.x
MOV R0, texcoords[A0.x][A0.y]; # texcoord A0.y of vertex A0.x
MOV R0, tcoords1[2]; # texcoord 3 of vertex 1
MOV R0, vertex[A0.x].texcoord[1]; # ILLEGAL allowed -- vertex number
# must be constant here.
If a geometry attribute binding matches "vertex[m].position", the "x",
"y", "z" and "w" components of the geometry attribute variable are filled
with the "x", "y", "z", and "w" components, respectively, of the
transformed position of vertex <m>, in clip coordinates.
If a geometry attribute binding matches any binding in Table X.2 beginning
with "vertex[m].color", the "x", "y", "z", and "w" components of the
geometry attribute variable are filled with the "r", "g", "b", and "a"
components, respectively, of the corresponding color of vertex <m>.
Bindings containing "front" and "back" refer to the front and back colors,
respectively. Bindings containing "primary" and "secondary" refer to
primary and secondary colors, respectively. If face or color type is
omitted in the binding, the binding is treated as though "front" and
"primary", respectively, were specified.
If a geometry attribute binding matches "vertex[m].fogcoord", the "x"
component of the geometry attribute variable is filled with the fog
coordinate of vertex <m>. The "y", "z", and "w" components are undefined.
If a geometry attribute binding matches "vertex[m].pointsize", the "x"
component of the geometry attribute variable is filled with the point size
of vertex <m> computed by the vertex program. For fixed-function vertex
processing, the point size attribute is undefined. The "y", "z", and "w"
components are always undefined.
If a geometry attribute binding matches "vertex[m].texcoord" or
"vertex[m].texcoord[n]", the "x", "y", "z", and "w" coordinates of the
geometry attribute variable are filled with the "s", "t", "r", and "q"
coordinates of texture coordinate set <n> of vertex <m>. If <n> is
omitted, texture coordinate set zero is used.
If a geometry attribute binding matches "vertex[m].attrib[n]", the "x",
"y", "z", and "w" components of the geometry attribute variable are filled
with the "x", "y", "z", and "w" coordinates of generic interpolant <n> of
vertex <m>. All generic interpolants will be undefined when used with
fixed-function vertex processing.
If a geometry attribute binding matches "vertex[m].clip[n]", the "x"
component of the geometry attribute variable is filled the clip distance
of vertex <m> for clip plane <n>, as written by the vertex program. If
fixed-function vertex processing or position-invariant vertex programs are
used, the clip distance is obtained by computing the per-clip plane dot
product:
(p_1' p_2' p_3' p_4') dot (x_e y_e z_e w_e),
at the vertex location, as described in section 2.12. The clip distance
for clip plane <n> is undefined if clip plane <n> is disabled. The "y",
"z", and "w" components of the attribute are undefined.
If a geometry attribute binding matches "vertex[m].texcoord[n..o]",
"vertex[m].attrib[n..o]", or "vertex[m].clip[n..o]", a sequence of
1+<o>-<n> texture coordinate bindings is created. For texture coordinate
bindings, it is as though the sequence "vertex[m].texcoord[n],
vertex[m].texcoord[n+1], ... vertex[m].texcoord[o]" were specfied. These
bindings are available only in explicit declarations of array variables.
A program will fail to load if <n> is greater than <o>.
If a geometry attribute binding matches "vertex[m].id", the "x" component
is filled with the vertex ID. If a vertex program is currently active,
the attribute variable is filled with the vertex ID result written by the
vertex program. If fixed-function vertex processing is used, the vertex
ID is undefined. The "y", "z", and "w" components of the attribute are
undefined.
If a geometry attribute binding matches "primitive.id", the "x" component
is filled with the number of primitives received by the GL 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
polygon primitive is processed. For QUADS and QUAD_STRIP primitives that
are decomposed into triangles, the primitive ID is incremented after each
complete quad is processed. For POLYGON primitives, the primitive ID
counter is zero. Restarting a primitive topology using the primitive
restart index has no effect on the primitive ID counter. The "y", "z",
and "w" components of the variable are always undefined.
(add the following subsection to section 2.X.3.5, Program Results.)
Geometry programs emit vertices, and the set of result variables available
to such programs correspond to the attributes of each emitted vertex. The
set of allowable result variable bindings for geometry programs is given
in Table X.3.
Binding Components Description
----------------------------- ---------- ----------------------------
result.position (x,y,z,w) position in clip coordinates
result.color (r,g,b,a) front-facing primary color
result.color.primary (r,g,b,a) front-facing primary color
result.color.secondary (r,g,b,a) front-facing secondary color
result.color.front (r,g,b,a) front-facing primary color
result.color.front.primary (r,g,b,a) front-facing primary color
result.color.front.secondary (r,g,b,a) front-facing secondary color
result.color.back (r,g,b,a) back-facing primary color
result.color.back.primary (r,g,b,a) back-facing primary color
result.color.back.secondary (r,g,b,a) back-facing secondary color
result.fogcoord (f,*,*,*) fog coordinate
result.pointsize (s,*,*,*) point size
result.texcoord (s,t,r,q) texture coordinate, unit 0
result.texcoord[n] (s,t,r,q) texture coordinate, unit n
result.attrib[n] (x,y,z,w) generic interpolant n
result.clip[n] (d,*,*,*) clip plane distance
result.texcoord[n..o] (s,t,r,q) texture coordinates n thru o
result.attrib[n..o] (x,y,z,w) generic interpolants n thru o
result.clip[n..o] (d,*,*,*) clip distances n thru o
result.primid (id,*,*,*) primitive id
result.layer (l,*,*,*) layer for cube/array/3D FBOs
Table X.3: Geometry Program Result Variable Bindings.
Components labeled "*" are unused.
If a result variable binding matches "result.position", updates to the
"x", "y", "z", and "w" components of the result variable modify the "x",
"y", "z", and "w" components, respectively, of the transformed vertex's
clip coordinates. Final window coordinates will be generated for the
vertex as described in section 2.14.4.4.
If a result variable binding match begins with "result.color", updates to
the "x", "y", "z", and "w" components of the result variable modify the
"r", "g", "b", and "a" components, respectively, of the corresponding
vertex color attribute in Table X.3. Color bindings that do not specify
"front" or "back" are consided to refer to front-facing colors. Color
bindings that do not specify "primary" or "secondary" are considered to
refer to primary colors.
If a result variable binding matches "result.fogcoord", updates to the "x"
component of the result variable set the transformed vertex's fog
coordinate. Updates to the "y", "z", and "w" components of the result
variable have no effect.
If a result variable binding matches "result.pointsize", updates to the
"x" component of the result variable set the transformed vertex's point
size. Updates to the "y", "z", and "w" components of the result variable
have no effect.
If a result variable binding matches "result.texcoord" or
"result.texcoord[n]", updates to the "x", "y", "z", and "w" components of
the result variable set the "s", "t", "r" and "q" components,
respectively, of the transformed vertex's texture coordinates for texture
unit <n>. If "[n]" is omitted, texture unit zero is selected.
If a result variable binding matches "result.attrib[n]", updates to the
"x", "y", "z", and "w" components of the result variable set the "x", "y",
"z", and "w" components of the generic interpolant <n>.
If a result variable binding matches "result.clip[n]", updates to the "x"
component of the result variable set the clip distance for clip plane <n>.
If a result variable binding matches "result.texcoord[n..o]",
"result.attrib[n..o]", or "result.clip[n..o]", a sequence of 1+<o>-<n>
bindings is created. For texture coordinates, it is as though the
sequence "result.texcoord[n], result.texcoord[n+1],
... result.texcoord[o]" were specfied. These bindings are available only
in explicit declarations of array variables. A program will fail to load
if <n> is greater than <o>.
If a result variable binding matches "result.primid", updates to the "x"
component of the result variable provide a single integer that serves as a
primitive identifier. The written primitive ID is available to fragment
programs using the "primitive.id" attribute binding. If a fragment
program using primitive IDs is active and a geometry program is also
active, the geometry program must write "result.primid" or the primitive
ID number is undefined.
If a result variable binding matches "result.layer", updates to the "x"
component of the result variable provide a single integer that serves as a
layer selector for layered rendering (section 2.14.6.5). The layer must
be written as an integer value; writing a floating-point layer number will
produce undefined results.
(modify Table X.13 in section 2.X.4, Program Instructions, to include the
following.)
Modifiers
Instruction F I C S H D Inputs Out Description
----------- - - - - - - ---------- --- --------------------------------
EMIT - - - - - - - - emit vertex
ENDPRIM - - - - - - - - end of primitive
(add the following subsection to section 2.X.6, Program Options.)
Section 2.X.6.Y, Geometry Program Options
No options are supported at present for geometry programs.
(add the following subsection to section 2.X.7, Program Declarations.)
Section 2.X.7.Y, Geometry Program Declarations
Geometry programs support three types of declaration statements, as
described below. Each of the three must be included exactly once in the
geometry program.
- Input Primitive Type (PRIMITIVE_IN)
The PRIMITIVE_IN statement declares the type of primitives seen by a
geometry program. The single argument must be one of "POINTS", "LINES",
"LINES_ADJACENCY", "TRIANGLES", or "TRIANGLES_ADJACENCY".
- Output Primitive Type (PRIMITIVE_OUT)
The PRIMITIVE_OUT statement declares the type of primitive emitted by a
geometry program. The single argument must be one of "POINTS",
"LINE_STRIP", or "TRIANGLE_STRIP".
- Maximum Vertex Count (VERTICES_OUT)
The VERTICES_OUT statement declares the maximum number of vertices that
may be emitted by a geometry program. The single argument must be a
positive integer. A vertex program that emits more than the specified
number of vertices may terminate abnormally.
(add the following subsections to section 2.X.8, Program Instruction Set.)
Section 2.X.8.Z, EMIT: Emit Vertex
The EMIT instruction emits a new vertex to be added to the current output
primitive of a geometry program. The attributes of the emitted vertex are
given by the current values of the vertex result variables. After the
EMIT instruction completes, a new vertex is started and all result
variables become undefined.
Section 2.X.8.Z, ENDPRIM: End of Primitive
A geometry program can emit multiple primitives in a single invocation.
The ENDPRIM instruction is used in a geometry program to signify the end
of the current primitive and the beginning of a new primitive of the same
type. The effect of ENDPRIM is roughly equivalent to calling End followed
by a new Begin, where the primitive mode is specified in the text of the
geometry program.
Like End, the ENDPRIM instruction does not emit a vertex. Any result
registers written prior to an ENDPRIM instruction are unchanged, and will
be used in the vertex specified by the next EMIT instruction if they are
not overwritten first.
When geometry program execution completes, the current primitive is
automatically terminated. It is not necessary to include an ENDPRIM
instruction if the geometry program writes only a single primitive.
Additions to Chapter 3 of the OpenGL 1.5 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 program 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 program 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
program is active, the point size is taken from the point size emitted by
the geometry program. If per-vertex point size is enabled an no geometry
program is active, the point size is taken from the point size result of
the vertex program. Otherwise, the point size is taken from the <size>
value provided to PointSize, with no distance attenuation applied. In all
cases, the 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. ...
Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
Operations and the Frame Buffer)
None.
Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions)
None.
Additions to Chapter 6 of the OpenGL 1.5 Specification (State and
State Requests)
None.
Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
None.
Additions to the AGL/GLX/WGL Specifications
None.
GLX Protocol
The following rendering commands are sent to the server as part of a
glXRender request:
ProgramVertexLimitNV
2 12 rendering command length
2 4312 rendering command opcode
4 ENUM target
4 INT32 limit
The extension EXT_geometry_shader4 defines GLX protocol for
the following non-rendering commands:
FramebufferTextureEXT, FramebufferTextureLayerEXT,
FramebufferTextureFaceEXT.
Errors
The error INVALID_OPERATION is generated if Begin, or any command that
implicitly calls Begin, is called when geometry program mode is enabled
and the currently bound geometry program object does not contain a valid
geometry program.
The error INVALID_OPERATION is generated if Begin, or any command that
implicitly calls Begin, is called when geometry program mode is enabled
and:
* the input primitive type of the current geometry program is POINTS and
<mode> is not POINTS,
* the input primitive type of the current geometry program is LINES and
<mode> is not LINES, LINE_STRIP, or LINE_LOOP,
* the input primitive type of the current geometry program is TRIANGLES
and <mode> is not TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN, QUADS,
QUAD_STRIP, or POLYGON,
* the input primitive type of the current geometry program is
LINES_ADJACENCY and <mode> is not LINES_ADJACENCY_EXT or
LINE_STRIP_ADJACENCY_EXT, or
* the input primitive type of the current geometry program is
TRIANGLES_ADJACENCY and <mode> is not TRIANGLES_ADJACENCY_EXT or
TRIANGLE_STRIP_ADJACENCY_EXT.
The error INVALID_ENUM is generated if GetProgramivARB is called with a
<pname> of MAX_PROGRAM_OUTPUT_VERTICES_NV or
MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV and the target isn't
GEOMETRY_PROGRAM_NV.
Dependencies on EXT_framebuffer_object
If EXT_framebuffer_object (or similar functionality) is not supported, the
"result.layer" binding should be removed. "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 programs 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 program 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 programs are disabled, or
* the current geometry program does not contain an instruction that
writes to the layer result binding.
Otherwise, the layer for each point, line, or triangle emitted by the
geometry program is taken from the layer output of the provoking vertex.
For line strips, the provoking vertex is the second vertex of each line
segment. For triangle strips, the provoking vertex is the third vertex of
each individual triangles. The per-fragment layer can be different for
fragments generated by each individual point, line, or triangle emitted by
a single geometry program invocation. A layer number written by a
geometry program 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.
Dependencies on NV_primitive_restart
The spec describes the behavior that primitive restart does not affect the
primitive ID counter, including for POLYGON primitives (where one could
argue that the restart index starts a new primitive without a new Begin to
reset the count). If NV_primitive_restart is not supported, references to
that extension in the discussion of the "primitive.id" attribute should be
removed.
New State
Initial
Get Value Type Get Command Value Description Sec. Attribute
------------------------- ---- ----------- ------- ---------------------- ------ ---------
GEOMETRY_PROGRAM_NV B IsEnabled FALSE Geometry shader enable 2.14.6 enable
FRAMEBUFFER_ATTACHMENT_ nxB GetFramebuffer- FALSE Framebuffer attachment 4.4.2.3 -
LAYERED_EXT Attachment- is layered
ParameterivEXT
GEOMETRY_VERTICES_OUT_EXT Z+ GetProgramivARB 0 vertex limit of the 2.14.6.4 -
current geometry
program
GEOMETRY_INPUT_TYPE_EXT Z+ GetProgramivARB 0 input primitive type 2.14.6.4 -
of the current geometry
program
GEOMETRY_OUTPUT_TYPE_EXT Z+ GetProgramivARB 0 output primitive type 2.14.6.4 -
of the current geometry
program
New Implementation Dependent State
Minimum
Get Value Type Get Command Value Description Sec Attrib
------------------------------- ---- --------------- ---------- -------------------- ------------ ------
MAX_GEOMETRY_TEXTURE_ Z+ GetIntegerv 16 maximum number of 2.14.6.3 -
IMAGE_UNITS_EXT texture image units
accessible in a
geometry program
MAX_PROGRAM_OUTPUT_VERTICES_NV Z+ GetProgramivARB 256 maximum number of 2.14.6.4 -
vertices that any
geometry program
could emit
MAX_PROGRAM_TOTAL_OUTPUT_ Z+ GetProgramivARB 1024 maximum number of 2.14.6.4 -
COMPONENTS_NV result components (all
vertices) that a
geometry program
can emit
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 programs fit into the existing GL pipeline?
RESOLVED: The following diagram illustrates how geometry programs 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 program 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 program only), and so on. Note
that on many current GL implementations, vertex processing is performed
by executing a "fixed function vertex program" 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 program is executed on each
individual point, line, or triangle primitive, if enabled. 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 program.
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 programs are never run on the raster position.
|generic |conventional
|vertex |vertex
|attributes |attributes
| |
| +-------------------+
| | |
V V V
vertex fixed-function
program vertex
| processing
| |
| |
+<-------------------+
| Output
|position, color, Primitive
|other vertex data Type
| |
V |
Begin/ primitive geometry primitive |
End ------> assembly -----> program ----> 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_NV_geometry_program4? There aren't any previous
versions of this extension, let alone three?
RESOLVED: The instruction set for GPU programs of all types (vertex,
fragment, and now geometry) have been unified in the GL_NV_gpu_program4
extension, and the "4" suffix in this extension name indicates the
instruction set type. There are three previous NV_vertex_program
variants (four if you count NV_vertex_program1_1), so "4" is the next
available numeric suffix.
(3) Should the GL produce errors at Begin time if an application specifies
a primitive mode that is "incompatible" with the geometry program? For
example, if the geometry program operates on triangles and the application
sends a POINTS primitive?
RESOLVED: Yes. Mismatches of app-specified primitive types and
geometry program input primitive types seem like clear errors and would
produce weird and wonderful effects.
(4) Can the input primitive type of a geometry program be changed at run
time?
RESOLVED: Not in this extension. Each geometry program has a single
input primitive type, and vertices are presented to the program in a
specific order based on that type.
(5) Can the output primitive type of a geometry program be determined at
run time?
RESOLVED: Not in this extension.
(6) Must the output primitive type of a geometry program match the input
primitive type in any way?
RESOLVED: No, you can have a geometry program 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.
(7) Are primitives emitted by a geometry program 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).
(8) Should geometry programs support additional input primitive types?
RESOLVED: Possibly in a future extension. It should be straightforward
to build a future extension to support geometry programs that operate on
quads. Other primitive types might be more demanding on hardware.
Quads with adjacency would require 12 vertices per program execution.
General polygons may require even more, since there is no fixed bound on
the number of vertices in a polygon.
(9) Should geometry programs 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.
(10) 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.
(11) How do geometry programs interact with RasterPos?
RESOLVED: Geometry programs are ignored when specifying the raster
position. While the raster position could be treated as a point,
turning it into a triangle strip would be quite bizarre.
(12) How do geometry programs interact with pixel primitives (DrawPixels,
Bitmap)?
RESOLVED: They do not. Fragments generated be DrawPixels and Bitmap
are injected into the pipeline after the point where geometry program
execution occurs.
(13) Is there a limit on the number of vertices that can be emitted by a
geometry program?
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 the all the primitives generated by the first geometry program
invocation must be consumed before any of the primitives generated by
the second program invocation. Limiting the amount of data a geometry
program can write substantially eases the implementation burden.
A geometry program must declare a maximum number of vertices that can be
emitted, called the vertex limit. There is an implementation-dependent
limit on the total number of vertices a program can emit (256 minimum)
and the product of the vertex limit and the number of active result
components (1024 minimum). A program will fail to load if doesn't
declare a limit or exceeds either of the two implementatoin-dependent
limits.
It would be ideal if the limit could be inferred from the instructions
in the program itself, and that would be possible for many programs,
particularly ones with straight-line flow control. For programs 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 EMIT instructions that can be issued can not
always be enforced at compile time, or even at Begin time. We specify
that if a program tries to emit more vertices than the vertex limit
allows, emits that exceed the limit may or may not have any effect.
(14) Should it be possible to change the limit on the number of vertices
emitted by a geometry program after the program is specified?
RESOLVED: Yes, using the function ProgramVertexLimitNV(). Applications
may want to tweak a piece of data that affects the number of vertices
emitted, but doesn't necessarily require recompiling the entire program.
Examples might be a "circular point sprite" program, that reads a single
point, and draws a circle centered at that point with <N> vertices. An
application could change the value <N> at run time, but it could require
a change in the vertex limit. Another example might be a geometry
program that does some fancy subdivision, where the relevant parameter
might be a limit on how far the primitive is subdivided.
Ideally, this program object state should be set by a "program
parameter" command, much like texture state is set by a "texture
parameter" (TexParameter) command. Unfortunately, there are already
several different "program parameter" functions:
ProgramEnvParameter4fARB() -- sets global environment constants
ProgramLocalParameter4fARB() -- sets per-program constants
ProgramParameter4fNV() -- also sets global environment constants
Additionally, GLSL and OpenGL 2.0 introduced "program objects" which are
linked collections of vertex, fragment, and now geometry shaders. A
GLSL vertex "shader" is equivalent to an ARB_vertex_program vertex
"program", which is nothing like a GLSL program. As of OpenGL 2.0, GLSL
programs do not have settable parameters, by subsequent extensions may
want to add them (for example, EXT_geometry_shader4, which has this same
functionality for GLSL). If that happens, they would want their own
ProgramParameter API, but with a different prototype than this extension
would want.
Naming this function "ProgramVertexLimitNV" sidesteps this issue for
now.
(15) 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.
(16) How do geometry programs interact with color clamping?
RESOLVED: Geometry program execution occurs prior to color clamping in
the pipeline. This means the colors written by vertex programs or
fixed-function vertex processing are not clamped to [0,1] before they
are read by geometry programs. If color clamping is enabled, any vertex
colors written by the geometry program will have their components
clamped to [0,1].
(17) How are QUADS, QUAD_STRIP, and POLYGON primitives decomposed into
triangles in the initial implementation of GL_NV_geometry_program4?
RESOLVED: The specification leaves the decomposition undefined, subject
to a small number of rules. Assume that four vertices are specified in
the order V0, V1, V2, V3.
For QUADS primitives, the quad V0->V1->V2->V3 is decomposed into the
triangles V0->V1->V2, and V0->V2->V3. The provoking vertex of the quad
(V3) is only found in the second triangle. If it's necessary to flat
shade over an entire quad, take the attributes from V0, which will be
the first vertex for both triangles in the decomposition.
For QUAD_STRIP primitives, the quad V0->V1->V3->V2 is decomposed into
the triangles V0->V1->V3 and V2->V0->V3. This has the property of
leaving the provoking vertex for the polygon (V3) as the third vertex
for each triangle of the decomposition.
For POLYGON primitives, the polygon V0->V1->V2->V3 is decomposed into
the triangles V1->V2->V0 and V2->V3->V0. This has the property of
leaving the provoking vertex for the polygon (V0) as the third vertex
for each triangle of the decomposition.
(18) Should geometry programs be able to select a layer of a 3D texture,
cube map texture, or array texture at run time? If so, how?
RESOLVED: This extension provides a per-vertex result binding called
"result.layer", which is an integer specifying the layer to render to.
When an each individual point, line, or triangle is emitted by a
geometry program, the layer number is taken from the provoking (last)
vertex of the primitive and 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) 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.
They can do anything that the old functions can do, except attach a
single face of a cube map texture. We considered adding a separate
function FramebufferTextureFaceEXT to provide this functionality, but
decided that the existing FramebufferTexture2DEXT API was adequate. We
also considered using FramebufferTextureLayerEXT for this purpose, but
it was not clear whether a layer number (0-5) or face enum (e.g,
TEXTURE_CUBE_MAP_POSITIVE_X) should be provided.
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 program that writes the layer result is enabled. When
rendering to a non-layered framebuffer, any layer result emitted from
geometry programs 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 program, or set as
a new property of the framebuffer object. There is presently
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.
(19) How can single-pass cube map rendering be done efficiently in a
geometry program?
UNRESOLVED: To do single-pass cubemap rendering, attach entire cube map
textures to framebuffer attachment points using the new functions
provided by this extension. The vertex program used should only
transform the vertex position to eye coordinates (position relative to
the center of the cube map). A geometry program should be used that
effectively projects each input triangle onto each of the six faces of
the cube map, emitting a triangle for each. Each of the projected
vertices should be emitted with a "result.layer" value matching the face
number (0-5). When the projected triangle is drawn, it is automatically
drawn on the face corresponding to the emitted layer number.
It should be simple to skip projecting primitives onto faces they won't
touch. For example, if all of the X eye coordinates are positive, there
is no reason to project to the "negative X" cube map face.
An example should be provided for this issue.
(20) How should per-vertex point size work with geometry programs?
RESOLVED: We will generalize the existing VERTEX_PROGRAM_POINT_SIZE
enable to control the point size behavior if either vertex or geometry
programs are enabled.
If geometry programs are enabled, the point size is taken from the point
size result of the emitted vertex if VERTEX_PROGRAM_POINT_SIZE is
enabled, or from the PointSize state otherwise.
If no geometry program is enabled, it works like OpenGL 2.0. If a
vertex program is active, it's taken from the point size result or
PointSize state, depending on the VERTEX_PROGRAM_POINT_SIZE enable. If
no program is enabled, normal fixed-function point size handling
(including distance attenuation) is supported.
This extension creates a new alias for the VERTEX_PROGRAM_POINT_SIZE
enum, called PROGRAM_POINT_SIZE_EXT, to reflect that the point size
enable now covers multiple program types. Both enums have the same
value.
(21) How do vertex IDs work with geometry programs?
RESOLVED: Vertex IDs are automatically provided to vertex programs
when applicable, via the "vertex.id" binding. However, they are not
automatically copied the transformed vertex results that are read by
geometry programs.
Geometry programs can read the ID of vertex <n> via the
"vertex[<n>].id" binding, but the vertex ID must have been copied by
the vertex program using an instruction such as:
MOV result.id.x, vertex.id.x;
If a vertex program doesn't write vertex ID, or fixed-function vertex
processing is used, the vertex ID visible to geometry programs is
undefined.
(22) How do primitive IDs work with geometry programs?
RESOLVED: Primitive IDs are automatically available to geometry
programs via the "primitive.id" binding and indicate the number of
input primitives previously processed since the last explicit or
implicit Begin call.
If a geometry program wants to make the primitive ID available to a
fragment program, it should copy the appropriate value to the
"result.primid" binding.
(23) How do primitive IDs work with primitives not supported directly by
geometry program input topologies (e.g., QUADS, POLYGON)?
RESOLVED: QUADS are decomposed into two triangles. Both triangles
will have the same primitive ID, which is the number of full quads
previously processed. POLYGON primitives are decomposed into a series
of triangles, and all of them will have the primitive ID -- zero.
(24) This is an NV extension (NV_geometry_program4). Why do some of the
new tokens have an "EXT" extension?
RESOLVED: Some of the tokens are shared between this extension and the
comparable high-level GLSL programmability extension
(EXT_geometry_shader4). Rather than provide a duplicate set of tokens,
we simply use the EXT versions here. The tokens specific to assembly
shader uses retain an NV suffix.
(25) What happens if you try to do a framebuffer blit (via
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
---- -------- -------- --------------------------------------------
13 12/14/09 mgodse Added GLX protocol.
12 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.
Also document several additional entry points
that accept GEOMETRY_PROGRAM_NV.
11 03/11/09 pbrown Fix section numbers for option/declaration
sections.
10 07/29/08 pbrown Clean up garbled language describing vertex
output limits.
9 04/04/08 pbrown Fixed error in the state tables; the geometry
program enable should push/pop only with the
enable bit like all the other program enables.
8 03/15/08 pbrown Additional dependency on EXT_framebuffer_blit;
blits to/from layered targets affect only
layer zero.
7 03/07/08 pbrown Fix grammar to allow vertex ID, as already
allowed in the rest of the spec body.
6 pbrown Internal spec development.