skia / external / github.com / KhronosGroup / OpenGL-Registry / refs/heads/11723-workgroup / . / extensions / NV / NV_vertex_program1_1.txt

Name | |

NV_vertex_program1_1 | |

Name Strings | |

GL_NV_vertex_program1_1 | |

Contact | |

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

Contributors | |

Pat Brown | |

Erik Lindholm | |

Steve Glanville | |

Erik Faye-Lund | |

Notice | |

Copyright NVIDIA Corporation, 2001, 2002. | |

IP Status | |

NVIDIA Proprietary. | |

Status | |

Version 1.0 | |

Version | |

NVIDIA Date: March 4, 2014 | |

Version: 8 | |

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.84467e+019) { | |

u.x = 1.84467e+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.84467e+019) { | |

u.x = -1.84467e+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 | |

Revision History | |

Rev. Date Author Changes | |

---- -------- --------- ---------------------------------------- | |

8 03/04/14 mjk RCC decimal value corrections |