GL_NV_vertex_program1_1 |

- Name
- Name Strings
- Contact
- Notice
- IP Status
- Status
- Version
- Number
- Dependencies
- Overview
- Issues
- New Procedures and Functions
- New Tokens
- Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
- Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment Operations and the Framebuffer)
- Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
- Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and State Requests)
- Additions to the AGL/GLX/WGL Specifications
- GLX Protocol
- Errors
- New State

Name |

NV_vertex_program1_1

Name Strings |

GL_NV_vertex_program1_1

Contact |

Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)

Notice |

Copyright NVIDIA Corporation, 2001, 2002.

IP Status |

NVIDIA Proprietary.

Status |

Version 1.0

Version |

NVIDIA Date: September 3, 2002 $Date: 2001/07/13 $ $Revision: #3 $ $Id: //sw/main/docs/OpenGL/specs/GL_NV_vertex_program1_1.txt#7 $

Number |

266

Dependencies |

Written based on the wording of the OpenGL 1.2.1 specification and requires OpenGL 1.2.1. Assumes support for the NV_vertex_program extension.

Overview |

This extension adds four new vertex program instructions (DPH, RCC, SUB, and ABS). This extension also supports a position-invariant vertex program option. A vertex program is position-invariant when it generates the _exact_ same homogenuous position and window space position for a vertex as conventional OpenGL transformation (ignoring vertex blending and weighting). By default, vertex programs are _not_ guaranteed to be position-invariant because there is no guarantee made that the way a vertex program might compute its homogenous position is exactly identical to the way conventional OpenGL transformation computes its homogenous positions. In a position-invariant vertex program, the homogeneous position (HPOS) is not output by the program. Instead, the OpenGL implementation is expected to compute the HPOS for position-invariant vertex programs in a manner exactly identical to how the homogenous position and window position are computed for a vertex by conventional OpenGL transformation. In this way position-invariant vertex programs guarantee correct multi-pass rendering semantics in cases where multiple passes are rendered and the second and subsequent passes use a GL_EQUAL depth test.

Issues |

How should options to the vertex program semantics be handled? RESOLUTION: A VP1.1 vertex program can contain a sequence of options. This extension provides a single option ("NV_position_invariant"). Specifying an option changes the way the program's subsequent instruction sequence are parsed, may add new semantic checks, and modifies the semantics by which the vertex program is executed. Should this extension provide SUB and ABS instructions even though the functionality can be accomplished with ADD and MAX? RESOLUTION: Yes. SUB and ABS provide no functionality that could not be accomplished in VP1.0 with ADD and MAX idioms, SUB and ABS provide more understanable vertex programs. Should the optionalSign in a VP1.1 accept both "-" and "+"? RESOLUTION: Yes. The "+" does not negate its operand but is available for symetry. Is relative addressing available to position-invariant version 1.1 vertex programs? RESOLUTION: No. This reflects a hardware restriction. Should something be said about the relative performance of position-invariant vertex programs and conventional vertex programs? RESOLUTION: For architectural reasons, position-invariant vertex programs may be _slightly_ faster than conventional vertex programs. This is true in the GeForce3 architecture. If your vertex program transforms the object-space position to clip-space with four DP4 instructions using the tracked GL_MODELVIEW_PROJECTION_NV matrix, consider using position-invariant vertex programs. Do not expect a measurable performance improvement unless vertex program processing is your bottleneck and your vertex program is relatively short. Should position-invariant vertex programs have a lower limit on the maximum instructions? RESOLUTION: Yes, the driver takes care to match the same instructions used for position transformation used by conventional transformation and this requires a few vertex program instructions.

New Procedures and Functions |

None.

New Tokens |

None.

Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation) |

2.14.1.9 Vertex Program Register Accesses Replace the first two sentences and update Table X.4: "There are 21 vertex program instructions. The instructions and their respective input and output parameters are summarized in Table X.4." Output Inputs (vector or Opcode (scalar or vector) replicated scalar) Operation ------ ------------------ ------------------ -------------------------- ARL s address register address register load MOV v v move MUL v,v v multiply ADD v,v v add MAD v,v,v v multiply and add RCP s ssss reciprocal RSQ s ssss reciprocal square root DP3 v,v ssss 3-component dot product DP4 v,v ssss 4-component dot product DST v,v v distance vector MIN v,v v minimum MAX v,v v maximum SLT v,v v set on less than SGE v,v v set on greater equal than EXP s v exponential base 2 LOG s v logarithm base 2 LIT v v light coefficients DPH v,v ssss homogeneous dot product RCC s ssss reciprocal clamped SUB v,v v subtract ABS v v absolute value Table X.4: Summary of vertex program instructions. "v" indicates a vector input or output, "s" indicates a scalar input, and "ssss" indicates a scalar output replicated across a 4-component vector. Add four new sections describing the DPH, RCC, SUB, and ABS instructions. "2.14.1.10.18 DPH: Homogeneous Dot Product The DPH instruction assigns the four-component dot product of the two source vectors where the W component of the first source vector is assumed to be 1.0 into the destination register. t.x = source0.c***; t.y = source0.*c**; t.z = source0.**c*; if (negate0) { t.x = -t.x; t.y = -t.y; t.z = -t.z; } u.x = source1.c***; u.y = source1.*c**; u.z = source1.**c*; u.w = source1.***c; if (negate1) { u.x = -u.x; u.y = -u.y; u.z = -u.z; u.w = -u.w; } v.x = t.x * u.x + t.y * u.y + t.z * u.z + u.w; if (xmask) destination.x = v.x; if (ymask) destination.y = v.x; if (zmask) destination.z = v.x; if (wmask) destination.w = v.x; 2.14.1.10.19 RCC: Reciprocal Clamped The RCC instruction inverts the value of the source scalar, clamps the result as described below, and stores the clamped result into the destination register. The reciprocal of exactly 1.0 must be exactly 1.0. Additionally (before clamping) the reciprocal of negative infinity gives [-0.0, -0.0, -0.0, -0.0]; the reciprocal of negative zero gives [-Inf, -Inf, -Inf, -Inf]; the reciprocal of positive zero gives [+Inf, +Inf, +Inf, +Inf]; and the reciprocal of positive infinity gives [0.0, 0.0, 0.0, 0.0]. t.x = source0.c; if (negate0) { t.x = -t.x; } if (t.x == 1.0f) { u.x = 1.0f; } else { u.x = 1.0f / t.x; } if (Positive(u.x)) { if (u.x > 1.884467e+019) { u.x = 1.884467e+019; // the IEEE 32-bit binary value 0x5F800000 } else if (u.x < 5.42101e-020) { u.x = 5.42101e-020; // the IEEE 32-bit bindary value 0x1F800000 } } else { if (u.x < -1.884467e+019) { u.x = -1.884467e+019; // the IEEE 32-bit binary value 0xDF800000 } else if (u.x > -5.42101e-020) { u.x = -5.42101e-020; // the IEEE 32-bit binary value 0x9F800000 } } if (xmask) destination.x = u.x; if (ymask) destination.y = u.x; if (zmask) destination.z = u.x; if (wmask) destination.w = u.x; where Positive(x) is true for +0 and other positive values and false for -0 and other negative values; and | u.x - IEEE(1.0f/t.x) | < 1.0f/(2^22) for 1.0f <= t.x <= 2.0f. The intent of this precision requirement is that this amount of relative precision apply over all values of t.x." 2.14.1.10.20 SUB: Subtract The SUB instruction subtracts the values of the one source vector from another source vector and stores the result into the destination register. t.x = source0.c***; t.y = source0.*c**; t.z = source0.**c*; t.w = source0.***c; if (negate0) { t.x = -t.x; t.y = -t.y; t.z = -t.z; t.w = -t.w; } u.x = source1.c***; u.y = source1.*c**; u.z = source1.**c*; u.w = source1.***c; if (negate1) { u.x = -u.x; u.y = -u.y; u.z = -u.z; u.w = -u.w; } if (xmask) destination.x = t.x - u.x; if (ymask) destination.y = t.y - u.y; if (zmask) destination.z = t.z - u.z; if (wmask) destination.w = t.w - u.w; 2.14.1.10.21 ABS: Absolute Value The ABS instruction assigns the component-wise absolute value of a source vector into the destination register. t.x = source0.c***; t.y = source0.*c**; t.z = source0.**c*; t.w = source0.***c; if (xmask) destination.x = (t.x >= 0) ? t.x : -t.x; if (ymask) destination.y = (t.y >= 0) ? t.y : -t.y; if (zmask) destination.z = (t.z >= 0) ? t.z : -t.z; if (wmask) destination.w = (t.w >= 0) ? t.w : -t.w; Insert sections 2.14.A and 2.14.B after section 2.14.4 "2.14.A Version 1.1 Vertex Programs Version 1.1 vertex programs provide support for the DPH, RCC, SUB, and ABS instructions (see sections 2.14.1.10.18 through 2.14.1.10.21). Version 1.1 vertex programs are loaded with the LoadProgramNV command (see section 2.14.1.7). The target must be VERTEX_PROGRAM_NV to load a version 1.1 vertex program. The initial "!!VP1.1" token designates the program should be parsed and treated as a version 1.1 vertex program. Version 1.1 programs must conform to a more expanded grammar than the grammar for vertex programs. The version 1.1 vertex program grammar for syntactically valid sequences is the same as the grammar defined in section 2.14.1.7 with the following modified rules: <program> ::= "!!VP1.1" <optionSequence> <instructionSequence> "END" <optionSequence> ::= <optionSequence> <option> | "" <option> ::= "OPTION" "NV_position_invariant" ";" <VECTORop> ::= "MOV" | "LIT" | "ABS" <SCALARop> ::= "RCP" | "RSQ" | "EXP" | "LOG" | "RCC" <BINop> ::= "MUL" | "ADD" | "DP3" | "DP4" | "DST" | "MIN" | "MAX" | "SLT" | "SGE" | "DPH" | "SUB" <optionalSign> ::= "-" | "+" | "" Except for supporting the additional DPH, RCC, SUB, and ABS instructions, version 1.1 vertex programs with no options specified otherwise behave in the same manner as version 1.0 vertex programs. 2.14.B Position-invariant Vertex Program Option By default, vertex programs are _not_ guaranteed to be position-invariant because there is no guarantee made that the way a vertex program might compute its homogenous position is exactly identical to the way conventional OpenGL transformation computes its homogenous positions. However in a position-invariant vertex program, the homogeneous position (HPOS) is not output by the program. Instead, the OpenGL implementation is expected to compute the HPOS for position-invariant vertex programs in a manner exactly identical to how the homogenous position and window position are computed for a vertex by conventional OpenGL transformation (assuming vertex weighting and vertex blending are disabled). In this way position-invariant vertex programs guarantee correct multi-pass rendering semantics in cases where multiple passes are rendered with conventional OpenGL transformation and position-invariant vertex programs and the second and subsequent passes use a EQUAL depth test. If an <option> with the identifier "NV_position_invariant" is encountered during the parsing of the program, the specified program is presumed to be position-invariant. When a position-invariant vertex program is specified, the <vertexResultRegName> rule is replaced with the following rule (that does not provide "HPOS"): <vertexResultRegName> ::= "COL0" | "COL1" | "BFC0" | "BFC1" | "FOGC" | "PSIZ" | "TEX0" | "TEX1" | "TEX2" | "TEX3" | "TEX4" | "TEX5" | "TEX6" | "TEX7" While position-invariant version 1.1 vertex programs provide position-invariance, such programs do not provide support for relative program parameter addressing. The <relProgParamReg> rule for version 1.1 position-invariant vertex programs is replaced by (eliminating the relative addressing cases): <relProgParamReg> ::= "c" "[" <addrReg> "]" Note that while the ARL instruction is still available to position-invariant version 1.1 vertex programs, it provides no meaningful functionality without support for relative addressing. The semantic restriction for vertex program instruction length is changed in the case of position-invariant vertex programs to the following: A position-invariant vertex program fails to load if it contains more than 124 instructions. "

Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment Operations and the Framebuffer) |

None

Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions) |

None

Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and State Requests) |

None

Additions to the AGL/GLX/WGL Specifications |

None

GLX Protocol |

None

Errors |

None

New State |

None

Last update: November 14, 2006.Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1. |