| Name |
| |
| ARB_vertex_program |
| |
| Name Strings |
| |
| GL_ARB_vertex_program |
| |
| Contributors |
| |
| Kurt Akeley |
| Allen Akin |
| Ben Ashbaugh |
| Bob Beretta |
| John Carmack |
| Matt Craighead |
| Ken Dyke |
| Steve Glanville |
| Michael Gold |
| Evan Hart |
| Mark Kilgard |
| Bill Licea-Kane |
| Barthold Lichtenbelt |
| Erik Lindholm |
| Benj Lipchak |
| Bill Mark |
| James McCombe |
| Jeremy Morris |
| Brian Paul |
| Bimal Poddar |
| Thomas Roell |
| Jeremy Sandmel |
| Jon Paul Schelter |
| Geoff Stahl |
| John Stauffer |
| Nick Triantos |
| |
| Contact |
| |
| Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright (c) 2002-2013 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Specification Update Policy |
| |
| Khronos-approved extension specifications are updated in response to |
| issues and bugs prioritized by the Khronos OpenGL Working Group. For |
| extensions which have been promoted to a core Specification, fixes will |
| first appear in the latest version of that core Specification, and will |
| eventually be backported to the extension document. This policy is |
| described in more detail at |
| https://www.khronos.org/registry/OpenGL/docs/update_policy.php |
| |
| IP Status |
| |
| NVIDIA claims to own intellectual property related to this extension, and |
| has signed an ARB Contributor License agreement licensing this |
| intellectual property. |
| |
| Microsoft claims to own intellectual property related to this extension. |
| |
| Status |
| |
| Complete. Approved by ARB on June 18, 2002 |
| |
| Version |
| |
| Last Modified Date: 07/25/07 |
| Revision: 46 |
| |
| Number |
| |
| ARB Extension #26 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 1.3 specification and requires |
| OpenGL 1.3. |
| |
| ARB_vertex_blend and EXT_vertex_weighting affect the definition of this |
| extension. |
| |
| ARB_matrix_palette affects the definition of this extension. |
| |
| ARB_point_parameters and EXT_point_parameters affect the definition of |
| this extension. |
| |
| EXT_secondary_color affects the definition of this extension. |
| |
| EXT_fog_coord affects the definition of this extension. |
| |
| ARB_transpose_matrix affects the definition of this extension. |
| |
| NV_vertex_program interacts with this extension. |
| |
| EXT_vertex_shader interacts with this extension. |
| |
| Overview |
| |
| Unextended OpenGL mandates a certain set of configurable per-vertex |
| computations defining vertex transformation, texture coordinate generation |
| and transformation, and lighting. Several extensions have added further |
| per-vertex computations to OpenGL. For example, extensions have defined |
| new texture coordinate generation modes (ARB_texture_cube_map, |
| NV_texgen_reflection, NV_texgen_emboss), new vertex transformation modes |
| (ARB_vertex_blend, EXT_vertex_weighting), new lighting modes (OpenGL 1.2's |
| separate specular and rescale normal functionality), several modes for fog |
| distance generation (NV_fog_distance), and eye-distance point size |
| attenuation (EXT/ARB_point_parameters). |
| |
| Each such extension adds a small set of relatively inflexible |
| per-vertex computations. |
| |
| This inflexibility is in contrast to the typical flexibility provided by |
| the underlying programmable floating point engines (whether micro-coded |
| vertex engines, DSPs, or CPUs) that are traditionally used to implement |
| OpenGL's per-vertex computations. The purpose of this extension is to |
| expose to the OpenGL application writer a significant degree of per-vertex |
| programmability for computing vertex parameters. |
| |
| For the purposes of discussing this extension, a vertex program is a |
| sequence of floating-point 4-component vector operations that determines |
| how a set of program parameters (defined outside of OpenGL's Begin/End |
| pair) and an input set of per-vertex parameters are transformed to a set |
| of per-vertex result parameters. |
| |
| The per-vertex computations for standard OpenGL given a particular set of |
| lighting and texture coordinate generation modes (along with any state for |
| extensions defining per-vertex computations) is, in essence, a vertex |
| program. However, the sequence of operations is defined implicitly by the |
| current OpenGL state settings rather than defined explicitly as a sequence |
| of instructions. |
| |
| This extension provides an explicit mechanism for defining vertex program |
| instruction sequences for application-defined vertex programs. In order |
| to define such vertex programs, this extension defines a vertex |
| programming model including a floating-point 4-component vector |
| instruction set and a relatively large set of floating-point 4-component |
| registers. |
| |
| The extension's vertex programming model is designed for efficient |
| hardware implementation and to support a wide variety of vertex programs. |
| By design, the entire set of existing vertex programs defined by existing |
| OpenGL per-vertex computation extensions can be implemented using the |
| extension's vertex programming model. |
| |
| Issues |
| |
| (1) What should this extension be called? |
| |
| RESOLVED: ARB_vertex_program. DirectX 8 refers to its similar |
| functionality as "vertex shaders". This is a confusing term because |
| shaders are usually assumed to operate at the fragment or pixel level, |
| not the vertex level. |
| |
| Conceptually, what the extension defines is an application-defined |
| program (admittedly limited by its sequential execution model) for |
| processing vertices so the "vertex program" term is more accurate. |
| |
| Some of the API machinery in this extension for describing programs |
| should be useful for extending other OpenGL operations with programs |
| (though other types of programs may look very different from vertex |
| programs). |
| |
| (2) What terms are important to this specification? |
| |
| vertex program mode - When vertex program mode is enabled, vertices are |
| transformed by an application-defined vertex program. |
| |
| conventional GL vertex transform mode - When vertex program mode is |
| disabled (or the extension is not supported), vertices are transformed |
| by GL's conventional texgen, lighting, and transform state. |
| |
| vertex program - An application-defined program used to transform |
| vertices when vertex program mode is enabled. |
| |
| program target - A type or class of program. This extension supports |
| the VERTEX_PROGRAM_ARB target. Future extensions may add other program |
| targets. |
| |
| program object - An object maintained internal to OpenGL that |
| encapsulates a program and a set of associated state. Operations |
| performed on program objects include loading a program, binding, |
| generating program object names, querying state, and deleting. |
| |
| program name - Each program object has an associated unsigned integer, |
| called the program name. Applications refer to a program object using |
| the program name. |
| |
| current program - Each program target may have a current program object. |
| For vertex programs, the current program is executed whenever a vertex |
| is specified when vertex program mode is enabled. |
| |
| default program - Each program target has a default program object, |
| referred to using a program name of zero. The current program for each |
| program target is initially the default program for that target. |
| |
| program execution environment - A set of resources, instructions, and |
| semantic rules used to execute a program. Each program target may |
| support one or more execution environment -- new execution environments |
| may provide new instructions, resources, or execution rules. Program |
| strings must specify the execution environment that should be used to |
| execute the program. |
| |
| program options - An optional feature that modifies the rules of the |
| execution environment. Vertex programs specify the options that they |
| require at the beginning of the program. |
| |
| vertex attribute - GL state associated with vertices that can vary per |
| vertex. |
| |
| conventional vertex attributes - Per-vertex attributes used in |
| conventional GL vertex transform mode, including colors, normals, |
| texture coordinate sets. |
| |
| generic vertex attributes - An array of 16+ 4-component vectors added by |
| this extension. Generic vertex attributes can be used by vertex |
| programs but are unused in conventional GL vertex transform mode. |
| |
| program parameter - A set of constants that are available for vertex |
| programs to use during their execution. Program parameters include |
| program environment parameters, program local parameters, conventional |
| GL state, and program constants. |
| |
| program environment parameter - A set of 96+ 4-component vectors |
| belonging to the GL context that can be used as constants during the |
| execution of any vertex program. |
| |
| program local parameter - A set of 96+ 4-component vectors belonging to |
| a vertex program object that can be used as constants during the |
| execution of the corresponding vertex program. Program local parameters |
| can not be used by any other vertex programs. |
| |
| program constants - Constants declared in the text of a program may be |
| used during the execution of that program. |
| |
| program temporaries - A set of 12+ 4-component vectors to hold temporary |
| results that can be read or written during the execution of a vertex |
| program. |
| |
| program address registers - A set of 1+ 1-component integer vectors that |
| can be used to perform variable indirect accesses to program parameter |
| arrays during the execution of a vertex program. Address registers are |
| specified as vectors to allow for future extensions supporting multiple |
| address register components. |
| |
| program results - A set of 4-component vectors to hold the final results |
| of a vertex program. The program results correspond closely to the set |
| of vertex attributes used during primitive assembly and rasterization. |
| |
| program variables - Variable names used to identify a specific vertex |
| attribute, program parameter, temporary, address register, or result. |
| |
| program binding - A program statement that declares a variable and |
| associates it with a specific vertex attribute, program parameter, or |
| program result. |
| |
| implicit binding - When an executable instruction refers to a specific |
| vertex attribute, program parameter, program result, or constant by |
| name, without using an explicit program binding statement. When such |
| values are encountered, an implicit binding to an anonymous variable |
| name is created. |
| |
| program invocation - The act of implicitly or explicitly kicking off |
| program execution. Vertex programs are invoked automatically when |
| vertex program mode is enabled and vertices are received. Vertex |
| programs are also invoked automatically when the current raster position |
| is specified. |
| |
| (3) What part of OpenGL do vertex programs specifically bypass? |
| |
| Vertex programs bypass the following OpenGL functionality: |
| |
| - The modelview and projection matrix vertex transformations. |
| |
| - Vertex weighting/blending (ARB_vertex_blend). |
| |
| - Normal transformation, rescaling, and normalization. |
| |
| - Color material. |
| |
| - Per-vertex lighting. |
| |
| - Texture coordinate generation and texture matrix transformations. |
| |
| - Per-vertex point size computations in ARB/EXT_point_parameters |
| |
| - Per-vertex fog coordinate computations in EXT_fog_coord and |
| NV_fog_distance. |
| |
| - Client-defined clip planes. |
| |
| - The normalization of AUTO_NORMAL evaluated normals |
| |
| - All of the above, when computing the current raster position. |
| |
| Operations not subsumed by vertex programs |
| |
| - Clipping to the view frustum. |
| |
| - Perspective divide (division by w). |
| |
| - The viewport transformation. |
| |
| - The depth range transformation. |
| |
| - Front and back color selection (for two-sided lighting and |
| coloring). |
| |
| - Clamping the primary and secondary colors to [0,1]. |
| |
| - Primitive assembly and subsequent operations. |
| |
| - Evaluators (except the AUTO_NORMAL normalization). |
| |
| (5) This extension adds a set of generic vertex attributes to the existing |
| conventional attributes. The sum of the number of generic and |
| conventional attributes supported on a given platform may exceed the total |
| number of per-vertex attributes supported in hardware. How should this |
| situation be handled? |
| |
| RESOLVED: Implementations may alias conventional and generic vertex |
| attributes, where pairs of conventional and generic vertex attributes |
| share the same storage. Such aliasing will effectively reduce the |
| number of vertex attributes a hardware platforms. While implementations |
| may alias attributes, that behavior is not required. To accommodate both |
| behaviors, changing a generic vertex attribute leaves the corresponding |
| conventional attribute undefined, and vice versa. |
| |
| This undefined behavior is a compromise between the existing |
| EXT_vertex_shader extension (which does not permit aliasing) and the |
| NV_vertex_program extension (which requires aliasing). The mapping |
| between generic and conventional vertex attributes is found in Table X.1 |
| below. This mapping is taken from the NV_vertex_program specification |
| and generalized to define behavior for >8 texture coordinate sets. |
| |
| Applications that mix conventional and generic vertex attributes in a |
| single rendering pass should be careful to avoid using attributes that |
| may alias. To limit inadvertent use of such attributes, loading a |
| vertex program that used a pair of attributes that may alias is |
| guaranteed to fail. Applications requiring a small number of generic |
| vertex attributes can always safely use generic attributes 6 and 7, and |
| any supported attributes corresponding to unused or unsupported texture |
| units. For example, if an implementation supports only four texture |
| units, generic attributes 12 through 15 can always be used safely. |
| |
| (6) Should there be a "VertexAttribs" entry point to specify multiple |
| vertex attributes in one immediate mode call. |
| |
| RESOLVED: No. Not providing such functionality serves to reduce the |
| already large number of required immediate mode entry points. A |
| "VertexAttribs" command would improve the efficiency of vertex attribute |
| transfer, but vertex arrays or display lists should still be better. |
| |
| (7) Should a full complement of data types (signed and unsigned bytes, |
| shorts, and ints, as well as floats and doubles) be supported for vertex |
| attributes? Should fixed-point data types be supported in both normalized |
| (map the range to [0,1] or [-1,1]) and unnormalized form? |
| |
| RESOLVED: For vertex arrays, all data type combinations are supported. |
| |
| For immediate mode, a smaller subset is supported, to limit the number |
| of immediate-mode entry points added by this extension. In fully |
| general form, 112 immediate-mode entry points (4 sizes x 2 |
| vector/non-vector x 14 data types) would be required. |
| |
| Immediate mode support is available for non-normalized shorts, floats, |
| and doubles for all component counts. Additionally, immediate mode |
| support is available for 4-component vectors of all data types |
| (normalized and unnormalized). |
| |
| Note also that in immediate mode, the "N" qualifier in function names |
| like VertexAttrib4Nub will be used to indicate that fixed-point data |
| should be normalized. |
| |
| (8) How should applications indicate that fixed-point generic vertex |
| attribute array components should be converted to [-1,+1] or [0,1] ranges? |
| |
| RESOLVED: The function VertexAttribPointerARB takes a boolean argument |
| <normalized> that indicates whether fixed-point array data should be |
| normalized to [-1,+1] or [0,1]. |
| |
| One alternate approach would have been to extend to set of enumerants to |
| include values such as NORMALIZED_UNSIGNED_BYTE_ARB. Adding such |
| enumerants in some sense implies that UNSIGNED_BYTE is not normalized, |
| even though it usually is. |
| |
| (9) In unextended OpenGL, calling Vertex() specifies a vertex and causes |
| vertex transformation operations to be performed on the vertex. Should |
| there be an equivalent method to specify a vertex using generic vertex |
| attributes? If so, how should this be accomplished? |
| |
| RESOLVED: Setting generic vertex attribute zero will always specify a |
| vertex. Vertex*(...) and VertexAttrib*(0,...) are specified to be |
| equivalent, whether or not vertex program mode is enabled. Allowing |
| generic vertex attribute zero to specify a vertex allows applications to |
| write vertex programs that use only generic attributes; otherwise, |
| applications would have had to use Vertex() to provoke vertex |
| processing. |
| |
| (10) How is this extension different from previous vertex program |
| extensions, such as EXT_vertex_shader or NV_vertex_program? What pitfalls |
| are there in porting vertex programs to/from this extension? |
| |
| RESOLVED: See "Interactions with NV_vertex_program" and "Interactions |
| with EXT_vertex_shader" sections near the end of this specification. |
| |
| (11) Should program parameter variables bound to GL state be updated |
| automatically after the bound state changes? If so, when? |
| |
| RESOLVED: Yes. Such variables are updated automatically prior to the |
| next vertex program invocation with no application intervention |
| required. A proposal to reduce the burden by requiring a manual "update |
| state" step was considered and rejected. |
| |
| (12) How should this specification handle variable bindings to Material |
| state? Material is allowed inside a Begin/End, so material properties are |
| technically per-vertex state. |
| |
| RESOLVED: Materials can be bound only as program parameters. Changes |
| to material properties inside a Begin/End will leave the bindings |
| undefined until the subsequent End command. At that point, all material |
| property bindings are guaranteed to be updated, and any material |
| property changes up to the next Begin command are guaranteed to take |
| effect immediately. |
| |
| Supporting per-vertex material properties places additional pressure on |
| the number of per-vertex bindings an implementation can support, which |
| was already a problem. See issue (5). |
| |
| In practice, material properties are usually not changed in this manner. |
| Applications needing to change material properties inside a Begin/End in |
| vertex program mode can work around this limitation by storing the color |
| in a conventional or generic vertex attribute and modifying the vertex |
| program accordingly. |
| |
| (13) What semantic restrictions, if any, should be imposed on binding the |
| same GL state to multiple variables? The grammar permits such bindings, |
| but allowing this behavior means that single state updates must update |
| multiple variables. |
| |
| RESOLVED: Cases where a single state update necessarily requires |
| updating multiple variables are disallowed. The only restriction |
| resulting from this decision is that a single state variable can not be |
| bound more than once in the collection of arrays that are accessed using |
| relative addressing (at run time). The driver can and will coalesce all |
| other bindings accessed only at fixed offsets into a single binding. |
| |
| This restriction and a little driver work allows the same state variable |
| to be used multiple times without requiring that a single state change |
| update multiple variables. |
| |
| (14) What semantic restrictions, if any, should be imposed on using |
| multiple vertex attributes or program parameters in the same instruction? |
| |
| RESOLVED: None. If the underlying hardware implementation does not |
| support reads of multiple attributes or program parameters, the driver |
| may need to transparently insert additional instructions and/or consume |
| temporaries to perform the operation. |
| |
| (15) How and when should related state be combined into a single program |
| parameter binding? Additionally, should any values derived from core GL |
| state be exposed, too? |
| |
| RESOLVED: Related state should be combined when possible, as long as |
| the binding name remains somewhat sensible. Additionally, certain |
| pre-computed state items useful for performance reasons are also |
| exposed. In particular, the following GL state combinations are |
| supported: |
| |
| * Light attenuation constants and the spot light exponent are combined |
| into a single vector called "state.light[n].attenuation" (spot |
| lights can attenuate the lit result). |
| |
| * Spot light direction and cutoff angle cosine are called |
| "state.light[n].spot.direction" (cutoff is directional information). |
| Binding the cutoff angle itself is pretty useless, so the cosine is |
| used. |
| |
| * A pre-computed half angle for lighting with infinite lights and an |
| infinite viewer is provided and called "state.light[n].half". |
| |
| * Pre-computed products of ambient, diffuse, and specular light colors |
| with the corresponding front or back material colors are supported, |
| and are called "state.lightprod[n].<face>.<property>". |
| |
| * Exponential fog density, linear fog start and end parameters, as |
| well as the pre-computed reciprocal of (end-start) are combined into |
| one vector called "state.fog.params". |
| |
| * The core point size, minimum and maximum size clamps |
| (ARB_point_parameters), and multisample fade size threshold |
| (ARB_point_parameters) are combined into a single vector called |
| "state.point.size". |
| |
| * Precomputed transpose, inverse, and inverse transpose matrices are |
| supported for each base matrix type. |
| |
| (16) Should the initial values of temporaries and results be undefined? |
| |
| RESOLVED: Since the underlying hardware differs, it was decided to |
| leave these values uninitalized. There are a few issues related to this |
| behavior that programs should keep in mind: |
| |
| * Since any results not written by the program are undefined, programs |
| should write to all result registers that are needed during |
| rasterization. |
| |
| * In particular, the initial vertex position result is undefined, and |
| will remain undefined if not written by a program. To achieve |
| proper results, vertex programs should be careful to write to all |
| four components of the vertex position. Otherwise, primitives may |
| be completely clipped or produce undefined results during |
| rasterization. There is no semantic requirement that programs must |
| write a transformed vertex position, so erroneous programs will load |
| succesfully, but will produce undefined (and probably useless) |
| results. Such a semantic requirement may be impossible to enforce |
| in future language versions that support run-time branching. |
| |
| * Since vertex programs may be executed when the raster position is |
| set, any attributes not written by the program will result in |
| undefined state in the current raster position. Programs should |
| write to all result registers that would be used when rasterizing |
| pixel primitives using the current raster position. |
| |
| * If conventional OpenGL texture mapping operations are performed, a |
| program should always write to the "w" coordinate of any texture |
| coordinates result registers it needs to use. Conventional OpenGL |
| texture accesses always use projective texture coordinates (e.g., |
| s/q, t/q, r/q), even though q is almost always 1.0. An undefined q |
| coordinate (coming from the "w" component of the result register) |
| may produce undefined coordinates on the texture lookup. |
| |
| (17) Should vertex programs be required to have a header token and an end |
| token? |
| |
| RESOLVED: Yes. The header token for this extension is named |
| "!!ARBvp1.0". The ARB may standardize future language versions which |
| would be expected to have tokens like "!!ARBvp2.0". Vertex programs |
| must end with the "END" token. |
| |
| The initial header token reminds the programmer what type of program |
| they are writing. If vertex programs are ever read from disk files, the |
| header token can be used to specifically identify vertex programs. The |
| initial header tokens will also make it easier for programmers to |
| distinguish between multiple types of vertex programs and between vertex |
| programs and another future type of programs. |
| |
| We expect that programs may be generated by concatenation of program |
| fragments. The "END" token will hopefully reduce bugs due to specifying |
| an incorrectly concatenated program. |
| |
| (18) Should ProgramStringARB take a <program> specifier? Should |
| ProgramLocalParameterARB and GetProgramLocalParameterARB take a <program> |
| specifier? How about GetProgramivARB and GetProgramStringARB? |
| |
| RESOLVED: No to all. Instead, these calls are specified to always |
| query or modify the currently bound program object. Using bound objects |
| allows GL implementations to avoid locking and name lookup overhead on |
| each such call. |
| |
| This behavior does imply that applications loading a sequence of program |
| objects must bind each in turn. |
| |
| (19) Should relative addressing be performed using an address register |
| (load up an integer register) or by taking a floating-point scalar? |
| |
| RESOLVED: Address register. It would not be a good idea to support |
| both syntaxes simultaneously, since using a floating-point scalar may |
| consume the only available address register in the process. The current |
| address register syntax can be easily extended to allow for multiple |
| integer registers and/or enable other integer operations in a later |
| extension. |
| |
| Using a floating-point index may require an extra instruction on some |
| architectures, and would require optimization work to eliminate |
| redundant loads. Using a floating-point index may consume one of a |
| small number of temporary registers. On the other hand, for |
| implementations without a dedicated address register, it may be |
| necessary to dedicate a general-purpose register (or register component) |
| to hold the address register contents. |
| |
| (20) How should user-defined clipping be supported in this specification? |
| |
| RESOLVED: User-defined clipping is not supported in standard vertex |
| program mode. User-defined clipping support will be provided for |
| programs that use the "position invariant" option, where all vertex |
| transformation operations are performed by the fixed-function pipeline. |
| |
| It is expected that future vertex program extensions or a future |
| language standard may provide more powerful user clipping functionality. |
| |
| The options considered were: |
| |
| (1) Not at all. Does not work for applications requiring user clipping. |
| User clipping could be supported through a language extension. |
| |
| (2) Support only through the "position_invariant" option, where vertex |
| transformation is performed by the fixed-function pipeline. |
| |
| (3) Support by using the fixed-function pipeline to generate eye |
| coordinates and perform user clipping as specified for conventional |
| transformation. May not work properly if the vertex transformation |
| doesn't match the standard "multiply by modelview and projection |
| matrices" model. |
| |
| (4) Project existing fixed-function clip planes into clip coordinates |
| and perform the clip test in clip space. The clip planes would be |
| transformed by the inverse of the projection matrix, which will not |
| work if the projection matrix is singular. |
| |
| (5) Provide a 4-component "user clip coordinate" result that can be |
| bound by a vertex program. User clipping is performed as in |
| unextended OpenGL, using the "user clip coordinate" in place of the |
| non-existant eye coordinates. This approach allows an application |
| to do user clipping in any coordinate system. Clipping would not be |
| independent of primitive tesselation as in the conventional |
| pipeline. Additionally, the implicit transformation of specified |
| clip planes by the modelview matrix may be undesirable (e.g., |
| clipping in object coordinates). |
| |
| (6) Provide one or more "clip plane distance" results that can be bound |
| by a vertex program. For conventional clipping applications, vertex |
| programs would compute the dot products normally computed by |
| fixed-function hardware. Additionally, this method would enable |
| additional unconventional clipping effects. Primitives would be |
| clipped to the portion whose interpolated clip distances are greater |
| than or equal to zero. This approach has the same issues as (5). |
| |
| (21) How should future vertex program opcodes be named? |
| |
| RESOLVED: Three-character names are recommended for brevity. Three |
| character names are not a hard-and-fast requirement; extra characters |
| may be needed for clarity or to disambiguate instructions. |
| |
| (22) Should anything be said about the precision used for carrying out the |
| instructions? |
| |
| RESOLVED: Not much; precision will vary across platforms. The minimum |
| precision requirements (1 part in 10^5 or roughly 17 bits) are spelled |
| out in section 2.1.1. In practice, implementations will generally |
| provide precision comparable to that obtained using single precision |
| floats. Documenting exact precision across implementations is |
| difficult. Additionally, it is difficult to spell out precision |
| requirements for "compound" operations such as DP4. |
| |
| (23) Should this extension support evaluator maps for generic vertex |
| attributes? If so, what attribute sizes should be supported? Note that |
| such maps are not supported at all for texture units except zero. |
| |
| RESOLVED: No. Evaluator support has not been consistently extended in |
| previous extensions. For example, neither ARB_multitexture nor OpenGL |
| 1.3 provide support for evaluators for texture units other than unit |
| zero. Adding evaluators for generic attributes involves a large amount |
| of new state and complexity, particularly if evaluators should be |
| supported in general form (1, 2, 3, and 4 components, all supported data |
| type). |
| |
| (25) The number of generic vertex attributes is implementation-dependent |
| and is at least 16. Each generic vertex attribute has a vertex array |
| enable. Should two new entry points be provided to accept an arbitrary |
| attribute number, or should we reserve a range of enumerants that is |
| "large enough"? |
| |
| RESOLVED: Yes. EnableVertexAttribArrayARB and |
| DisableVertexAttribArrayARB. This allows the number of vertex |
| attributes to be unbounded, instead of using a limited range. |
| |
| (26) What limits should be imposed on the constants that can be added to |
| or subtracted from the address register for relative addressing? Negative |
| offsets are sometimes useful for shifting down in an array. |
| |
| RESOLVED: -64 to +63 should be sufficient for the time being. Offset |
| sizes are limited to allow offsets to be baked into device-dependent |
| instruction encodings. |
| |
| (28) What level of precision should be guaranteed for the EXP and LOG |
| instructions? And for the EX2 and LG2 instructions? |
| |
| RESOLVED: The low precision EXP and LOG instructions should give at |
| least 10 bits (2^-11 maximum relative error). No specific treatment |
| will be added for EX2/LG2, implying that the computations should at |
| least meet the minimal floating-point precision required by the spec. |
| |
| (29) Should incremental program compilation be supported? |
| |
| RESOLVED: No. Applications can compile programs just as easily using |
| string concatenation. |
| |
| (30) Should the execution environment be identified by the program itself |
| or as an additional "language" parameter to ProgramStringARB? |
| |
| RESOLVED: Programs should identify their execution environment in the |
| header. The header (plus any specified options) make it clear what kind |
| of program is being defined. |
| |
| (31) Should this extension provide support for character sets other than |
| 7-bit ASCII? |
| |
| RESOLVED: Provide a <format> argument to ProgramStringARB to allow for |
| future extensions. Only ASCII will be supported by this extension; |
| additional character sets or encodings could be supported using separate |
| extensions. |
| |
| (32) Support for "program object" functionality may be applicable to |
| future program targets. Should this functionality be factored out into a |
| separate extension? |
| |
| RESOLVED: No, such separation is not necessary. This extension was |
| designed to allow to easily accommodate future program target types. It |
| would be straightforward to put program object functionality into a |
| separate extension, but the functionality provided by that extension |
| would be of no value by itself. |
| |
| (33) Should program residency management be supported? |
| |
| RESOLVED: No. This functionality can be supported in a separate |
| extension if desired. If may be desirable to address residency |
| management in a more general form, where an application may desire a |
| diverse set of objects (textures, programs) to be resident at once. |
| |
| (34) Should program object management APIs (GenProgramsARB, |
| DeleteProgramsARB) work like texture objects or display lists? |
| |
| RESOLVED: Texture objects. |
| |
| Both approaches have their merits. Pluses for the display list model |
| include: no need to keep around multiple indices if you want to |
| allocate a group of object, contiguous indices may fall out on |
| implementations that share one block allocator for textures and display |
| lists. Pluses for the texture object model: non-contiguous indices may |
| be more optimizable -- new objects can be mapped to empty blocks in a |
| hash table to avoid collisions with existing objects, separate indices |
| are more compatible with a future handle-based object paradigm, and a |
| larger base of extensions using this model. Note that display list |
| allocations needed to be contiguous to support CallLists, but no such |
| requirement for texture or program objects exists for programs. |
| |
| (35) Should there be support for a program object zero? With texture |
| objects, texture object zero is "special" because it is the default |
| texture object for each target type. Is there something like this for |
| program objects? |
| |
| RESOLVED: Yes. Like texture objects, there should be a separate |
| program object zero for each program type. This allows applications to |
| use vertex programs without needing to generate and manage program |
| objects. |
| |
| With texture objects, an object zero was needed for backward |
| compatibility with pre-OpenGL 1.1 applications. There is no such |
| requirement here, but providing an object zero nicely matches the |
| familiar texture object model. |
| |
| (36) How should this extension provide feedback on why a program failed to |
| load? |
| |
| RESOLVED: Two queries are provided. Calling GetIntegerv() with |
| PROGRAM_ERROR_POSITION_ARB provides the offset of an offending |
| instruction in the program string. An error position of -1 indicates |
| that a program loaded successfully. Calling GetString() with |
| PROGRAM_ERROR_STRING_ARB returns an implementation-dependent error |
| string explaining the reason for the failure. The error string can be |
| queried even on successful program loads to check for warning messages. |
| |
| The error string may be kept in a static buffer managed by the GL |
| implementation. Implementations may reuse the same buffer on subsequent |
| calls to ProgramStringARB, so returned error strings are guaranteed to |
| be valid only until the next such call. |
| |
| (37) How does ARB_vertex_blend's WEIGHT_SUM_UNITY_ARB mode interact with |
| this extension? This mode allows an application to specify N-1 weights, |
| and have the Nth weight computed by the GL. |
| |
| RESOLVED: The ARB_vertex_blend spec (as of May, 2002) specifies that |
| the nth weight is automatically computed by the GL and is effectively |
| current state. In practice, ARB_vertex_blend implementations compute |
| the nth weight on the fly in the fixed-function transformation pipeline, |
| implying that the ARB_vertex_blend spec may require a fix. For the |
| purposes of this extension, the WEIGHT_SUM_UNITY_ARB enable is ignored |
| in vertex program mode. Applications performing a vertex weighting |
| operation in a vertex program are free to compute the extra weight in |
| the program. |
| |
| (38) Should program environment parameters be pushed and popped? |
| |
| RESOLVED: No. There is no need to push and pop this large set of |
| state, much like pixel maps. Adding a new attribute bit would have |
| complicated logistics (would the bit be included in ALL_ATTRIB_BITS?). |
| Having program local parameters provides a method for making localized |
| changes to certain state simply by switching programs. |
| |
| (39) How should this extension interact with color material? |
| |
| RESOLVED: When color material is enabled, any bindings of material |
| colors that track the current color should be updated when the current |
| color is updated. In this specification, material properties can be |
| bound only as program parameters, and any changes to the material |
| properties inside a Begin/End leave the bindings undefined until the |
| next End command. Similarly, any indirect changes to the material |
| properties (through ColorMaterial) will have a similar effect. |
| |
| Several other options were considered here. One option was to support |
| per-vertex material property bindings and have programs that reference |
| tracked material properties should get the current color. This could be |
| handled either by broadcasting the current color to multiple vertex |
| attributes, or recompiling the vertex program so that references to a |
| tracked material property are redirected to the vertex color. Both such |
| solutions are somewhat complex. A second option would be to ignore the |
| COLOR_MATERIAL enable and instead use an "old" material color. This |
| breaks the standard color material model. Implementations can and often |
| do defer such updates (making an "old" color available), some conditions |
| may cause an implementation to update of material state at odd times. |
| |
| (41) What about when the execution environment involves support for other |
| extensions? In particular, the execution environment subsumes some |
| functionality from EXT/ARB_point_parameters, EXT_fog_coord, |
| EXT_secondary_color, and ARB_multitexture. |
| |
| RESOLVED: This extension assumes support for functionality that |
| includes a fog coordinate, secondary color, per-vertex point sizes, and |
| multiple texture coordinates (at least to the extent that it exposes >1 |
| texture coordinate). All of these extensions are supported fairly |
| widely. On some platforms, some of this functionality may require |
| software fallbacks. |
| |
| (42) How does PointSize work with vertex programs? |
| |
| RESOLVED: If VERTEX_PROGRAM_POINT_SIZE_ARB is disabled, the size of |
| points is determined by the PointSize state and is not attenuated, even |
| if EXT_point_parameters is supported. If enabled, the point size is the |
| point size result value, and is clamped to implementation-dependent |
| point size limits during point rasterization. |
| |
| (43) What do we say about the alpha component of the secondary color? |
| |
| RESOLVED: The alpha component of the secondary color has generally been |
| treated as zero. This extension specifies that only the R, G, and B |
| components are added in the color sum operation, making the alpha |
| component of the secondary color irrelevant. Other downstream |
| extensions may allow applications to make use of this component. |
| |
| (44) How are edge flags handled? |
| |
| RESOLVED: Edge flags are passed through without the ability to be |
| modified by a vertex program. Applications are free to send edge flags |
| when vertex program mode is enabled. |
| |
| (45) Should programs be C-style null-terminated strings? |
| |
| RESOLVED: No. Programs should be specified as an array of GLubyte with |
| an explicit length parameter. OpenGL has no precedent for passing |
| null-terminated strings into the API (though GetString returns |
| null-terminated strings). Null-terminated strings may be problematic |
| for some programming languages. |
| |
| (46) Should all existing OpenGL transform functionality and extensions be |
| implementable as vertex programs? |
| |
| RESOLVED: Yes. Vertex programs should be a complete superset of what |
| you can do with OpenGL 1.2 and existing vertex transform extensions. To |
| implement EXT_point_parameters, the VERTEX_PROGRAM_POINT_SIZE_ARB enable |
| is introduced. To implement two-sided lighting, the |
| VERTEX_PROGRAM_TWO_SIDE_ARB enable is introduced. To implement color |
| material, applications should refer to the per-vertex color attribute in |
| their vertex programs. |
| |
| (47) Should there be a plural version of ProgramEnvParameter and |
| ProgramLocalParameter, which would set multiple parameters in a single |
| call? |
| |
| RESOLVED: No; not necessary. |
| |
| (48) Can the currently bound vertex program object be deleted or reloaded? |
| |
| RESOLVED: Yes. When ProgramStringARB is called to reload a program |
| object, subsequent program executions will use the new program. When |
| DeleteProgramsARB deletes a currently bound program object, object zero |
| becomes the new current program object. |
| |
| (49) What happens if you transform vertices in vertex program mode, but |
| the current program object does not contain a valid vertex program? |
| |
| RESOLVED: Begin will fail with an INVALID_OPERATION error if the |
| currently bound vertex program object does not have a valid program. |
| The same applies to RasterPos and any command (Rect, DrawArrays, |
| DrawElements) that implies a Begin. |
| |
| Because Vertex is ignored outside of a Begin/End pair (without |
| generating an error) it is impossible to provoke a vertex program if the |
| current vertex program object is nonexistent or invalid. Other |
| per-vertex parameters (for examples those set by Color, Normal, and |
| VertexAttrib*ARB when the attribute number is not zero) are allowed |
| since they are legal outside of a Begin/End. |
| |
| (50) Discussing matrices is confusing because of row-major versus |
| column-major issues. Can you give an example of how a matrix is bound? |
| |
| RESOLVED: Assume program matrix zero were loaded with the following |
| code: |
| |
| // When loaded, the first row is "1, 2, 3, 4", because of column-major |
| // (OpenGL spec) vs. row-major (C) differences. |
| GLfloat matrix[16] = { 1, 5, 9, 13, |
| 2, 6, 10, 14, |
| 3, 7, 11, 15, |
| 4, 8, 12, 16 }; |
| glMatrixMode(GL_MATRIX0_ARB); |
| glLoadMatrixf(matrix); |
| |
| Then in the program |
| |
| !!ARBvp1.0 |
| PARAM mat1[4] = { state.matrix.program[0] }; |
| PARAM mat2[4] = { state.matrix.program[0].transpose }; |
| |
| mat1[0] would have (1,2,3,4), mat1[3] would have (13,14,15,16), mat2[0] |
| would have (1,5,9,13), and mat2[3] would have (4,8,12,16). |
| |
| (51) Should the new vertex program-related enables push/pop with |
| ENABLE_BIT? |
| |
| RESOLVED: Yes. Pushing and popping enable bits is easy. |
| |
| (52) Should all the vertex attribute state push/pop with CURRENT_BIT? |
| |
| RESOLVED: Yes. |
| |
| (53) Should all the vertex attrib vertex array state push/pop with |
| CLIENT_VERTEX_ARRAY_BIT? |
| |
| RESOLVED: Yes. |
| |
| (55) Should we generate an INVALID_VALUE operation if updating a vertex |
| attribute greater than MAX_VERTEX_ATTRIBS_ARB? |
| |
| RESOLVED: Yes. The other option would be to leave the behavior |
| undefined, as with MultiTexCoord() functions. An implementation could |
| mask or modulo the vertex attribute index with MAX_VERTEX_ATTRIB_ARB if |
| it were a power of two. This error check will be a minor performance |
| issue with VertexAttrib*ARB() and VertexAttribArrayARB() calls. There |
| will be no per-vertex overhead when using vertex arrays or display |
| lists. |
| |
| (56) Should writes to program environment or local parameters during a |
| vertex program be supported? |
| |
| RESOLVED. No. Writes to program parameter registers from within a |
| vertex program would require the execution of vertex programs to be |
| serialized with respect to each other. This would create a severe |
| implementation penalty for pipelined or parallel vertex program |
| execution implementations. |
| |
| (58) Should program objects be shared among rendering contexts in the same |
| manner as display lists and texture objects? |
| |
| RESOLVED: Yes. |
| |
| (60) Should there be a MatrixMode or ActiveTexture-style selector for |
| vertex attributes? |
| |
| RESOLVED: No. While this would reduce the number of enumerants used by |
| this extensions, it would create programming a hassle in lots of cases. |
| Consider having to change the vertex attribute mode to enable a set of |
| vertex arrays. |
| |
| (61) How should queries of vertex attribute arrays work? |
| |
| RESOLVED: Add new get commands. Using the existing calls would require |
| adding 6 sets of 16+ enumerants for current state and vertex attribute |
| array state. That's too many new enumerants. Instead, add |
| GetVertexAttribARB and GetVertexAttribPointervARB. GetVertexAttribARB |
| will be used to query vertex attribute array state and the current |
| values of the generic vertex attributes. Get and GetPointerv will not |
| return vertex attribute array state and pointers. |
| |
| (63) What should be said about rendering invariances? |
| |
| RESOLVED: See the Appendix A additions below. |
| |
| The justification for the two rules cited is to support multi-pass |
| rendering when using vertex programs. Different rendering passes will |
| likely use different programs so there must be some means of |
| guaranteeing that two different programs can generate particular |
| identical vertex results between different passes. |
| |
| In practice, this does limit the type of vertex program implementations |
| that are possible. |
| |
| For example, consider a limited hardware implementation of vertex |
| programs that uses a different floating-point implementation than the |
| CPU's floating-point implementation. If the limited hardware |
| implementation can only run small vertex programs (say the hardware |
| provides on 4 temporary registers instead of the required 12), the |
| implementation is incorrect and non-conformant if programs that only |
| require 4 temporary registers use the vertex program hardware, but |
| programs that require more than 4 temporary registers are implemented by |
| the CPU. |
| |
| This is a very important practical requirement. Consider a multi-pass |
| rendering algorithm where one pass uses a vertex program that uses only |
| 4 temporary registers, but a different pass uses a vertex program that |
| uses 5 temporary registers. If two programs have instruction sequences |
| that given the same input state compute identical resulting vertex |
| positions, the multi-pass algorithm should generate identically |
| positioned primitives for each pass. But given the non-conformant |
| vertex program implementation described above, this could not be |
| guaranteed. |
| |
| This does not mean that schemes for splitting vertex program |
| implementations between dedicated hardware and CPUs are impossible. If |
| the CPU and dedicated vertex program hardware used IDENTICAL |
| floating-point implementations and therefore generated exactly identical |
| results, the above described could work. |
| |
| While these invariance rules are vital for vertex programs operating |
| correctly for multi-pass algorithms, there is no requirement that |
| conventional OpenGL vertex transform mode will be invariant with vertex |
| program mode. A multi-pass algorithm should not assume that one pass |
| using vertex program mode and another pass using conventional GL vertex |
| transform mode will generate identically positioned primitives. |
| |
| Consider that while the conventional OpenGL vertex program mode is |
| repeatable with itself, the exact procedure used to transform vertices |
| is not specified nor is the procedure's precision specified. The GL |
| specification indicates that vertex coordinates are transformed by the |
| modelview matrix and then transformed by the projection matrix. Some |
| implementations may perform this sequence of transformations exactly, |
| but other implementations may transform vertex coordinates by the |
| composite of the modelview and projection matrices (one matrix transform |
| instead of two matrix transforms in sequence). Given this |
| implementation flexibility, there is no way for a vertex program author |
| to exactly duplicate the precise computations used by the conventional |
| OpenGL vertex transform mode. |
| |
| The guidance to OpenGL application programs is clear. If you are going |
| to implement multi-pass rendering algorithms that require certain |
| invariances between the multiple passes, choose either vertex program |
| mode or the conventional OpenGL vertex transform mode for your rendering |
| passes, but do not mix the two modes. |
| |
| (64) Should there be a way to guarantee position invariance with respect |
| to conventional vertex transformation? |
| |
| RESOLVED: Yes. The "OPTION ARB_position_invariant" program option |
| addresses this issue. This program option will be available on all |
| implementations of this extension. |
| |
| John Carmack advocated the need for this. |
| |
| (65) Why must RCP of 1.0 always be 1.0? |
| |
| RESOLVED: This is important for 3D graphics so that non-projective |
| textures and orthogonal projections work as expected. Basically when q |
| or w is 1.0, things should work as expected. Stronger requirements such |
| as "RCP of -1.0 must always be -1.0" are encouraged, but there is no |
| compelling reason to state such requirements explicitly as is the case |
| for "RCP of 1.0 must always be 1.0". |
| |
| (66) What happens when the source scalar value for the ARL instruction is |
| an extremely large positive or negative floating-point value? Is there a |
| problem mapping the value to a constrained integer range? |
| |
| RESOLVED: In this extension, address registers are only useful for |
| relative addressing. The range of offsets that can be added to an |
| address register is limited (-64 to +63) and the set of valid array |
| indices is also limited to MAX_PROGRAM_PARAMETERS_ARB. So, the set of |
| floating-point values that needs to be handled properly is |
| well-constrained. |
| |
| (67) How do you perform a 3-component normalize in three instructions? |
| |
| RESOLVED: As follows. |
| |
| DP3 result.w, vector, vector; # result.w = nx^2+ny^2+nz^2 |
| RSQ result.w, result.w; # result.w = 1/sqrt(nx^2+ny^2+nz^2) |
| MUL result.xyz, result.w, vector; |
| |
| (69) How do you compute the determinant of a 3x3 matrix in three |
| instructions? |
| |
| RESOLVED: As follows. |
| |
| # |
| # Determinant of | vec0.x vec0.y vec0.z | into result. |
| # | vec1.x vec1.y vec1.z | |
| # | vec2.x vec2.y vec2.z | |
| # |
| MUL result, vec1.zxyw, vec2.yzxw; |
| MAD result, vec1.yzxw, vec2.zxyw, -result; |
| DP3 result, vec0, result; |
| |
| (70) How do you transform a vertex position by a 4x4 matrix and then |
| perform a homogeneous divide? |
| |
| RESOLVED: As follows. |
| |
| ATTRIB pos = vertex.position; |
| TEMP result, temp; |
| PARAM mat[4] = { state.matrix.modelview }; |
| |
| DP4 result.w, pos, mat[3]; |
| DP4 result.x, pos, mat[0]; |
| DP4 result.y, pos, mat[1]; |
| DP4 result.z, pos, mat[2]; |
| RCP temp.w, result.w; |
| MUL result, result, temp.w; |
| |
| (71) How do you perform a vector weighting of two vectors using a single |
| weight? |
| |
| RESOLVED: As follows. |
| |
| # result = a * vec0 + (1-a) * vec1 |
| # = vec1 + a * (vec0 - vec1) |
| SUB result, vec0, vec1; |
| MAD result, a, result, vec1; |
| |
| (72) How do you reduce a value to some fundamental period such as 2*PI? |
| |
| RESOLVED: As follows. |
| |
| # result = 2*PI * fraction(in/(2*PI)) |
| # piVec = (1/(2*PI), 2*PI, 0, 0) |
| PARAM piVec = { 0.159154943, 6.283185307, 0, 0 }; |
| |
| MUL result, in, piVec.x; |
| EXP result, result.x; |
| MUL result, result.y, piVec.y; |
| |
| (73) How do you implement a simple ambient, specular, and diffuse infinite |
| lighting computation with a single light and an eye-space normal? |
| |
| RESOLVED: As follows. |
| |
| !!ARBvp1.0 |
| ATTRIB iPos = vertex.position; |
| ATTRIB iNormal = vertex.normal; |
| PARAM mvinv[4] = { state.matrix.modelview.invtrans }; |
| PARAM mvp[4] = { state.matrix.mvp }; |
| PARAM lightDir = state.light[0].position; |
| PARAM halfDir = state.light[0].half; |
| PARAM specExp = state.material.shininess; |
| PARAM ambientCol = state.lightprod[0].ambient; |
| PARAM diffuseCol = state.lightprod[0].diffuse; |
| PARAM specularCol = state.lightprod[0].specular; |
| TEMP xfNormal, temp, dots; |
| OUTPUT oPos = result.position; |
| OUTPUT oColor = result.color; |
| |
| # Transform the vertex to clip coordinates. |
| DP4 oPos.x, mvp[0], iPos; |
| DP4 oPos.y, mvp[1], iPos; |
| DP4 oPos.z, mvp[2], iPos; |
| DP4 oPos.w, mvp[3], iPos; |
| |
| # Transform the normal to eye coordinates. |
| DP3 xfNormal.x, mvinv[0], iNormal; |
| DP3 xfNormal.y, mvinv[1], iNormal; |
| DP3 xfNormal.z, mvinv[2], iNormal; |
| |
| # Compute diffuse and specular dot products and use LIT to compute |
| # lighting coefficients. |
| DP3 dots.x, xfNormal, lightDir; |
| DP3 dots.y, xfNormal, halfDir; |
| MOV dots.w, specExp.x; |
| LIT dots, dots; |
| |
| # Accumulate color contributions. |
| MAD temp, dots.y, diffuseCol, ambientCol; |
| MAD oColor.xyz, dots.z, specularCol, temp; |
| MOV oColor.w, diffuseCol.w; |
| END |
| |
| (75) Can you perturb transformed vertex positions with a vertex program? |
| |
| RESOLVED: Yes. Here is an example that performs an object-space |
| diffuse lighting computations and perturbs the vertex position based on |
| this lighting result. Do not take this example too seriously. |
| |
| !!ARBvp1.0 |
| # |
| # Program environment parameters: |
| # c[0].xyz = normalized light direction in object-space |
| # |
| # outputs diffuse illumination for color and perturbed position |
| # |
| ATTRIB iPos = vertex.position; |
| ATTRIB iNormal = vertex.normal; |
| PARAM mvp[4] = { state.matrix.mvp }; |
| PARAM lightDir = program.env[0]; |
| PARAM diffuseCol = { 1, 1, 0, 1 }; |
| TEMP temp; |
| OUTPUT oPos = result.position; |
| OUTPUT oColor = result.color; |
| |
| DP3 temp, lightDir, iNormal; |
| MUL oColor.xyz, temp, diffuseCol; |
| MAX temp, temp, 0; # clamp dot product to zero |
| MUL temp, temp, iNormal; # align in direction of normal |
| MUL temp, temp, 0.125; # scale displacement by 1/8 |
| SUB temp, temp, iPos; # perturb |
| DP4 oPos.x, mvp[0], temp; # xform using perturbed position |
| DP4 oPos.y, mvp[1], temp; |
| DP4 oPos.z, mvp[2], temp; |
| DP4 oPos.w, mvp[3], temp; |
| END |
| |
| (76) Should this extension provide any method for updating program |
| parameters in a program itself? |
| |
| RESOLVED: No. NV_vertex_program provided a special mechanism to do |
| this using a "vertex state program" manually executed by calling |
| ExecuteProgramNV. This capability has not proven itself particularly |
| useful to date. |
| |
| (78) Should there be a different ProgramStringARB call for every distinct |
| program target? Arguably, 1D, 2D, and 3D textures each have their own |
| TexImage command for specifying their image data. |
| |
| RESOLVED: No. All program objects can/should be loaded with |
| ProgramStringARB. We expect the string to be a sufficient to express |
| any kind of programmability. |
| |
| Moreover, the 1D, 2D, and 3D TexImage commands describe the image being |
| specified as opposed to the texture target being updated. With cube map |
| textures, there are six face texture targets that use the TexImage2D |
| command but not with the TEXTURE_2D target. |
| |
| (79) This extension introduces a collection of new matrices for use by |
| vertex programs (and possibly other programs as well). What should these |
| matrices be called? |
| |
| RESOLVED: Program matrices. These matrices are referred to as |
| "tracking matrices" in NV_vertex_program, but the functionality is |
| equivalent. |
| |
| (80) With ARB_vertex_blend and EXT_vertex_weighting, there are multiple |
| modelview matrices. This extension provides a single "MVP" matrix, |
| defined to be the product of modelview matrix 0 and the projection |
| matrices. Should this extension instead provide one MVP matrix per |
| modelview matrix? |
| |
| RESOLVED: No. Providing multiple MVP matrices allows applications to |
| do N transformations into clip space and then one weighting operation, |
| instead of N transformations into eye space, a weighting operation, and |
| then a single transformation into clip space. This would potentially |
| save instructions, but this optimization would be of no value if the |
| program did any other operations that required eye coordinates. |
| |
| Note also that the MVP transformations are likely general 4x4 matrix |
| multiplies (4 DP4 instructions per transform). On the other hand, |
| object and eye coordinates are often 3D coordinates with a constant W of |
| 1.0. So each transformation to eye coordinates may require only 3 DP4 |
| instructions, in which case the comparison may be 4N instructions (clip |
| weighting) vs. 3N+4 (eye weighting). |
| |
| (81) Should variable declarations be allowed to be anywhere within the |
| program body, or should they instead be required to be done at the |
| beginning of the program? Should the possibility of branching in a future |
| standard affect this resolution? |
| |
| RESOLVED: Declarations will be allowed anywhere in the program text; |
| the only ordering requirement is that the declaration of a variable must |
| precede its use in the program text. Requiring up-front variable |
| declarations may require multiple passes for applications that build |
| programs on the fly. |
| |
| While declarations can appear anywhere in the program body, they are not |
| executable statements. Any corresponding bindings (including constant |
| initializations) are resolved before the program executes. The bindings |
| will be resolved even if a program were to "branch around" a |
| declaration. |
| |
| (82) Should address register variables be treated as vectors? If so, |
| should a variable number of components (up to four) be supported by this |
| extension? |
| |
| RESOLVED: In the future, four-component address vectors may be |
| supported, and vector notation is used for forward compatibility. Using |
| this notation makes address registers consistent with all the other |
| vector data types in this extension. However, support for more than one |
| usable component will be left for future extensions, but could be added |
| via a program option or in a new language revision (e.g., !!ARBvp2.0). |
| |
| (83) Should program local parameters be logically connected to the program |
| string or the program object? |
| |
| RESOLVED: Program local parameters are properties of a program object. |
| Their values persist even after a new program is loaded into the object. |
| This model does allow applications to recompile the program in a given |
| object based on certain rendering settings without having to |
| re-initialize any state stored in the object. |
| |
| (84) Should this extension provide a method to specify "anonymous" program |
| local parameters and query an index into the program parameter array. |
| |
| RESOLVED: No. It would be nice to declare a variable in a program such |
| as |
| |
| PARAM foo = program.local; # note no index in the array |
| |
| after which an application could query the location of "foo" in the |
| program local parameter array. However, given that local parameters |
| persist even across program loads, it would be difficult to specify what |
| program local parameter "foo" would be assigned to. |
| |
| (85) EXT_vertex_weighting provides a single vertex blend weight. |
| ARB_vertex_blend generalizes this concept to a weight vector. Both pieces |
| of state are specified separately, and could be thought of as distinct. |
| Should distinct bindings be provided in this extension? |
| |
| RESOLVED: No. No current implementation supports both extensions, but |
| the vendors involved in this standardization process agree that the |
| state should not be considered distinct. If an implementation supported |
| both extensions, the APIs would modify the same state. |
| |
| (86) Should this extension provide functionality for variable aliasing? |
| If so, how should it be specified and what types of variables can be |
| aliasesed? |
| |
| RESOLVED: Yes, for all variable types. The syntax is a simple text |
| replacement: |
| |
| ALIAS a = b; |
| |
| This functionality allows applications to "share" variables, and thereby |
| exceed implementation-dependent limits on the number of variable |
| declarations. This may be particularly significant for temporaries, |
| where the limit on the number of variables may be fairly low. |
| |
| (87) How do you determine whether a given program option is supported by |
| the GL implementation? |
| |
| RESOLVED: Program options may be introduced in OpenGL extensions and |
| may be added to future OpenGL specifications. An option will be |
| supported if and only if (1) the corresponding OpenGL extension appears |
| in the implementation-dependent EXTENSIONS string or (2) the option is |
| documented in the OpenGL specification version corresponding to the |
| implementation's VERSION string. |
| |
| The ARB_position_invariant option is provided by this extension, and |
| will always be available (provided this extension is supported). |
| |
| (88) What's the deal with binding the alpha component of light colors, fog |
| colors, and material colors (other than diffuse)? They don't do anything, |
| right? |
| |
| RESOLVED: The GL state for these different colors includes alpha |
| components, which will be returned by queries. However, in the |
| conventional OpenGL pipeline, most of these alpha components are |
| effectively ignored. However, since they are present in the GL state, |
| they will be exposed in bindings. What is done with these alpha values |
| in program mode is completely up to the vertex program. |
| |
| Vertex programs need to be careful to ensure that the alpha component is |
| computed correctly when evaluating lighting equations. When |
| accumulating light contributions, it may be necessary to use write masks |
| to disable writes to the alpha component. |
| |
| (89) The LOG instruction takes the logarithm of the absolute value of its |
| operand while the LG2 instruction takes the logarithm of the operand |
| itself. In LG2, the logarithm of negative numbers is undefined. |
| |
| RESOLVED: The LOG instruction is present for (1) compatibility with |
| NV_vertex_program and DirectX 8 languages and (2) because it may |
| outperform LG2 on some platforms. For compatibility, it is defined to |
| behave identically to existing languages. |
| |
| (90) With vertex programs, fog coordinates and point sizes can be computed |
| on a per-vertex basis. How are the fog coordinates and point sizes |
| associated with vertices introduced by clipping computed? |
| |
| RESOLVED: Fog coordinates and point sizes for clipped vertices are |
| computed by interpolating the computed values at the original vertices |
| in exactly the same manner as colors and texture coordinates are |
| interpolated in section 2.13.8 of the OpenGL 1.3 specification. |
| |
| (91) Vertex programs support only RGBA colors, but do not support color |
| index inputs or results. What happens if an application uses vertex |
| programs in color index mode. |
| |
| RESOLVED: The results of vertex program execution are undefined if the |
| GL is in color index mode. |
| |
| (92) Should automatic normalization of evaluated normals (AUTO_NORMAL) be |
| supported when the GL is in vertex program mode? |
| |
| RESOLVED: Automatic normalization of normals will be disabled in vertex |
| program mode. The current vertex program can easily normalize the |
| normal if required. This can lead to greater efficiency if the vertex |
| program transforms the normal to another coordinate system such as |
| eye-space with a transform that preserves vector length. Then a single |
| normalize after transform is more efficient than normalizing after |
| evaluation and normalizing again after transform. Conceptually, the |
| normalize mandated for AUTO_NORMAL in section 5.1 is just one of the |
| many transformation operations subsumed by vertex programs. |
| |
| (93) This extension allows applications to name their own variables. What |
| keywords should be reserved? |
| |
| RESOLVED: Instruction names and declaration keywords (e.g., PARAM) will |
| be reserved. Additionally, since attribute, parameter, and result |
| bindings are allowed in the program text, the binding prefix keywords |
| "vertex", "state", "program", and "result" are reserved to simplify |
| parsing. This prevents the need to distinguish between |
| "vertex.position" ("vertex" as a binding) and "vertex.xyzw" ("vertex" as |
| a variable). |
| |
| (94) When counting the number of program parameter bindings, multiple |
| constant vectors with the same components are counted only once. How is |
| this determined? |
| |
| RESOLVED: The implementation does a numerical comparison after the |
| specified constants are converted to an internal floating-point |
| representation. Due to floating-point representation limits, such |
| conversions are not always precise. Constants specified with different |
| text that are "equivalent" (e.g., "12" and "1.2E+01") are not guaranteed |
| to resolve to the same value. Additionally, constants that are not |
| "equivalent" but have only small relative differences (e.g., "200000000" |
| and "200000001") may end up resolving to the same value. Constants |
| specified with the same text should always be identical. |
| |
| (95) What characters are allowed in identifier names? |
| |
| RESOLVED: Letters ("A"-"Z", "a"-"z"), numbers ("0"-"9"), underscores |
| ("_"), and dollar signs ("$"). |
| |
| (96) How should future programmability extensions interact with this one? |
| |
| RESOLVED: Future programmability extensions are expected to fall in one |
| of two classes: (1) extensions that bring programmability to new |
| sections and (2) extensions the extend existing programmability models. |
| The former class should introduce a new program target; the latter class |
| would extend the functionality of an existing target. |
| |
| Recommendations for extensions introducing new program targets include: |
| |
| * Re-use and reference the functionality specified in this extension |
| (or in a future OpenGL specification incorporating this extension) |
| as much as possible, to maintain a consistent model. |
| |
| * Provide a program header allowing for easy identification and |
| versioning of programs for the new target. |
| |
| Recommendations for extensions modifying existing program targets |
| include: |
| |
| * The option mechanism (section 2.14.4.5) should be used to provide |
| minor modifications to the program language. |
| |
| * The program header/version string (section 2.14.2) should be used to |
| provide major modifications to the language, or potentially to |
| provide a commonly used collection of options. Program header |
| string changes should be multi-vendor extensions as much as |
| possible. |
| |
| * For portability, programs should not be allowed to use extended |
| language features without specifying the corresponding program |
| options or program header. |
| |
| |
| New Procedures and Functions |
| |
| void VertexAttrib1sARB(uint index, short x); |
| void VertexAttrib1fARB(uint index, float x); |
| void VertexAttrib1dARB(uint index, double x); |
| void VertexAttrib2sARB(uint index, short x, short y); |
| void VertexAttrib2fARB(uint index, float x, float y); |
| void VertexAttrib2dARB(uint index, double x, double y); |
| void VertexAttrib3sARB(uint index, short x, short y, short z); |
| void VertexAttrib3fARB(uint index, float x, float y, float z); |
| void VertexAttrib3dARB(uint index, double x, double y, double z); |
| void VertexAttrib4sARB(uint index, short x, short y, short z, short w); |
| void VertexAttrib4fARB(uint index, float x, float y, float z, float w); |
| void VertexAttrib4dARB(uint index, double x, double y, double z, double w); |
| void VertexAttrib4NubARB(uint index, ubyte x, ubyte y, ubyte z, ubyte w); |
| |
| void VertexAttrib1svARB(uint index, const short *v); |
| void VertexAttrib1fvARB(uint index, const float *v); |
| void VertexAttrib1dvARB(uint index, const double *v); |
| void VertexAttrib2svARB(uint index, const short *v); |
| void VertexAttrib2fvARB(uint index, const float *v); |
| void VertexAttrib2dvARB(uint index, const double *v); |
| void VertexAttrib3svARB(uint index, const short *v); |
| void VertexAttrib3fvARB(uint index, const float *v); |
| void VertexAttrib3dvARB(uint index, const double *v); |
| void VertexAttrib4bvARB(uint index, const byte *v); |
| void VertexAttrib4svARB(uint index, const short *v); |
| void VertexAttrib4ivARB(uint index, const int *v); |
| void VertexAttrib4ubvARB(uint index, const ubyte *v); |
| void VertexAttrib4usvARB(uint index, const ushort *v); |
| void VertexAttrib4uivARB(uint index, const uint *v); |
| void VertexAttrib4fvARB(uint index, const float *v); |
| void VertexAttrib4dvARB(uint index, const double *v); |
| void VertexAttrib4NbvARB(uint index, const byte *v); |
| void VertexAttrib4NsvARB(uint index, const short *v); |
| void VertexAttrib4NivARB(uint index, const int *v); |
| void VertexAttrib4NubvARB(uint index, const ubyte *v); |
| void VertexAttrib4NusvARB(uint index, const ushort *v); |
| void VertexAttrib4NuivARB(uint index, const uint *v); |
| |
| void VertexAttribPointerARB(uint index, int size, enum type, |
| boolean normalized, sizei stride, |
| const void *pointer); |
| |
| void EnableVertexAttribArrayARB(uint index); |
| void DisableVertexAttribArrayARB(uint index); |
| |
| void ProgramStringARB(enum target, enum format, sizei len, |
| const void *string); |
| |
| void BindProgramARB(enum target, uint program); |
| |
| void DeleteProgramsARB(sizei n, const uint *programs); |
| |
| void GenProgramsARB(sizei n, uint *programs); |
| |
| void ProgramEnvParameter4dARB(enum target, uint index, |
| double x, double y, double z, double w); |
| void ProgramEnvParameter4dvARB(enum target, uint index, |
| const double *params); |
| void ProgramEnvParameter4fARB(enum target, uint index, |
| float x, float y, float z, float w); |
| void ProgramEnvParameter4fvARB(enum target, uint index, |
| const float *params); |
| |
| void ProgramLocalParameter4dARB(enum target, uint index, |
| double x, double y, double z, double w); |
| void ProgramLocalParameter4dvARB(enum target, uint index, |
| const double *params); |
| void ProgramLocalParameter4fARB(enum target, uint index, |
| float x, float y, float z, float w); |
| void ProgramLocalParameter4fvARB(enum target, uint index, |
| const float *params); |
| |
| void GetProgramEnvParameterdvARB(enum target, uint index, |
| double *params); |
| void GetProgramEnvParameterfvARB(enum target, uint index, |
| float *params); |
| |
| void GetProgramLocalParameterdvARB(enum target, uint index, |
| double *params); |
| void GetProgramLocalParameterfvARB(enum target, uint index, |
| float *params); |
| |
| void GetProgramivARB(enum target, enum pname, int *params); |
| |
| void GetProgramStringARB(enum target, enum pname, void *string); |
| |
| void GetVertexAttribdvARB(uint index, enum pname, double *params); |
| void GetVertexAttribfvARB(uint index, enum pname, float *params); |
| void GetVertexAttribivARB(uint index, enum pname, int *params); |
| |
| void GetVertexAttribPointervARB(uint index, enum pname, void **pointer); |
| |
| boolean IsProgramARB(uint program); |
| |
| |
| 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. |
| |
| VERTEX_PROGRAM_ARB 0x8620 |
| |
| Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, and by |
| the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and |
| GetDoublev: |
| |
| VERTEX_PROGRAM_POINT_SIZE_ARB 0x8642 |
| VERTEX_PROGRAM_TWO_SIDE_ARB 0x8643 |
| COLOR_SUM_ARB 0x8458 |
| |
| Accepted by the <format> parameter of ProgramStringARB: |
| |
| PROGRAM_FORMAT_ASCII_ARB 0x8875 |
| |
| Accepted by the <pname> parameter of GetVertexAttrib[dfi]vARB: |
| |
| VERTEX_ATTRIB_ARRAY_ENABLED_ARB 0x8622 |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB 0x8623 |
| VERTEX_ATTRIB_ARRAY_STRIDE_ARB 0x8624 |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB 0x8625 |
| VERTEX_ATTRIB_ARRAY_NORMALIZED_ARB 0x886A |
| CURRENT_VERTEX_ATTRIB_ARB 0x8626 |
| |
| Accepted by the <pname> parameter of GetVertexAttribPointervARB: |
| |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB 0x8645 |
| |
| Accepted by the <pname> parameter of GetProgramivARB: |
| |
| PROGRAM_LENGTH_ARB 0x8627 |
| PROGRAM_FORMAT_ARB 0x8876 |
| PROGRAM_BINDING_ARB 0x8677 |
| PROGRAM_INSTRUCTIONS_ARB 0x88A0 |
| MAX_PROGRAM_INSTRUCTIONS_ARB 0x88A1 |
| PROGRAM_NATIVE_INSTRUCTIONS_ARB 0x88A2 |
| MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB 0x88A3 |
| PROGRAM_TEMPORARIES_ARB 0x88A4 |
| MAX_PROGRAM_TEMPORARIES_ARB 0x88A5 |
| PROGRAM_NATIVE_TEMPORARIES_ARB 0x88A6 |
| MAX_PROGRAM_NATIVE_TEMPORARIES_ARB 0x88A7 |
| PROGRAM_PARAMETERS_ARB 0x88A8 |
| MAX_PROGRAM_PARAMETERS_ARB 0x88A9 |
| PROGRAM_NATIVE_PARAMETERS_ARB 0x88AA |
| MAX_PROGRAM_NATIVE_PARAMETERS_ARB 0x88AB |
| PROGRAM_ATTRIBS_ARB 0x88AC |
| MAX_PROGRAM_ATTRIBS_ARB 0x88AD |
| PROGRAM_NATIVE_ATTRIBS_ARB 0x88AE |
| MAX_PROGRAM_NATIVE_ATTRIBS_ARB 0x88AF |
| PROGRAM_ADDRESS_REGISTERS_ARB 0x88B0 |
| MAX_PROGRAM_ADDRESS_REGISTERS_ARB 0x88B1 |
| PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB 0x88B2 |
| MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB 0x88B3 |
| MAX_PROGRAM_LOCAL_PARAMETERS_ARB 0x88B4 |
| MAX_PROGRAM_ENV_PARAMETERS_ARB 0x88B5 |
| PROGRAM_UNDER_NATIVE_LIMITS_ARB 0x88B6 |
| |
| Accepted by the <pname> parameter of GetProgramStringARB: |
| |
| PROGRAM_STRING_ARB 0x8628 |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| PROGRAM_ERROR_POSITION_ARB 0x864B |
| CURRENT_MATRIX_ARB 0x8641 |
| TRANSPOSE_CURRENT_MATRIX_ARB 0x88B7 |
| CURRENT_MATRIX_STACK_DEPTH_ARB 0x8640 |
| MAX_VERTEX_ATTRIBS_ARB 0x8869 |
| MAX_PROGRAM_MATRICES_ARB 0x862F |
| MAX_PROGRAM_MATRIX_STACK_DEPTH_ARB 0x862E |
| |
| Accepted by the <name> parameter of GetString: |
| |
| PROGRAM_ERROR_STRING_ARB 0x8874 |
| |
| Accepted by the <mode> parameter of MatrixMode: |
| |
| MATRIX0_ARB 0x88C0 |
| MATRIX1_ARB 0x88C1 |
| MATRIX2_ARB 0x88C2 |
| MATRIX3_ARB 0x88C3 |
| MATRIX4_ARB 0x88C4 |
| MATRIX5_ARB 0x88C5 |
| MATRIX6_ARB 0x88C6 |
| MATRIX7_ARB 0x88C7 |
| MATRIX8_ARB 0x88C8 |
| MATRIX9_ARB 0x88C9 |
| MATRIX10_ARB 0x88CA |
| MATRIX11_ARB 0x88CB |
| MATRIX12_ARB 0x88CC |
| MATRIX13_ARB 0x88CD |
| MATRIX14_ARB 0x88CE |
| MATRIX15_ARB 0x88CF |
| MATRIX16_ARB 0x88D0 |
| MATRIX17_ARB 0x88D1 |
| MATRIX18_ARB 0x88D2 |
| MATRIX19_ARB 0x88D3 |
| MATRIX20_ARB 0x88D4 |
| MATRIX21_ARB 0x88D5 |
| MATRIX22_ARB 0x88D6 |
| MATRIX23_ARB 0x88D7 |
| MATRIX24_ARB 0x88D8 |
| MATRIX25_ARB 0x88D9 |
| MATRIX26_ARB 0x88DA |
| MATRIX27_ARB 0x88DB |
| MATRIX28_ARB 0x88DC |
| MATRIX29_ARB 0x88DD |
| MATRIX30_ARB 0x88DE |
| MATRIX31_ARB 0x88DF |
| |
| Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) |
| |
| Modify Section 2.6, Begin/End Paradigm (p. 12) |
| |
| (modify last paragraph, p. 12) ... In addition, a current normal, a |
| current color, multiple current texture coordinate sets, and multiple |
| generic vertex attributes may be used in processing each vertex. Normals |
| are used by the GL in lighting calculations; the current normal is a |
| three-dimensional vector that may be set by sending three coordinates that |
| specify it. Texture coordinates determine how a texture image is mapped |
| onto a primitive. Multiple sets of texture coordinates may be used to |
| specify how multiple texture images are mapped onto a primitive. Generic |
| vertex attributes do not have any specific function but can be used in |
| vertex program mode (section 2.14) to compute final values for any data |
| associated with a vertex. |
| |
| |
| Modify Section 2.6.3, GL Commands within Begin/End (p. 19) |
| |
| (modify first paragraph of section, p. 19) The only GL commands that are |
| allowed within any Begin/End pairs are the commands for specifying vertex |
| coordinates, vertex color, normal coordinates, texture coordinates, and |
| generic vertex attributes (Vertex, Color, Index, Normal, TexCoord, |
| VertexAttrib*ARB), ... |
| |
| |
| Modify Section 2.7, Vertex Specification (p. 19) |
| |
| (remove the "Finally" from the next-to-last paragraph, p. 20) There are |
| several ways to set the current color. The GL stores both a current |
| single-valued color index, and a current four-valued RGBA color. One |
| |
| (add new paragraph before last paragraph of section, p. 21) Vertex |
| programs (section 2.14) can access an array of four-component generic |
| current vertex attributes. The first entry of this array is numbered |
| zero, and the number of entries in the array is given by the |
| implementation-dependent constant MAX_VERTEX_ATTRIBS_ARB. The commands |
| |
| void VertexAttrib{1234}{sfd}ARB(uint index, T coords); |
| void VertexAttrib{123}{sfd}vARB(uint index, T coords); |
| void VertexAttrib4{bsifd ubusui}vARB(uint index, T coords); |
| |
| specify the current vertex attribute numbered <index>, whose components |
| are named <x>, <y>, <z>, and <w>. The VertexAttrib1ARB family of commands |
| sets the <x> coordinate to the provided single argument while setting <y> |
| and <z> to 0 and <w> to 1. Similarly, VertexAttrib2ARB commands set <x> |
| and <y> to the specified values, <z> to 0 and <w> to 1; VertexAttrib3ARB |
| commands set <x>, <y>, and <z>, with <w> set to 1, and VertexAttrib4ARB |
| commands set all four coordinates. The error INVALID_VALUE is generated |
| if <index> is greater than or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| The commands |
| |
| void VertexAttrib4NubARB(uint index, T coords); |
| void VertexAttrib4N{bsi ubusui}vARB(uint index, T coords); |
| |
| also specify vertex attributes with fixed-point coordinates that are |
| scaled to the range [0,1] or [-1,1], according to Table 2.6. |
| |
| Setting generic vertex attribute zero specifies a vertex; the four vertex |
| coordinates are taken from the values of attribute zero. A Vertex2, |
| Vertex3, or Vertex4 command is completely equivalent to the corresponding |
| VertexAttrib command with an index of zero. Setting any other generic |
| vertex attribute updates the current values of the attribute. There are |
| no current values for vertex attribute zero. |
| |
| Implementations may, but do not necessarily, use the same storage for the |
| current values of generic and certain conventional vertex attributes. |
| When any generic vertex attribute other than zero is specified, the |
| current values for the corresponding conventional attribute in Table X.1 |
| become undefined. Additionally, when a conventional vertex attribute is |
| specified, the current values for the corresponding generic vertex |
| attribute in Table X.1 become undefined. For example, setting the current |
| normal will leave generic vertex attribute 2 undefined, and vice versa. |
| |
| Generic |
| Attribute Conventional Attribute Conventional Attribute Command |
| --------- ------------------------ ------------------------------ |
| 0 vertex position Vertex |
| 1 vertex weights 0-3 WeightARB, VertexWeightEXT |
| 2 normal Normal |
| 3 primary color Color |
| 4 secondary color SecondaryColorEXT |
| 5 fog coordinate FogCoordEXT |
| 6 - - |
| 7 - - |
| 8 texture coordinate set 0 MultiTexCoord(TEXTURE0, ...) |
| 9 texture coordinate set 1 MultiTexCoord(TEXTURE1, ...) |
| 10 texture coordinate set 2 MultiTexCoord(TEXTURE2, ...) |
| 11 texture coordinate set 3 MultiTexCoord(TEXTURE3, ...) |
| 12 texture coordinate set 4 MultiTexCoord(TEXTURE4, ...) |
| 13 texture coordinate set 5 MultiTexCoord(TEXTURE5, ...) |
| 14 texture coordinate set 6 MultiTexCoord(TEXTURE6, ...) |
| 15 texture coordinate set 7 MultiTexCoord(TEXTURE7, ...) |
| 8+n texture coordinate set n MultiTexCoord(TEXTURE0+n, ...) |
| |
| Table X.1, Generic and Conventional Vertex Attribute Mappings. For each |
| row, the current value of the conventional attribute becomes undefined |
| when the corresponding generic attribute is set, and vice versa. |
| Attribute zero corresponds to the vertex position and has no current |
| state. |
| |
| Setting any conventional vertex attribute not listed in Table X.1 |
| (including vertex weights 4 and above, if supported) will not cause any |
| generic vertex attribute to become undefined, and such attributes will not |
| become undefined when any generic vertex attribute is set. |
| |
| |
| |
| (modify the last paragraph in the section, p.21) The state required to |
| support vertex specification consists of four floating-point numbers per |
| texture unit to store the current texture coordinates s, t, r, and q, |
| three floating-point numbers to store the three coordinates of the current |
| normal, four floating-point values to store the current RGBA color, one |
| floating-point value to store the current color index, and |
| MAX_VERTEX_ATTRIBS_ARB-1 four-component floating-point vectors for generic |
| vertex attributes. There is no notion of a current vertex, so no state is |
| devoted to vertex coordinates or vertex attribute zero. The initial |
| texture coordinates are (S,T,R,Q) = (0,0,0,1) for each texture unit. The |
| initial current normal has coordinates (0,0,1). The initial RGBA color is |
| (R,G,B,A) = (1,1,1,1). The initial color index is 1. The initial values |
| for all generic vertex attributes are undefined. |
| |
| |
| Modify Section 2.8, Vertex Arrays (p. 21) |
| |
| (modify first paragraph of section, p.21) The vertex specification |
| commands described in section 2.7 accept data in almost any format, but |
| their use requires many command executions to specify even simple |
| geometry. Vertex data may also be placed into arrays that are stored in |
| the client's address space. Blocks of data in these arrays may then be |
| used to specify multiple geometric primitives through the execution of a |
| single GL command. The client may specify up to 5 plus the values of |
| MAX_TEXTURE_UNITS and MAX_VERTEX_ATTRIBS_ARB arrays: one each to store |
| vertex coordinates, edge flags, colors, color indices, normals, one or |
| more texture coordinate sets, and one or more generic vertex attributes. |
| The commands |
| |
| ... |
| |
| void VertexAttribPointerARB(uint index, int size, enum type, |
| boolean normalized, sizei stride, |
| const void *pointer); |
| |
| describe the locations and organizations... |
| |
| (add after the first paragraph, p.22) The <index> parameter in the |
| VertexAttribPointer command identifies the generic vertex attribute array |
| being described. The error INVALID_VALUE is generated if <index> is |
| greater than or equal to MAX_VERTEX_ATTRIBS_ARB. The <normalized> |
| parameter in the VertexAttribPointer command identifies whether |
| fixed-point types should be normalized when converted to floating-point. |
| If <normalized> is TRUE, fixed-point data are converted as specified in |
| Table 2.6; otherwise, the fixed-point values are converted directly. |
| |
| (add after first paragraph, p.23) An individual generic vertex attribute |
| array is enabled or disabled by calling one of |
| |
| void EnableVertexAttribArrayARB(uint index); |
| void DisableVertexAttribArrayARB(uint index); |
| |
| where <index> identifies the generic vertex attribute array to enable or |
| disable. The error INVALID_VALUE is generated if <index> is greater than |
| or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| (modify Table 2.4, p.23) |
| |
| Normal |
| Command Sizes ized? Types |
| ---------------------- ------- ------ -------------------------------- |
| VertexPointer 2,3,4 no short, int, float, double |
| NormalPointer 3 yes byte, short, int, float, double |
| ColorPointer 3,4 yes byte, ubyte, short, ushort, |
| int, uint, float, double |
| IndexPointer 1 no ubyte, short, int, float, double |
| TexCoordPointer 1,2,3,4 no short, int, float, double |
| EdgeFlagPointer 1 no boolean |
| VertexAttribPointerARB 1,2,3,4 flag byte, ubyte, short, ushort, |
| int, uint, float, double |
| WeightPointerARB >=1 yes byte, ubyte, short, ushort, |
| int, uint, float, double |
| VertexWeightPointerEXT 1 n/a float |
| SecondaryColor- 3 yes byte, ubyte, short, ushort, |
| PointerEXT int, uint, float, double |
| FogCoordPointerEXT 1 n/a float, double |
| MatrixIndexPointerARB >=1 no ubyte, ushort, uint |
| |
| Table 2.4: Vertex array sizes (values per vertex) and data types. The |
| "normalized" column indicates whether fixed-point types are accepted |
| directly or normalized to [0,1] (for unsigned types) or [-1,1] (for |
| singed types). For generic vertex attributes, fixed-point data are |
| normalized if and only if the <normalized> flag is set. |
| |
| (modify last paragraph, p.23) The command |
| |
| void ArrayElement(int i); |
| |
| transfers the ith element of every enabled array to the GL. The effect of |
| ArrayElement(i) is the same as the effect of the command sequence |
| |
| if (ARB_vertex_blend vertex weight array enabled) { |
| Weight[type]vARB(vertex weight array size, |
| vertex weight array element i); |
| } |
| if (EXT_vertex_weighting vertex weight array enabled) { |
| VertexWeight[type]vARB(vertex weight array element i); |
| } |
| if (normal array enabled) { |
| Normal3[type]v(normal array element i); |
| } |
| if (color array enabled) { |
| Color[size][type]v(color array element i); |
| } |
| if (secondary color array enabled) { |
| SecondaryColor3[type]vEXT(secondary color array element i); |
| } |
| if (fog coordinate array enabled) { |
| FogCoord[type]vEXT(fog coordinate array element i); |
| } |
| if (matrix index array enabled) { |
| MatrixIndex[type]vARB(matrix index array size, |
| matrix index array element i); |
| } |
| for (j = 0; j < textureUnits; j++) { |
| if (texture coordinate set j array enabled) { |
| MultiTexCoord[size][type]v(TEXTURE0 + j, |
| texture coordinate set j |
| array element i); |
| } |
| if (color index array enabled) { |
| Index[type]v(color index array element i); |
| } |
| if (edge flag array enabled) { |
| EdgeFlagv(edge flag array element i); |
| } |
| for (j = 1; j < genericAttributes; j++) { |
| if (generic vertex attribute j array enabled) { |
| if (generic vertex attribute j array normalization flag |
| is set, and type is not FLOAT or DOUBLE) { |
| VertexAttrib[size]N[type]vARB(j, generic vertex attribute j |
| array element i); |
| } else { |
| VertexAttrib[size][type]vARB(j, generic vertex attribute j |
| array element i); |
| } |
| } |
| } |
| if (generic attribute array 0 enabled) { |
| if (generic vertex attribute j array normalization flag |
| is set, and type is not FLOAT or DOUBLE) { |
| VertexAttrib[size]N[type]vARB(0, generic vertex attribute 0 |
| array element i); |
| } else { |
| VertexAttrib[size][type]vARB(0, generic vertex attribute 0 |
| array element i); |
| } |
| } else if (vertex array enabled) { |
| Vertex[size][type]vARB(vertex array element i); |
| } |
| |
| where <textureUnits> and <genericAttributes> give the number of texture |
| units and generic vertex attributes supported by the implementation, |
| respectively. "[size]" and "[type]" correspond to the size and type of |
| the corresponding array. For generic vertex attributes, it is assumed |
| that a complete set of vertex attribute commands exists, even though not |
| all such functions are provided by the GL. Both generic attribute array |
| zero and the vertex array can specify a vertex if enabled, but only one |
| such array is used. As described in section 2.7, setting a generic vertex |
| attributes listed in Table X.1 will leave the corresponding conventional |
| vertex attribute undefined, and vice versa. |
| |
| |
| (modify last paragraph of section, p.28) If the number of supported |
| texture units (the value of MAX TEXTURE UNITS) is m and the number of |
| supported generic vertex attributes (MAX_VERTEX_ATTRIBS_ARB) is n, then |
| the client state required to implement vertex arrays consists of 5+m+n |
| boolean enables, 5+m+n memory pointers, 5+m+n integer stride values, 4+m+n |
| symbolic constants representing array types, 2+m+n integers representing |
| values per element, and n boolean normalization flags. In the initial |
| state, the enable values are each disabled, the memory pointers are each |
| null, the strides are each zero, the array types are each FLOAT, the |
| integers representing values per element are each four, and the |
| normalization flags are disabled.. |
| |
| |
| Modify Section 2.10, Coordinate Transformations (p. 29) |
| |
| (add new paragraphs) Vertex attributes are transformed before the vertex |
| is used to generate primitives for rasterization, establish a raster |
| position, or generate vertices for selection or feedback. The attributes |
| of each vertex are transformed using one of two vertex transformation |
| modes. The first mode, described in this and subsequent sections, is GL's |
| conventional vertex transformation model. The second mode, known as |
| vertex program mode and described in section 2.14, transforms vertex |
| attributes as specified in an application-supplied vertex program. |
| |
| Vertex program mode is enabled and disabled, respectively, by |
| |
| void Enable(enum target); |
| |
| and |
| |
| void Disable(enum target); |
| |
| with <target> equal to VERTEX_PROGRAM_ARB. When vertex program mode is |
| enabled, vertices are transformed by the currently bound vertex program as |
| discussed in section 2.14. |
| |
| When vertex program mode is disabled, vertices, normals, and texture |
| coordinates are transformed before their coordinates are used to produce |
| an image in the framebuffer. We begin with a description of how vertex |
| coordinates are transformed and how the transformation is controlled in |
| this case. The discussion that continues through section 2.13 applies |
| when vertex program mode is disabled. |
| |
| |
| Modify Section 2.10.2, Matrices (p. 31) |
| |
| (modify 1st paragraph) The projection matrix and model-view matrix are set |
| and modified with a variety of commands. The affected matrix is |
| determined by the current matrix mode. The current matrix mode is set |
| with |
| |
| void MatrixMode(enum mode); |
| |
| which takes one of the pre-defined constants TEXTURE, MODELVIEW, COLOR, |
| PROJECTION, or MATRIX<i>_ARB as the argument. In the case of |
| MATRIX<i>_ARB, <i> is an integer between 0 and <n>-1 indicating one of <n> |
| program matrices where <n> is the value of the implementation defined |
| constant MAX_PROGRAM_MATRICES_ARB. Such program matrices are described in |
| section 2.14.6. TEXTURE is described later in section 2.10.2, and COLOR |
| is described in section 3.6.3. If the current matrix mode is MODELVIEW, |
| then matrix operations apply to the model-view matrix; if PROJECTION, then |
| they apply to the projection matrix. |
| |
| (modify last paragraph of section) The state required to implement |
| transformations consists of a <n>-value integer indicating the current |
| matrix mode (where <n> is 4 + the number of supported texture and program |
| matrices), a stack of at least two 4x4 matrices for each of COLOR, |
| PROJECTION, and TEXTURE with associated stack pointers, <n> stacks (where |
| <n> is at least 8) of at least one 4x4 matrix for each MATRIX<i>_ARB with |
| associated stack pointers, and a stack of at least 32 4x4 matrices with an |
| associated stack pointer for MODELVIEW. Initially, there is only one |
| matrix on each stack, and all matrices are set to the identity. The |
| initial matrix mode is MODELVIEW. The initial value of ACTIVE_TEXTURE is |
| TEXTURE0. |
| |
| |
| Modify Section 2.11, Clipping (p. 39) |
| |
| (add to end of next-to-last paragraph, p. 40) ... User clipping is not |
| supported in vertex program mode if the current program is not |
| position-invariant (section 2.14.4.5.1). In this case, client-defined |
| clip planes are always treated as disabled. |
| |
| |
| Modify Section 2.12, Current Raster Position (p. 42) |
| |
| (modify fourth paragraph, p.42) The coordinates are treated as if they |
| were specified in a Vertex command. If vertex program mode is enabled, |
| the currently bound vertex program is executed, using the x, y, z, and w |
| coordinates as the object coordinates of the vertex. Otherwise, the x, y, |
| z, and w coordinates are transformed by the current model-view and |
| projection matrices. These coordinates, along with current values, are |
| used to generate a color and texture coordinates just as is done for a |
| vertex. The color and texture coordinates produced using either method |
| replace the color and texture coordinates stored in the current raster |
| position's associated data. When in vertex program mode, the "x" |
| component of the fog coordinate result replaces the current raster |
| distance; otherwise, the distance from the origin of the eye coordinate |
| system to the vertex as transformed by only the current model-view matrix |
| replaces the current raster distance. The latter distance can be |
| approximated (see section 3.10). |
| |
| Rename and Modify Section 2.13.8, Color and Vertex Data Clipping (p.56) |
| |
| (modify second paragraph, p.57) Texture coordinates, as well as fog |
| coordinates and point sizes computed on a per-vertex basis, must also be |
| clipped when a primitive is clipped. The method is exactly analogous to |
| that used for color clipping. |
| |
| |
| Add New Section 2.14 and subsections (p. 57). |
| |
| Section 2.14, Vertex Programs |
| |
| The conventional GL vertex transformation model described in sections 2.10 |
| through 2.13 is a configurable but essentially hard-wired sequence of |
| per-vertex computations based on a canonical set of per-vertex parameters |
| and vertex transformation related state such as transformation matrices, |
| lighting parameters, and texture coordinate generation parameters. The |
| general success and utility of the conventional GL vertex transformation |
| model reflects its basic correspondence to the typical vertex |
| transformation requirements of 3D applications. |
| |
| However when the conventional GL vertex transformation model is not |
| sufficient, the vertex program mode provides a substantially more flexible |
| model for vertex transformation. The vertex program mode permits |
| applications to define their own vertex programs. |
| |
| A vertex program is a character string that specifies a sequence of |
| operations to perform. Vertex program instructions are typically |
| 4-component vector operations that operate on per-vertex attributes and |
| program parameters. Vertex programs execute on a per-vertex basis and |
| operate on each vertex completely independently from any other vertices. |
| Vertex programs execute a finite fixed sequence of instructions with no |
| branching or looping. Vertex programs execute without data hazards so |
| results computed in one instruction can be used immediately afterwards. |
| The result of a vertex program is a set of vertex result registers that |
| becomes the set of transformed vertex attributes used during clipping and |
| primitive assembly. |
| |
| Vertex programs are defined to operate only in RGBA mode. The results of |
| vertex program execution are undefined if the GL is in color index mode. |
| |
| |
| Section 2.14.1, Program Objects |
| |
| The GL provides one or more program targets, each identifying a portion of |
| the GL that can be controlled through application-specified programs. The |
| program target for vertex programs is VERTEX_PROGRAM_ARB. Each program |
| target has an associated program object, called the current program |
| object. Each program target also has a default program object, which is |
| initially the current program object. |
| |
| Each program object has an associated program string. The command |
| |
| ProgramStringARB(enum target, enum format, sizei len, |
| const void *string); |
| |
| updates the program string for the current program object for <target>. |
| <format> describes the format of the program string, which must currently |
| be PROGRAM_FORMAT_ASCII_ARB. <string> is a pointer to the array of bytes |
| representing the program string being loaded, which need not be |
| null-terminated. The length of the array is given by <len>. If <string> |
| is null-terminated, <len> should not include the terminator. |
| |
| When a program string is loaded, it is interpreted according to syntactic |
| and semantic rules corresponding to the program target specified by |
| <target>. If a program violates the syntactic or semantic restrictions of |
| the program target, ProgramStringARB generates the error |
| INVALID_OPERATION. |
| |
| Additionally, ProgramString will update the program error position |
| (PROGRAM_ERROR_POSITION_ARB) and error string (PROGRAM_ERROR_STRING_ARB). |
| If a program fails to load, the value of the program error position is set |
| to the ubyte offset into the specified program string indicating where the |
| first program error was detected. If the program fails to load because of |
| a semantic restriction that is not detected until the program is fully |
| scanned, the error position is set to the value of <len>. If a program |
| loads successfully, the error position is set to the value negative one. |
| The implementation-dependent program error string contains one or more |
| error or warning messages. If a program loads succesfully, the error |
| string may either contain warning messages or be empty. |
| |
| Each program object has an associated array of program local parameters. |
| The number and type of program local parameters is target- and |
| implementation-dependent. For vertex programs, program local parameters |
| are four-component floating-point vectors. The number of vectors is given |
| by the implementation-dependent constant MAX_PROGRAM_LOCAL_PARAMETERS_ARB, |
| which must be at least 96. The commands |
| |
| void ProgramLocalParameter4fARB(enum target, uint index, |
| float x, float y, float z, float w); |
| void ProgramLocalParameter4fvARB(enum target, uint index, |
| const float *params); |
| void ProgramLocalParameter4dARB(enum target, uint index, |
| double x, double y, double z, double w); |
| void ProgramLocalParameter4dvARB(enum target, uint index, |
| const double *params); |
| |
| update the values of the program local parameter numbered <index> |
| belonging to the program object currently bound to <target>. For |
| ProgramLocalParameter4fARB and ProgramLocalParameter4dARB, the four |
| components of the parameter are updated with the values of <x>, <y>, <z>, |
| and <w>, respectively. For ProgramLocalParameter4fvARB and |
| ProgramLocalParameter4dvARB, the four components of the parameter are |
| updated with the array of four values pointed to by <params>. The error |
| INVALID_VALUE is generated if <index> is greater than or equal to the |
| number of program local parameters supported by <target>. |
| |
| Additionally, each program target has an associated array of program |
| environment parameters. Unlike program local parameters, program |
| environment parameters are shared by all program objects of a given |
| target. The number and type of program environment parameters is target- |
| and implementation-dependent. For vertex programs, program environment |
| parameters are four-component floating-point vectors. The number of |
| vectors is given by the implementation-dependent constant |
| MAX_PROGRAM_ENV_PARAMETERS_ARB, which must be at least 96. The commands |
| |
| void ProgramEnvParameter4fARB(enum target, uint index, |
| float x, float y, float z, float w); |
| void ProgramEnvParameter4fvARB(enum target, uint index, |
| const float *params); |
| void ProgramEnvParameter4dARB(enum target, uint index, |
| double x, double y, double z, double w); |
| void ProgramEnvParameter4dvARB(enum target, uint index, |
| const double *params); |
| |
| update the values of the program environment parameter numbered <index> |
| for the given program target <target>. For ProgramEnvParameter4fARB and |
| ProgramEnvParameter4dARB, the four components of the parameter are updated |
| with the values of <x>, <y>, <z>, and <w>, respectively. For |
| ProgramEnvParameter4fvARB and ProgramEnvParameter4dvARB, the four |
| components of the parameter are updated with the array of four values |
| pointed to by <params>. The error INVALID_VALUE is generated if <index> |
| is greater than or equal to the number of program environment parameters |
| supported by <target>. |
| |
| Each program target has a default program object. Additionally, named |
| program objects can be created and operated upon. The name space for |
| program objects is the positive integers and is shared by programs of all |
| targets. The name zero is reserved by the GL. |
| |
| A named program object is created by binding an unused program object name |
| to a valid program target. The binding is effected by calling |
| |
| BindProgramARB(enum target, uint program); |
| |
| with <target> set to the desired program target and <program> set to the |
| unused program name. The resulting program object has a program target |
| given by <target> and is assigned target-specific default values (see |
| section 2.14.7 for vertex programs). BindProgramARB may also be used to |
| bind an existing program object to a program target. If <program> is |
| zero, the default program object for <target> is bound. If <program> is |
| the name of an existing program object whose associated program target is |
| <target>, the named program object is bound. The error INVALID_OPERATION |
| is generated if <program> names an existing program object whose |
| associated program target is anything other than <target>. |
| |
| Programs objects are deleted by calling |
| |
| void DeleteProgramsARB(sizei n, const uint *programs); |
| |
| <programs> contains <n> names of programs to be deleted. After a program |
| object is deleted, its name is again unused. If a program object that is |
| bound to any target is deleted, it is as though BindProgramARB is first |
| executed with same target and a <program> of zero. Unused names in |
| <programs> are silently ignored, as is the value zero. |
| |
| The command |
| |
| void GenProgramsARB(sizei n, uint *programs); |
| |
| returns <n> currently unused program names in <programs>. These names are |
| marked as used, for the purposes of GenProgramsARB only, but objects are |
| created only when they are first bound using BindProgramARB. |
| |
| |
| Section 2.14.2, Vertex Program Grammar and Semantic Restrictions |
| |
| Vertex program strings are specified as an array of ASCII characters |
| containing the program text. When a vertex program is loaded by a call to |
| ProgramStringARB, the program string is parsed into a set of tokens |
| possibly separated by whitespace. Spaces, tabs, newlines, carriage |
| returns, and comments are considered whitespace. Comments begin with the |
| character "#" and are terminated by a newline, a carriage return, or the |
| end of the program array. |
| |
| The Backus-Naur Form (BNF) grammar below specifies the syntactically valid |
| sequences for vertex programs. The set of valid tokens can be inferred |
| from the grammar. The token "" represents an empty string and is used to |
| indicate optional rules. A program is invalid if it contains any |
| undefined tokens or characters. |
| |
| A vertex program is required to begin with the header string "!!ARBvp1.0", |
| without any preceding whitespace. This string identifies the subsequent |
| program text as a vertex program (version 1.0) that should be parsed |
| according to the following grammar and semantic rules. Program string |
| parsing begins with the character immediately following the header string. |
| |
| <program> ::= <optionSequence> <statementSequence> "END" |
| |
| <optionSequence> ::= <optionSequence> <option> |
| | "" |
| |
| <option> ::= "OPTION" <identifier> ";" |
| |
| <statementSequence> ::= <statementSequence> <statement> |
| | "" |
| |
| <statement> ::= <instruction> ";" |
| | <namingStatement> ";" |
| |
| <instruction> ::= <ARL_instruction> |
| | <VECTORop_instruction> |
| | <SCALARop_instruction> |
| | <BINSCop_instruction> |
| | <BINop_instruction> |
| | <TRIop_instruction> |
| | <SWZ_instruction> |
| |
| <ARL_instruction> ::= "ARL" <maskedAddrReg> "," <scalarSrcReg> |
| |
| <VECTORop_instruction> ::= <VECTORop> <maskedDstReg> "," <swizzleSrcReg> |
| |
| <VECTORop> ::= "ABS" |
| | "FLR" |
| | "FRC" |
| | "LIT" |
| | "MOV" |
| |
| <SCALARop_instruction> ::= <SCALARop> <maskedDstReg> "," <scalarSrcReg> |
| |
| <SCALARop> ::= "EX2" |
| | "EXP" |
| | "LG2" |
| | "LOG" |
| | "RCP" |
| | "RSQ" |
| |
| <BINSCop_instruction> ::= <BINSCop> <maskedDstReg> "," <scalarSrcReg> "," |
| <scalarSrcReg> |
| |
| <BINSCop> ::= "POW" |
| |
| <BINop_instruction> ::= <BINop> <maskedDstReg> "," |
| <swizzleSrcReg> "," <swizzleSrcReg> |
| |
| <BINop> ::= "ADD" |
| | "DP3" |
| | "DP4" |
| | "DPH" |
| | "DST" |
| | "MAX" |
| | "MIN" |
| | "MUL" |
| | "SGE" |
| | "SLT" |
| | "SUB" |
| | "XPD" |
| |
| <TRIop_instruction> ::= <TRIop> <maskedDstReg> "," |
| <swizzleSrcReg> "," <swizzleSrcReg> "," |
| <swizzleSrcReg> |
| |
| <TRIop> ::= "MAD" |
| |
| <SWZ_instruction> ::= "SWZ" <maskedDstReg> "," <srcReg> "," |
| <extendedSwizzle> |
| |
| <scalarSrcReg> ::= <optionalSign> <srcReg> <scalarSuffix> |
| |
| <swizzleSrcReg> ::= <optionalSign> <srcReg> <swizzleSuffix> |
| |
| <maskedDstReg> ::= <dstReg> <optionalMask> |
| |
| <maskedAddrReg> ::= <addrReg> <addrWriteMask> |
| |
| <extendedSwizzle> ::= <extSwizComp> "," <extSwizComp> "," |
| <extSwizComp> "," <extSwizComp> |
| |
| <extSwizComp> ::= <optionalSign> <extSwizSel> |
| |
| <extSwizSel> ::= "0" |
| | "1" |
| | <component> |
| |
| <srcReg> ::= <vertexAttribReg> |
| | <temporaryReg> |
| | <progParamReg> |
| |
| <dstReg> ::= <temporaryReg> |
| | <vertexResultReg> |
| |
| <vertexAttribReg> ::= <establishedName> |
| | <vtxAttribBinding> |
| |
| <temporaryReg> ::= <establishedName> |
| |
| <progParamReg> ::= <progParamSingle> |
| | <progParamArray> "[" <progParamArrayMem> "]" |
| | <paramSingleItemUse> |
| |
| <progParamSingle> ::= <establishedName> |
| |
| <progParamArray> ::= <establishedName> |
| |
| <progParamArrayMem> ::= <progParamArrayAbs> |
| | <progParamArrayRel> |
| |
| <progParamArrayAbs> ::= <integer> |
| |
| <progParamArrayRel> ::= <addrReg> <addrComponent> <addrRegRelOffset> |
| |
| <addrRegRelOffset> ::= "" |
| | "+" <addrRegPosOffset> |
| | "-" <addrRegNegOffset> |
| |
| <addrRegPosOffset> ::= <integer> from 0 to 63 |
| |
| <addrRegNegOffset> ::= <integer> from 0 to 64 |
| |
| <vertexResultReg> ::= <establishedName> |
| | <resultBinding> |
| |
| <addrReg> ::= <establishedName> |
| |
| <addrComponent> ::= "." "x" |
| |
| <addrWriteMask> ::= "." "x" |
| |
| <scalarSuffix> ::= "." <component> |
| |
| <swizzleSuffix> ::= "" |
| | "." <component> |
| | "." <component> <component> |
| <component> <component> |
| |
| <component> ::= "x" |
| | "y" |
| | "z" |
| | "w" |
| |
| <optionalMask> ::= "" |
| | "." "x" |
| | "." "y" |
| | "." "xy" |
| | "." "z" |
| | "." "xz" |
| | "." "yz" |
| | "." "xyz" |
| | "." "w" |
| | "." "xw" |
| | "." "yw" |
| | "." "xyw" |
| | "." "zw" |
| | "." "xzw" |
| | "." "yzw" |
| | "." "xyzw" |
| |
| <namingStatement> ::= <ATTRIB_statement> |
| | <PARAM_statement> |
| | <TEMP_statement> |
| | <ADDRESS_statement> |
| | <OUTPUT_statement> |
| | <ALIAS_statement> |
| |
| <ATTRIB_statement> ::= "ATTRIB" <establishName> "=" |
| <vtxAttribBinding> |
| |
| <vtxAttribBinding> ::= "vertex" "." <vtxAttribItem> |
| |
| <vtxAttribItem> ::= "position" |
| | "weight" <vtxOptWeightNum> |
| | "normal" |
| | "color" <optColorType> |
| | "fogcoord" |
| | "texcoord" <optTexCoordNum> |
| | "matrixindex" "[" <vtxWeightNum> "]" |
| | "attrib" "[" <vtxAttribNum> "]" |
| |
| <vtxAttribNum> ::= <integer> from 0 to MAX_VERTEX_ATTRIBS_ARB-1 |
| |
| <vtxOptWeightNum> ::= "" |
| | "[" <vtxWeightNum> "]" |
| |
| <vtxWeightNum> ::= <integer> from 0 to MAX_VERTEX_UNITS_ARB-1, |
| must be divisible by four |
| |
| <PARAM_statement> ::= <PARAM_singleStmt> |
| | <PARAM_multipleStmt> |
| |
| <PARAM_singleStmt> ::= "PARAM" <establishName> <paramSingleInit> |
| |
| <PARAM_multipleStmt> ::= "PARAM" <establishName> "[" <optArraySize> "]" |
| <paramMultipleInit> |
| |
| <optArraySize> ::= "" |
| | <integer> from 1 to MAX_PROGRAM_PARAMETERS_ARB |
| (maximum number of allowed program |
| parameter bindings) |
| |
| <paramSingleInit> ::= "=" <paramSingleItemDecl> |
| |
| <paramMultipleInit> ::= "=" "{" <paramMultInitList> "}" |
| |
| <paramMultInitList> ::= <paramMultipleItem> |
| | <paramMultipleItem> "," <paramMultiInitList> |
| |
| <paramSingleItemDecl> ::= <stateSingleItem> |
| | <programSingleItem> |
| | <paramConstDecl> |
| |
| <paramSingleItemUse> ::= <stateSingleItem> |
| | <programSingleItem> |
| | <paramConstUse> |
| |
| <paramMultipleItem> ::= <stateMultipleItem> |
| | <programMultipleItem> |
| | <paramConstDecl> |
| |
| <stateMultipleItem> ::= <stateSingleItem> |
| | "state" "." <stateMatrixRows> |
| |
| <stateSingleItem> ::= "state" "." <stateMaterialItem> |
| | "state" "." <stateLightItem> |
| | "state" "." <stateLightModelItem> |
| | "state" "." <stateLightProdItem> |
| | "state" "." <stateTexGenItem> |
| | "state" "." <stateFogItem> |
| | "state" "." <stateClipPlaneItem> |
| | "state" "." <statePointItem> |
| | "state" "." <stateMatrixRow> |
| |
| <stateMaterialItem> ::= "material" <optFaceType> "." <stateMatProperty> |
| |
| <stateMatProperty> ::= "ambient" |
| | "diffuse" |
| | "specular" |
| | "emission" |
| | "shininess" |
| |
| <stateLightItem> ::= "light" "[" <stateLightNumber> "]" "." |
| <stateLightProperty> |
| |
| <stateLightProperty> ::= "ambient" |
| | "diffuse" |
| | "specular" |
| | "position" |
| | "attenuation" |
| | "spot" "." <stateSpotProperty> |
| | "half" |
| |
| <stateSpotProperty> ::= "direction" |
| |
| <stateLightModelItem> ::= "lightmodel" <stateLModProperty> |
| |
| <stateLModProperty> ::= "." "ambient" |
| | <optFaceType> "." "scenecolor" |
| |
| <stateLightProdItem> ::= "lightprod" "[" <stateLightNumber> "]" |
| <optFaceType> "." <stateLProdProperty> |
| |
| <stateLProdProperty> ::= "ambient" |
| | "diffuse" |
| | "specular" |
| |
| <stateLightNumber> ::= <integer> from 0 to MAX_LIGHTS-1 |
| |
| <stateTexGenItem> ::= "texgen" <optTexCoordNum> "." |
| <stateTexGenType> "." <stateTexGenCoord> |
| |
| <stateTexGenType> ::= "eye" |
| | "object" |
| |
| <stateTexGenCoord> ::= "s" |
| | "t" |
| | "r" |
| | "q" |
| |
| <stateFogItem> ::= "fog" "." <stateFogProperty> |
| |
| <stateFogProperty> ::= "color" |
| | "params" |
| |
| <stateClipPlaneItem> ::= "clip" "[" <stateClipPlaneNum> "]" "." "plane" |
| |
| <stateClipPlaneNum> ::= <integer> from 0 to MAX_CLIP_PLANES-1 |
| |
| <statePointItem> ::= "point" "." <statePointProperty> |
| |
| <statePointProperty> ::= "size" |
| | "attenuation" |
| |
| <stateMatrixRow> ::= <stateMatrixItem> "." "row" "[" |
| <stateMatrixRowNum> "]" |
| |
| <stateMatrixRows> ::= <stateMatrixItem> <optMatrixRows> |
| |
| <optMatrixRows> ::= "" |
| | "." "row" "[" <stateMatrixRowNum> ".." |
| <stateMatrixRowNum> "]" |
| |
| <stateMatrixItem> ::= "matrix" "." <stateMatrixName> |
| <stateOptMatModifier> |
| |
| <stateOptMatModifier> ::= "" |
| | "." <stateMatModifier> |
| |
| <stateMatModifier> ::= "inverse" |
| | "transpose" |
| | "invtrans" |
| |
| <stateMatrixRowNum> ::= <integer> from 0 to 3 |
| |
| <stateMatrixName> ::= "modelview" <stateOptModMatNum> |
| | "projection" |
| | "mvp" |
| | "texture" <optTexCoordNum> |
| | "palette" "[" <statePaletteMatNum> "]" |
| | "program" "[" <stateProgramMatNum> "]" |
| |
| <stateOptModMatNum> ::= "" |
| | "[" <stateModMatNum> "]" |
| |
| <stateModMatNum> ::= <integer> from 0 to MAX_VERTEX_UNITS_ARB-1 |
| |
| <statePaletteMatNum> ::= <integer> from 0 to MAX_PALETTE_MATRICES_ARB-1 |
| |
| <stateProgramMatNum> ::= <integer> from 0 to MAX_PROGRAM_MATRICES_ARB-1 |
| |
| <programSingleItem> ::= <progEnvParam> |
| | <progLocalParam> |
| |
| <programMultipleItem> ::= <progEnvParams> |
| | <progLocalParams> |
| |
| <progEnvParams> ::= "program" "." "env" |
| "[" <progEnvParamNums> "]" |
| |
| <progEnvParamNums> ::= <progEnvParamNum> |
| | <progEnvParamNum> ".." <progEnvParamNum> |
| |
| <progEnvParam> ::= "program" "." "env" |
| "[" <progEnvParamNum> "]" |
| |
| <progLocalParams> ::= "program" "." "local" |
| "[" <progLocalParamNums> "]" |
| |
| <progLocalParamNums> ::= <progLocalParamNum> |
| | <progLocalParamNum> ".." <progLocalParamNum> |
| |
| <progLocalParam> ::= "program" "." "local" |
| "[" <progLocalParamNum> "]" |
| |
| <progEnvParamNum> ::= <integer> from 0 to |
| MAX_PROGRAM_ENV_PARAMETERS_ARB - 1 |
| |
| <progLocalParamNum> ::= <integer> from 0 to |
| MAX_PROGRAM_LOCAL_PARAMETERS_ARB - 1 |
| |
| <paramConstDecl> ::= <paramConstScalarDecl> |
| | <paramConstVector> |
| |
| <paramConstUse> ::= <paramConstScalarUse> |
| | <paramConstVector> |
| |
| <paramConstScalarDecl> ::= <signedFloatConstant> |
| |
| <paramConstScalarUse> ::= <floatConstant> |
| |
| <paramConstVector> ::= "{" <signedFloatConstant> "}" |
| | "{" <signedFloatConstant> "," |
| <signedFloatConstant> "}" |
| | "{" <signedFloatConstant> "," |
| <signedFloatConstant> "," |
| <signedFloatConstant> "}" |
| | "{" <signedFloatConstant> "," |
| <signedFloatConstant> "," |
| <signedFloatConstant> "," |
| <signedFloatConstant> "}" |
| |
| <signedFloatConstant> ::= <optionalSign> <floatConstant> |
| |
| <floatConstant> ::= see text |
| |
| <optionalSign> ::= "" |
| | "-" |
| | "+" |
| |
| <TEMP_statement> ::= "TEMP" <varNameList> |
| |
| <ADDRESS_statement> ::= "ADDRESS" <varNameList> |
| |
| <varNameList> ::= <establishName> |
| | <establishName> "," <varNameList> |
| |
| <OUTPUT_statement> ::= "OUTPUT" <establishName> "=" |
| <resultBinding> |
| |
| <resultBinding> ::= "result" "." "position" |
| | "result" "." <resultColBinding> |
| | "result" "." "fogcoord" |
| | "result" "." "pointsize" |
| | "result" "." "texcoord" <optTexCoordNum> |
| |
| <resultColBinding> ::= "color" <optFaceType> <optColorType> |
| |
| <optFaceType> ::= "" |
| | "." "front" |
| | "." "back" |
| |
| <optColorType> ::= "" |
| | "." "primary" |
| | "." "secondary" |
| |
| <optTexCoordNum> ::= "" |
| | "[" <texCoordNum> "]" |
| |
| <texCoordNum> ::= <integer> from 0 to MAX_TEXTURE_UNITS-1 |
| |
| <ALIAS_statement> ::= "ALIAS" <establishName> "=" |
| <establishedName> |
| |
| <establishName> ::= <identifier> |
| |
| <establishedName> ::= <identifier> |
| |
| <identifier> ::= see text |
| |
| The <integer> rule matches an integer constant. The integer consists |
| of a sequence of one or more digits ("0" through "9"). |
| |
| The <floatConstant> rule matches a floating-point constant consisting |
| of an integer part, a decimal point, a fraction part, an "e" or |
| "E", and an optionally signed integer exponent. The integer and |
| fraction parts both consist of a sequence of one or more digits ("0" |
| through "9"). Either the integer part or the fraction parts (not |
| both) may be missing; either the decimal point or the "e" (or "E") |
| and the exponent (not both) may be missing. |
| |
| The <identifier> rule matches a sequence of one or more letters ("A" |
| through "Z", "a" through "z"), digits ("0" through "9), underscores ("_"), |
| or dollar signs ("$"); the first character must not be a number. Upper |
| and lower case letters are considered different (names are |
| case-sensitive). The following strings are reserved keywords and may not |
| be used as identifiers: |
| |
| ABS, ADD, ADDRESS, ALIAS, ARL, ATTRIB, DP3, DP4, DPH, DST, END, EX2, |
| EXP, FLR, FRC, LG2, LIT, LOG, MAD, MAX, MIN, MOV, MUL, OPTION, OUTPUT, |
| PARAM, POW, RCP, RSQ, SGE, SLT, SUB, SWZ, TEMP, XPD, program, result, |
| state, and vertex. |
| |
| The error INVALID_OPERATION is generated if a vertex program fails to load |
| because it is not syntactically correct or for one of the semantic |
| restrictions described in the following sections. |
| |
| A successfully loaded vertex program is parsed into a sequence of |
| instructions. Each instruction is identified by its tokenized name. The |
| operation of these instructions when executed is defined in section |
| 2.14.5. A successfully loaded program string replaces the program string |
| previously loaded into the specified program object. If the OUT_OF_MEMORY |
| error is generated by ProgramStringARB, no change is made to the previous |
| contents of the current program object. |
| |
| |
| Section 2.14.3, Vertex Program Variables |
| |
| Vertex programs may access a number of different variables during their |
| execution. The following sections define the variables that can be |
| declared and used by a vertex program. |
| |
| Explicit variable declarations allow a vertex program to establish a |
| variable name that can be used to refer to a specified resource in |
| subsequent instructions. A vertex program will fail to load if it |
| declares the same variable name more than once or if it refers to a |
| variable name that has not been previously declared in the program string. |
| |
| Implicit variable declarations allow a vertex program to use the name of |
| certain available resources by name. |
| |
| Section 2.14.3.1, Vertex Attributes |
| |
| Vertex program attribute variables are a set of four-component |
| floating-point vectors holding the attributes of the vertex being |
| processed. Vertex attribute variables are read-only during vertex program |
| execution. |
| |
| Vertex attribute variables can be declared explicitly using the |
| <ATTRIB_statement> grammar rule, or implicitly using the |
| <vtxAttribBinding> grammar rule in an executable instruction. |
| |
| Each vertex attribute variable is bound to a single item of vertex state |
| according to the <vtxAttrBinding> grammar rule. The set of GL state that |
| can be bound to a vertex attribute variable is given in Table X.2. Vertex |
| attribute variables are initialized at each vertex program invocation with |
| the current values of the bound state. |
| |
| Vertex Attribute Binding Components Underlying State |
| ------------------------ ---------- ------------------------------ |
| vertex.position (x,y,z,w) object coordinates |
| vertex.weight (w,w,w,w) vertex weights 0-3 |
| vertex.weight[n] (w,w,w,w) vertex weights n-n+3 |
| vertex.normal (x,y,z,1) normal |
| vertex.color (r,g,b,a) primary color |
| vertex.color.primary (r,g,b,a) primary color |
| vertex.color.secondary (r,g,b,a) secondary color |
| vertex.fogcoord (f,0,0,1) fog coordinate |
| vertex.texcoord (s,t,r,q) texture coordinate, unit 0 |
| vertex.texcoord[n] (s,t,r,q) texture coordinate, unit n |
| vertex.matrixindex (i,i,i,i) vertex matrix indices 0-3 |
| vertex.matrixindex[n] (i,i,i,i) vertex matrix indices n-n+3 |
| vertex.attrib[n] (x,y,z,w) generic vertex attribute n |
| |
| Table X.2: Vertex Attribute Bindings. The "Components" column |
| indicates the mapping of the state in the "Underlying State" column. |
| Values of "0" or "1" in the "Components" column indicate the constants |
| 0.0 and 1.0, respectively. Bindings containing "[n]" require an integer |
| value of <n> to select an individual item. |
| |
| If a vertex attribute binding matches "vertex.position", the "x", "y", "z" |
| and "w" components of the vertex attribute variable are filled with the |
| "x", "y", "z", and "w" components, respectively, of the vertex position. |
| |
| If a vertex attribute binding matches "vertex.normal", the "x", "y", and |
| "z" components of the vertex attribute variable are filled with the "x", |
| "y", and "z" components, respectively, of the vertex normal. The "w" |
| component is filled with 1. |
| |
| If a vertex attribute binding matches "vertex.color" or |
| "vertex.color.primary", the "x", "y", "z", and "w" components of the |
| vertex attribute variable are filled with the "r", "g", "b", and "a" |
| components, respectively, of the vertex color. |
| |
| If a vertex attribute binding matches "vertex.color.secondary", the "x", |
| "y", "z", and "w" components of the vertex attribute variable are filled |
| with the "r", "g", "b", and "a" components, respectively, of the vertex |
| secondary color. |
| |
| If a vertex attribute binding matches "vertex.fogcoord", the "x" component |
| of the vertex attribute variable is filled with the vertex fog coordinate. |
| The "y", "z", and "w" coordinates are filled with 0, 0, and 1, |
| respectively. |
| |
| If a vertex attribute binding matches "vertex.texcoord" or |
| "vertex.texcoord[n]", the "x", "y", "z", and "w" components of the vertex |
| attribute variable are filled with the "s", "t", "r", and "q" components, |
| respectively, of the vertex texture coordinates for texture unit <n>. If |
| "[n]" is omitted, texture unit zero is used. |
| |
| If a vertex attribute binding matches "vertex.weight" or |
| "vertex.weight[n]", the "x", "y", "z", and "w" components of the vertex |
| attribute variable are filled with vertex weights <n> through <n>+3, |
| respectively. If "[n]" is omitted, weights zero through three are used. |
| For the purposes of this binding, all weights supported by the |
| implementation but not set by the application are set to zero, including |
| the extra derived weight corresponding to the fixed-function |
| WEIGHT_SUM_UNITY_ARB enable. For components whose corresponding weight is |
| not supported by the implementation (i.e., numbered MAX_VERTEX_UNITS_ARB |
| or larger), "y" and "z" components are set to 0.0 and "w" components are |
| set to 1.0. A vertex program will fail to load if a vertex attribute |
| binding specifies a weight number <n> that is greater than or equal to |
| MAX_VERTEX_UNITS_ARB or is not divisible by four. |
| |
| If a vertex attribute binding matches "vertex.matrixindex" or |
| "vertex.matrixindex[n]", the "x", "y", "z", and "w" components of the |
| vertex attribute variable are filled with matrix indices <n> through <n>+3 |
| of the vertex, respectively. If "[n]" is omitted, matrix indices zero |
| through three are used. For components whose corresponding matrix index |
| is not supported by the implementation (i.e., numbered |
| MAX_VERTEX_UNITS_ARB or larger), "y", and "z" components are set to 0.0 |
| and "w" components are set to 1.0. A vertex program will fail to load if |
| an attribute binding specifies a matrix index number <n> that is greater |
| than or equal MAX_VERTEX_UNITS_ARB or is not divisible by four. |
| |
| If a vertex attribute binding matches "vertex.attrib[n]", the "x", "y", |
| "z" and "w" components of the vertex attribute variable are filled with |
| the "x", "y", "z", and "w" components, respectively, of generic vertex |
| attribute <n>. Note that "vertex.attrib[0]" and "vertex.position" are |
| equivalent. |
| |
| As described in section 2.7, setting a generic vertex attribute may leave |
| a corresponding conventional vertex attribute undefined, and vice versa. |
| To prevent inadvertent use of attribute pairs with undefined attributes, a |
| vertex program will fail to load if it binds both a conventional vertex |
| attribute and a generic vertex attribute listed in the same row of Table |
| X.2.1. |
| |
| Conventional Attribute Binding Generic Attribute Binding |
| ------------------------------ ------------------------- |
| vertex.position vertex.attrib[0] |
| vertex.weight vertex.attrib[1] |
| vertex.weight[0] vertex.attrib[1] |
| vertex.normal vertex.attrib[2] |
| vertex.color vertex.attrib[3] |
| vertex.color.primary vertex.attrib[3] |
| vertex.color.secondary vertex.attrib[4] |
| vertex.fogcoord vertex.attrib[5] |
| vertex.texcoord vertex.attrib[8] |
| vertex.texcoord[0] vertex.attrib[8] |
| vertex.texcoord[1] vertex.attrib[9] |
| vertex.texcoord[2] vertex.attrib[10] |
| vertex.texcoord[3] vertex.attrib[11] |
| vertex.texcoord[4] vertex.attrib[12] |
| vertex.texcoord[5] vertex.attrib[13] |
| vertex.texcoord[6] vertex.attrib[14] |
| vertex.texcoord[7] vertex.attrib[15] |
| vertex.texcoord[n] vertex.attrib[8+n] |
| |
| Table X.2.1: Invalid Vertex Attribute Binding Pairs. Vertex programs |
| may not bind both attributes listed in any row. The <n> in the last row |
| matches the number of any valid texture unit. |
| |
| |
| Section 2.14.3.2, Vertex Program Parameters |
| |
| Vertex program parameter variables are a set of four-component |
| floating-point vectors used as constants during vertex program execution. |
| Vertex program parameters retain their values across vertex program |
| invocations, although their values can change between invocations due to |
| GL state changes. |
| |
| Single program parameter variables and arrays of program parameter |
| variables can be declared explicitly using the <PARAM_statement> grammar |
| rule. Single program parameter variables can also be declared implicitly |
| using the <paramSingleItemUse> grammar rule in an executable instruction. |
| |
| Each single program parameter variable is bound to a constant vector or to |
| a GL state vector according to the <paramSingleInit> grammar rule. |
| Individual items of a program parameter array are bound to constant |
| vectors or GL state vectors according to the <programMultipleInit> grammar |
| rule. The set of GL state that can be bound to program parameter |
| variables are given in Tables X.3.1 through X.3.8. |
| |
| |
| Constant Bindings |
| |
| A program parameter variable can be bound to a scalar or vector constant |
| using the <paramConstDecl> grammar rule (explicit declarations) or the |
| <paramConstUse> grammar rule (implicit declarations). |
| |
| If a program parameter binding matches the <paramConstScalarDecl> or |
| <paramConstScalarUse> grammar rules, the corresponding program parameter |
| variable is bound to the vector (X,X,X,X), where X is the value of the |
| specified constant. Note that the <paramConstScalarUse> grammar rule, |
| used only in implicit declarations, allows only non-negative constants. |
| This disambiguates cases like "-2", which could conceivably be taken to |
| mean either the vector "(2,2,2,2)" with all components negated or |
| "(-2,-2,-2,-2)" without negation. Only the former interpretation is |
| allowed by the grammar. |
| |
| If a program parameter binding matches <paramConstVector>, the |
| corresponding program parameter variable is bound to the vector (X,Y,Z,W), |
| where X, Y, Z, and W are the values corresponding to the first, second, |
| third, and fourth match of <signedFloatConstant>. If fewer than four |
| constants are specified, Y, Z, and W assume the values 0.0, 0.0, and 1.0, |
| if their respective constants are not specified. |
| |
| Program parameter variables initialized to constant values can never be |
| modified. |
| |
| |
| Program Environment/Local Parameter Bindings |
| |
| Binding Components Underlying State |
| ----------------------------- ---------- ---------------------------- |
| program.env[a] (x,y,z,w) program environment |
| parameter a |
| program.local[a] (x,y,z,w) program local parameter a |
| program.env[a..b] (x,y,z,w) program environment |
| parameters a through b |
| program.local[a..b] (x,y,z,w) program local parameters |
| a through b |
| |
| Table X.3.1: Program Environment/Local Parameter Bindings. <a> and <b> |
| indicate parameter numbers, where <a> must be less than or equal to <b>. |
| |
| If a program parameter binding matches "program.env[a]" or |
| "program.local[a]", the four components of the program parameter variable |
| are filled with the four components of program environment parameter <a> |
| or program local parameter <a>, respectively. |
| |
| Additionally, for program parameter array bindings, "program.env[a..b]" |
| and "program.local[a..b]" are equivalent to specifying program environment |
| parameters <a> through <b> in order or program local parameters <a> |
| through <b> in order, respectively. In either case, a program will fail |
| to load if <a> is greater than <b>. |
| |
| |
| Material Property Bindings |
| |
| Binding Components Underlying State |
| ----------------------------- ---------- ---------------------------- |
| state.material.ambient (r,g,b,a) front ambient material color |
| state.material.diffuse (r,g,b,a) front diffuse material color |
| state.material.specular (r,g,b,a) front specular material color |
| state.material.emission (r,g,b,a) front emissive material color |
| state.material.shininess (s,0,0,1) front material shininess |
| state.material.front.ambient (r,g,b,a) front ambient material color |
| state.material.front.diffuse (r,g,b,a) front diffuse material color |
| state.material.front.specular (r,g,b,a) front specular material color |
| state.material.front.emission (r,g,b,a) front emissive material color |
| state.material.front.shininess (s,0,0,1) front material shininess |
| state.material.back.ambient (r,g,b,a) back ambient material color |
| state.material.back.diffuse (r,g,b,a) back diffuse material color |
| state.material.back.specular (r,g,b,a) back specular material color |
| state.material.back.emission (r,g,b,a) back emissive material color |
| state.material.back.shininess (s,0,0,1) back material shininess |
| |
| Table X.3.2: Material Property Bindings. If a material face is not |
| specified in the binding, the front property is used. |
| |
| If a program parameter binding matches any of the material properties |
| listed in Table X.3.2, the program parameter variable is filled according |
| to the table. For ambient, diffuse, specular, or emissive colors, the |
| "x", "y", "z", and "w" components are filled with the "r", "g", "b", and |
| "a" components, respectively, of the corresponding material color. For |
| material shininess, the "x" component is filled with the material's |
| specular exponent, and the "y", "z", and "w" components are filled with 0, |
| 0, and 1, respectively. Bindings containing ".back" refer to the back |
| material; all other bindings refer to the front material. |
| |
| Material properties can be changed inside a Begin/End pair, either |
| directly by calling Material, or indirectly through color material. |
| However, such property changes are not guaranteed to update program |
| parameter bindings until the following End command. Program parameter |
| variables bound to material properties changed inside a Begin/End pair are |
| undefined until the following End command. |
| |
| |
| Light Property Bindings |
| |
| Binding Components Underlying State |
| ----------------------------- ---------- ---------------------------- |
| state.light[n].ambient (r,g,b,a) light n ambient color |
| state.light[n].diffuse (r,g,b,a) light n diffuse color |
| state.light[n].specular (r,g,b,a) light n specular color |
| state.light[n].position (x,y,z,w) light n position |
| state.light[n].attenuation (a,b,c,e) light n attenuation constants |
| and spot light exponent |
| state.light[n].spot.direction (x,y,z,c) light n spot direction and |
| cutoff angle cosine |
| state.light[n].half (x,y,z,1) light n infinite half-angle |
| state.lightmodel.ambient (r,g,b,a) light model ambient color |
| state.lightmodel.scenecolor (r,g,b,a) light model front scene color |
| state.lightmodel. (r,g,b,a) light model front scene color |
| front.scenecolor |
| state.lightmodel. (r,g,b,a) light model back scene color |
| back.scenecolor |
| state.lightprod[n].ambient (r,g,b,a) light n / front material |
| ambient color product |
| state.lightprod[n].diffuse (r,g,b,a) light n / front material |
| diffuse color product |
| state.lightprod[n].specular (r,g,b,a) light n / front material |
| specular color product |
| state.lightprod[n]. (r,g,b,a) light n / front material |
| front.ambient ambient color product |
| state.lightprod[n]. (r,g,b,a) light n / front material |
| front.diffuse diffuse color product |
| state.lightprod[n]. (r,g,b,a) light n / front material |
| front.specular specular color product |
| state.lightprod[n]. (r,g,b,a) light n / back material |
| back.ambient ambient color product |
| state.lightprod[n]. (r,g,b,a) light n / back material |
| back.diffuse diffuse color product |
| state.lightprod[n]. (r,g,b,a) light n / back material |
| back.specular specular color product |
| |
| Table X.3.3: Light Property Bindings. <n> indicates a light number. |
| |
| If a program parameter binding matches "state.light[n].ambient", |
| "state.light[n].diffuse", or "state.light[n].specular", the "x", "y", "z", |
| and "w" components of the program parameter variable are filled with the |
| "r", "g", "b", and "a" components, respectively, of the corresponding |
| light color. |
| |
| If a program parameter binding matches "state.light[n].position", the "x", |
| "y", "z", and "w" components of the program parameter variable are filled |
| with the "x", "y", "z", and "w" components, respectively, of the light |
| position. |
| |
| If a program parameter binding matches "state.light[n].attenuation", the |
| "x", "y", and "z" components of the program parameter variable are filled |
| with the constant, linear, and quadratic attenuation parameters of the |
| specified light, respectively (section 2.13.1). The "w" component of the |
| program parameter variable is filled with the spot light exponent of the |
| specified light. |
| |
| If a program parameter binding matches "state.light[n].spot.direction", |
| the "x", "y", and "z" components of the program parameter variable are |
| filled with the "x", "y", and "z" components of the spot light direction |
| of the specified light, respectively (section 2.13.1). The "w" component |
| of the program parameter variable is filled with the cosine of the spot |
| light cutoff angle of the specified light. |
| |
| If a program parameter binding matches "state.light[n].half", the "x", |
| "y", and "z" components of the program parameter variable are filled with |
| the x, y, and z components, respectively, of the normalized infinite |
| half-angle vector |
| |
| h_inf = || P + (0, 0, 1) ||. |
| |
| The "w" component is filled with 1. In the computation of h_inf, P |
| consists of the x, y, and z coordinates of the normalized vector from the |
| eye position P_e to the eye-space light position P_pli (section 2.13.1). |
| h_inf is defined to correspond to the normalized half-angle vector when |
| using an infinite light (w coordinate of the position is zero) and an |
| infinite viewer (v_bs is FALSE). For local lights or a local viewer, |
| h_inf is well-defined but does not match the normalized half-angle vector, |
| which will vary depending on the vertex position. |
| |
| If a program parameter binding matches "state.lightmodel.ambient", the |
| "x", "y", "z", and "w" components of the program parameter variable are |
| filled with the "r", "g", "b", and "a" components of the light model |
| ambient color, respectively. |
| |
| If a program parameter binding matches "state.lightmodel.scenecolor" or |
| "state.lightmodel.front.scenecolor", the "x", "y", and "z" components of |
| the program parameter variable are filled with the "r", "g", and "b" |
| components respectively of the "front scene color" |
| |
| c_scene = a_cs * a_cm + e_cm, |
| |
| where a_cs is the light model ambient color, a_cm is the front ambient |
| material color, and e_cm is the front emissive material color. The "w" |
| component of the program parameter variable is filled with the alpha |
| component of the front diffuse material color. If a program parameter |
| binding matches "state.lightmodel.back.scenecolor", a similar back scene |
| color, computed using back-facing material properties, is used. The front |
| and back scene colors match the values that would be assigned to vertices |
| using conventional lighting if all lights were disabled. |
| |
| If a program parameter binding matches anything beginning with |
| "state.lightprod[n]", the "x", "y", and "z" components of the program |
| parameter variable are filled with the "r", "g", and "b" components, |
| respectively, of the corresponding light product. The three light product |
| components are the products of the corresponding color components of the |
| specified material property and the light color of the specified light |
| (see Table X.3.3). The "w" component of the program parameter variable is |
| filled with the alpha component of the specified material property. |
| |
| Light products depend on material properties, which can be changed inside |
| a Begin/End pair. Such property changes are not guaranteed to take effect |
| until the following End command. Program parameter variables bound to |
| light products whose corresponding material property changes inside a |
| Begin/End pair are undefined until the following End command. |
| |
| |
| Texture Coordinate Generation Property Bindings |
| |
| Binding Components Underlying State |
| ------------------------- ---------- ---------------------------- |
| state.texgen[n].eye.s (a,b,c,d) TexGen eye linear plane |
| coefficients, s coord, unit n |
| state.texgen[n].eye.t (a,b,c,d) TexGen eye linear plane |
| coefficients, t coord, unit n |
| state.texgen[n].eye.r (a,b,c,d) TexGen eye linear plane |
| coefficients, r coord, unit n |
| state.texgen[n].eye.q (a,b,c,d) TexGen eye linear plane |
| coefficients, q coord, unit n |
| state.texgen[n].object.s (a,b,c,d) TexGen object linear plane |
| coefficients, s coord, unit n |
| state.texgen[n].object.t (a,b,c,d) TexGen object linear plane |
| coefficients, t coord, unit n |
| state.texgen[n].object.r (a,b,c,d) TexGen object linear plane |
| coefficients, r coord, unit n |
| state.texgen[n].object.q (a,b,c,d) TexGen object linear plane |
| coefficients, q coord, unit n |
| |
| Table X.3.4: Texture Coordinate Generation Property Bindings. "[n]" is |
| optional -- texture unit <n> is used if specified; texture unit 0 is |
| used otherwise. |
| |
| If a program parameter binding matches a set of TexGen plane coefficients, |
| the "x", "y", "z", and "w" components of the program parameter variable |
| are filled with the coefficients p1, p2, p3, and p4, respectively, for |
| object linear coefficients, and the coefficents p1', p2', p3', and p4', |
| respectively, for eye linear coefficients (section 2.10.4). |
| |
| |
| Fog Property Bindings |
| |
| Binding Components Underlying State |
| ----------------------------- ---------- ---------------------------- |
| state.fog.color (r,g,b,a) RGB fog color (section 3.10) |
| state.fog.params (d,s,e,r) fog density, linear start |
| and end, and 1/(end-start) |
| (section 3.10) |
| |
| Table X.3.5: Fog Property Bindings |
| |
| If a program parameter binding matches "state.fog.color", the "x", "y", |
| "z", and "w" components of the program parameter variable are filled with |
| the "r", "g", "b", and "a" components, respectively, of the fog color |
| (section 3.10). |
| |
| If a program parameter binding matches "state.fog.params", the "x", "y", |
| and "z" components of the program parameter variable are filled with the |
| fog density, linear fog start, and linear fog end parameters (section |
| 3.10), respectively. The "w" component is filled with 1/(end-start), |
| where end and start are the linear fog end and start parameters, |
| respectively. |
| |
| |
| Clip Plane Property Bindings |
| |
| Binding Components Underlying State |
| ----------------------------- ---------- ---------------------------- |
| state.clip[n].plane (a,b,c,d) clip plane n coefficients |
| |
| Table X.3.6: Clip Plane Property Bindings. <n> specifies the clip |
| plane number, and is required. |
| |
| If a program parameter binding matches "state.clip[n].plane", the "x", |
| "y", "z", and "w" components of the program parameter variable are filled |
| with the coefficients p1', p2', p3', and p4', respectively, of clip plane |
| <n> (section 2.11). |
| |
| |
| Point Property Bindings |
| |
| Binding Components Underlying State |
| ----------------------------- ---------- ---------------------------- |
| state.point.size (s,n,x,f) point size, min and max size |
| clamps, and fade threshold |
| (section 3.3) |
| state.point.attenuation (a,b,c,1) point size attenuation consts |
| |
| Table X.3.7: Point Property Bindings |
| |
| If a program parameter binding matches "state.point.size", the "x", "y", |
| "z", and "w" components of the program parameter variable are filled with |
| the point size, minimum point size, maximum point size, and fade |
| threshold, respectively (section 3.3). |
| |
| If a program parameter binding matches "state.point.attenuation", the "x", |
| "y", and "z" components of the program parameter variable are filled with |
| the constant, linear, and quadratic point size attenuation parameters (a, |
| b, and c), respectively (section 3.3). The "w" component is filled with |
| 1. |
| |
| |
| Matrix Property Bindings |
| |
| Binding Underlying State |
| ------------------------------------ --------------------------- |
| * state.matrix.modelview[n] modelview matrix n |
| state.matrix.projection projection matrix |
| state.matrix.mvp modelview-projection matrix |
| * state.matrix.texture[n] texture matrix n |
| state.matrix.palette[n] modelview palette matrix n |
| state.matrix.program[n] program matrix n |
| |
| Table X.3.8: Base Matrix Property Bindings. The "[n]" syntax indicates |
| a specific matrix number. For modelview and texture matrices, a matrix |
| number is optional, and matrix zero will be used if the matrix number is |
| omitted. These base bindings may further be modified by a |
| inverse/transpose selector and a row selector. |
| |
| If the beginning of a program parameter binding matches any of the matrix |
| binding names listed in Table X.3.8, the binding corresponds to a 4x4 |
| matrix. If the parameter binding is followed by ".inverse", ".transpose", |
| or ".invtrans" (<stateMatModifier> grammar rule), the inverse, transpose, |
| or transpose of the inverse, respectively, of the matrix specified in |
| Table X.3.8 is selected. Otherwise, the matrix specified in Table X.3.8 |
| is selected. If the specified matrix is poorly-conditioned (singular or |
| nearly so), its inverse matrix is undefined. The binding name |
| "state.matrix.mvp" refers to the product of modelview matrix zero and the |
| projection matrix, defined as |
| |
| MVP = P * M0, |
| |
| where P is the projection matrix and M0 is modelview matrix zero. |
| |
| If the selected matrix is followed by ".row[<a>]" (matching the |
| <stateMatrixRow> grammar rule), the "x", "y", "z", and "w" components of |
| the program parameter variable are filled with the four entries of row <a> |
| of the selected matrix. In the example, |
| |
| PARAM m0 = state.matrix.modelview[1].row[0]; |
| PARAM m1 = state.matrix.projection.transpose.row[3]; |
| |
| the variable "m0" is set to the first row (row 0) of modelview matrix 1 |
| and "m1" is set to the last row (row 3) of the transpose of the projection |
| matrix. |
| |
| For program parameter array bindings, multiple rows of the selected matrix |
| can be bound via the <stateMatrixRows> grammar rule. If the selected |
| matrix binding is followed by ".row[<a>..<b>]", the result is equivalent |
| to specifying matrix rows <a> through <b>, in order. A program will fail |
| to load if <a> is greater than <b>. If no row selection is specified |
| (<optMatrixRows> matches ""), matrix rows 0 through 3 are bound in order. |
| In the example, |
| |
| PARAM m2[] = { state.matrix.program[0].row[1..2] }; |
| PARAM m3[] = { state.matrix.program[0].transpose }; |
| |
| the array "m2" has two entries, containing rows 1 and 2 of program matrix |
| zero, and "m3" has four entries, containing all four rows of the transpose |
| of program matrix zero. |
| |
| |
| Program Parameter Arrays |
| |
| A program parameter array variable can be declared explicitly by matching |
| the <PARAM_multipleStmt> grammar rule. Programs can optionally specify |
| the number of individual program parameters in the array, using the |
| <optArraySize> grammar rule. Program parameter arrays may not be declared |
| implicity. |
| |
| Individual parameter variables in a program parameter array are bound to |
| GL state vectors or constant vectors as specified by the grammar rule |
| <paramMultInitList>. Each individual parameter in the array is bound in |
| turn as described above. |
| |
| The total number of entries in the array is equal to the number of |
| parameters bound in the initializer list. A vertex program that specifies |
| an array size (<optArraySize> matches <integer>) that does not match the |
| number of parameter bindings in the initialization list will fail to load. |
| |
| Program parameter array variables may be accessed using absolute |
| addressing by matching the <progParamArrayAbs> grammar rule, or relative |
| addressing by matching the <progParamArrayRel> grammar rule. |
| |
| Array accesses using absolute addressing are checked against the limits of |
| the array. If any vertex program instruction accesses a program parameter |
| array using absolute addressing with an out-of-range index (greater than |
| or equal to the size of the array), the vertex program will fail to load. |
| |
| Individual state vectors can have no more than one unique binding in any |
| given program. The GL will automatically combine multiple bindings of the |
| same state vector into a single unique binding, except for the case where |
| a state vector is bound multiple times in program parameter arrays |
| accessed using relative addressing. A vertex program will fail to load if |
| any GL state vector is bound multiple times in a single array accessed |
| using relative addressing or bound once in two or more arrays accessed |
| using relative addressing. |
| |
| |
| Section 2.14.3.3, Vertex Program Temporaries |
| |
| Vertex program temporary variables are a set of four-component |
| floating-point vectors used to hold temporary results during vertex |
| program execution. Temporaries do not persist between program |
| invocations, and are undefined at the beginning of each vertex program |
| invocation. |
| |
| Vertex program temporary variables can be declared explicitly using the |
| <TEMP_statement> grammar rule. Each such statement can declare one or |
| more temporaries. Vertex program temporary variables can not be declared |
| implicitly. |
| |
| |
| Section 2.14.3.4, Vertex Program Results |
| |
| Vertex program result variables are a set of four-component floating-point |
| vectors used to hold the final results of a vertex program. Vertex |
| program result variables are write-only during vertex program execution. |
| |
| Vertex program result variables can be declared explicitly using the |
| <OUTPUT_statement> grammar rule, or implicitly using the <resultBinding> |
| grammar rule in an executable instruction. Each vertex program result |
| variable is bound to a transformed vertex attribute used during primitive |
| assembly and rasterization. The set of vertex program result variable |
| bindings is given in Table X.4. |
| |
| 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 |
| |
| Table X.4: Vertex 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.4. 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. |
| |
| When in vertex program mode, all attributes of a transformed vertex are |
| undefined at each vertex program invocation. Any results, or even |
| individual components of results, that are not written to during vertex |
| program execution remain undefined. |
| |
| |
| Section 2.14.3.5, Vertex Program Address Registers |
| |
| Vertex program address register variables are a set of four-component |
| signed integer vectors where only the "x" component of the address |
| registers is currently accessible. Address registers are used as indices |
| when performing relative addressing in program parameter arrays (section |
| 2.14.4.2). |
| |
| Vertex program address registers can be declared explicitly using the |
| <ADDRESS_statement> grammar rule. Each such statement can declare one or |
| more address registers. Vertex program address registers can not be |
| declared implicitly. |
| |
| Vertex program address register variables are undefined at each vertex |
| program invocation. Address registers can be written by the ARL |
| instruction (section 2.14.5.3), and will be read when a program uses |
| relative addressing in program parameter arrays. |
| |
| |
| Section 2.14.3.6, Vertex Program Aliases |
| |
| Vertex programs can create aliases by matching the <ALIAS_statement> |
| grammar rule. Aliases allow programs to use multiple variable names to |
| refer to a single underlying variable. For example, the statement |
| |
| ALIAS var1 = var0 |
| |
| establishes a variable name named "var1". Subsequent references to "var1" |
| in the program text are treated as references to "var0". The left hand |
| side of an ALIAS statement must be a new variable name, and the right hand |
| side must be an established variable name. |
| |
| Aliases are not considered variable declarations, so do not count against |
| the limits on the number of variable declarations allowed in the program |
| text. |
| |
| |
| Section 2.14.3.7, Vertex Program Resource Limits |
| |
| The vertex program execution environment provides implementation-dependent |
| resource limits on the number of instructions, temporary variable |
| declarations, vertex attribute bindings, address register declarations, |
| and program parameter bindings. A program that exceeds any of these |
| resource limits will fail to load. The resource limits for vertex |
| programs can be queried by calling GetProgramiv (section 6.1.12) with a |
| target of VERTEX_PROGRAM_ARB. |
| |
| The limit on vertex program instructions can be queried with a <pname> of |
| MAX_PROGRAM_INSTRUCTIONS_ARB, and must be at least 128. Each instruction |
| in the program (matching the <instruction> grammar rule) counts against |
| this limit. |
| |
| The limit on vertex program temporary variable declarations can be queried |
| with a <pname> of MAX_PROGRAM_TEMPORARIES_ARB, and must be at least 12. |
| Each temporary declared in the program, using the <TEMP_statement> grammar |
| rule, counts against this limit. Aliases of declared temporaries do not. |
| |
| The limit on vertex program attribute bindings can be queried with a |
| <pname> of MAX_PROGRAM_ATTRIBS_ARB and must be at least 16. Each distinct |
| vertex attribute bound explicitly or implicitly in the program counts |
| against this limit; vertex attributes bound multiple times count only |
| once. |
| |
| The limit on vertex program address register declarations can be queried |
| with a <pname> of MAX_PROGRAM_ADDRESS_REGISTERS_ARB, and must be at least |
| 1. Each address register declared in the program, using the |
| <ADDRESS_statement> grammar rule, counts against this limit. |
| |
| The limit on vertex program parameter bindings can be queried with a |
| <pname> of MAX_PROGRAM_PARAMETERS_ARB, and must be at least 96. Each |
| distinct GL state vector bound explicitly or implicitly in the program |
| counts against this limit; GL state vectors bound multiple times count |
| only once. Each constant vector bound to an array accessed using relative |
| addressing counts against this limit, even if the same constant vector is |
| bound multiple times or in multiple arrays. Every other constant vector |
| bound in the program is counted if and only if an identical constant |
| vector has not already been counted. Two constant vectors are considered |
| identical if the four component values are numerically equivalent. Recall |
| that scalar constants bound in a program are treated as vector constants |
| with the scalar value replicated. In the following code |
| |
| PARAM arr1[4] = { {1,2,3,4}, {1,2,3,4}, {4,4,4,4}, {5,6,7,8} }; |
| PARAM arr2[3] = { {1,2,3,4}, {5,6,7,8}, {0,1,2,3} }; |
| PARAM x = {4,3,2,1}; |
| PARAM y = {1,2,3,4}; |
| PARAM z = 4; |
| PARAM r = {4,3,2,1}; |
| |
| assume that arr1 is accessed using relative addressing but arr2 is not. |
| The four constants in arr1 all count against the limit. Only two other |
| constants, {0,1,2,3} in arr2, and {4,3,2,1} in x, are counted; the other |
| constants are identical to constants that had been previously counted. |
| |
| In addition to the limits described above, the GL provides a similar set |
| of implementation-dependent native resource limits. These limits, |
| specified in section 6.1.12, provide guidance as to whether the program is |
| small enough to use a "native" mode where vertex programs may be executed |
| with higher performance. The native resource limits and usage counts are |
| implementation-dependent and may not exactly correspond to limits and |
| counts described above. In particular, native resource consumption may be |
| reduced by program optimizations performed by the GL, or increased due to |
| emulation of non-native instructions. Programs that satisfy the program |
| resource limits described above, but whose native resource usage exceeds |
| one or more native resource limits, are guaranteed to load but may execute |
| suboptimally. |
| |
| To assist in resource counting, the GL additionally provides GetProgram |
| queries to determine the resource usage and native resource usage of the |
| currently bound program, and to determine whether the bound program |
| exceeds any native resource limit. |
| |
| |
| Section 2.14.4, Vertex Program Execution Environment |
| |
| If vertex program mode is enabled, the currently bound vertex program is |
| executed when a vertex is specified directly through the Vertex command, |
| indirectly through vertex arrays or evaluators (section 5.1), or when the |
| current raster position is updated. |
| |
| If vertex program mode is enabled and the currently bound program object |
| does not contain a valid vertex program, the error INVALID_OPERATION will |
| be generated by Begin, RasterPos, and any command that implicitly calls |
| Begin (e.g., DrawArrays). |
| |
| Vertex programs execute a sequence of instructions without |
| branching. Vertex programs begin by executing the first instruction in |
| the program, and execute instructions in the order specified in the |
| program until the last instruction is completed. |
| |
| There are twenty-seven vertex program instructions. The instructions and |
| their respective input and output parameters are summarized in Table X.5. |
| |
| Instruction Inputs Output Description |
| ----------- ------ ------ -------------------------------- |
| ABS v v absolute value |
| ADD v,v v add |
| ARL s a address register load |
| DP3 v,v ssss 3-component dot product |
| DP4 v,v ssss 4-component dot product |
| DPH v,v ssss homogeneous dot product |
| DST v,v v distance vector |
| EX2 s ssss exponential base 2 |
| EXP s v exponential base 2 (approximate) |
| FLR v v floor |
| FRC v v fraction |
| LG2 s ssss logarithm base 2 |
| LIT v v compute light coefficients |
| LOG s v logarithm base 2 (approximate) |
| MAD v,v,v v multiply and add |
| MAX v,v v maximum |
| MIN v,v v minimum |
| MOV v v move |
| MUL v,v v multiply |
| POW s,s ssss exponentiate |
| RCP s ssss reciprocal |
| RSQ s ssss reciprocal square root |
| SGE v,v v set on greater than or equal |
| SLT v,v v set on less than |
| SUB v,v v subtract |
| SWZ v v extended swizzle |
| XPD v,v v cross product |
| |
| Table X.5: Summary of vertex program instructions. "v" indicates a |
| floating-point vector input or output, "s" indicates a floating-point |
| scalar input, "ssss" indicates a scalar output replicated across a |
| 4-component result vector, and "a" indicates a single address register |
| component. |
| |
| |
| Section 2.14.4.1, Vertex Program Operands |
| |
| Most vertex program instructions operate on floating-point vectors or |
| scalars, as indicated by the grammar rules <swizzleSrcReg> and |
| <scalarSrcReg>, respectively. |
| |
| Vector and scalar operands can be obtained from vertex attribute, program |
| parameter, or temporary registers, as indicated by the <srcReg> rule. For |
| scalar operands, a single vector component is selected by the |
| <scalarSuffix> rule, where the characters "x", "y", "z", and "w" select |
| the x, y, z, and w components, respectively, of the vector. |
| |
| Vector operands can be swizzled according to the <swizzleSuffix> rule. In |
| its most general form, the <swizzleSuffix> rule matches the pattern |
| ".????" where each question mark is replaced with one of "x", "y", "z", or |
| "w". For such patterns, the x, y, z, and w components of the operand are |
| taken from the vector components named by the first, second, third, and |
| fourth character of the pattern, respectively. For example, if the |
| swizzle suffix is ".yzzx" and the specified source contains {2,8,9,0}, the |
| swizzled operand used by the instruction is {8,9,9,2}. |
| |
| If the <swizzleSuffix> rule matches "", it is treated as though it were |
| ".xyzw". If the <swizzleSuffix> rule matches (ignoring whitespace) ".x", |
| ".y", ".z", or ".w", these are treated the same as ".xxxx", ".yyyy", |
| ".zzzz", and ".wwww" respectively. |
| |
| Floating-point scalar or vector operands can optionally be negated |
| according to the <optionalSign> rule in <scalarSrcReg> and |
| <swizzleSrcReg>. If the <optionalSign> matches "-", each operand or |
| operand component is negated. |
| |
| The following pseudo-code spells out the operand generation process. In |
| the example, "float" is a floating-point scalar type, while "floatVec" is |
| a four-component vector. "source" refers to the register used for the |
| operand, matching the <srcReg> rule. "negate" is TRUE if the |
| <optionalSign> rule in <scalarSrcReg> or <swizzleSrcReg> matches "-" and |
| FALSE otherwise. The ".c***", ".*c**", ".**c*", ".***c" modifiers refer |
| to the x, y, z, and w components obtained by the swizzle operation; the |
| ".c" modifier refers to the single component selected for a scalar load. |
| |
| floatVec VectorLoad(floatVec source) |
| { |
| floatVec operand; |
| |
| operand.x = source.c***; |
| operand.y = source.*c**; |
| operand.z = source.**c*; |
| operand.w = source.***c; |
| if (negate) { |
| operand.x = -operand.x; |
| operand.y = -operand.y; |
| operand.z = -operand.z; |
| operand.w = -operand.w; |
| } |
| |
| return operand; |
| } |
| |
| float ScalarLoad(floatVec source) |
| { |
| float operand; |
| |
| operand = source.c; |
| if (negate) { |
| operand = -operand; |
| } |
| |
| return operand; |
| } |
| |
| Section 2.14.4.2, Vertex Program Parameter Arrays |
| |
| A vertex program can load a single element of a program parameter array |
| using either absolute or relative addressing. Program parameter arrays |
| are accessed when the <progParamArray> rule is matched. |
| |
| Absolute addressing is used when the <progParamArrayMem> grammar rule |
| matches <progParamArrayAbs>. When using absolute addressing, the offset |
| of the selected entry in the array is given by the number matching |
| <progParamRegNum>. |
| |
| Relative addressing is used when the <progParamArrayMem> grammar rule |
| matches <progParamArrayRel>. When using relative addressing, the offset |
| of the selected entry in the array is computed by adding the address |
| register component specified by the <addrReg> and <addrComponent> rules to |
| the positive or negative offset specified by the <addrRegRelOffset> rule. |
| If <addrRegRelOffset> matches "", no fixed offset is added to the address |
| register component. If the computed offset is negative or exceeds the |
| size of the array, the results of the access are undefined, but may not |
| lead to program or GL termination. |
| |
| The following pseudo-code spells out the process of loading a program |
| parameter from an array. "addrReg" refers to the address register |
| component used for relative addressing, "absolute" is TRUE if the operand |
| uses absolute addressing and FALSE otherwise. "paramNumber" is the |
| program parameter number for absolute addressing; "paramOffset" is the |
| constant program parameter offset for relative addressing. "paramArray" |
| is the parameter array that matches the <progParamArray> rule. |
| |
| floatVec ProgramParameterLoad(int addrReg) |
| { |
| int index; |
| |
| if (absolute) { |
| index = paramNumber; |
| } else { |
| index = addrReg + paramOffset |
| } |
| |
| return paramArray[index]; |
| } |
| |
| Relative addressing can only be used for accessing program parameter |
| arrays. |
| |
| |
| Section 2.14.4.3, Vertex Program Destination Register Update |
| |
| Most vertex program instructions write a 4-component result vector to a |
| single temporary or vertex result register. Writes to individual |
| components of the destination register are controlled by individual |
| component write masks specified as part of the instruction. |
| |
| The component write mask is specified by the <optionalMask> rule found in |
| the <maskedDstReg> rule. If the optional mask is "", all components are |
| enabled. Otherwise, the optional mask names the individual components to |
| enable. The characters "x", "y", "z", and "w" match the x, y, z, and w |
| components respectively. For example, an optional mask of ".xzw" |
| indicates that the x, z, and w components should be enabled for writing |
| but the y component should not. The grammar requires that the destination |
| register mask components must be listed in "xyzw" order. |
| |
| Each component of the destination register is updated with the result of |
| the vertex program instruction if and only if the component is enabled for |
| writes by the component write mask. Otherwise, the component of the |
| destination register remains unchanged. |
| |
| The following pseudocode illustrates the process of writing a result |
| vector to the destination register. In the pseudocode, "instrmask" refers |
| to the component write mask given by the <optionalMask> rule. "result" |
| and "destination" refer to the result vector and the register selected by |
| <dstReg>, respectively. |
| |
| void UpdateDestination(floatVec destination, floatVec result) |
| { |
| floatVec merged; |
| |
| // Merge the converted result into the destination register, under |
| // control of the compile-time write mask. |
| merged = destination; |
| if (instrMask.x) { |
| merged.x = result.x; |
| } |
| if (instrMask.y) { |
| merged.y = result.y; |
| } |
| if (instrMask.z) { |
| merged.z = result.z; |
| } |
| if (instrMask.w) { |
| merged.w = result.w; |
| } |
| |
| // Write out the new destination register. |
| destination = merged; |
| } |
| |
| The "ARL" instruction updates the single address register component |
| similarly; the grammar is designed so that it writes to only the "x" |
| component of an address register variable. |
| |
| |
| Section 2.14.4.4, Vertex Program Result Processing |
| |
| As a vertex program executes, it will write to one or more result |
| registers that are mapped to transformed vertex attributes. When a vertex |
| program completes, the transformed vertex attributes are used to generate |
| primitives. |
| |
| The clip coordinates written to "result.position" are used to generate |
| normalized device coordinates and window coordinates for the vertex in the |
| manner described section 2.10. |
| |
| Transformed vertices are then assembled into primitives and clipped as |
| described in section 2.11. |
| |
| The selection between front-facing and back-facing color attributes |
| depends on the primitive to which the vertex belongs. If the primitive is |
| a point or a line segment, or if vertex program two-sided color mode is |
| disabled, the front-facing colors are always selected. If it is a polygon |
| and two-sided color mode is enabled, then the selection is performed in |
| exactly the same way as in two-sided lighting mode (section 2.13.1). |
| Vertex program two-sided color mode is enabled and disabled by calling |
| Enable or Disable with the symbolic value VERTEX_PROGRAM_TWO_SIDE_ARB. |
| |
| Finally, as primitives are assembled, color clamping (section 2.13.6), |
| flatshading (section 2.13.7), color, attribute clipping (section 2.13.8), |
| and final color processing (section 2.13.9) operations are applied to the |
| transformed vertices. |
| |
| |
| Section 2.14.4.5, Vertex Program Options |
| |
| The <optionSequence> grammar rule provides a mechanism for programs to |
| indicate that one or more extended language features are used by the |
| program. All program options used by the program must be declared at the |
| beginning of the program string. Each program option specified in a |
| program string will modify the syntactic or semantic rules used to |
| interpet the program and the execution environment used to execute the |
| program. Program options not present in the program string are ignored, |
| even if they are supported by the GL. |
| |
| The <identifier> token in the <option> rule must match the name of a |
| program option supported by the implementation. To avoid option name |
| conflicts, option identifiers are required to begin with a vendor prefix. |
| A program will fail to load if it specifies a program option not supported |
| by the GL. |
| |
| Vertex program options should confine their semantic changes to the domain |
| of vertex programs. Support for a vertex program option should not change |
| the specification and behavior of vertex programs not requesting use of |
| that option. |
| |
| 2.14.4.5.1, Position-Invariant Vertex Program Option |
| |
| If a vertex program specifies the "ARB_position_invariant" option, the |
| program is used to generate all transformed vertex attributes except for |
| position. Instead, clip coordinates are computed as specified in section |
| 2.10. Additionally, user clipping is performed as described in section |
| 2.11. Use of position-invariant vertex programs should generally |
| guarantee that the transformed position of a vertex should be the same |
| whether vertex program mode is enabled or disabled, allowing for correct |
| mixed multi-pass rendering semantics. |
| |
| When the position-invariant option is specified in a vertex program, |
| vertex programs can no longer produced a transformed position. The |
| <resultBinding> rule is modified to remove "result.position" from the list |
| of token sequences matching the rule. A semantic restriction is added to |
| indicate that a vertex program will fail to load if the number of |
| instructions it contains exceeds the implementation-dependent limit minus |
| four. |
| |
| |
| Section 2.14.5, Vertex Program Instruction Set |
| |
| The following sections describe the set of supported vertex program |
| instructions. Each section contains pseudocode describing the |
| instruction. Instructions will have up to three operands, referred to as |
| "op0", "op1", and "op2". The operands are loaded using the mechanisms |
| specified in section 2.14.4.1. The variables "tmp", "tmp0", "tmp1", and |
| "tmp2" describe scalars or vectors used to hold intermediate results in |
| the instruction. Most instructions will generate a result vector called |
| "result". The result vector is then written to the destination register |
| specified in the instruction as described in section 2.14.4.3. |
| |
| |
| Section 2.14.5.1, ABS: Absolute Value |
| |
| The ABS instruction performs a component-wise absolute value operation on |
| the single operand to yield a result vector. |
| |
| tmp = VectorLoad(op0); |
| result.x = fabs(tmp.x); |
| result.y = fabs(tmp.y); |
| result.z = fabs(tmp.z); |
| result.w = fabs(tmp.w); |
| |
| |
| Section 2.14.5.2, ADD: Add |
| |
| The ADD instruction performs a component-wise add of the two operands to |
| yield a result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = tmp0.x + tmp1.x; |
| result.y = tmp0.y + tmp1.y; |
| result.z = tmp0.z + tmp1.z; |
| result.w = tmp0.w + tmp1.w; |
| |
| The following rules apply to addition: |
| |
| 1. <x> + <y> == <y> + <x>, for all <x> and <y>. |
| 2. <x> + 0.0 == <x>, for all <x>. |
| |
| |
| Section 2.14.5.3, ARL: Address Register Load |
| |
| The ARL instruction loads a single scalar operand and performs a floor |
| operation to generate a signed integer scalar result: |
| |
| result = floor(ScalarLoad(op0)); |
| |
| The floor operation returns the largest integer less than or equal to the |
| operand. For example floor(-1.7) = -2.0, floor(+1.0) = +1.0, and |
| floor(+3.7) = +3.0. |
| |
| |
| Section 2.14.5.4, DP3: Three-Component Dot Product |
| |
| The DP3 instruction computes a three-component dot product of the two |
| operands (using the x, y, and z components) and replicates the dot product |
| to all four components of the result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + |
| (tmp0.z * tmp1.z); |
| result.x = dot; |
| result.y = dot; |
| result.z = dot; |
| result.w = dot; |
| |
| |
| Section 2.14.5.5, DP4: Four-Component Dot Product |
| |
| The DP4 instruction computes a four-component dot product of the two |
| operands and replicates the dot product to all four components of the |
| result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1): |
| dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + |
| (tmp0.z * tmp1.z) + (tmp0.w * tmp1.w); |
| result.x = dot; |
| result.y = dot; |
| result.z = dot; |
| result.w = dot; |
| |
| |
| Section 2.14.5.6, DPH: Homogeneous Dot Product |
| |
| The DPH instruction computes a three-component dot product of the two |
| operands (using the x, y, and z components), adds the w component of the |
| second operand, and replicates the sum to all four components of the |
| result vector. This is equivalent to a four-component dot product where |
| the w component of the first operand is forced to 1.0. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1): |
| dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + |
| (tmp0.z * tmp1.z) + tmp1.w; |
| result.x = dot; |
| result.y = dot; |
| result.z = dot; |
| result.w = dot; |
| |
| |
| Section 2.14.5.7, DST: Distance Vector |
| |
| The DST instruction computes a distance vector from two specially- |
| formatted operands. The first operand should be of the form [NA, d^2, |
| d^2, NA] and the second operand should be of the form [NA, 1/d, NA, 1/d], |
| where NA values are not relevant to the calculation and d is a vector |
| length. If both vectors satisfy these conditions, the result vector will |
| be of the form [1.0, d, d^2, 1/d]. |
| |
| The exact behavior is specified in the following pseudo-code: |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = 1.0; |
| result.y = tmp0.y * tmp1.y; |
| result.z = tmp0.z; |
| result.w = tmp1.w; |
| |
| Given an arbitrary vector, d^2 can be obtained using the DP3 instruction |
| (using the same vector for both operands) and 1/d can be obtained from d^2 |
| using the RSQ instruction. |
| |
| This distance vector is useful for per-vertex light attenuation |
| calculations: a DP3 operation using the distance vector and an |
| attenuation constants vector as operands will yield the attenuation |
| factor. |
| |
| |
| Section 2.14.5.8, EX2: Exponential Base 2 |
| |
| The EX2 instruction approximates 2 raised to the power of the scalar |
| operand and replicates the approximation to all four components of the |
| result vector. |
| |
| tmp = ScalarLoad(op0); |
| result.x = Approx2ToX(tmp); |
| result.y = Approx2ToX(tmp); |
| result.z = Approx2ToX(tmp); |
| result.w = Approx2ToX(tmp); |
| |
| |
| Section 2.14.5.9, EXP: Exponential Base 2 (approximate) |
| |
| The EXP instruction computes a rough approximation of 2 raised to the |
| power of the scalar operand. The approximation is returned in the "z" |
| component of the result vector. A vertex program can also use the "x" and |
| "y" components of the result vector to generate a more accurate |
| approximation by evaluating |
| |
| result.x * f(result.y), |
| |
| where f(x) is a user-defined function that approximates 2^x over the |
| domain [0.0, 1.0). The "w" component of the result vector is always 1.0. |
| |
| The exact behavior is specified in the following pseudo-code: |
| |
| tmp = ScalarLoad(op0); |
| result.x = 2^floor(tmp); |
| result.y = tmp - floor(tmp); |
| result.z = RoughApprox2ToX(tmp); |
| result.w = 1.0; |
| |
| The approximation function is accurate to at least 10 bits: |
| |
| | RoughApprox2ToX(x) - 2^x | < 1.0 / 2^11, if 0.0 <= x < 1.0, |
| |
| and, in general, |
| |
| | RoughApprox2ToX(x) - 2^x | < (1.0 / 2^11) * (2^floor(x)). |
| |
| |
| Section 2.14.5.10, FLR: Floor |
| |
| The FLR instruction performs a component-wise floor operation on the |
| operand to generate a result vector. The floor of a value is defined as |
| the largest integer less than or equal to the value. The floor of 2.3 is |
| 2.0; the floor of -3.6 is -4.0. |
| |
| tmp = VectorLoad(op0); |
| result.x = floor(tmp.x); |
| result.y = floor(tmp.y); |
| result.z = floor(tmp.z); |
| result.w = floor(tmp.w); |
| |
| |
| Section 2.14.5.11, FRC: Fraction |
| |
| The FRC instruction extracts the fractional portion of each component of |
| the operand to generate a result vector. The fractional portion of a |
| component is defined as the result after subtracting off the floor of the |
| component (see FLR), and is always in the range [0.0, 1.0). |
| |
| For negative values, the fractional portion is NOT the number written to |
| the right of the decimal point -- the fractional portion of -1.7 is not |
| 0.7 -- it is 0.3. 0.3 is produced by subtracting the floor of -1.7 (-2.0) |
| from -1.7. |
| |
| tmp = VectorLoad(op0); |
| result.x = fraction(tmp.x); |
| result.y = fraction(tmp.y); |
| result.z = fraction(tmp.z); |
| result.w = fraction(tmp.w); |
| |
| |
| Section 2.14.5.12, LG2: Logarithm Base 2 |
| |
| The LG2 instruction approximates the base 2 logarithm of the scalar |
| operand and replicates it to all four components of the result vector. |
| |
| tmp = ScalarLoad(op0); |
| result.x = ApproxLog2(tmp); |
| result.y = ApproxLog2(tmp); |
| result.z = ApproxLog2(tmp); |
| result.w = ApproxLog2(tmp); |
| |
| If the scalar operand is zero or negative, the result is undefined. |
| |
| |
| Section 2.14.5.13, LIT: Light Coefficients |
| |
| The LIT instruction accelerates per-vertex lighting by computing lighting |
| coefficients for ambient, diffuse, and specular light contributions. The |
| "x" component of the single operand is assumed to hold a diffuse dot |
| product (n dot VP_pli, as in the vertex lighting equations in Section |
| 2.13.1). The "y" component of the operand is assumed to hold a specular |
| dot product (n dot h_i). The "w" component of the operand is assumed to |
| hold the specular exponent of the material (s_rm), and is clamped to the |
| range (-128, +128) exclusive. |
| |
| The "x" component of the result vector receives the value that should be |
| multiplied by the ambient light/material product (always 1.0). The "y" |
| component of the result vector receives the value that should be |
| multiplied by the diffuse light/material product (n dot VP_pli). The "z" |
| component of the result vector receives the value that should be |
| multiplied by the specular light/material product (f_i * (n dot h_i) ^ |
| s_rm). The "w" component of the result is the constant 1.0. |
| |
| Negative diffuse and specular dot products are clamped to 0.0, as is done |
| in the standard per-vertex lighting operations. In addition, if the |
| diffuse dot product is zero or negative, the specular coefficient is |
| forced to zero. |
| |
| tmp = VectorLoad(op0); |
| if (tmp.x < 0) tmp.x = 0; |
| if (tmp.y < 0) tmp.y = 0; |
| if (tmp.w < -(128.0-epsilon)) tmp.w = -(128.0-epsilon); |
| else if (tmp.w > 128-epsilon) tmp.w = 128-epsilon; |
| result.x = 1.0; |
| result.y = tmp.x; |
| result.z = (tmp.x > 0) ? RoughApproxPower(tmp.y, tmp.w) : 0.0; |
| result.w = 1.0; |
| |
| The exponentiation approximation function may be defined in terms of the |
| base 2 exponentiation and logarithm approximation operations in the EXP |
| and LOG instructions, where |
| |
| RoughApproxPower(a,b) = RoughApproxExp2(b * RoughApproxLog2(a)). |
| |
| In particular, the approximation may not be any more accurate than the |
| underlying EXP and LOG operations. |
| |
| Also, since 0^0 is defined to be 1, RoughApproxPower(0.0, 0.0) will |
| produce 1.0. |
| |
| |
| Section 2.14.5.14, LOG: Logarithm Base 2 (approximate) |
| |
| The LOG instruction computes a rough approximation of the base 2 logarithm |
| of the absolute value of the scalar operand. The approximation is |
| returned in the "z" component of the result vector. A vertex program can |
| also use the "x" and "y" components of the result vector to generate a |
| more accurate approximation by evaluating |
| |
| result.x + f(result.y), |
| |
| where f(x) is a user-defined function that approximates 2^x over the |
| domain [1.0, 2.0). The "w" component of the result vector is always 1.0. |
| |
| The exact behavior is specified in the following pseudo-code: |
| |
| tmp = fabs(ScalarLoad(op0)); |
| result.x = floor(log2(tmp)); |
| result.y = tmp / 2^(floor(log2(tmp))); |
| result.z = RoughApproxLog2(tmp); |
| result.w = 1.0; |
| |
| Here, "floor(log2(tmp))" refers to the floor of the exact logarithm, which |
| can be easily computed for standard floating-point representations. The |
| approximation function is accurate to at least 10 bits: |
| |
| | RoughApproxLog2(x) - log_2(x) | < 1.0 / 2^11. |
| |
| |
| Section 2.14.5.15, MAD: Multiply and Add |
| |
| The MAD instruction performs a component-wise multiply of the first two |
| operands, and then does a component-wise add of the product to the third |
| operand to yield a result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| tmp2 = VectorLoad(op2); |
| result.x = tmp0.x * tmp1.x + tmp2.x; |
| result.y = tmp0.y * tmp1.y + tmp2.y; |
| result.z = tmp0.z * tmp1.z + tmp2.z; |
| result.w = tmp0.w * tmp1.w + tmp2.w; |
| |
| The multiplication and addition operations in this instruction are subject |
| to the same rules as described for the MUL and ADD instructions. |
| |
| |
| Section 2.14.5.16, MAX: Maximum |
| |
| The MAX instruction computes component-wise maximums of the values in the |
| two operands to yield a result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = (tmp0.x > tmp1.x) ? tmp0.x : tmp1.x; |
| result.y = (tmp0.y > tmp1.y) ? tmp0.y : tmp1.y; |
| result.z = (tmp0.z > tmp1.z) ? tmp0.z : tmp1.z; |
| result.w = (tmp0.w > tmp1.w) ? tmp0.w : tmp1.w; |
| |
| |
| Section 2.14.5.17, MIN: Minimum |
| |
| The MIN instruction computes component-wise minimums of the values in the |
| two operands to yield a result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = (tmp0.x > tmp1.x) ? tmp1.x : tmp0.x; |
| result.y = (tmp0.y > tmp1.y) ? tmp1.y : tmp0.y; |
| result.z = (tmp0.z > tmp1.z) ? tmp1.z : tmp0.z; |
| result.w = (tmp0.w > tmp1.w) ? tmp1.w : tmp0.w; |
| |
| |
| Section 2.14.5.18, MOV: Move |
| |
| The MOV instruction copies the value of the operand to yield a result |
| vector. |
| |
| result = VectorLoad(op0); |
| |
| |
| Section 2.14.5.19, MUL: Multiply |
| |
| The MUL instruction performs a component-wise multiply of the two operands |
| to yield a result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = tmp0.x * tmp1.x; |
| result.y = tmp0.y * tmp1.y; |
| result.z = tmp0.z * tmp1.z; |
| result.w = tmp0.w * tmp1.w; |
| |
| The following rules apply to multiplication: |
| |
| 1. <x> * <y> == <y> * <x>, for all <x> and <y>. |
| 2. +/-0.0 * <x> = +/-0.0, at least for all <x> that correspond to |
| representable numbers (IEEE "not a number" and "infinity" encodings |
| may be exceptions). |
| 3. +1.0 * <x> = <x>, for all <x>. |
| |
| Multiplication by zero and one should be invariant, as it may be used to |
| evaluate conditional expressions without branching. |
| |
| |
| Section 2.14.5.20, POW: Exponentiate |
| |
| The POW instruction approximates the value of the first scalar operand |
| raised to the power of the second scalar operand and replicates it to all |
| four components of the result vector. |
| |
| tmp0 = ScalarLoad(op0); |
| tmp1 = ScalarLoad(op1); |
| result.x = ApproxPower(tmp0, tmp1); |
| result.y = ApproxPower(tmp0, tmp1); |
| result.z = ApproxPower(tmp0, tmp1); |
| result.w = ApproxPower(tmp0, tmp1); |
| |
| The exponentiation approximation function may be implemented using the |
| base 2 exponentiation and logarithm approximation operations in the EX2 |
| and LG2 instructions. In particular, |
| |
| ApproxPower(a,b) = ApproxExp2(b * ApproxLog2(a)). |
| |
| Note that a logarithm may be involved even for cases where the exponent is |
| an integer. This means that it may not be possible to exponentiate |
| correctly with a negative base. In constrast, it is possible in a |
| "normal" mathematical formulation to raise negative numbers to integral |
| powers (e.g., (-3)^2== 9, and (-0.5)^-2==4). |
| |
| |
| Section 2.14.5.21, RCP: Reciprocal |
| |
| The RCP instruction approximates the reciprocal of the scalar operand and |
| replicates it to all four components of the result vector. |
| |
| tmp = ScalarLoad(op0); |
| result.x = ApproxReciprocal(tmp); |
| result.y = ApproxReciprocal(tmp); |
| result.z = ApproxReciprocal(tmp); |
| result.w = ApproxReciprocal(tmp); |
| |
| The following rule applies to reciprocation: |
| |
| 1. ApproxReciprocal(+1.0) = +1.0. |
| |
| |
| Section 2.14.5.22, RSQ: Reciprocal Square Root |
| |
| The RSQ instruction approximates the reciprocal of the square root of the |
| absolute value of the scalar operand and replicates it to all four |
| components of the result vector. |
| |
| tmp = fabs(ScalarLoad(op0)); |
| result.x = ApproxRSQRT(tmp); |
| result.y = ApproxRSQRT(tmp); |
| result.z = ApproxRSQRT(tmp); |
| result.w = ApproxRSQRT(tmp); |
| |
| |
| Section 2.14.5.23, SGE: Set On Greater or Equal Than |
| |
| The SGE instruction performs a component-wise comparison of the two |
| operands. Each component of the result vector is 1.0 if the corresponding |
| component of the first operands is greater than or equal that of the |
| second, and 0.0 otherwise. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = (tmp0.x >= tmp1.x) ? 1.0 : 0.0; |
| result.y = (tmp0.y >= tmp1.y) ? 1.0 : 0.0; |
| result.z = (tmp0.z >= tmp1.z) ? 1.0 : 0.0; |
| result.w = (tmp0.w >= tmp1.w) ? 1.0 : 0.0; |
| |
| |
| Section 2.14.5.24, SLT: Set On Less Than |
| |
| The SLT instruction performs a component-wise comparison of the two |
| operands. Each component of the result vector is 1.0 if the corresponding |
| component of the first operand is less than that of the second, and 0.0 |
| otherwise. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = (tmp0.x < tmp1.x) ? 1.0 : 0.0; |
| result.y = (tmp0.y < tmp1.y) ? 1.0 : 0.0; |
| result.z = (tmp0.z < tmp1.z) ? 1.0 : 0.0; |
| result.w = (tmp0.w < tmp1.w) ? 1.0 : 0.0; |
| |
| |
| Section 2.14.5.25, SUB: Subtract |
| |
| The SUB instruction performs a component-wise subtraction of the second |
| operand from the first to yield a result vector. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = tmp0.x - tmp1.x; |
| result.y = tmp0.y - tmp1.y; |
| result.z = tmp0.z - tmp1.z; |
| result.w = tmp0.w - tmp1.w; |
| |
| |
| Section 2.14.5.26, SWZ: Extended Swizzle |
| |
| The SWZ instruction loads the single vector operand, and performs a |
| swizzle operation more powerful than that provided for loading normal |
| vector operands to yield an instruction vector. |
| |
| After the operand is loaded, the "x", "y", "z", and "w" components of the |
| result vector are selected by the first, second, third, and fourth matches |
| of the <extSwizComp> pattern in the <extendedSwizzle> rule. |
| |
| A result component can be selected from any of the four components of the |
| operand or the constants 0.0 and 1.0. The result component can also be |
| optionally negated. The following pseudocode describes the component |
| selection method. "operand" refers to the vector operand, "select" is an |
| enumerant where the values ZERO, ONE, X, Y, Z, and W correspond to the |
| <extSwizSel> rule matching "0", "1", "x", "y", "z", and "w", respectively. |
| "negate" is TRUE if and only if the <optionalSign> rule in <extSwizComp> |
| matches "-". |
| |
| float ExtSwizComponent(floatVec operand, enum select, boolean negate) |
| { |
| float result; |
| switch (select) { |
| case ZERO: result = 0.0; break; |
| case ONE: result = 1.0; break; |
| case X: result = operand.x; break; |
| case Y: result = operand.y; break; |
| case Z: result = operand.z; break; |
| case W: result = operand.w; break; |
| } |
| if (negate) { |
| result = -result; |
| } |
| return result; |
| } |
| |
| The entire extended swizzle operation is then defined using the following |
| pseudocode: |
| |
| tmp = VectorLoad(op0); |
| result.x = ExtSwizComponent(tmp, xSelect, xNegate); |
| result.y = ExtSwizComponent(tmp, ySelect, yNegate); |
| result.z = ExtSwizComponent(tmp, zSelect, zNegate); |
| result.w = ExtSwizComponent(tmp, wSelect, wNegate); |
| |
| "xSelect", "xNegate", "ySelect", "yNegate", "zSelect", "zNegate", |
| "wSelect", and "wNegate" correspond to the "select" and "negate" values |
| above for the four <extSwizComp> matches. |
| |
| Since this instruction allows for component selection and negation for |
| each individual component, the grammar does not allow the use of the |
| normal swizzle and negation operations allowed for vector operands in |
| other instructions. |
| |
| |
| Section 2.14.5.27, XPD: Cross Product |
| |
| The XPD instruction computes the cross product using the first three |
| components of its two vector operands to generate the x, y, and z |
| components of the result vector. The w component of the result vector is |
| undefined. |
| |
| tmp0 = VectorLoad(op0); |
| tmp1 = VectorLoad(op1); |
| result.x = tmp0.y * tmp1.z - tmp0.z * tmp1.y; |
| result.y = tmp0.z * tmp1.x - tmp0.x * tmp1.z; |
| result.z = tmp0.x * tmp1.y - tmp0.y * tmp1.x; |
| |
| |
| Section 2.14.6, Program Matrices |
| |
| In addition to GL's conventional matrices, several additional program |
| matrices are available for use as program parameters. These matrices have |
| names of the form MATRIX<i>_ARB where <i> is between zero and <n>-1 where |
| <n> is the value of the implementation-dependent constant |
| MAX_PROGRAM_MATRICES_ARB. The MATRIX<i>_ARB constants obey MATRIX<i>_ARB |
| = MATRIX0_ARB + <i>. The value of MAX_PROGRAM_MATRICES_ARB must be at |
| least eight. The maximum stack depth for program matrices is defined by |
| the MAX_PROGRAM_MATRIX_STACK_DEPTH_ARB and must be at least 1. |
| |
| |
| Section 2.14.7 Required Vertex Program State |
| |
| The state required to support program objects of all targets consists of: |
| |
| an integer for the program error position, initially -1; |
| |
| an array of ubytes for the program error string, initially empty; |
| |
| and the state that must be maintained to indicate which integers are |
| currently in use as program object names. |
| |
| The state required to support the vertex program target consists of: |
| |
| a bit indicating whether or not program mode is enabled, initially |
| disabled; |
| |
| a bit indicating whether or not vertex program two-sided color mode is |
| enabled, initially disabled; |
| |
| a bit indicating whether or not vertex program point size mode is |
| enabled, initially disabled; |
| |
| a set of MAX_PROGRAM_ENV_PARAMETERS_ARB four-component floating-point |
| program environment parameters, initially set to (0,0,0,0); |
| |
| and an unsigned integer naming the currently bound vertex program, |
| initially zero. |
| |
| The state required for each vertex program object consists of: |
| |
| an unsigned integer indicating the program object name; |
| |
| an array of type ubyte containing the program string, initially empty; |
| |
| an unsigned integer holding the length of the program string, initially |
| zero; |
| |
| an enum indicating the program string format, initially |
| PROGRAM_FORMAT_ASCII_ARB; |
| |
| five unsigned integers holding the number of instruction, temporary |
| variable, vertex attribute binding, address register, and program |
| parameter binding resources used by the program, initially all zero; |
| |
| five unsigned integers holding the number of native instruction, |
| temporary variable, vertex attribute binding, address register, and |
| program parameter binding resources used by the program, initially all |
| zero; |
| |
| and a set of MAX_PROGRAM_LOCAL_PARAMETERS_ARB four-component |
| floating-point program local parameters, initially set to (0,0,0,0). |
| |
| Initially, no vertex program objects exist. |
| |
| |
| Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) |
| |
| Modify Section 3.3, Points (p. 63) |
| |
| (replace the first paragraph) When vertex program mode and vertex progam |
| point size mode are both enabled, the point size used for point |
| rasterization is taken from the transformed vertex's point size attribute. |
| Otherwise, it is controlled with |
| |
| void PointSize(float size); |
| |
| size specifies the width or diameter of a point. The initial point size |
| value is 1.0. A value less than or equal to zero results in the error |
| INVALID_VALUE. |
| |
| Vertex program point size mode is enabled and disabled by calling Enable |
| or Disable with the symbolic value VERTEX_PROGRAM_POINT_SIZE_ARB. |
| |
| |
| Modify Section 3.9, Color Sum (p. 154) |
| |
| After texturing, a fragment has two RGBA colors: a primary color c_pri |
| (which texturing, if enabled, may have modified) and a secondary color |
| c_sec. If color sum is enabled, the R, G, and B components of these two |
| colors are summed, and with the A component of the primary color produce a |
| single post-texturing RGBA color c. The components of c are then clamped |
| to the range [0,1]. If color sum is disabled, then c_pri is assigned to |
| the post-texturing color. |
| |
| Color sum is enabled or disabled using the generic Enable and Disable |
| commands, respectively, with the symbolic constant COLOR_SUM_ARB. If |
| vertex program mode is disabled and lighting is enabled, the color sum |
| stage is always applied, ignoring the value of COLOR_SUM_ARB. |
| |
| The state required is a single bit indicating whether color sum is enabled |
| or disabled. In the initial state, color sum is disabled. |
| |
| |
| Modify Section 3.10, Fog (p. 154) |
| |
| (modify second paragraph) This factor f may be computed according to one |
| of three equations: |
| |
| f = exp(-d*c), (3.24) |
| f = exp(-(d*c)^2), or (3.25) |
| f = (e-c)/(e-s) (3.26) |
| |
| If vertex program mode is enabled or if the fog source (as defined below) |
| is FOG_COORDINATE_EXT, then c is the fragment's fog coordinate. |
| Otherwise, the c is the eye-coordinate distance from the eye, (0,0,0,1) in |
| eye-coordinates, to the fragment center. ... |
| |
| Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment |
| Operations and the Framebuffer) |
| |
| None |
| |
| Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) |
| |
| Modify Section 5.1, Evaluators (p. 181) |
| |
| (modify next-to-last paragraph, p. 184) For MAP VERTEX 3, let q = p. For |
| MAP VERTEX 4, let q=(x/w,y/w,z/w), where (x; y; z;w) = p. Then let |
| |
| dq dq |
| m = -- x --. |
| du dv |
| |
| The the generated analytic normal, n, is given by n=m if vertex program |
| mode is enabled or by n=m/|m| if vertex program mode is disabled. |
| |
| |
| Modify Section 5.4, Display Lists (p. 191) |
| |
| (modify third paragraph, p. 195) ... These are IsList, GenLists, ..., |
| IsProgramARB, GenProgramsARB, DeleteProgramsARB, and |
| VertexAttribPointerARB, EnableVertexAttribArrayARB, |
| DisableVertexAttribArrayARB, as well as IsEnabled and all the Get commands |
| (chapter 6). |
| |
| |
| Additions to Chapter 6 of the OpenGL 1.3 Specification (State and State |
| Requests) |
| |
| Modify Section 6.1.2, Data Conversions (p. 198) |
| |
| (add before last paragraph, p. 198) The matrix selected by the current |
| matrix mode can be queried by calling GetBooleanv, GetIntegerv, GetFloatv, |
| and GetDoublev with <pname> set to CURRENT_MATRIX_ARB; the matrix will be |
| returned in transposed form with <pname> set to |
| TRANSPOSE_CURRENT_MATRIX_ARB. The depth of the selected matrix stack can |
| be queried with <pname> set to CURRENT_MATRIX_STACK_DEPTH_ARB. Querying |
| CURRENT_MATRIX_ARB and CURRENT_MATRIX_STACK_DEPTH_ARB is the only means |
| for querying the matrix and matrix stack depth of the program matrices |
| described in section 2.14.6. |
| |
| |
| Modify Section 6.1.11, Pointer and String Queries (p. 206) |
| |
| (modify last paragraph, p. 206) ... The possible values for <name> are |
| VENDOR, RENDERER, VERSION, EXTENSIONS, and PROGRAM_ERROR_STRING_ARB. |
| |
| (add after last paragraph of section, p. 207) Queries of |
| PROGRAM_ERROR_STRING_ARB return a pointer to an implementation-dependent |
| program load error string. If the last call to ProgramStringARB failed to |
| load a program, the returned string describes at least one reason why the |
| program failed to load. If the last call to ProgramStringARB successfully |
| loaded a program, the returned string may be empty (containing only a zero |
| terminator) or may contain one or more implementation-dependent warning |
| messages. The contents of the error string are guaranteed to remain |
| constant only until the next ProgramStringARB command, which may overwrite |
| the error string. |
| |
| |
| Insert a new Section 6.1.12, Program Queries (p. 207), between existing |
| sections 6.1.11 and 6.1.12. |
| |
| Section 6.1.12, Program Queries |
| |
| The commands |
| |
| void GetProgramEnvParameterdvARB(enum target, uint index, |
| double *params); |
| void GetProgramEnvParameterfvARB(enum target, uint index, |
| float *params); |
| |
| obtain the current value for the program environment parameter numbered |
| <index> for the given program target <target>, and places the information |
| in the array <params>. The error INVALID_ENUM is generated if <target> |
| specifies a nonexistent program target or a program target that does not |
| support program environment parameters. The error INVALID_VALUE is |
| generated if <index> is greater than or equal to the |
| implementation-dependent number of supported program environment |
| parameters for the program target. |
| |
| When <target> is VERTEX_PROGRAM_ARB, each program parameter returned is an |
| array of four values. |
| |
| The commands |
| |
| void GetProgramLocalParameterdvARB(enum target, uint index, |
| double *params); |
| void GetProgramLocalParameterfvARB(enum target, uint index, |
| float *params); |
| |
| obtain the current value for the program local parameter numbered <index> |
| belonging to the program object currently bound to <target>, and places |
| the information in the array <params>. The error INVALID_ENUM is |
| generated if <target> specifies a nonexistent program target or a program |
| target that does not support program local parameters. The error |
| INVALID_VALUE is generated if <index> is greater than or equal to the |
| implementation-dependent number of supported program local parameters for |
| the program target. |
| |
| When the program target type is VERTEX_PROGRAM_ARB, each program |
| local parameter returned is an array of four values. |
| |
| The command |
| |
| void GetProgramivARB(enum target, enum pname, int *params); |
| |
| obtains program state for the program target <target>, writing the state |
| into the array given by <params>. GetProgramivARB can be used to |
| determine the properties of the currently bound program object or |
| implementation limits for <target>. |
| |
| If <pname> is PROGRAM_LENGTH_ARB, PROGRAM_FORMAT_ARB, or |
| PROGRAM_BINDING_ARB, GetProgramivARB returns one integer holding the |
| program string length (in bytes), program string format, and program name, |
| respectively, for the program object currently bound to <target>. |
| |
| If <pname> is MAX_PROGRAM_LOCAL_PARAMETERS_ARB or |
| MAX_PROGRAM_ENV_PARAMETERS_ARB, GetProgramivARB returns one integer |
| holding the maximum number of program local parameters or program |
| environment parameters, respectively, supported for the program target |
| <target>. |
| |
| If <pname> is MAX_PROGRAM_INSTRUCTIONS_ARB, MAX_PROGRAM_TEMPORARIES_ARB, |
| MAX_PROGRAM_PARAMETERS_ARB, MAX_PROGRAM_ATTRIBS_ARB, or |
| MAX_PROGRAM_ADDRESS_REGISTERS_ARB, GetProgramivARB returns a single |
| integer giving the maximum number of instructions, temporaries, |
| parameters, attributes, and address registers that can be used by a |
| program of type <target>. If <pname> is PROGRAM_INSTRUCTIONS_ARB, |
| PROGRAM_TEMPORARIES_ARB, PROGRAM_PARAMETERS_ARB, PROGRAM_ATTRIBS_ARB, or |
| PROGRAM_ADDRESS_REGISTERS_ARB, GetProgramivARB returns a single integer |
| giving the number of instructions, temporaries, parameters, attributes, |
| and address registers used by the current program for <target>. |
| |
| If <pname> is MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB, |
| MAX_PROGRAM_NATIVE_TEMPORARIES_ARB, MAX_PROGRAM_NATIVE_PARAMETERS_ARB, |
| MAX_PROGRAM_NATIVE_ATTRIBS_ARB, or |
| MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB, GetProgramivARB returns a single |
| integer giving the maximum number of native instruction, temporary, |
| parameter, attribute, and address register resources available to a |
| program of type <target>. If <pname> is PROGRAM_NATIVE_INSTRUCTIONS_ARB, |
| PROGRAM_NATIVE_TEMPORARIES_ARB, PROGRAM_NATIVE_PARAMETERS_ARB, |
| PROGRAM_NATIVE_ATTRIBS_ARB, or PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB, |
| GetProgramivARB returns a single integer giving the number of native |
| instruction, temporary, parameter, attribute, and address register |
| resources consumed by the program currently bound to <target>. Native |
| resource counts will reflect the results of implementation-dependent |
| scheduling and optimization algorithms applied by the GL, as well as |
| emulation of non-native features. If <pname> is |
| PROGRAM_UNDER_NATIVE_LIMITS_ARB, GetProgramivARB returns 0 if the native |
| resource consumption of the program currently bound to <target> exceeds |
| the number of available resources for any resource type, and 1 otherwise. |
| |
| The command |
| |
| void GetProgramStringARB(enum target, enum pname, void *string); |
| |
| obtains the program string for the program object bound to <target> and |
| places the information in the array <string>. <pname> must be |
| PROGRAM_STRING_ARB. <n> ubytes are returned into the array program where |
| <n> is the length of the program in ubytes, as returned by GetProgramivARB |
| when <pname> is PROGRAM_LENGTH_ARB. The program string is always returned |
| using the format given when the program string was specified. |
| |
| The commands |
| |
| void GetVertexAttribdvARB(uint index, enum pname, double *params); |
| void GetVertexAttribfvARB(uint index, enum pname, float *params); |
| void GetVertexAttribivARB(uint index, enum pname, int *params); |
| |
| obtain the vertex attribute state named by <pname> for the vertex |
| attribute numbered <index> and places the information in the array |
| <params>. <pname> must be one of VERTEX_ATTRIB_ARRAY_ENABLED_ARB, |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB, VERTEX_ATTRIB_ARRAY_STRIDE_ARB, |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB, VERTEX_ATTRIB_ARRAY_NORMALIZED_ARB, or |
| CURRENT_VERTEX_ATTRIB_ARB. Note that all the queries except |
| CURRENT_VERTEX_ATTRIB_ARB return client state. The error INVALID_VALUE is |
| generated if <index> is greater than or equal to MAX_VERTEX_ATTRIBS_ARB. |
| The error INVALID_OPERATION is generated if <index> is zero and <pname> is |
| CURRENT_VERTEX_ATTRIB_ARB, as there is no current value for vertex |
| attribute zero. |
| |
| The command |
| |
| void GetVertexAttribPointervARB(uint index, enum pname, void **pointer); |
| |
| obtains the pointer named <pname> for vertex attribute numbered <index> |
| and places the information in the array <pointer>. <pname> must be |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB. The INVALID_VALUE error is generated if |
| <index> is greater than or equal to MAX_VERTEX_ATTRIBS_ARB. |
| |
| The command |
| |
| boolean IsProgramARB(uint program); |
| |
| returns TRUE if <program> is the name of a program object. If <program> |
| is zero or is a non-zero value that is not the name of a program object, |
| or if an error condition occurs, IsProgramARB returns FALSE. A name |
| returned by GenProgramsARB, but not yet bound, is not the name of a |
| program object. |
| |
| |
| Concerning Section 6.1.12, Saving and Restoring State (p. 207): |
| |
| (no actual modifications to the spec) Only the enables, current vertex |
| attributes, and vertex array state introduced by this extension can be |
| pushed and popped. See the attribute column in Table X.6 for determining |
| what vertex program state can be pushed and popped with PushAttrib, |
| PopAttrib, PushClientAttrib, and PopClientAttrib. |
| |
| |
| Additions to Appendix A of the OpenGL 1.3 Specification (Invariance) |
| |
| Add to end of Section A.3 (p. 242): |
| |
| Rule 4. Vertex program instructions not relevant to the calculation of |
| any result must have no effect on that result. |
| |
| Rule 5. Vertex program instructions relevant to the calculation of any |
| result must always produce the identical result. |
| |
| Instructions relevant to the calculation of a result are any instructions |
| in a sequence of instructions that eventually determine the source values |
| for the calculation under consideration. |
| |
| There is no guaranteed invariance between vertices transformed by |
| conventional GL vertex transform mode and vertices transformed by vertex |
| program mode. Multi-pass rendering algorithms that require rendering |
| invariances to operate correctly should not mix conventional GL vertex |
| transform mode with vertex program mode for different rendering passes, |
| except by using the position invariance option (section 2.14.4.5.1) in all |
| vertex program mode passes. However, such algorithms will operate |
| correctly if the algorithms limit themselves to a single mode of vertex |
| transformation. |
| |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| Program objects are shared between AGL/GLX/WGL rendering contexts if |
| and only if the rendering contexts share display lists. No change |
| is made to the AGL/GLX/WGL API. |
| |
| Changes to program objects shared between multiple rendering contexts will |
| be serialized (i.e., the changes will occur in a specific order). |
| |
| Changes to a program object made by one rendering context are not |
| guaranteed to take effect in another rendering context until the other |
| calls BindProgram to bind the program object. |
| |
| When a program object is deleted by one rendering context, the object |
| itself is not destroyed until it is no longer the current program object |
| in any context. However, the name of the deleted object is removed from |
| the program object name space, so the next attempt to bind a program using |
| the same name will create a new program object. Recall that destroying a |
| program object bound in the current rendering context effectively unbinds |
| the object being destroyed. |
| |
| |
| Dependencies on EXT_vertex_weighting and ARB_vertex_blend |
| |
| If EXT_vertex_weighting and ARB_vertex_blend are both not supported, all |
| discussions of vertex weights should be removed. |
| |
| In particular, references to vertex weights should be removed from Table |
| X.1, and the description of ArrayElement in section 2.8. The line |
| |
| "weight" <vtxOptWeightNum> |
| |
| should be removed from the <vtxAttribItem> grammar rule, and the grammar |
| rules <vtxOptWeightNum> and <vtxWeightNum> should be deleted. |
| "vertex.weight" and "vertex.weight[n]" should be removed from Table X.2. |
| The discussion of vertex weights in section 2.14.3.1 should be removed. |
| |
| Additionally, the first line of Table X.3.8 should be modified to read: |
| |
| Binding Underlying State |
| ------------------------------------ --------------------------- |
| state.matrix.modelview modelview matrix |
| |
| |
| Dependencies on ARB_matrix_palette: |
| |
| If ARB_matrix_palette is not supported, all discussions of per-vertex |
| matrix indices and the matrix palette should be removed. |
| |
| In particular, the reference to matrix indices should be removed from the |
| description of ArrayElement in section 2.8. The line |
| |
| "matrixindex" "[" <vtxWeightNum> "]" |
| |
| should be removed from the <vtxAttribItem> grammar rule. The line |
| |
| "palette" "[" <statePaletteMatNum> "]" |
| |
| should be removed from the <stateMatrixName> grammar rule, and the |
| <statePaletteMatNum> grammar rule should be removed entirely. |
| "vertex.matrixindex[n]" should be removed from Table X.2, and |
| "state.matrix.palette[n]" should be removed from Table X.3.8. The |
| discussion of vertex matrix indices in section 2.14.3.1 should be removed. |
| |
| Dependencies on EXT_point_parameters and ARB_point_parameters |
| |
| The discussion of point size determination in EXT/ARB_point_parameters |
| should qualified to indicate that this functionality only applies when |
| vertex program mode is disabled. |
| |
| If EXT/ARB_point_parameters is not supported, references to point |
| parameter state should be eliminated. In particular, |
| |
| "attenuation" |
| |
| should be eliminated from the <statePointProperty> grammar rule, and the |
| corresponding entries in Table X.3.7 should be eliminated. |
| |
| Additionally, references to the minimum and maximum point sizes and the |
| fade threshold should be removed from Table X.3.7 and the explanatory text |
| immediately thereafter. The components column of the "state.point.size" |
| binding in Table X.3.7 should read (s,0,0,1). |
| |
| Even if EXT/ARB_point_parameters is not supported, the point size result |
| (result.pointsize) still operates as specified. |
| |
| Dependencies on EXT_fog_coord |
| |
| If EXT_fog_coord is not supported, references to fog coordinates should be |
| removed from Table X.1, and the description of ArrayElement in section |
| 2.8. The line "fogcoord" should be removed from the <vtxAttribItem> |
| grammar rule, and "vertex.fogcoord" should be removed from Table X.2. |
| Also, the use of FOG_COORDINATE_SOURCE_EXT in section 3.10 should be |
| removed. |
| |
| Even if EXT_fog_coord is not supported, the fog coordinate output |
| (result.fogcoord) still operates as specified. When in vertex program |
| mode, there are no well-defined eye coordinates that could be used for |
| fog. This means that the functionality of EXT_fog_coord is required to |
| implement ARB_vertex_program even if the EXT_fog_coord extension itself is |
| not supported. |
| |
| Dependencies on EXT_secondary_color |
| |
| If EXT_secondary_color is not supported, references to secondary color |
| should be removed from Table X.1, and the description of ArrayElement in |
| section 2.8. The line "secondary" should be removed from the |
| <vtxOptColorType> grammar rule, and "vertex.color.secondary" should be |
| removed from Table X.2. |
| |
| Even if EXT_secondary_color is not supported, the secondary color results |
| (result.color.secondary, result.color.front.secondary, |
| result.color.back.secondary) still operate as specified in program mode, |
| and when in program mode, the color sum enable behaves exactly as |
| specified in EXT_secondary_color. These vertex result registers are |
| required to implement OpenGL 1.2's separate specular mode within a vertex |
| program. |
| |
| The color sum enable enumerant from EXT_secondary_color has been brought |
| over and renamed to COLOR_SUM_ARB. The enumerant value itself is |
| unchanged from EXT_secondary_color. |
| |
| Dependencies on ARB_transpose_matrix |
| |
| If ARB_transpose_matrix is not supported, the discussion of |
| TRANSPOSE_CURRENT_MATRIX_ARB in the edits to section 6.1.2 should be |
| removed. |
| |
| Interactions with NV_vertex_program |
| |
| The existing NV_vertex_program extension, if supported, also provides a |
| similar vertex programming model. This extension is incompatible with |
| NV_vertex_program in a number of different ways. Mixing the two models in |
| a single application is possible but not recommended. The interactions |
| between the extensions are defined below. |
| |
| Functions, enumerants, and programs defined in NV_vertex_program are |
| called "NV functions", "NV enumerants", and "NV programs" respectively. |
| Functions, enumerants, and programs defined in ARB_vertex_program are |
| called "ARB functions", "ARB enumerants", and "ARB programs" respectively. |
| |
| The following enumerants are identical in the two extensions: |
| |
| ARB_vertex_program NV_vertex_program |
| ------------------------------ ------------------------------ |
| VERTEX_PROGRAM_ARB VERTEX_PROGRAM_NV |
| VERTEX_PROGRAM_POINT_SIZE_ARB VERTEX_PROGRAM_POINT_SIZE_NV |
| VERTEX_PROGRAM_TWO_SIDE_ARB VERTEX_PROGRAM_TWO_SIDE_NV |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB ATTRIB_ARRAY_SIZE_NV |
| VERTEX_ATTRIB_ARRAY_STRIDE_ARB ATTRIB_ARRAY_STRIDE_NV |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB ATTRIB_ARRAY_TYPE_NV |
| CURRENT_VERTEX_ATTRIB_ARB CURRENT_ATTRIB_NV |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB ATTRIB_ARRAY_POINTER_NV |
| PROGRAM_LENGTH_ARB PROGRAM_LENGTH_NV |
| PROGRAM_STRING_ARB PROGRAM_STRING_NV |
| PROGRAM_ERROR_POSITION_ARB PROGRAM_ERROR_POSITION_NV |
| CURRENT_MATRIX_ARB CURRENT_MATRIX_NV |
| CURRENT_MATRIX_STACK_DEPTH_ARB CURRENT_MATRIX_STACK_DEPTH_NV |
| MAX_PROGRAM_MATRICES_ARB MAX_TRACK_MATRICES_NV |
| MAX_PROGRAM_MATRIX_STACK_DEPTH_ARB MAX_TRACK_MATRIX_STACK_DEPTH_NV |
| |
| The following GL state is identical in the two extensions and can be set |
| or queried using either NV functions or ARB functions. |
| |
| - Vertex program mode enable. |
| |
| - Vertex program point size mode enable. |
| |
| - Vertex program two sided mode enable. |
| |
| - Program error position. |
| |
| - NV_vertex_program "program parameters" and ARB_vertex_program "program |
| environment parameters". |
| |
| - Current values of generic vertex attributes. Conventional and generic |
| vertex attributes will alias according to the NV_vertex_program spec, |
| which is permissible but optional under ARB_vertex_program. |
| |
| - NV_vertex_program "tracking matrices" and ARB_vertex_program "program |
| matrices". The NV and ARB enumerants passed to MatrixMode are |
| different, however. |
| |
| - Vertex attribute array sizes, types, strides, and pointers. |
| |
| - Vertex program object names, targets, formats, program string, program |
| string lengths, and residency information. The ARB and NV query |
| functions operate differently. The ARB query function does not allow |
| queries of target (passed in to the query) and residency information. |
| The NV query function does not allow queries of program name (passed |
| in to the query) or format. The format of NV programs is always |
| PROGRAM_FORMAT_ASCII_ARB. |
| |
| - Current matrix and current matrix stack depth. |
| |
| - Implementation-dependent limits on number of tracking/program matrices |
| and tracking/program matrix stack depth. |
| |
| - Program object name space. Program objects are created differently in |
| the NV and ARB specs. Under the NV spec, program objects are created |
| by calling LoadProgramNV. Under the ARB spec, program objects are |
| created by calling BindProgramARB with an unused program name. |
| |
| The following state is provided only by ARB_vertex_program: |
| |
| - Program error string. Querying the error string after calling |
| LoadProgramNV produces undefined results. |
| |
| - Vertex attribute array normalization enables. Setting up vertex |
| attribute arrays through NV functions will set the normalization |
| enable appropriately based on the NV spec. |
| |
| - Vertex program object resource counts and native resource counts. |
| These values are undefined for NV programs. |
| |
| - Vertex program local parameters. They can not be used by NV programs. |
| |
| - Implementation-dependent limits on the number of program environment |
| parameters, program local parameters, resource counts, and native |
| resource counts. These limits are baked into the NV spec, except for |
| native counts, which don't exist. |
| |
| The following state is provided only by NV_vertex_program: |
| |
| - TrackMatrix enables and transforms. |
| |
| - Generic vertex attribute evaluator maps. The NV evaluator |
| functionality will be supported even for ARB programs. |
| |
| The following are additional functional differences between |
| ARB_vertex_program and NV_vertex_program: |
| |
| - ARB program temporaries, address registers, and result registers are |
| initially undefined. The corresponding values in NV programs are |
| initialized to (0,0,0,0), 0, and (0,0,0,1), respectively. ARB |
| programs running on NV_vertex_program platforms can not rely on |
| NV_vertex_program initialization behavior for temporaries or address |
| registers, but result registers will be initialized to (0,0,0,1). In |
| any event, ARB programs that rely on NV_vertex_program initialization |
| may not behave properly on other platforms that support |
| ARB_vertex_program but not NV_vertex_program. |
| |
| - NV programs use a set of fixed variable and register names, with no |
| support for user-defined variables. ARB programs provide no support |
| for fixed variable names; all variables must be declared, explicitly |
| or implicitly, in the program. |
| |
| - ARB programs support parameter variables that can be bound to selected |
| GL state variables, and are updated automatically when the underlying |
| state changes. NV programs provide no such support; applications must |
| set program parameters themselves. |
| |
| - ARB programs allow program constants to be declared in the program |
| text; NV programs require that constants be loaded into the program |
| parameter array. |
| |
| - ARB programs support program local parameters; NV programs do not. |
| Applications using multiple NV programs must manage the shared program |
| parameter array appropriately. |
| |
| - ARB_vertex_program vertex array support provides a normalized flag to |
| optionally normalize fixed-point array data to the [0,1] or [-1,1] |
| range. ARB_vertex_program also provides several immediate-mode entry |
| points with the same support. NV_vertex_program supports normalized |
| data only for unsigned byte data types, and does not support |
| non-normalized unsigned bytes. VertexAttrib4ub{v}NV was renamed to |
| VertexAttrib4Nub{v}ARB to indicate that the 4ub call normalizes its |
| parameters to a [0,1] range. |
| |
| - ARB_vertex_blend and ARB_matrix_palette support are documented by the |
| ARB spec, but not by the NV spec. |
| |
| - ARB_vertex_program contains an OPTION mechanism for future |
| extensibility, and a position invariant program option. Both features |
| are found in NV_vertex_program1_1, but not in NV_vertex_program. |
| |
| - NV_vertex_program supports a vertex state program target that allows |
| programs to write to program parameters (VERTEX_STATE_PROGRAM_NV). No |
| such support exists in ARB_vertex_program. Running a NV state program |
| will update the program parameter/program environment parameter array, |
| and such updates can be visible through ARB programs. |
| |
| - LoadProgramNV entry point was changed to ProgramStringARB to match |
| OpenGL convention that a verb should not be included in a command name |
| that merely sets state. |
| |
| - The formal parameter name for program objects was "id" in |
| NV_vertex_program; in ARB_vertex_program, this formal name is now |
| "program" to match how texture object routines name their formal |
| texture object names "texture". |
| |
| - NV_vertex_program has language that makes it sound that LoadProgramNV |
| (ProgramStringARB) only accepts the VERTEX_PROGRAM_NV target and the |
| start token must be "!!VP1.0". This extension clarifies the language |
| so that it is clear that other targets and start token types are |
| permitted. |
| |
| - NV_vertex_program numeric requirements are not present in the ARB |
| spec. The ARB spec requires nothing more than the numeric |
| requirements spelled out in section 2.1.1 (Floating-Point |
| Computations) in the core specification. |
| |
| - ARB programs allow single instructions to source multiple distinct |
| vertex attributes or program parameters. NV programs do not. On |
| current NV_vertex_program hardware, such instructions may require |
| additional instructions and temporaries to execute. |
| |
| - ARB programs support the folowing instructions not supported by NV |
| "VP1.0" programs: |
| |
| * ABS: absolute value. Supported on VP1.1 NV programs, but not |
| on VP1.0 programs. Equivalent to "MAX dst, src, -src". |
| |
| * EX2: exponential base 2. On VP1.0 and VP1.1 hardware, this |
| instruction will be emulated using EXP and a number of |
| additional instructions. |
| |
| * FLR: floor. On VP1.0 and VP1.1 hardware, this instruction will |
| be emulated using an EXP and an ADD instruction. |
| |
| * FRC: fraction. On VP1.0 and VP1.1 hardware, this instruction |
| will be emulated using an EXP instruction, and possibly a MOV |
| instruction to replicate the scalar result. |
| |
| * LG2: logarithm base 2. On VP1.0 and VP1.1 hardware, this |
| instruction will be emulated using LOG and a number of |
| additional instructions. |
| |
| * POW: exponentiation. On VP1.0 and VP1.1 hardware, this |
| instruction will be emulated using LOG, MUL, and EXP |
| instructions, and possibly additional instructions to generate a |
| high-precision result. |
| |
| * SUB: subtraction. Supported on VP1.1 NV programs, but not on |
| VP1.0 programs. Equivalent to "ADD dst, src1, -src2". |
| |
| * SWZ: extended swizzle. On VP1.0 and VP1.1 hardware, this |
| instruction will be emulated using a single MAD instruction and |
| a program parameter constant. |
| |
| * XPD: cross product. On VP1.0 and VP1.1 hardware, this |
| instruction will be emulated using a MUL and a MAD instruction. |
| |
| - The COLOR_SUM_EXT enable is ignored when NV programs are executed |
| (default secondary color outputs are zero) but not when ARB programs |
| are executed (default secondary color outputs are undefined). The |
| driver will take care of the color sum operation based on which type |
| of program is currently bound. |
| |
| - NV programs are required to write a vertex position; ARB programs are |
| not. |
| |
| - There is both an ARB and an NV boolean enable for each generic |
| array (two booleans per generic array). Each generic array's NV |
| enable is enabled with EnableClientState(VERTEX_ATTRIB_ARRAYn_NV) |
| or disabled with DisableClientState(VERTEX_ATTRIB_ARRAYn_NV) |
| while each generic array's ARB enable is enabled |
| with EnableVertexAttribArrayARB(n) and disabled with |
| DisableVertexAttribArrayARB(n). |
| |
| Enabling (or disabling) an ARB generic array enables (or disables) |
| BOTH the NV and ARB generic array booleans. |
| |
| However enabling (or disabling) the NV generic array enable |
| changes only the NV generic array enable (the ARB enable is |
| UNchanged). |
| |
| When an enabled valid current vertex program (whether specified |
| as an ARB or NV vertex program) is bound, the NV generic array |
| enables are considered (and the ARB enables are ignored). If a |
| given NV generic array enable is true, the corresponding generic |
| array state is applied. However if there is an enabled valid |
| vertex program and a particular NV generic array is disabled, then |
| the corresponding conventional aliased array state is applied. |
| |
| When the current vertex program is disabled or not valid (so |
| conventional vertex processing is performed), the ARB generic |
| array enables are considered (and the NV enables are ignored). |
| If a given ARB generic array enable is true, the corresponding |
| generic array state is applied. However if the current vertex |
| program is disabled or NOT valid and a particular ARB generic |
| array is disabled, then the corresponding conventional aliased |
| array state is applied. |
| |
| This behavior means generic vertex arrays can be applied to |
| conventional vertex processing when the ARB generic vertex array |
| enable boolean is true. For example, you can send normalized |
| UNSIGNED_SHORT texture coordinate set arrays as aliased generic |
| vertex arrays where conventionally UNSIGNED_SHORT texture |
| coordinate set arrays are unnormalized. |
| |
| NV_vertex_program interaction Issues: |
| |
| - Should matrix tracking support extend to ARB program environment |
| parameters? |
| |
| |
| Interactions with EXT_vertex_shader |
| |
| The existing EXT_vertex_shader extension, if supported, also provides a |
| similar vertex programming model. This extension is incompatible with |
| ARB_vertex_program in a number of different ways. Mixing the two models |
| in a single application is possible but not recommended. The interactions |
| between the extensions are defined below. |
| |
| First, it should be trivially noted that an EXT_vertex_shader "shader" |
| serves the same purpose as an ARB_vertex_program "program". The two terms |
| will be used interchangeably throughout this discussion. |
| |
| The most obvious difference between the two extensions is that the |
| definition of the vertex program is accomplished in EXT_vertex_shader |
| through the use of instruction-specifying procedure calls and is |
| accomplished in ARB_vertex_program by providing a textual string |
| describing the program. This is mostly a distinction of interface rather |
| than functionality. |
| |
| Each extension provides its own distinct set of GL state, entry points, |
| and enumerants. However, there are several areas of overlap both in |
| conceptual framework and in programming model that are worth noting for |
| those familiar with both API's. |
| |
| 1. Resource terminology and types |
| |
| Both ARB_vertex_program and EXT_vertex_shader offer access to similar |
| types of resources for use by vertex programs. |
| |
| The following terms describe roughly equivalent resources in their |
| respective extensions: |
| |
| EXT_vertex_shader ARB_vertex_program Note |
| ----------------- ------------------ ---- |
| instructions instructions |
| variants attributes |
| locals temporaries |
| local constants parameters bound to inline constants (a) |
| invariants parameters bound to GL state and (b) |
| program environment parameters |
| |
| a. ARB_vertex_program has no intrinsic storage type that corresponds |
| to EXT_vertex_shader's LOCAL_CONSTANT storage type, but rather |
| supports program parameters bound to inline constant vectors |
| specified within the program text. This essentially makes |
| LOCAL_CONSTANT a special case of an ARB_vertex_program program |
| parameter. The values of these inline constant parameters can not |
| be changed without redefining the program itself, just like the |
| values of EXT_vertex_shader LOCAL_CONSTANTs. |
| |
| b. ARB_vertex_program has no intrinsic storage type that corresponds |
| to EXT_vertex_shader's INVARIANT storage type, but rather supports |
| program parameters bound to GL state variables, program |
| environment parameters, and program local parameters. This |
| essentially makes INVARIANT a special case of an |
| ARB_vertex_program program parameter. The values of these bound |
| program parameters can be changed without redefining the program |
| itself, but remain constant from vertex to vertex during vertex |
| program execution, just like the values of EXT_vertex_shader |
| INVARIANTs. |
| |
| ARB_vertex_program also adds the concept of a program local parameter, |
| which has no direct analogue in EXT_vertex_shader, as it represents a |
| parameter that is stored locally with the program object, but the |
| values of these parameters can be changed without redefining the |
| program itself. |
| |
| 2. Resource usage queries |
| |
| Both ARB_vertex_program and EXT_vertex_shader provide queries to assist |
| in determining the resource usage of a given shader and whether the |
| shader would "fit" within the limits imposed by the underlying hardware |
| implementation. The application can investigate the maximum numbers of |
| shader resources supported by an implementation, shader resources |
| available in hardware, and resources consumed by a given shader after |
| being compiled into the implementation's native representation. |
| |
| In EXT_vertex_shader (see the end of section 2.14 of the |
| EXT_vertex_shader specification), the queries are handled by glGet. |
| |
| In ARB_vertex_programs (see section 2.14.3.7 of this specification), |
| similar queries are handled by GetProgramivARB, with a target of |
| VERTEX_PROGRAM_ARB. |
| |
| The following queries exist in both extensions and serve roughly |
| equivalent purposes in each: |
| |
| EXT_vertex_shader ARB_vertex_program |
| ----------------- ------------------ |
| MAX_VERTEX_SHADER_INSTRUCTIONS_EXT MAX_PROGRAM_INSTRUCTIONS_ARB |
| MAX_VERTEX_SHADER_VARIANTS_EXT MAX_PROGRAM_ATTRIBS_ARB |
| MAX_VERTEX_SHADER_LOCALS_EXT MAX_PROGRAM_TEMPORARIES_ARB |
| |
| MAX_OPTIMIZED_VERTEX_SHADER_INSTRUCTIONS_EXT MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB |
| MAX_OPTIMIZED_VERTEX_SHADER_VARIANTS_EXT MAX_PROGRAM_NATIVE_ATTRIBS_ARB |
| MAX_OPTIMIZED_VERTEX_SHADER_LOCALS_EXT MAX_PROGRAM_NATIVE_TEMPORARIES_ARB |
| |
| VERTEX_SHADER_INSTRUCTIONS_EXT PROGRAM_NATIVE_INSTRUCTIONS_ARB |
| VERTEX_SHADER_VARIANTS_EXT PROGRAM_NATIVE_ATTRIBS_ARB |
| VERTEX_SHADER_LOCALS_EXT PROGRAM_NATIVE_TEMPORARIES_ARB |
| |
| VERTEX_SHADER_OPTIMIZED_EXT PROGRAM_UNDER_NATIVE_LIMITS_ARB |
| |
| ARB_vertex_program offers additional queries to account for differences |
| in some of the resource definitions (program environment parameters and |
| program local parameters, address registers, etc.) as well as the |
| ability to separately query a compiled program's resource usage |
| according to the specification versus a possibly more efficient |
| resource usage obtained by passing the program through by a "smart" |
| compiler. |
| |
| The following queries do not exist in ARB_vertex_program due to the |
| slightly different resource models: |
| |
| EXT_vertex_shader ARB_vertex_program |
| ----------------- ------------------ |
| {MAX_}{OPTIMIZED_}VERTEX_SHADER_INVARIANTS_EXT (a) |
| {MAX_}{OPTIMIZED_}VERTEX_SHADER_LOCAL_CONSTANTS_EXT (a) |
| |
| a. ARB_vertex_program coalesces all of the different program |
| parameters (environment, local, inline constant, and those bound |
| to GL state) into a single queryable resource for |
| PROGRAM_PARAMETERS. EXT_vertex_shader provides separate queries |
| even though these parameters may consume the same resource on some |
| implementations. |
| |
| The following queries do not exist in EXT_vertex_shader due to the |
| slightly different resource models: |
| |
| EXT_vertex_shader ARB_vertex_program |
| ----------------- ------------------ |
| (b) PROGRAM_*_ARB |
| |
| (c) {MAX_}{NATIVE_}PROGRAM_PARAMETERS_ARB |
| |
| (d) {MAX_}{NATIVE_}PROGRAM_ADDRESS_REGISTERS_ARB |
| |
| b. These queries are used to find out how many resources a given |
| program used according to the specification, *before* running the |
| program through an optimizing compiler. This distinction is not |
| made in EXT_vertex_shader. |
| |
| c. These queries are used to find out how many parameters were used |
| by a program or are allowed by an implementation, in total without |
| distinguishing between environment parameters, program local |
| parameters, inline constant parameters, or parameters bound to GL |
| state. EXT_vertex_shader does not provide this information. |
| |
| d. EXT_vertex_shader does not provide have any address register |
| resources since all dynamic array references are handled with the |
| atomic OP_INDEX instruction. |
| |
| 3. Symbols and variable names |
| |
| In EXT_vertex_shader resources that represent storage locations |
| (i.e. INVARIANTS, VARIANTS, LOCALS, LOCAL_CONSTANTS) are abstractly |
| referenced through a GL-allocated symbol id obtained from |
| GenSymbolsEXT. This level of abstraction is provided to allow the |
| implementation to make hardware-dependent decisions about the best way |
| to arrange, allocate, and re-use hardware resources. |
| |
| Though ARB_vertex_program does not use symbol id's to refer to similar |
| types of resources, it does provide similar functionality by allowing a |
| vertex program to declare arbitrarily named variables for each resource |
| in use. These names are assigned using the declaration syntax |
| associated with the "PARAM", "ATTRIB", "TEMP", and "OUTPUT", and |
| "ADDRESS" keywords. |
| |
| 4. Program management |
| |
| With the exception of the actual program specification itself, |
| EXT_vertex_shader and ARB_vertex_program have very similar program |
| management API's. |
| |
| The following procedures serve roughly equivalent functions in their |
| respective extensions. |
| |
| EXT_vertex_shader ARB_vertex_program |
| ----------------- ------------------ |
| BindVertexShaderEXT BindProgramARB |
| GenVertexShadersEXT GenProgramsARB |
| DeleteVertexShaderEXT DeleteProgramsARB |
| |
| The following procedures are used in EXT_vertex_shader to define the |
| program instruction sequence, and are not present in ARB_vertex_program |
| since the string provided to ProgramStringARB fully defines the program |
| contents. |
| |
| ShaderOp1EXT |
| ShaderOp2EXT |
| ShaderOp3EXT |
| SwizzleEXT |
| WriteMaskEXT |
| InsertComponentEXT |
| ExtractComponentEXT |
| |
| 5. Data specification routines |
| |
| With the exception of the discrepancies in data types and resource |
| names described above, EXT_vertex_shader and ARB_vertex_program provide |
| similar program data specification and "current data query" API's. |
| |
| The following procedures serve roughly equivalent functions in their |
| respective extensions: |
| |
| EXT_vertex_shader ARB_vertex_program Note |
| ----------------- ------------------ ----- |
| SetInvariantEXT ProgramEnvParameter4*ARB (a) |
| GetInvariant*vEXT GetProgramEnvParameter*vARB (a) |
| Variant*vEXT VertexAttrib*ARB |
| VariantPointerEXT VertexAttribPointerARB |
| GetVariant*vEXT GetVertexAttrib*vARB |
| GetVariantPointervEXT GetVertexAttribPointervARB |
| EnableVariantClientStateEXT EnableVertexAttribArrayARB |
| DisableVariantClientStateEXT DisableVertexAttribArrayARB |
| IsVariantEnabledEXT GetVertexAttrib*vARB (b) |
| |
| a. See item #1 and #2 for more information on the relationship |
| between EXT_vertex_shader invariants and ARB_vertex_program |
| program parameters. |
| |
| b. The enabled state of an attribute array in ARB_vertex_program can |
| be queried with GetVertexAttrib*v and a parameter of |
| VERTEX_ATTRIB_ARRAY_ENABLED_ARB. In EXT_vertex_shader there is a |
| dedicated enabled query procedure. |
| |
| However, there are some data specification routines in |
| EXT_vertex_shader that have no procedure call analogue in |
| ARB_vertex_program as their functions are subsumed by the string |
| representation of the program itself. |
| |
| The following procedures in EXT_vertex_shader have functionality |
| roughly covered by the following strings within the program text in |
| ARB_vertex_shader: |
| |
| EXT_vertex_shader ARB_vertex_program Note |
| ----------------- ------------------ ----- |
| SetLocalConstantEXT PARAM C = {<x>,<y>,<z>,<w>}; (c) |
| |
| BindLightParameterEXT state.light[n].* |
| BindMaterialParameterEXT state.material.* (d) |
| BindTexGenParameterEXT state.texgen[n].* |
| |
| BindTextureUnitParameterEXT |
| CURRENT_TEXTURE_COORDS vertex.texcoord[n] |
| TEXTURE_MATRIX state.matrix.texture[n] |
| |
| BindParameterEXT |
| CURRENT_VERTEX_EXT vertex.position |
| CURRENT_NORMAL vertex.normal |
| CURRENT_COLOR vertex.color.* |
| MODELVIEW_MATRIX state.matrix.modelview[n] |
| PROJECTION_MATRIX state.matrix.projection |
| MVP_MATRIX_EXT state.matrix.mvp |
| COLOR_MATRIX <unavailable> (e) |
| CLIP_PLANE state.clip[n].plane |
| FOG_COLOR state.fog.color |
| FOG_DENSITY state.fog.params.x |
| FOG_START state.fog.params.y |
| FOG_END state.fog.params.z |
| LIGHT_MODEL_AMBIENT state.lightmodel.ambient |
| |
| c. Note that while EXT_vertex_shader style local constants can be |
| specified using inline constants in the program text, there is no |
| functionality in ARB_vertex_program that corresponds to the |
| GetLocalConstant*vEXT call. That is, program parameters bound to |
| inline constant vectors can be set in the text, but not queried |
| from the application. |
| |
| d. Note that while EXT_vertex_shader supports binding material |
| properties to variants, ARB_vertex_shader only supports binding |
| them to program parameters (invariants). See item #11 below for |
| more information. |
| |
| e. Note that while EXT_vertex_shader supports binding color matrix if |
| the ARB_imaging subset is supported, ARB_vertex_shader does not |
| allow for such a binding. See item #11 below for more information. |
| |
| 6. Data types |
| |
| EXT_vertex_shader supports data types of SCALAR, VECTOR, and MATRIX. |
| |
| ARB_vertex_program intrinsically supports only vectors, though it |
| allows for the definition of a matrix as a contiguous allocation of |
| four row vectors. Some operations that, in EXT_vertex_shader require |
| scalar inputs or scalar outputs, will, in ARB_vertex_program, use the |
| selected component of the source vector as input and/or replicate their |
| output to all components. |
| |
| Further, EXT_vertex_shader supports a pair of InsertComponents and |
| ExtractComponents functions that are not available (nor required) in |
| ARB_vertex_program, as they essentially provide for conversion between |
| the SCALAR, VECTOR, and MATRIX data types. |
| |
| 7. Input swizzles and output write-masks |
| |
| In EXT_vertex_shader, write masks are specified as a type of |
| "instruction", using WriteMaskEXT, while in ARB_vertex_program, write |
| masks are specified as modifiers to the destination resource with |
| writemask modifiers, such as ".xyz" or ".w". |
| |
| In EXT_vertex_shader, source operand swizzles (component re- ordering, |
| negation, and hard-coding to the value 0 and +/- 1.0) are also |
| specified as a type of "instruction", using SwizzleEXT. |
| |
| In ARB_vertex_program, swizzles can either be handled as instruction |
| ("SWZ") or as part of a modifier of the source argument to an |
| instruction. The only differences between the two methods is that the |
| source modifiers in ARB_vertex_program do not provide the ability to |
| use 0.0 and +/- 1.0, or negate individual components, while the "SWZ" |
| instruction does. |
| |
| 8. Support for clipping and user clip planes |
| |
| Both extensions provide similar support for traditional clipping to the |
| view frustum, namely that frustum clipping is not subsumed by vertex |
| shader, or vertex program execution. |
| |
| Additionally, EXT_vertex_shader supports user clip planes by |
| transforming the user clip planes from eye-space into clip space and |
| clipping in the clip space coordinate system. This is supported as long |
| as the projection matrix is non-singular. |
| |
| ARB_vertex_program provides similar functionality but only for programs |
| specified using the "position invariant" option. For more information on |
| user clip-plane support, see issue #20 and section 2.14.4.5.1 of this |
| specification. |
| |
| 9. Support for glRasterPos |
| |
| EXT_vertex_shader does not support transforming the current raster |
| position vertex by the current vertex shader, while ARB_vertex_program |
| does. |
| |
| 10. Relative addressing. |
| |
| The string based syntax of ARB_vertex_program supports a relative |
| addressing model where a given declared array can be dynamically |
| dereferenced by first loading a declared ADDRESS register, using the |
| "ARL" instruction with a value obtained at program execution then using |
| that named ADDRESS register as the index to dereference a declared array |
| of parameters later on. See section 2.14.3.5 of this specification for |
| details. |
| |
| For example, in ARB_vertex_program you can specify the following |
| piece of a program. |
| |
| PARAM arr[5] = { program.env[0..4] }; |
| ADDRESS addr; |
| ATTRIB v1 = vertex.attrib[1]; |
| ARL addr, v1; |
| MOV result, arr[addr.x + 1]; |
| |
| EXT_vertex_shader supports relative addressing as as a single atomic |
| operation through the use of the instruction OP_INDEX_EXT, as in |
| |
| ShaderOp2EXT(OP_INDEX_EXT, <res>, <arg1>, <arg2>). |
| |
| OP_INDEX_EXT supports relative addressing by taking the value stored in |
| the register referred to by <arg1> and adding that value to the register |
| number referred to by <arg2>, and loading <res> with the value stored in |
| the register at the resulting offset. EXT_vertex_shader has the |
| requirement that the register referred to by <arg2> is allocated as one |
| of a contiguous range of symbols obtained from a single call to |
| GenSymbolsEXT. |
| |
| To achieve the same functionality as the above ARB_vertex_program, using |
| EXT_vertex_shader, one could allocate a LOCAL symbol to hold a "fake" |
| address register, and do a similar type of dynamic dereference |
| operation, placing the output in a temporary LOCAL before giving it as |
| an source argument to the "real" instruction. |
| |
| arr_contiguousArraySymbol = |
| GenSymbolsEXT(GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 5); |
| |
| addr_fakeAddressRegSymbol = |
| GenSymbolsEXT(GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 1); |
| |
| v1_srcSymbolForARLOp = |
| GenSymbolsEXT(GL_VECTOR_EXT, GL_VARIANT_EXT, GL_FULL_RANGE_EXT, 1); |
| |
| temp = |
| GenSymbolsEXT(GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 1); |
| |
| result_ForMovOpSymbol = |
| GenSymbolsEXT(GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 1); |
| |
| // load fake ADDRESS register |
| ExtractComponentEXT( |
| addr_fakeAddressRegSymbol, |
| v1_srcSymbolForARLOp, |
| 0); |
| |
| // do dynamic dereference into a temp |
| ShaderOp2EXT( |
| GL_OP_INDEX_EXT, |
| temp, |
| addr_fakeAddressRegSymbol, |
| contiguousArraySymbol); |
| |
| // do operation we really wanted (MOV) using looked up src value |
| ShaderOp1EXT( |
| GL_OP_MOV_EXT, |
| result_ForMovOpSymbol, |
| temp, |
| (arr_contiguousArraySymbol + 1)); |
| |
| 11. Available GL state bindings |
| |
| Both EXT_vertex_shader and ARB_vertex_program offer the ability to bind |
| program resources to pieces of OpenGL state so that the values of |
| OpenGL state parameters are available to the program without the |
| application having to copy the state values manually into program |
| parameters. |
| |
| The two extensions differ in exactly which pieces of state are |
| available to a vertex program, with the main difference being that |
| ARB_vertex_program offers a more comprehensive set of state bindings. |
| |
| First, EXT_vertex_shader can bind pieces of GL state considered to be |
| "scalar" values to a single SCALAR symbol, whereas ARB_vertex_program, |
| which handles only vectors, packs up to 4 scalar bindings into a single |
| vector parameter. |
| |
| Similarly, EXT_vertex_shader can bind pieces of GL state considered to |
| be "matrix" values to a single MATRIX symbol, whereas |
| ARB_vertex_program supports bindings to matrix data by using up to four |
| vectors to store the rows of the matrix. |
| |
| Other differences between the state bindings available in both API's |
| are listed below: |
| |
| a. In EXT_vertex_shader, the light attenuation factors (CONSTANT, |
| LINEAR, QUADRATIC, and SPOT_EXPONENT), are available as separate |
| SCALAR bindings. |
| |
| In ARB_vertex_program, the light attenuation factors are all |
| packed into a single vector called state.light[n].attenuation with |
| the CONSTANT, LINEAR, QUADRATIC, and SPOT_EXPONENT factors in the |
| x,y,z, and w parameters respectively. |
| |
| b. In EXT_vertex_shader the spotlight direction (SPOT_DIRECTION) and |
| spot light cutoff angle (SPOT_CUTOFF), are available as separate |
| bindings. |
| |
| In ARB_vertex_program, these parameters are all packed into a |
| single vector called state.light[n].spot.direction with the with |
| the x,y,z parameters of the spotlight direction and the the |
| *cosine* of the cutoff angle in the x,y,z, and w parameters |
| respectively. |
| |
| c. In EXT_vertex_shader, the fog equation factors (FOG_DENSITY, |
| FOG_START, FOG_END), are avaiable as separate SCALAR bindings. |
| |
| In ARB_vertex_program, the fog equation factors are all packed |
| into a single vector called state.fog.params with the fog density, |
| linear start, linear end, and pre-computed 1.0/ (end-start) |
| factors in the x,y,z, and w parameters respectively. |
| |
| d. In EXT_vertex_shader, material properties can be bound to a |
| variant (i.e. "attribute" in ARB_vertex_program terminology) and |
| can change per vertex, and the changes take effect immediately. |
| |
| In ARB_vertex_program, material properties can only be bound to |
| program parameters, and any changes to material properties between |
| a Begin/End pair are not guaranteed to take effect until the |
| following End command. |
| |
| e. In EXT_vertex_shader, the material shininess property is bound to |
| a SCALAR variable. |
| |
| In ARB_vertex_program, the material shininess property is bound to |
| a vector with elements { s, 0.0, 0.0, 1.0 } where "s" is the |
| material shininess property. |
| |
| f. In EXT_vertex_shader, a program can bind to the current modelview, |
| projection, composite modelview-projection, color, and texture |
| matrices only in their entirety. |
| |
| In ARB_vertex_program, a program can bind to individual rows of |
| any matrix, with the exception of the color matrix, which is not |
| available in ARB_vertex_program. |
| |
| Additionally, ARB_vertex_program adds the ability to bind to |
| multiple modelview matrices, multiple palette matrices, and a set |
| of matrices dedicated for use with vertex programs called "program |
| matrices". Further, ARB_vertex_program offers the ability to bind |
| to the inverse, transpose, and inverse_transpose of any of the |
| matrices available for binding. |
| |
| If an application desires the functionality of binding to the |
| color matrix in ARB_vertex_program, that application can use one |
| of the other matrices, for instance program matrices, to store the |
| current color matrix. |
| |
| 12. Instruction set differences. |
| |
| In general, ARB_vertex_program's instruction set is a super-set of the |
| EXT_vertex_shader instructions that take VECTOR inputs and produce |
| VECTOR outputs. The versions of the EXT_vertex_shader instructions that |
| take non-vector (i.e. SCALAR or MATRIX) operands are almost all |
| available in vector form as well. |
| |
| The instructions from each set correspond as follows: |
| |
| EXT_vertex_shader ARB_vertex_program Note |
| ----------------- ------------------ ----- |
| OP_INDEX_EXT <unavailable> (a) |
| OP_NEGATE_EXT <unavailable> (b) |
| OP_DOT3_EXT "DP3" (c) |
| OP_DOT4_EXT "DP4" |
| OP_MUL_EXT "MUL" |
| OP_ADD_EXT "ADD" |
| OP_MADD_EXT "MAD" |
| OP_FRAC_EXT "FRC" |
| OP_MAX_EXT "MAX" |
| OP_MIN_EXT "MIN" |
| OP_SET_GE_EXT "SGE" |
| OP_SET_LT_EXT "SLT" |
| OP_CLAMP_EXT <unavailable> (d) |
| OP_FLOOR_EXT "FLR" |
| OP_ROUND_EXT <unavailable> (e) |
| OP_EXP_BASE_2_EXT "EX2" (f) |
| OP_LOG_BASE_2_EXT "LG2" (g) |
| OP_POWER_EXT "POW" (h) |
| OP_RECIP_EXT "RCP" (i) |
| OP_RECIP_SQRT_EXT "RSQ" (j) |
| OP_SUB_EXT "SUB" |
| OP_CROSS_PRODUCT_EXT "XPD" (k) |
| OP_MULTIPLY_MATRIX_EXT <unavailable> (l) |
| OP_MOV_EXT "MOV" |
| <unavailable> "ARL" (a) |
| <unavailable> "ABS" |
| <unavailable> "LIT" |
| <unavailable> "EXP" (f) |
| <unavailable> "LOG" (g) |
| <unavailable> "DPH" |
| <unavailable> "DST" |
| |
| There are a few minor differences, however. |
| |
| a. EXT_vertex_shader's OP_INDEX_EXT is not available in |
| ARB_vertex_program which uses the "ARL" instruction and array syntax |
| to handle dynamically dereferencing source data. See item #10 above |
| and the discussion of "ARL" in section 2.14.3.5. |
| |
| b. EXT_vertex_shader's OP_NEGATE_EXT is not available in |
| ARB_vertex_program. ARB_vertex_program can support a "NEGATE" |
| operation through the use of swizzle modifiers on source operands or |
| the "SWZ" instruction. |
| |
| MOV tempA, -tempB; |
| |
| or |
| |
| SWZ tempA, -tempB, x,y,z,w; |
| |
| c. The "w" component of EXT_vertex_shader's OP_DOT3_EXT instruction is |
| left unchanged. |
| |
| However, in ARB_vertex_program, the "w" component gets the same |
| result as the "x", "y", and "z" components. |
| |
| d. EXT_vertex_shader's OP_CLAMP_EXT is not available in |
| ARB_vertex_program. ARB_vertex_program can support a "CLAMP" |
| operation by using a pair of "MAX" and "MIN" instructions as in: |
| |
| # CLAMP arg1 to be within [arg2, arg3] |
| MAX temp, arg1, arg2; |
| MIN result, temp, arg3; |
| |
| e. EXT_vertex_shader's OP_ROUND_EXT is not available in |
| ARB_vertex_program. ARB_vertex_program can support a "ROUND" |
| operation by using a pair of "ADD" and "FLOOR" instructions as in: |
| |
| ADD temp, arg1, 0.5; |
| FLOOR result, temp; |
| |
| f. EXT_vertex_shader's OP_EXP_BASE_2_EXT is designed to support high |
| precision calculations of base-2 exponentiation. |
| |
| ARB_vertex_program's "EX2" is the equivalent function, however |
| ARB_vertex_program also offers an "EXP" function that is designed to |
| support a lower precision approximation of base-2 exponentiation |
| that can be further refined through an iterative process. |
| |
| On some implementations, both "EX2" and "EXP" may be carried out |
| with the same high precision at no cost relative to each other. As |
| such, if a vertex program is using "EXP" with the intent of |
| iteratively refining the approximation by using several successive |
| instructions it may be more efficient to use a single call to "EX2" |
| and get the high precision with a single instruction. |
| |
| If on the other hand, a single approximation is good enough, there |
| is no additional cost to using "EXP" on such implementations. |
| |
| Further note that in EXT_vertex_shader, OP_EXP_BASE_2_EXT is |
| specified to take a scalar operand, whereas ARB_vertex_program's |
| "EXP" and "EX2" instruction each take a vector operand, use the "x" |
| component, and then write (partial) results to all components of a |
| destination vector. |
| |
| g. EXT_vertex_shader's OP_LOG_BASE_2_EXT is designed to support high |
| precision calculations of base-2 logarithms. |
| |
| ARB_vertex_program's "LG2" is the equivalent function, however |
| ARB_vertex_program also offers an "LOG" function that is designed to |
| support a lower precision approximation of base-2 logarithms that |
| can be further refined through an iterative process. |
| |
| On some implementations, both "LG2" and "LOG" may be carried out |
| with the same high precision at no cost relative to each other. As |
| such, if a vertex program is using "LOG" with the intent of |
| iteratively refining the approximation by using several successive |
| instructions it may be more efficient to use a single call to "LG2" |
| and get the high precision with a single instruction. |
| |
| If on the other hand, a single approximation is good enough, there |
| is no additional cost to using "LOG" on such implementations. |
| |
| Further note that in EXT_vertex_shader, OP_LOG_BASE_2_EXT is |
| specified to take a scalar operand, whereas ARB_vertex_program's |
| "LOG" and "LOG2" instruction each take a vector operand, use the "x" |
| component, and then write (partial) results to all components of a |
| destination vector. |
| |
| h. EXT_vertex_shader's OP_POWER_EXT is designed to support high |
| precision calculations of the power function. |
| |
| ARB_vertex_program's "POW" is the equivalent function. |
| |
| Further note that in EXT_vertex_shader, OP_POWER_EXT is specified to |
| take a scalar operand, whereas ARB_vertex_program's "POW" |
| instruction takes a vector operand, uses the "x" component, and |
| replicates the same result to all components of a destination |
| vector. |
| |
| i. EXT_vertex_shader's OP_RECIP_EXT is specified to take a scalar |
| operand, whereas ARB_vertex_program's "RCP" instruction takes a |
| single component of a vector and replicates the same result to all |
| components of the destination vector. |
| |
| j. EXT_vertex_shader's OP_RECIP_SQRT_EXT is specified to take a scalar |
| operand, whereas ARB_vertex_program's "RSQ" instruction takes a |
| single component of a vector and replicates the same result to all |
| components of the destination vector. |
| |
| k. The "w" component of EXT_vertex_shader's OP_CROSS_PRODUCT_EXT |
| instruction is forced to 1.0; |
| |
| However, in ARB_vertex_program, the "w" component is left undefined |
| and "writes to the w component of the destination are treated as |
| disabled, regardless of the write mask specified in the XPD |
| instruction". |
| |
| l. EXT_vertex_shader's OP_MULTIPLY_MATRIX is not available in |
| ARB_vertex_program. ARB_vertex_program can support a "MATRIX |
| MULTIPLY" operation by using a series of "DP4" instructions as in: |
| |
| PARAM mat[4] = { state.matrix.modelview }; |
| DP4 result.x, vec, mat[0]; |
| DP4 result.y, vec, mat[1]; |
| DP4 result.z, vec, mat[2]; |
| DP4 result.w, vec, mat[3]; |
| |
| 13. Vertex provoking behavior |
| |
| EXT_vertex_shader does not provoke vertex shader execution when variant |
| 0 is specified (either using Variant*EXT, or variant |
| arrays). Applications are required to use the conventional Vertex* or |
| vertex arrays to provoke a vertex in both vertex shader mode and |
| conventional mode. Variant 0 is considered current state and is |
| queryable. |
| |
| Conversely, ARB_vertex_program does provoke vertex program execution |
| when attribute 0 is specified (either using VertexAttrib*vARB, or |
| attribute arrays) in both vertex program mode and conventional mode. |
| Attribute 0 is not considered current state and is not queryable. |
| |
| For implementations that support both extensions, this means that if |
| ARB_vertex_program is disabled, and EXT_vertex_shader is enabled, then |
| specifying ARB_vertex_program's attribute 0 will still provoke |
| execution of the currently bound EXT_vertex_shader defined shader. |
| |
| 14. Enabled state |
| |
| On implementations that support both EXT_vertex_shader, and |
| ARB_vertex_program, priority is given to ARB_vertex_program. That is to |
| say, if both are enabled, the implementation uses the program defined |
| by ARB_vertex_program and does not execute the currently bound |
| EXT_vertex_shader shader unless or until ARB_vertex_program is |
| subsequently disabled. Needless to say, it is not expected that a given |
| application will actually attempt to use both vertex program API's at |
| once. |
| |
| |
| GLX Protocol |
| |
| The following rendering commands are sent to the server as part of a |
| glXRender request: |
| |
| VertexAttrib1svARB |
| 2 12 rendering command length |
| 2 4189 rendering command opcode |
| 4 CARD32 index |
| 2 INT16 v[0] |
| 2 unused |
| |
| VertexAttrib1fvARB |
| 2 12 rendering command length |
| 2 4193 rendering command opcode |
| 4 CARD32 index |
| 4 FLOAT32 v[0] |
| |
| VertexAttrib1dvARB |
| 2 16 rendering command length |
| 2 4197 rendering command opcode |
| 4 CARD32 index |
| 8 FLOAT64 v[0] |
| |
| VertexAttrib2svARB |
| 2 12 rendering command length |
| 2 4190 rendering command opcode |
| 4 CARD32 index |
| 2 INT16 v[0] |
| 2 INT16 v[1] |
| |
| VertexAttrib2fvARB |
| 2 16 rendering command length |
| 2 4194 rendering command opcode |
| 4 CARD32 index |
| 4 FLOAT32 v[0] |
| 4 FLOAT32 v[1] |
| |
| VertexAttrib2dvARB |
| 2 24 rendering command length |
| 2 4198 rendering command opcode |
| 4 CARD32 index |
| 8 FLOAT64 v[0] |
| 8 FLOAT64 v[1] |
| |
| VertexAttrib3svARB |
| 2 16 rendering command length |
| 2 4191 rendering command opcode |
| 4 CARD32 index |
| 2 INT16 v[0] |
| 2 INT16 v[1] |
| 2 INT16 v[2] |
| 2 unused |
| |
| VertexAttrib3fvARB |
| 2 20 rendering command length |
| 2 4195 rendering command opcode |
| 4 CARD32 index |
| 4 FLOAT32 v[0] |
| 4 FLOAT32 v[1] |
| 4 FLOAT32 v[2] |
| |
| VertexAttrib3dvARB |
| 2 32 rendering command length |
| 2 4199 rendering command opcode |
| 4 CARD32 index |
| 8 FLOAT64 v[0] |
| 8 FLOAT64 v[1] |
| 8 FLOAT64 v[2] |
| |
| VertexAttrib4bvARB |
| 2 12 rendering command length |
| 2 4230 rendering command opcode |
| 4 CARD32 index |
| 1 INT8 v[0] |
| 1 INT8 v[1] |
| 1 INT8 v[2] |
| 1 INT8 v[3] |
| |
| VertexAttrib4svARB |
| 2 16 rendering command length |
| 2 4192 rendering command opcode |
| 4 CARD32 index |
| 2 INT16 v[0] |
| 2 INT16 v[1] |
| 2 INT16 v[2] |
| 2 INT16 v[3] |
| |
| VertexAttrib4ivARB |
| 2 24 rendering command length |
| 2 4231 rendering command opcode |
| 4 CARD32 index |
| 4 INT32 v[0] |
| 4 INT32 v[1] |
| 4 INT32 v[2] |
| 4 INT32 v[3] |
| |
| VertexAttrib4ubvARB |
| 2 12 rendering command length |
| 2 4232 rendering command opcode |
| 4 CARD32 index |
| 1 CARD8 v[0] |
| 1 CARD8 v[1] |
| 1 CARD8 v[2] |
| 1 CARD8 v[3] |
| |
| VertexAttrib4usvARB |
| 2 16 rendering command length |
| 2 4233 rendering command opcode |
| 4 CARD32 index |
| 2 CARD16 v[0] |
| 2 CARD16 v[1] |
| 2 CARD16 v[2] |
| 2 CARD16 v[3] |
| |
| VertexAttrib4uivARB |
| 2 24 rendering command length |
| 2 4234 rendering command opcode |
| 4 CARD32 index |
| 4 CARD32 v[0] |
| 4 CARD32 v[1] |
| 4 CARD32 v[2] |
| 4 CARD32 v[3] |
| |
| VertexAttrib4fvARB |
| 2 24 rendering command length |
| 2 4196 rendering command opcode |
| 4 CARD32 index |
| 4 FLOAT32 v[0] |
| 4 FLOAT32 v[1] |
| 4 FLOAT32 v[2] |
| 4 FLOAT32 v[3] |
| |
| VertexAttrib4dvARB |
| 2 40 rendering command length |
| 2 4200 rendering command opcode |
| 4 CARD32 index |
| 8 FLOAT64 v[0] |
| 8 FLOAT64 v[1] |
| 8 FLOAT64 v[2] |
| 8 FLOAT64 v[3] |
| |
| VertexAttrib4NbvARB |
| 2 12 rendering command length |
| 2 4235 rendering command opcode |
| 4 CARD32 index |
| 1 INT8 v[0] |
| 1 INT8 v[1] |
| 1 INT8 v[2] |
| 1 INT8 v[3] |
| |
| VertexAttrib4NsvARB |
| 2 16 rendering command length |
| 2 4236 rendering command opcode |
| 4 CARD32 index |
| 2 INT16 v[0] |
| 2 INT16 v[1] |
| 2 INT16 v[2] |
| 2 INT16 v[3] |
| |
| VertexAttrib4NivARB |
| 2 24 rendering command length |
| 2 4237 rendering command opcode |
| 4 CARD32 index |
| 4 INT32 v[0] |
| 4 INT32 v[1] |
| 4 INT32 v[2] |
| 4 INT32 v[3] |
| |
| VertexAttrib4NubvARB |
| 2 12 rendering command length |
| 2 4201 rendering command opcode |
| 4 CARD32 index |
| 1 CARD8 v[0] |
| 1 CARD8 v[1] |
| 1 CARD8 v[2] |
| 1 CARD8 v[3] |
| |
| VertexAttrib4NusvARB |
| 2 16 rendering command length |
| 2 4238 rendering command opcode |
| 4 CARD32 index |
| 2 CARD16 v[0] |
| 2 CARD16 v[1] |
| 2 CARD16 v[2] |
| 2 CARD16 v[3] |
| |
| VertexAttrib4NuivARB |
| 2 24 rendering command length |
| 2 4239 rendering command opcode |
| 4 CARD32 index |
| 4 CARD32 v[0] |
| 4 CARD32 v[1] |
| 4 CARD32 v[2] |
| 4 CARD32 v[3] |
| |
| BindProgramARB |
| 2 12 rendering command length |
| 2 4180 rendering command opcode |
| 4 ENUM target |
| 4 CARD32 program |
| |
| ProgramEnvParameter4fvARB |
| 2 32 rendering command length |
| 2 4184 rendering command opcode |
| 4 ENUM target |
| 4 CARD32 index |
| 4 FLOAT32 params[0] |
| 4 FLOAT32 params[1] |
| 4 FLOAT32 params[2] |
| 4 FLOAT32 params[3] |
| |
| ProgramEnvParameter4dvARB |
| 2 44 rendering command length |
| 2 4185 rendering command opcode |
| 4 ENUM target |
| 4 CARD32 index |
| 8 FLOAT64 params[0] |
| 8 FLOAT64 params[1] |
| 8 FLOAT64 params[2] |
| 8 FLOAT64 params[3] |
| |
| ProgramLocalParameter4fvARB |
| 2 32 rendering command length |
| 2 4215 rendering command opcode |
| 4 ENUM target |
| 4 CARD32 index |
| 4 FLOAT32 params[0] |
| 4 FLOAT32 params[1] |
| 4 FLOAT32 params[2] |
| 4 FLOAT32 params[3] |
| |
| ProgramLocalParameter4dvARB |
| 2 44 rendering command length |
| 2 4216 rendering command opcode |
| 4 ENUM target |
| 4 CARD32 index |
| 8 FLOAT64 params[0] |
| 8 FLOAT64 params[1] |
| 8 FLOAT64 params[2] |
| 8 FLOAT64 params[3] |
| |
| The ProgramStringARB is potentially large, and hence can be sent in a |
| glXRender or glXRenderLarge request. |
| |
| ProgramStringARB |
| 2 16+len+p rendering command length |
| 2 4217 rendering command opcode |
| 4 ENUM target |
| 4 ENUM format |
| 4 sizei len |
| len LISTofBYTE program |
| p unused, p=pad(len) |
| |
| If the command is encoded in a glxRenderLarge request, the command |
| opcode and command length fields above are expanded to 4 bytes each: |
| |
| 4 16+len+p rendering command length |
| 4 4217 rendering command opcode |
| |
| VertexAttribPointerARB, EnableVertexAttribArrayARB, and |
| DisableVertexAttribArrayARB are entirely client-side commands. |
| |
| The remaining commands are non-rendering commands. These commands are |
| sent separately (i.e., not as part of a glXRender or glXRenderLarge |
| request), using the glXVendorPrivateWithReply request: |
| |
| DeleteProgramsARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 4+n request length |
| 4 1294 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 n |
| n*4 LISTofCARD32 programs |
| |
| GenProgramsARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 4 request length |
| 4 1295 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 n |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 n reply length |
| 24 unused |
| n*4 LISTofCARD322 programs |
| |
| GetProgramEnvParameterfvARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 6 request length |
| 4 1296 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 CARD32 index |
| 4 unused |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n (number of parameter components) |
| |
| if (n=1) this follows: |
| |
| 4 FLOAT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofFLOAT32 params |
| |
| GetProgramEnvParameterdvARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 6 request length |
| 4 1297 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 CARD32 index |
| 4 unused |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n*2) |
| 4 unused |
| 4 CARD32 n (number of parameter components) |
| |
| if (n=1) this follows: |
| |
| 8 FLOAT64 params |
| 8 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*8 LISTofFLOAT64 params |
| |
| GetProgramLocalParameterfvARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 6 request length |
| 4 1305 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 CARD32 index |
| 4 unused |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n (number of parameter components) |
| |
| if (n=1) this follows: |
| |
| 4 FLOAT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofFLOAT32 params |
| |
| GetProgramLocalParameterdvARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 6 request length |
| 4 1306 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 CARD32 index |
| 4 unused |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n*2) |
| 4 unused |
| 4 CARD32 n (number of parameter components) |
| |
| if (n=1) this follows: |
| |
| 8 FLOAT64 params |
| 8 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*8 LISTofFLOAT64 params |
| |
| GetProgramivARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 1307 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 INT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofINT32 params |
| |
| GetProgramStringARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 1308 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 ENUM target |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 (n+p)/4 reply length |
| 4 unused |
| 4 CARD32 n |
| 16 unused |
| n STRING program |
| p unused, p=pad(n) |
| |
| Note that VERTEX_ATTRIB_ARRAY_ENABLED_ARB, |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB, VERTEX_ATTRIB_ARRAY_STRIDE_ARB, |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB, and VERTEX_ATTRIB_ARRAY_NORMALIZED_ARB |
| may be queried by GetVertexAttrib[dfi]ARB, but generate no protocol |
| and return client-side state. |
| |
| GetVertexAttribdvARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 1301 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 index |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n*2) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 8 FLOAT64 params |
| 8 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*8 LISTofFLOAT64 params |
| |
| GetVertexAttribfvARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 1302 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 index |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 FLOAT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofFLOAT32 params |
| |
| GetVertexAttribivARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 5 request length |
| 4 1303 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 index |
| 4 ENUM pname |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 m reply length, m=(n==1?0:n) |
| 4 unused |
| 4 CARD32 n |
| |
| if (n=1) this follows: |
| |
| 4 INT32 params |
| 12 unused |
| |
| otherwise this follows: |
| |
| 16 unused |
| n*4 LISTofINT32 params |
| |
| IsProgramARB |
| 1 CARD8 opcode (X assigned) |
| 1 17 GLX opcode (glXVendorPrivateWithReply) |
| 2 4 request length |
| 4 1304 vendor specific opcode |
| 4 GLX_CONTEXT_TAG context tag |
| 4 INT32 n |
| => |
| 1 1 reply |
| 1 unused |
| 2 CARD16 sequence number |
| 4 0 reply length |
| 4 BOOL32 return value |
| 20 unused |
| |
| When transferring vertex attribute array elements, there may not be a |
| protocol encoding that exactly matches the combination of combination of |
| size, normalization enable, and data type in the array. If no match |
| protocol encoding exists, the encoding for the corresponding 4-component |
| attribute is used. v[1] and v[2] are set to zero if not specified in the |
| vertex array. If v[3] is not specified in the vertex array, it is set to |
| 0x7F, 0x7FFF, 0x7FFFFFFF, 0xFF, 0xFFFF, or 0xFFFFFFFF for the |
| VertexAttrib4NbvARB, VertexAttrib4NsvARB, VertexAttrib4NivARB, |
| VertexAttrib4NubvARB, VertexAttrib4NusvARB, and VertexAttrib4NuivARB |
| protocol encodings, respectively. v[3] is set to one if it is not |
| specified in the vertex array for the the VertexAttrib4bvARB, |
| VertexAttrib4svARB, VertexAttrib4ivARB, VertexAttrib4ubvARB, |
| VertexAttrib4usvARB, and VertexAttrib4uivARB protocol encodings. |
| |
| |
| Errors |
| |
| The error INVALID_VALUE is generated by any VertexAttrib*ARB or |
| GetVertexAttrib*ARB command if <index> is greater than or equal to |
| MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_VALUE is generated by VertexAttribPointerARB or |
| GetVertexAttribPointervARB if <index> is greater than or equal to |
| MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_VALUE is generated by VertexAttribPointerARB if <size> |
| is not one of 1, 2, 3, or 4. |
| |
| The error INVALID_VALUE is generated by VertexAttribPointerARB if <stride> |
| is negative. |
| |
| The error INVALID_VALUE is generated by EnableVertexAttribArrayARB or |
| DisableVertexAttribArrayARB if <index> is greater than or equal to |
| MAX_VERTEX_ATTRIBS_ARB. |
| |
| The error INVALID_OPERATION is generated by ProgramStringARB if the |
| program string <string> is syntactically incorrect or violates any |
| semantic restriction of the execution environment of the specified program |
| target <target>. |
| |
| The error INVALID_OPERATION is generated by BindProgramARB if <program> is |
| the name of a program whose target does not match <target>. |
| |
| The error INVALID_VALUE is generated by any ProgramEnvParameter*ARB or |
| GetProgramEnvParameter*ARB command if <index> is greater than or equal to |
| the value of MAX_PROGRAM_ENV_PARAMETERS_ARB corresponding to the program |
| target <target>. |
| |
| The error INVALID_VALUE is generated by any ProgramLocalParameter*ARB or |
| GetProgramLocalParameter*ARB command if <index> is greater than or equal |
| to the value of MAX_PROGRAM_LOCAL_PARAMETERS_ARB corresponding to the |
| program target <target>. |
| |
| The error INVALID_OPERATION is generated if Begin, RasterPos, or any |
| command that performs an explicit Begin is called when vertex program mode |
| is enabled and the currently bound vertex program object does not contain |
| a valid vertex program. |
| |
| The error INVALID_OPERATION is generated by GetVertexAttrib*ARB if <index> |
| is zero and <pname> is CURRENT_VERTEX_ATTRIB_ARB. |
| |
| |
| New State |
| |
| |
| Get Value Type Get Command Initial Value Description Section Attribute |
| ------------------------------- ------ ------------- ------------- ------------------ ------------ ------------ |
| VERTEX_PROGRAM_ARB B IsEnabled False vertex program 2.10 enable |
| enable |
| VERTEX_PROGRAM_POINT_SIZE_ARB B IsEnabled False program-specified 2.14.3.7 enable |
| point size mode |
| VERTEX_PROGRAM_TWO_SIDE_ARB B IsEnabled False two-sided color 2.14.3.7 enable |
| mode |
| - 96+xR4 GetProgramEnv- (0,0,0,0) program environment 2.14.1 - |
| ParameterARB parameters |
| CURRENT_VERTEX_ATTRIB_ARB 16+xR4 GetVertex- undefined generic vertex 2.7 current |
| AttribARB attributes |
| PROGRAM_ERROR_POSITION_ARB Z GetIntegerv -1 last program error 2.14.1 - |
| position |
| PROGRAM_ERROR_STRING_ARB 0+xub GetString "" last program error 2.14.1 - |
| string |
| |
| Table X.6. New Accessible State Introduced by ARB_vertex_program. |
| |
| |
| Get Value Type Get Command Initial Value Description Section Attribute |
| ------------------------------- ------ ------------- ------------- ------------------ ------------ ------------ |
| VERTEX_ATTRIB_ARRAY_ENABLED_ARB 16+xB GetVertex- False vertex attrib 2.8 vertex-array |
| AttribARB array enable |
| VERTEX_ATTRIB_ARRAY_SIZE_ARB 16+xZ GetVertex- 4 vertex attrib 2.8 vertex-array |
| AttribARB array size |
| VERTEX_ATTRIB_ARRAY_STRIDE_ARB 16+xZ+ GetVertex- 0 vertex attrib 2.8 vertex-array |
| AttribARB array stride |
| VERTEX_ATTRIB_ARRAY_TYPE_ARB 16+xZ4 GetVertex- FLOAT vertex attrib 2.8 vertex-array |
| AttribARB array type |
| VERTEX_ATTRIB_ARRAY_ 16+xB GetVertex- False vertex attrib 2.8 vertex-array |
| NORMALIZED_ARB AttribARB array normalized |
| VERTEX_ATTRIB_ARRAY_POINTER_ARB 16+xP GetVertex- NULL vertex attrib 2.8 vertex-array |
| AttribPointerARB array pointer |
| |
| Table X.7. New Accessible Client State Introduced by ARB_vertex_program. |
| |
| |
| Get Value Type Get Command Initial Value Description Sec Attrib |
| -------------------- ----- ------------------- --------------- ---------------------- -------- ------ |
| PROGRAM_BINDING_ARB Z+ GetProgramivARB object-specific bound program name 6.1.12 - |
| PROGRAM_LENGTH_ARB Z+ GetProgramivARB 0 bound program length 6.1.12 - |
| PROGRAM_FORMAT_ARB Z1 GetProgramivARB PROGRAM_FORMAT_ bound program format 6.1.12 - |
| ASCII_ARB |
| PROGRAM_STRING_ARB ubxn GetProgramStringARB (empty) bound program string 6.1.12 - |
| PROGRAM_INSTRUCTIONS_ARB Z+ GetProgramivARB 0 bound program 6.1.12 - |
| instructions |
| PROGRAM_TEMPORARIES_ARB Z+ GetProgramivARB 0 bound program 6.1.12 - |
| temporaries |
| PROGRAM_PARAMETERS_ARB Z+ GetProgramivARB 0 bound program 6.1.12 - |
| parameter bindings |
| PROGRAM_ATTRIBS_ARB Z+ GetProgramivARB 0 bound program 6.1.12 - |
| attribute bindings |
| PROGRAM_ADDRESS_REGISTERS_ARB Z+ GetProgramivARB 0 bound program 6.1.12 - |
| address registers |
| PROGRAM_NATIVE_INSTRUCTIONS_ARB Z+ GetProgramivARB 0 bound program native 6.1.12 - |
| instructions |
| PROGRAM_NATIVE_TEMPORARIES_ARB Z+ GetProgramivARB 0 bound program native 6.1.12 - |
| temporaries |
| PROGRAM_NATIVE_PARAMETERS_ARB Z+ GetProgramivARB 0 bound program native 6.1.12 - |
| parameter bindings |
| PROGRAM_NATIVE_ATTRIBS_ARB Z+ GetProgramivARB 0 bound program native 6.1.12 - |
| attribute bindings |
| PROGRAM_NATIVE_ADDRESS_ Z+ GetProgramivARB 0 bound program native 6.1.12 - |
| REGISTERS_ARB address registers |
| PROGRAM_UNDER_NATIVE_LIMITS_ARB B GetProgramivARB 0 bound program under 6.1.12 - |
| native resource limits |
| - 96+xR4 GetProgramLocal- (0,0,0,0) bound program local 2.14.1 - |
| ParameterARB parameter value |
| |
| Table X.8. Program Object State. Program object queries return attributes of |
| the program object currently bound to the program target <target>. |
| |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| --------- ------ ----------- ------------- ----------------------- -------- --------- |
| - 12+xR4 - undefined temporary registers 2.14.3.6 - |
| - 8+xR4 - undefined vertex result registers 2.14.3.7 - |
| 1+xZ1 - undefined vertex program 2.14.3.8 - |
| address registers |
| |
| Table X.9. Vertex Program Per-vertex Execution State. All per-vertex |
| execution state registers are uninitialized at the beginning of program |
| execution. |
| |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| ------------------------------ -------- -------------- ------------- ------------------- ------- --------- |
| CURRENT_MATRIX_ARB m*n*xM^4 GetFloatv Identity current matrix 6.1.2 - |
| CURRENT_MATRIX_STACK_DEPTH_ARB m*Z+ GetIntegerv 1 current stack depth 6.1.2 - |
| |
| Table X.10. Current matrix state where m is the total number of matrices |
| including texture matrices and program matrices and n is the number of |
| matrices on each particular matrix stack. Note that this state is aliased |
| with existing matrix state. |
| |
| |
| New Implementation Dependent State |
| Minimum |
| Get Value Type Get Command Value Description Sec Attrib |
| ----------------------------------- ---- --------------- ---------- -------------------- ------------ ------ |
| MAX_PROGRAM_ENV_PARAMETERS_ARB Z+ GetProgramivARB 96 maximum program 2.14.1 - |
| env parameters |
| MAX_PROGRAM_LOCAL_PARAMETERS_ARB Z+ GetProgramivARB 96 maximum program 2.14.1 - |
| local parameters |
| MAX_PROGRAM_MATRICES_ARB Z+ GetIntegerv 8 (not to maximum number of 2.14.6 - |
| exceed 32) program matrices |
| MAX_PROGRAM_MATRIX_STACK_DEPTH_ARB Z+ GetIntegerv 1 maximum program 2.14.6 - |
| matrix stack depth |
| MAX_PROGRAM_INSTRUCTIONS_ARB Z+ GetProgramivARB 128 maximum program 6.1.12 - |
| instructions |
| MAX_PROGRAM_TEMPORARIES_ARB Z+ GetProgramivARB 12 maximum program 6.1.12 - |
| temporaries |
| MAX_PROGRAM_PARAMETERS_ARB Z+ GetProgramivARB 96 maximum program 6.1.12 - |
| parameter bindings |
| MAX_PROGRAM_ATTRIBS_ARB Z+ GetProgramivARB 16 maximum program 6.1.12 - |
| attribute bindings |
| MAX_PROGRAM_ADDRESS_REGISTERS_ARB Z+ GetProgramivARB 1 maximum program 6.1.12 - |
| address registers |
| MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB Z+ GetProgramivARB - maximum program native 6.1.12 - |
| instructions |
| MAX_PROGRAM_NATIVE_TEMPORARIES_ARB Z+ GetProgramivARB - maximum program native 6.1.12 - |
| temporaries |
| MAX_PROGRAM_NATIVE_PARAMETERS_ARB Z+ GetProgramivARB - maximum program native 6.1.12 - |
| parameter bindings |
| MAX_PROGRAM_NATIVE_ATTRIBS_ARB Z+ GetProgramivARB - maximum program native 6.1.12 - |
| attribute bindings |
| MAX_PROGRAM_NATIVE_ADDRESS_ Z+ GetProgramivARB - maximum program native 6.1.12 - |
| REGISTERS_ARB address registers |
| |
| Table X.11. New Implementation-Dependent Values Introduced by |
| ARB_vertex_program. Values queried by GetProgramivARB require a <pname> of |
| VERTEX_PROGRAM_ARB. |
| |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- -------------------------------------------- |
| 46 07/25/07 mjk Document how the ARB and NV generic arrays |
| interact. This documents NVIDIA's |
| long-standing implemented behavior. |
| |
| 45 09/27/04 pbrown Fixed GLX protocol, removing the unused <pname> |
| parameters for GetProgram{Env,Local}Parameter |
| [df]vARB, leaving an unused CARD32 in its place. |
| This was an error when propogating |
| NV_vertex_program protocol, which did have a |
| <pname> parameter. |
| |
| 44 09/12/03 pbrown Fixed opcode table entry for "ARL" -- it takes a |
| scalar operand as specified in the grammar. |
| |
| 43 08/17/03 pbrown Fixed a couple minor typos (missing quotes) |
| in the grammar. |
| |
| 42 05/01/03 pbrown Clarified the handling of color sum; old text |
| suggested that COLOR_SUM controlled the |
| operation even when doing separate specular |
| lighting. |
| |
| 41 04/18/03 pbrown Add a couple overlooked contributors. |
| |
| 40 03/03/03 pbrown Fixed list of immediate-mode VertexAttrib |
| functions in Section 2.7 -- there are no |
| normalized float functions (e.g., |
| VertexAttrib4Nfv). Clarified issue (42) |
| describing how point size is handled in vertex |
| program mode. |
| |
| 39 01/31/03 pbrown Fixed minor bug in the description of vertex |
| array state kept by the GL -- normalization |
| flags were omitted from the text (but were in |
| the state tables). |
| |
| 38 01/08/03 pbrown Fixed bug where "state.matrix.mvp" was specified |
| incorrectly -- it should be P*M0 rather than |
| M0*P. |
| |
| 37 12/23/02 pbrown Fixed minor typos. Fixed state table bug where |
| CURRENT_VERTEX_ATTRIB_ARB was incorrectly called |
| CURRENT_ATTRIB_ARB. |
| |
| 36 09/09/02 pbrown Fixed incorrect example of matrix row bindings |
| (and transposition). Small wording/typo fixes. |
| |
| 35 08/27/02 pbrown Fixed several minor typos. Documented that a |
| program string should not include a null |
| terminator in its first <len> characters. Fixed |
| dangling reference in <paramMultipleItem> |
| grammar rule. Fix incorrect wording in |
| computation of state.light.half vector. |
| Documented that the inverse of a singular matrix |
| is undefined. Clarified that native |
| instructions can include additions due to |
| emulation of features not supported natively. |
| Documented that LG2 produces undefined results |
| with zero or negative inputs. Clarified that |
| POW may be a LOG/MUL/EXP sequence, but isn't |
| necessarily so. Disallowed multiple modelview |
| matrix syntax if ARB_vertex_blend or |
| EXT_vertex_weighting is unsupported. Fixed |
| state table query function for attribute array |
| enables. Added missing state table entry for |
| PROGRAM_UNDER_NATIVE_LIMITS_ARB. |
| |
| 34 07/19/02 pbrown Fixed typo in ArrayElement pseudo-code. |
| |
| 33 07/17/02 pbrown Fixed bug in the <stateLModProperty> grammar |
| rule. Fixed documentation to indicate that |
| Enable/DisableVertexAttribArray are not display |
| listable. |
| |
| 31 07/15/02 pbrown Fixed <SWZ_instruction> grammar rule to match |
| the spec language -- base operand negation |
| doesn't apply, since you can independently |
| negate components. Modified "XPD" instruction |
| to eliminate the implicit masking of the "w" |
| component; slight efficiency gain for some SW |
| implementations. Modified "scenecolor" binding |
| to pass the diffuse alpha instead of the ambient |
| alpha; the former is more useful. |
| |
| 30 07/02/02 pbrown Minor wording fixes. |
| |
| 29 06/21/02 pbrown Mostly minor bug fixes from reviewer feedback; |
| also added one new item approved at ARB meeting. |
| |
| Additions: Added a "lightmodel.*.scenecolor" |
| holding lit color containing the composite |
| lighting result ignoring individual lights -- |
| i.e., from only emissive materials and the light |
| model. Added GLX protocol. |
| |
| Minor changes: Numerous minor typo and wording |
| fixes. Added missing vertex array types to |
| vertex array size/type/normalized table. Added |
| missing description of ambient light model color |
| binding. Removed several references to language |
| features long since deleted. Documented that |
| POW is not necessarily implemented as |
| LOG/MUL/EXP. Fixed a couple minor errata in the |
| EXT_vertex_shader interaction section. Added a |
| list of reserved keywords. |
| |
| 28 06/16/02 pbrown Minor updates based on feedback given on |
| versions 26 and 27. |
| |
| Additions: Added section on EXT_vertex_shader |
| interaction, provided by ATI. |
| |
| Minor changes: Minor grammar and readability |
| fixes. Fixed several incomplete definitions. |
| Removed "GL" and "gl" prefixes from several |
| enumerants and function names to match spec |
| conventions. Clarified the precision issue on |
| EX2/LG2. Added missing functions that take |
| VERTEX_PROGRAM_ARB. Clarified component |
| normalization on vertex arrays. Clarified |
| clipping section to note that user clipping is |
| done with position invariant programs. |
| Clarified the handling of program zero in |
| BindProgramARB. Fixed a couple incorrect |
| grammar rules. Fixed incorrect grammar |
| references in description of vertex program |
| parameter array accesses. Documented that the |
| SWZ instruction doesn't take "normal" swizzle |
| and negation modifiers, since it already has |
| some. Clarified some NV_vertex_program |
| interactions. |
| |
| 27 06/07/02 pbrown Minor update based on ARB_vertex_program sample |
| implementation work. |
| |
| Changes: Changed fog coordinate attribute and |
| result binding name to "fogcoord" (was "fog"). |
| Rearranged grammar based on sample |
| implementation verification. There might be a |
| minor fix or two stuck in there. |
| |
| 26 06/04/02 pbrown Spec checkpoint published on the working group |
| web site. Resolves most of the remaining open |
| issues. |
| |
| Deletions: Removed the ability to bind the |
| color matrix (from ARB_imaging). |
| |
| Changes: Resolved the handling of vertex |
| attribute zero (it always specifies a vertex, in |
| program mode or not). Resolved the handling of |
| generic and conventional vertex attribute arrays |
| (they are always sent, although they also have |
| "undefined aliasing" behavior). Default values |
| of generic attributes are undefined, to |
| accommodate aliasing and non-aliasing |
| implementations. Added pseudocode to document |
| the processing of ArrayElement. Moved program |
| object language into the vertex program section. |
| Renamed the fog coordinate attribute and result |
| binding to "fogcoord". Added missing |
| documentation of the agreed-upon semantic |
| restriction that programs can't bind |
| conventional / generic attribute pairs that may |
| alias. Added documentation of what happens when |
| multiple contexts share program objects |
| Disallowed queries of generic attribute zero. |
| |
| Fixes: Fixed prototype for VertexAttrib4Nub. |
| |
| Minor Changes: Minor typo and language |
| fixes. Added guidelines for future |
| programmability extensions. Added several |
| missing grammar rules. |
| |
| 25 05/30/02 pbrown Spec checkpoint published on the working group |
| web site. |
| |
| Additions: Add "DPH" (dot product homogeneous) |
| instruction. Added the ability to query the |
| current matrix in transposed form. Assigned |
| enumerant values for program matrices. Added |
| the ability bind selected rows of a matrix. |
| Added ability to bind matrix palette matrices. |
| |
| Changes: Renamed PROGRAM_NAME_ARB to |
| PROGRAM_BINDING_ARB. Specifying the number of |
| elements in parameter arrays is now optional, |
| but compilation will fail if the specified count |
| does not match. Programs performing |
| out-of-bounds array accesses using absolute |
| addressing will now fail to load. Allow "$" in |
| token names. |
| |
| Minor changes: Completed scrub of the issues |
| and error list. Added new issues about reserved |
| keywords, identifier characters, and parsing of |
| floating-point constants in programs. |
| Miscellaneous typo fixes. Updated the grammar |
| to include light products and half angles, moved |
| material properties from per-vertex to parameter |
| bindings, and a few other miscellaneous fixes. |
| Simplified the matrix binding table. Modified |
| the color sum portion of the spec to explicitly |
| add R,G,B only. Removed several incorrect |
| errors. Fixed program object state table. |
| |
| 24 05/21/02 pbrown Spec checkpoint published on the working group |
| web site. |
| |
| Deletions: Removed the semantic requirement |
| that vertex programs write a vertex position, |
| per working group resolution. |
| |
| Minor changes: Cleaned up cruft in a number of |
| issues; many more to go. Added several issues. |
| Documented that VertexAttrib functions are |
| allowed inside Begin/End pairs. Changed default |
| initialization values of generic attributes to |
| accommodate attribute aliasing. Documented that |
| point sizes and fog coordinates computed by |
| vertex programs are clipped during primitive |
| clipping. Documented that vertex program |
| behavior is undefined in color index mode. |
| |
| 23 05/21/02 pbrown Spec checkpoint. More changes from working |
| group deliberations. |
| |
| Additions: Added vertex materials as allowed |
| program parameter bindings. Allow programs to |
| use vertex attribute binding names, program |
| parameter binding names, result variable binding |
| names, and constants in executable statements, |
| resulting in implicit bindings. Added support |
| for binding a single row of a matrix. Added |
| support for binding precomputed light/material |
| products. Added restriction that a single GL |
| state vector can't be bound multiple times in |
| two separate arrays accessed with relative |
| addressing. Added new section documenting the |
| various resource limits, and introducting the |
| idea of "native" resource limits and counts. |
| |
| Deletions: Removed vertex materials as allowed |
| vertex attribute bindings. |
| |
| Minor changes: Added more names to the |
| contributors list. Updated issues concerning |
| undefined aliasing. Moved NV_vertex_program |
| related issues to the NV_vertex_program |
| interaction sections. Updated NV_vertex_program |
| interactions. Updated lighting example using |
| new derived state bindings. Clarified that |
| "!!ARBvp1.0" is not a token in the grammar and |
| that programs are parsed beginning immediately |
| after the header string. Added text to explain |
| all attribute, program parameter, and result |
| bindings instead of depending on binding table |
| interpretations. Broke the large program |
| parameter binding table into several smaller |
| tables, organized by function. Documented that |
| the queryable program error string may contain |
| warnings when a program loads successfully, and |
| that a queried program error string is |
| guaranteed to remain constant only until the |
| next program load attempt. Added PROGRAM_NAME |
| query to the appropriate state table. |
| |
| 22 05/20/02 pbrown Spec checkpoint. More changes from working |
| group deliberations. |
| |
| Added functionality: Assigned enumerant values. |
| Added "undefined (vertex attribute) aliasing" |
| language, where setting a generic attribute |
| leaves a conventional one undefined, and vice |
| versa. Added support for matrix indices from |
| ARB_matrix_palette. Added default program |
| object zero. Added support for simple named |
| variable aliasing. Added queries of API-level |
| and "native" resources used by a program and |
| their corresponding limits. Added general query |
| to determine if a program fits in native limits. |
| |
| Removed functionality: Removed extension string |
| entry for position-invariant programs (now |
| mandatory). |
| |
| Modified functionality: GetProgram and |
| GetProgramString now take a target instead of a |
| program name. Default values for 3 generic |
| attributes are changed for consistent aliasing. |
| Added 1/(end-start) binding for fog parameters. |
| Added precomputed infinite light/viewer half |
| angle binding. ProgramString takes a "void *" |
| instead of a "ubyte *". |
| |
| Minor Changes: Clarified key terms for the |
| extension. Documented that user clipping is not |
| supported in the base extension. Added warnings |
| on a couple pitfalls from uninitalized result |
| registers. Document that EXT_vertex_weighting |
| and ARB_vertex_blend use the same weight. |
| Cleaned up bindings for 4-component colors for |
| cases where only three components are used. |
| Documented the implicit absolute value operation |
| on the LOG instruction. Renamed query token for |
| querying generic vertex attribute array enables. |
| Renamed and relocated vertex program binding |
| query. Added language to Section 2.6. Changed |
| syntax to bind a range of the environment or |
| local paramater array to use double dots (".."). |
| Clarified what happens on a weight binding using |
| more weights than an implementation supports. |
| Clarified the component selection pseudocode for |
| scalar operand loads. Clarified what happens to |
| vertex program results during primitive |
| assembly. Fixed a number of errors in the state |
| tables. |
| |
| 21 04/29/02 pbrown More changes from working group deliberations. |
| |
| Added functionality: Added "FLR", "FRC", "POW", |
| and "XPD" (cross product) instructions. Added |
| functions to enable/disable generic attribute |
| arrays. Added query of a program error string. |
| Added "format" enum argument to ProgramStringARB |
| to provide for possible programs not using ASCII |
| text. Added new enums to permit different |
| limits for overall numbers of program |
| environment and local parameters and the number |
| of parameters that can be bound by a program. |
| |
| Removed functionality: Removed support for |
| evaluators for generic attributes. Removed |
| support for program residency management. |
| Removed support for user clipping in standard |
| vertex programs. Removed functionality to set |
| more than one program environment parameter at |
| once. |
| |
| Issues/Changes: Resolved set of immediate mode |
| VertexAttrib functions. Combined parameter |
| bindings for several groups of related GL state. |
| Resolved user clipping issue by disallowing |
| except for position invariant programs. |
| Resolved limits for array relative offsets. |
| GenProgramsARB and DeleteProgramsARB will use |
| texture object model. Program environment |
| parameters will not be pushed/popped. |
| |
| Bug fixes: Fixed vertex attribute index |
| prototypes (should be uint instead of int). |
| Fixed tokens used to query generic attribute |
| state (should have VERTEX prefixes). Fixed |
| documentation of the alpha component of material |
| colors. Fixed documentation of initial state |
| for vertex program objects. |
| |
| Temporarily removed dated GLX protocol language |
| (will restore in one pass after resolving |
| remaining issues). |
| |
| 20 04/17/02 pbrown Clarify the meaning of individual components of |
| program parameters where the component mapping |
| is not obvious from the mapping table. |
| |
| 18 04/15/02 pbrown Update spec to reflect issues resolved by the |
| working group on 4/11. |
| |
| Started using "program matrix" terminology -- |
| was "tracking matrix". |
| |
| Address register variables must now be declared. |
| The number of address registers can be queried. |
| Only 1-component address registers are currently |
| supported. |
| |
| VertexAttribPointer takes a separate argument to |
| indicate normalized data, now called |
| "normalized" (was "normalize"). |
| |
| ProgramString and functions to set and query |
| local parameters all take a <target> and refer |
| to the currently bound program (previously took |
| a program number). Have not touched other |
| somewhat related issues (e.g., is there a |
| program object zero?). |
| |
| Added COLOR_SUM enable (taken directly from |
| EXT_secondary_color) for completeness and a |
| few updates to EXT_secondary_color |
| interactions. |
| |
| Fixed cut-and-paste error in specification of |
| the clip-space user clip dot product. |
| |
| Documented special-case arithmetic for ADD, MAD, |
| and MUL. |
| |
| Eliminated some wordiness in DP3 and DP4 |
| instruction pseudo-code. |
| |
| Minor changes not from working group: More |
| verbose documentation on the user clipping |
| issue. More detail on other opcode candidates. |
| Removed redundant color material issue. Minor |
| fixes to error roundup (not complete) and to |
| state tables to reflect that most program |
| execution variables are initially undefined. |
| |
| 17 04/08/02 pbrown Issues: Enumerated other candidates for |
| consideration in the instruction set -- there |
| may be more that I missed. Added a description |
| of some of the considerations on how color |
| material should be treated. Added issues on the |
| name of the program matrices, the number of MVP |
| matrices, and where variable declarations |
| can be done. Added numbers to all spec issues. |
| Fixed lighting example (issue 74) so it |
| compiles, and so that the half vector is |
| properly normalized. |
| |
| Grammar: Eliminated stale hardwired temporary, |
| parameter array, and result register names |
| (R<n>, c[<n>], and o[...]). Should have been |
| deleted going from revision 5 to revision 12. |
| Added missing program matrix bindings to the |
| grammar. Eliminated state material-as-parameter |
| bindings. Fixed texgen paramete bindings, which |
| should have had both "eye" and "object" planes. |
| Added separate address register write masks and |
| selectors to reflect the current single- |
| component address register restriction. Added |
| an array[A0.x] rule -- before, you erroneously |
| had to add or subtract a constant. Modified SWZ |
| so that the register being swizzled can't take a |
| conventional swizzle suffix, too. |
| |
| Also reorganized grammar to closely mirror the |
| sample implementation, consolidating a number of |
| redundant rules. Also fixed several bugs |
| found by the implementation. |
| |
| Documentation changes to "LIT" to use the right |
| variable name and also indicate that 0^0=1. |
| Fixed the computation of result.y in the "LOG" |
| instruction. |
| |
| Other: Added dependency on ARB_imaging. Added |
| notation of Microsoft's IP claims. Fixed name |
| of MAX_VERTEX_PROGRAM_TEMPORARIES_ARB. |
| |
| A few minor typo fixes. |
| |
| 12 03/11/02 pbrown Modified spec to reflect decisions made at |
| the March 2002 ARB meeting. Distributed |
| to the OpenGL participants list. |
| |
| 5 03/03/02 pbrown Distributed to the ARB prior to March 2002 |
| ARB meeting. |