15bd8deadSopenharmony_ciName 25bd8deadSopenharmony_ci 35bd8deadSopenharmony_ci NV_vertex_program1_1 45bd8deadSopenharmony_ci 55bd8deadSopenharmony_ciName Strings 65bd8deadSopenharmony_ci 75bd8deadSopenharmony_ci GL_NV_vertex_program1_1 85bd8deadSopenharmony_ci 95bd8deadSopenharmony_ciContact 105bd8deadSopenharmony_ci 115bd8deadSopenharmony_ci Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 125bd8deadSopenharmony_ci 135bd8deadSopenharmony_ciContributors 145bd8deadSopenharmony_ci 155bd8deadSopenharmony_ci Pat Brown 165bd8deadSopenharmony_ci Erik Lindholm 175bd8deadSopenharmony_ci Steve Glanville 185bd8deadSopenharmony_ci Erik Faye-Lund 195bd8deadSopenharmony_ci 205bd8deadSopenharmony_ciNotice 215bd8deadSopenharmony_ci 225bd8deadSopenharmony_ci Copyright NVIDIA Corporation, 2001, 2002. 235bd8deadSopenharmony_ci 245bd8deadSopenharmony_ciIP Status 255bd8deadSopenharmony_ci 265bd8deadSopenharmony_ci NVIDIA Proprietary. 275bd8deadSopenharmony_ci 285bd8deadSopenharmony_ciStatus 295bd8deadSopenharmony_ci 305bd8deadSopenharmony_ci Version 1.0 315bd8deadSopenharmony_ci 325bd8deadSopenharmony_ciVersion 335bd8deadSopenharmony_ci 345bd8deadSopenharmony_ci NVIDIA Date: March 4, 2014 355bd8deadSopenharmony_ci Version: 8 365bd8deadSopenharmony_ci 375bd8deadSopenharmony_ciNumber 385bd8deadSopenharmony_ci 395bd8deadSopenharmony_ci 266 405bd8deadSopenharmony_ci 415bd8deadSopenharmony_ciDependencies 425bd8deadSopenharmony_ci 435bd8deadSopenharmony_ci Written based on the wording of the OpenGL 1.2.1 specification and 445bd8deadSopenharmony_ci requires OpenGL 1.2.1. 455bd8deadSopenharmony_ci 465bd8deadSopenharmony_ci Assumes support for the NV_vertex_program extension. 475bd8deadSopenharmony_ci 485bd8deadSopenharmony_ciOverview 495bd8deadSopenharmony_ci 505bd8deadSopenharmony_ci This extension adds four new vertex program instructions (DPH, 515bd8deadSopenharmony_ci RCC, SUB, and ABS). 525bd8deadSopenharmony_ci 535bd8deadSopenharmony_ci This extension also supports a position-invariant vertex program 545bd8deadSopenharmony_ci option. A vertex program is position-invariant when it generates 555bd8deadSopenharmony_ci the _exact_ same homogenuous position and window space position 565bd8deadSopenharmony_ci for a vertex as conventional OpenGL transformation (ignoring vertex 575bd8deadSopenharmony_ci blending and weighting). 585bd8deadSopenharmony_ci 595bd8deadSopenharmony_ci By default, vertex programs are _not_ guaranteed to be 605bd8deadSopenharmony_ci position-invariant because there is no guarantee made that the way 615bd8deadSopenharmony_ci a vertex program might compute its homogenous position is exactly 625bd8deadSopenharmony_ci identical to the way conventional OpenGL transformation computes 635bd8deadSopenharmony_ci its homogenous positions. In a position-invariant vertex program, 645bd8deadSopenharmony_ci the homogeneous position (HPOS) is not output by the program. 655bd8deadSopenharmony_ci Instead, the OpenGL implementation is expected to compute the HPOS 665bd8deadSopenharmony_ci for position-invariant vertex programs in a manner exactly identical 675bd8deadSopenharmony_ci to how the homogenous position and window position are computed 685bd8deadSopenharmony_ci for a vertex by conventional OpenGL transformation. In this way 695bd8deadSopenharmony_ci position-invariant vertex programs guarantee correct multi-pass 705bd8deadSopenharmony_ci rendering semantics in cases where multiple passes are rendered and 715bd8deadSopenharmony_ci the second and subsequent passes use a GL_EQUAL depth test. 725bd8deadSopenharmony_ci 735bd8deadSopenharmony_ciIssues 745bd8deadSopenharmony_ci 755bd8deadSopenharmony_ci How should options to the vertex program semantics be handled? 765bd8deadSopenharmony_ci 775bd8deadSopenharmony_ci RESOLUTION: A VP1.1 vertex program can contain a sequence 785bd8deadSopenharmony_ci of options. This extension provides a single option 795bd8deadSopenharmony_ci ("NV_position_invariant"). Specifying an option changes the 805bd8deadSopenharmony_ci way the program's subsequent instruction sequence are parsed, 815bd8deadSopenharmony_ci may add new semantic checks, and modifies the semantics by which 825bd8deadSopenharmony_ci the vertex program is executed. 835bd8deadSopenharmony_ci 845bd8deadSopenharmony_ci Should this extension provide SUB and ABS instructions even though 855bd8deadSopenharmony_ci the functionality can be accomplished with ADD and MAX? 865bd8deadSopenharmony_ci 875bd8deadSopenharmony_ci RESOLUTION: Yes. SUB and ABS provide no functionality that could 885bd8deadSopenharmony_ci not be accomplished in VP1.0 with ADD and MAX idioms, SUB and ABS 895bd8deadSopenharmony_ci provide more understanable vertex programs. 905bd8deadSopenharmony_ci 915bd8deadSopenharmony_ci Should the optionalSign in a VP1.1 accept both "-" and "+"? 925bd8deadSopenharmony_ci 935bd8deadSopenharmony_ci RESOLUTION: Yes. The "+" does not negate its operand but is 945bd8deadSopenharmony_ci available for symetry. 955bd8deadSopenharmony_ci 965bd8deadSopenharmony_ci Is relative addressing available to position-invariant version 1.1 975bd8deadSopenharmony_ci vertex programs? 985bd8deadSopenharmony_ci 995bd8deadSopenharmony_ci RESOLUTION: No. This reflects a hardware restriction. 1005bd8deadSopenharmony_ci 1015bd8deadSopenharmony_ci Should something be said about the relative performance of 1025bd8deadSopenharmony_ci position-invariant vertex programs and conventional vertex programs? 1035bd8deadSopenharmony_ci 1045bd8deadSopenharmony_ci RESOLUTION: For architectural reasons, position-invariant vertex 1055bd8deadSopenharmony_ci programs may be _slightly_ faster than conventional vertex programs. 1065bd8deadSopenharmony_ci This is true in the GeForce3 architecture. If your vertex program 1075bd8deadSopenharmony_ci transforms the object-space position to clip-space with four DP4 1085bd8deadSopenharmony_ci instructions using the tracked GL_MODELVIEW_PROJECTION_NV matrix, 1095bd8deadSopenharmony_ci consider using position-invariant vertex programs. Do not expect a 1105bd8deadSopenharmony_ci measurable performance improvement unless vertex program processing 1115bd8deadSopenharmony_ci is your bottleneck and your vertex program is relatively short. 1125bd8deadSopenharmony_ci 1135bd8deadSopenharmony_ci Should position-invariant vertex programs have a lower limit on the 1145bd8deadSopenharmony_ci maximum instructions? 1155bd8deadSopenharmony_ci 1165bd8deadSopenharmony_ci RESOLUTION: Yes, the driver takes care to match the same 1175bd8deadSopenharmony_ci instructions used for position transformation used by conventional 1185bd8deadSopenharmony_ci transformation and this requires a few vertex program instructions. 1195bd8deadSopenharmony_ci 1205bd8deadSopenharmony_ciNew Procedures and Functions 1215bd8deadSopenharmony_ci 1225bd8deadSopenharmony_ci None. 1235bd8deadSopenharmony_ci 1245bd8deadSopenharmony_ciNew Tokens 1255bd8deadSopenharmony_ci 1265bd8deadSopenharmony_ci None. 1275bd8deadSopenharmony_ci 1285bd8deadSopenharmony_ciAdditions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation) 1295bd8deadSopenharmony_ci 1305bd8deadSopenharmony_ci 2.14.1.9 Vertex Program Register Accesses 1315bd8deadSopenharmony_ci 1325bd8deadSopenharmony_ci Replace the first two sentences and update Table X.4: 1335bd8deadSopenharmony_ci 1345bd8deadSopenharmony_ci "There are 21 vertex program instructions. The instructions and their 1355bd8deadSopenharmony_ci respective input and output parameters are summarized in Table X.4." 1365bd8deadSopenharmony_ci 1375bd8deadSopenharmony_ci Output 1385bd8deadSopenharmony_ci Inputs (vector or 1395bd8deadSopenharmony_ciOpcode (scalar or vector) replicated scalar) Operation 1405bd8deadSopenharmony_ci------ ------------------ ------------------ -------------------------- 1415bd8deadSopenharmony_ci ARL s address register address register load 1425bd8deadSopenharmony_ci MOV v v move 1435bd8deadSopenharmony_ci MUL v,v v multiply 1445bd8deadSopenharmony_ci ADD v,v v add 1455bd8deadSopenharmony_ci MAD v,v,v v multiply and add 1465bd8deadSopenharmony_ci RCP s ssss reciprocal 1475bd8deadSopenharmony_ci RSQ s ssss reciprocal square root 1485bd8deadSopenharmony_ci DP3 v,v ssss 3-component dot product 1495bd8deadSopenharmony_ci DP4 v,v ssss 4-component dot product 1505bd8deadSopenharmony_ci DST v,v v distance vector 1515bd8deadSopenharmony_ci MIN v,v v minimum 1525bd8deadSopenharmony_ci MAX v,v v maximum 1535bd8deadSopenharmony_ci SLT v,v v set on less than 1545bd8deadSopenharmony_ci SGE v,v v set on greater equal than 1555bd8deadSopenharmony_ci EXP s v exponential base 2 1565bd8deadSopenharmony_ci LOG s v logarithm base 2 1575bd8deadSopenharmony_ci LIT v v light coefficients 1585bd8deadSopenharmony_ci DPH v,v ssss homogeneous dot product 1595bd8deadSopenharmony_ci RCC s ssss reciprocal clamped 1605bd8deadSopenharmony_ci SUB v,v v subtract 1615bd8deadSopenharmony_ci ABS v v absolute value 1625bd8deadSopenharmony_ci 1635bd8deadSopenharmony_ciTable X.4: Summary of vertex program instructions. "v" indicates a 1645bd8deadSopenharmony_civector input or output, "s" indicates a scalar input, and "ssss" indicates 1655bd8deadSopenharmony_cia scalar output replicated across a 4-component vector. 1665bd8deadSopenharmony_ci 1675bd8deadSopenharmony_ci Add four new sections describing the DPH, RCC, SUB, and ABS 1685bd8deadSopenharmony_ci instructions. 1695bd8deadSopenharmony_ci 1705bd8deadSopenharmony_ci "2.14.1.10.18 DPH: Homogeneous Dot Product 1715bd8deadSopenharmony_ci 1725bd8deadSopenharmony_ci The DPH instruction assigns the four-component dot product of the 1735bd8deadSopenharmony_ci two source vectors where the W component of the first source vector 1745bd8deadSopenharmony_ci is assumed to be 1.0 into the destination register. 1755bd8deadSopenharmony_ci 1765bd8deadSopenharmony_ci t.x = source0.c***; 1775bd8deadSopenharmony_ci t.y = source0.*c**; 1785bd8deadSopenharmony_ci t.z = source0.**c*; 1795bd8deadSopenharmony_ci if (negate0) { 1805bd8deadSopenharmony_ci t.x = -t.x; 1815bd8deadSopenharmony_ci t.y = -t.y; 1825bd8deadSopenharmony_ci t.z = -t.z; 1835bd8deadSopenharmony_ci } 1845bd8deadSopenharmony_ci u.x = source1.c***; 1855bd8deadSopenharmony_ci u.y = source1.*c**; 1865bd8deadSopenharmony_ci u.z = source1.**c*; 1875bd8deadSopenharmony_ci u.w = source1.***c; 1885bd8deadSopenharmony_ci if (negate1) { 1895bd8deadSopenharmony_ci u.x = -u.x; 1905bd8deadSopenharmony_ci u.y = -u.y; 1915bd8deadSopenharmony_ci u.z = -u.z; 1925bd8deadSopenharmony_ci u.w = -u.w; 1935bd8deadSopenharmony_ci } 1945bd8deadSopenharmony_ci v.x = t.x * u.x + t.y * u.y + t.z * u.z + u.w; 1955bd8deadSopenharmony_ci if (xmask) destination.x = v.x; 1965bd8deadSopenharmony_ci if (ymask) destination.y = v.x; 1975bd8deadSopenharmony_ci if (zmask) destination.z = v.x; 1985bd8deadSopenharmony_ci if (wmask) destination.w = v.x; 1995bd8deadSopenharmony_ci 2005bd8deadSopenharmony_ci 2.14.1.10.19 RCC: Reciprocal Clamped 2015bd8deadSopenharmony_ci 2025bd8deadSopenharmony_ci The RCC instruction inverts the value of the source scalar, clamps 2035bd8deadSopenharmony_ci the result as described below, and stores the clamped result into 2045bd8deadSopenharmony_ci the destination register. The reciprocal of exactly 1.0 must be 2055bd8deadSopenharmony_ci exactly 1.0. 2065bd8deadSopenharmony_ci 2075bd8deadSopenharmony_ci Additionally (before clamping) the reciprocal of negative infinity 2085bd8deadSopenharmony_ci gives [-0.0, -0.0, -0.0, -0.0]; the reciprocal of negative zero gives 2095bd8deadSopenharmony_ci [-Inf, -Inf, -Inf, -Inf]; the reciprocal of positive zero gives 2105bd8deadSopenharmony_ci [+Inf, +Inf, +Inf, +Inf]; and the reciprocal of positive infinity 2115bd8deadSopenharmony_ci gives [0.0, 0.0, 0.0, 0.0]. 2125bd8deadSopenharmony_ci 2135bd8deadSopenharmony_ci t.x = source0.c; 2145bd8deadSopenharmony_ci if (negate0) { 2155bd8deadSopenharmony_ci t.x = -t.x; 2165bd8deadSopenharmony_ci } 2175bd8deadSopenharmony_ci if (t.x == 1.0f) { 2185bd8deadSopenharmony_ci u.x = 1.0f; 2195bd8deadSopenharmony_ci } else { 2205bd8deadSopenharmony_ci u.x = 1.0f / t.x; 2215bd8deadSopenharmony_ci } 2225bd8deadSopenharmony_ci if (Positive(u.x)) { 2235bd8deadSopenharmony_ci if (u.x > 1.84467e+019) { 2245bd8deadSopenharmony_ci u.x = 1.84467e+019; // the IEEE 32-bit binary value 0x5F800000 2255bd8deadSopenharmony_ci } else if (u.x < 5.42101e-020) { 2265bd8deadSopenharmony_ci u.x = 5.42101e-020; // the IEEE 32-bit bindary value 0x1F800000 2275bd8deadSopenharmony_ci } 2285bd8deadSopenharmony_ci } else { 2295bd8deadSopenharmony_ci if (u.x < -1.84467e+019) { 2305bd8deadSopenharmony_ci u.x = -1.84467e+019; // the IEEE 32-bit binary value 0xDF800000 2315bd8deadSopenharmony_ci } else if (u.x > -5.42101e-020) { 2325bd8deadSopenharmony_ci u.x = -5.42101e-020; // the IEEE 32-bit binary value 0x9F800000 2335bd8deadSopenharmony_ci } 2345bd8deadSopenharmony_ci } 2355bd8deadSopenharmony_ci if (xmask) destination.x = u.x; 2365bd8deadSopenharmony_ci if (ymask) destination.y = u.x; 2375bd8deadSopenharmony_ci if (zmask) destination.z = u.x; 2385bd8deadSopenharmony_ci if (wmask) destination.w = u.x; 2395bd8deadSopenharmony_ci 2405bd8deadSopenharmony_ci where Positive(x) is true for +0 and other positive values and false 2415bd8deadSopenharmony_ci for -0 and other negative values; and 2425bd8deadSopenharmony_ci 2435bd8deadSopenharmony_ci | u.x - IEEE(1.0f/t.x) | < 1.0f/(2^22) 2445bd8deadSopenharmony_ci 2455bd8deadSopenharmony_ci for 1.0f <= t.x <= 2.0f. The intent of this precision requirement is 2465bd8deadSopenharmony_ci that this amount of relative precision apply over all values of t.x." 2475bd8deadSopenharmony_ci 2485bd8deadSopenharmony_ci 2.14.1.10.20 SUB: Subtract 2495bd8deadSopenharmony_ci 2505bd8deadSopenharmony_ci The SUB instruction subtracts the values of the one source vector 2515bd8deadSopenharmony_ci from another source vector and stores the result into the destination 2525bd8deadSopenharmony_ci register. 2535bd8deadSopenharmony_ci 2545bd8deadSopenharmony_ci t.x = source0.c***; 2555bd8deadSopenharmony_ci t.y = source0.*c**; 2565bd8deadSopenharmony_ci t.z = source0.**c*; 2575bd8deadSopenharmony_ci t.w = source0.***c; 2585bd8deadSopenharmony_ci if (negate0) { 2595bd8deadSopenharmony_ci t.x = -t.x; 2605bd8deadSopenharmony_ci t.y = -t.y; 2615bd8deadSopenharmony_ci t.z = -t.z; 2625bd8deadSopenharmony_ci t.w = -t.w; 2635bd8deadSopenharmony_ci } 2645bd8deadSopenharmony_ci u.x = source1.c***; 2655bd8deadSopenharmony_ci u.y = source1.*c**; 2665bd8deadSopenharmony_ci u.z = source1.**c*; 2675bd8deadSopenharmony_ci u.w = source1.***c; 2685bd8deadSopenharmony_ci if (negate1) { 2695bd8deadSopenharmony_ci u.x = -u.x; 2705bd8deadSopenharmony_ci u.y = -u.y; 2715bd8deadSopenharmony_ci u.z = -u.z; 2725bd8deadSopenharmony_ci u.w = -u.w; 2735bd8deadSopenharmony_ci } 2745bd8deadSopenharmony_ci if (xmask) destination.x = t.x - u.x; 2755bd8deadSopenharmony_ci if (ymask) destination.y = t.y - u.y; 2765bd8deadSopenharmony_ci if (zmask) destination.z = t.z - u.z; 2775bd8deadSopenharmony_ci if (wmask) destination.w = t.w - u.w; 2785bd8deadSopenharmony_ci 2795bd8deadSopenharmony_ci 2.14.1.10.21 ABS: Absolute Value 2805bd8deadSopenharmony_ci 2815bd8deadSopenharmony_ci The ABS instruction assigns the component-wise absolute value of a 2825bd8deadSopenharmony_ci source vector into the destination register. 2835bd8deadSopenharmony_ci 2845bd8deadSopenharmony_ci t.x = source0.c***; 2855bd8deadSopenharmony_ci t.y = source0.*c**; 2865bd8deadSopenharmony_ci t.z = source0.**c*; 2875bd8deadSopenharmony_ci t.w = source0.***c; 2885bd8deadSopenharmony_ci if (xmask) destination.x = (t.x >= 0) ? t.x : -t.x; 2895bd8deadSopenharmony_ci if (ymask) destination.y = (t.y >= 0) ? t.y : -t.y; 2905bd8deadSopenharmony_ci if (zmask) destination.z = (t.z >= 0) ? t.z : -t.z; 2915bd8deadSopenharmony_ci if (wmask) destination.w = (t.w >= 0) ? t.w : -t.w; 2925bd8deadSopenharmony_ci 2935bd8deadSopenharmony_ci Insert sections 2.14.A and 2.14.B after section 2.14.4 2945bd8deadSopenharmony_ci 2955bd8deadSopenharmony_ci "2.14.A Version 1.1 Vertex Programs 2965bd8deadSopenharmony_ci 2975bd8deadSopenharmony_ci Version 1.1 vertex programs provide support for the DPH, RCC, SUB, 2985bd8deadSopenharmony_ci and ABS instructions (see sections 2.14.1.10.18 through 2.14.1.10.21). 2995bd8deadSopenharmony_ci 3005bd8deadSopenharmony_ci Version 1.1 vertex programs are loaded with the LoadProgramNV command 3015bd8deadSopenharmony_ci (see section 2.14.1.7). The target must be VERTEX_PROGRAM_NV to 3025bd8deadSopenharmony_ci load a version 1.1 vertex program. The initial "!!VP1.1" token 3035bd8deadSopenharmony_ci designates the program should be parsed and treated as a version 1.1 3045bd8deadSopenharmony_ci vertex program. 3055bd8deadSopenharmony_ci 3065bd8deadSopenharmony_ci Version 1.1 programs must conform to a more expanded grammar than 3075bd8deadSopenharmony_ci the grammar for vertex programs. The version 1.1 vertex program 3085bd8deadSopenharmony_ci grammar for syntactically valid sequences is the same as the grammar 3095bd8deadSopenharmony_ci defined in section 2.14.1.7 with the following modified rules: 3105bd8deadSopenharmony_ci 3115bd8deadSopenharmony_ci <program> ::= "!!VP1.1" <optionSequence> <instructionSequence> "END" 3125bd8deadSopenharmony_ci 3135bd8deadSopenharmony_ci <optionSequence> ::= <optionSequence> <option> 3145bd8deadSopenharmony_ci | "" 3155bd8deadSopenharmony_ci 3165bd8deadSopenharmony_ci <option> ::= "OPTION" "NV_position_invariant" ";" 3175bd8deadSopenharmony_ci 3185bd8deadSopenharmony_ci <VECTORop> ::= "MOV" 3195bd8deadSopenharmony_ci | "LIT" 3205bd8deadSopenharmony_ci | "ABS" 3215bd8deadSopenharmony_ci 3225bd8deadSopenharmony_ci <SCALARop> ::= "RCP" 3235bd8deadSopenharmony_ci | "RSQ" 3245bd8deadSopenharmony_ci | "EXP" 3255bd8deadSopenharmony_ci | "LOG" 3265bd8deadSopenharmony_ci | "RCC" 3275bd8deadSopenharmony_ci 3285bd8deadSopenharmony_ci <BINop> ::= "MUL" 3295bd8deadSopenharmony_ci | "ADD" 3305bd8deadSopenharmony_ci | "DP3" 3315bd8deadSopenharmony_ci | "DP4" 3325bd8deadSopenharmony_ci | "DST" 3335bd8deadSopenharmony_ci | "MIN" 3345bd8deadSopenharmony_ci | "MAX" 3355bd8deadSopenharmony_ci | "SLT" 3365bd8deadSopenharmony_ci | "SGE" 3375bd8deadSopenharmony_ci | "DPH" 3385bd8deadSopenharmony_ci | "SUB" 3395bd8deadSopenharmony_ci 3405bd8deadSopenharmony_ci <optionalSign> ::= "-" 3415bd8deadSopenharmony_ci | "+" 3425bd8deadSopenharmony_ci | "" 3435bd8deadSopenharmony_ci 3445bd8deadSopenharmony_ci Except for supporting the additional DPH, RCC, SUB, and ABS 3455bd8deadSopenharmony_ci instructions, version 1.1 vertex programs with no options specified 3465bd8deadSopenharmony_ci otherwise behave in the same manner as version 1.0 vertex programs. 3475bd8deadSopenharmony_ci 3485bd8deadSopenharmony_ci 2.14.B Position-invariant Vertex Program Option 3495bd8deadSopenharmony_ci 3505bd8deadSopenharmony_ci By default, vertex programs are _not_ guaranteed to be 3515bd8deadSopenharmony_ci position-invariant because there is no guarantee made that the 3525bd8deadSopenharmony_ci way a vertex program might compute its homogenous position is 3535bd8deadSopenharmony_ci exactly identical to the way conventional OpenGL transformation 3545bd8deadSopenharmony_ci computes its homogenous positions. However in a position-invariant 3555bd8deadSopenharmony_ci vertex program, the homogeneous position (HPOS) is not output by 3565bd8deadSopenharmony_ci the program. Instead, the OpenGL implementation is expected to 3575bd8deadSopenharmony_ci compute the HPOS for position-invariant vertex programs in a manner 3585bd8deadSopenharmony_ci exactly identical to how the homogenous position and window position 3595bd8deadSopenharmony_ci are computed for a vertex by conventional OpenGL transformation 3605bd8deadSopenharmony_ci (assuming vertex weighting and vertex blending are disabled). In this 3615bd8deadSopenharmony_ci way position-invariant vertex programs guarantee correct multi-pass 3625bd8deadSopenharmony_ci rendering semantics in cases where multiple passes are rendered with 3635bd8deadSopenharmony_ci conventional OpenGL transformation and position-invariant vertex 3645bd8deadSopenharmony_ci programs and the second and subsequent passes use a EQUAL depth test. 3655bd8deadSopenharmony_ci 3665bd8deadSopenharmony_ci If an <option> with the identifier "NV_position_invariant" is 3675bd8deadSopenharmony_ci encountered during the parsing of the program, the specified program 3685bd8deadSopenharmony_ci is presumed to be position-invariant. 3695bd8deadSopenharmony_ci 3705bd8deadSopenharmony_ci When a position-invariant vertex program is specified, the 3715bd8deadSopenharmony_ci <vertexResultRegName> rule is replaced with the following rule 3725bd8deadSopenharmony_ci (that does not provide "HPOS"): 3735bd8deadSopenharmony_ci 3745bd8deadSopenharmony_ci <vertexResultRegName> ::= "COL0" 3755bd8deadSopenharmony_ci | "COL1" 3765bd8deadSopenharmony_ci | "BFC0" 3775bd8deadSopenharmony_ci | "BFC1" 3785bd8deadSopenharmony_ci | "FOGC" 3795bd8deadSopenharmony_ci | "PSIZ" 3805bd8deadSopenharmony_ci | "TEX0" 3815bd8deadSopenharmony_ci | "TEX1" 3825bd8deadSopenharmony_ci | "TEX2" 3835bd8deadSopenharmony_ci | "TEX3" 3845bd8deadSopenharmony_ci | "TEX4" 3855bd8deadSopenharmony_ci | "TEX5" 3865bd8deadSopenharmony_ci | "TEX6" 3875bd8deadSopenharmony_ci | "TEX7" 3885bd8deadSopenharmony_ci 3895bd8deadSopenharmony_ci While position-invariant version 1.1 vertex programs provide 3905bd8deadSopenharmony_ci position-invariance, such programs do not provide support for 3915bd8deadSopenharmony_ci relative program parameter addressing. The <relProgParamReg> rule 3925bd8deadSopenharmony_ci for version 1.1 position-invariant vertex programs is replaced by 3935bd8deadSopenharmony_ci (eliminating the relative addressing cases): 3945bd8deadSopenharmony_ci 3955bd8deadSopenharmony_ci <relProgParamReg> ::= "c" "[" <addrReg> "]" 3965bd8deadSopenharmony_ci 3975bd8deadSopenharmony_ci Note that while the ARL instruction is still available to 3985bd8deadSopenharmony_ci position-invariant version 1.1 vertex programs, it provides no 3995bd8deadSopenharmony_ci meaningful functionality without support for relative addressing. 4005bd8deadSopenharmony_ci 4015bd8deadSopenharmony_ci The semantic restriction for vertex program instruction length is 4025bd8deadSopenharmony_ci changed in the case of position-invariant vertex programs to the 4035bd8deadSopenharmony_ci following: A position-invariant vertex program fails to load if it 4045bd8deadSopenharmony_ci contains more than 124 instructions. 4055bd8deadSopenharmony_ci 4065bd8deadSopenharmony_ci " 4075bd8deadSopenharmony_ci 4085bd8deadSopenharmony_ciAdditions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment 4095bd8deadSopenharmony_ciOperations and the Framebuffer) 4105bd8deadSopenharmony_ci 4115bd8deadSopenharmony_ci None 4125bd8deadSopenharmony_ci 4135bd8deadSopenharmony_ciAdditions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions) 4145bd8deadSopenharmony_ci 4155bd8deadSopenharmony_ci None 4165bd8deadSopenharmony_ci 4175bd8deadSopenharmony_ciAdditions to Chapter 6 of the OpenGL 1.2.1 Specification (State and 4185bd8deadSopenharmony_ciState Requests) 4195bd8deadSopenharmony_ci 4205bd8deadSopenharmony_ci None 4215bd8deadSopenharmony_ci 4225bd8deadSopenharmony_ciAdditions to the AGL/GLX/WGL Specifications 4235bd8deadSopenharmony_ci 4245bd8deadSopenharmony_ci None 4255bd8deadSopenharmony_ci 4265bd8deadSopenharmony_ciGLX Protocol 4275bd8deadSopenharmony_ci 4285bd8deadSopenharmony_ci None 4295bd8deadSopenharmony_ci 4305bd8deadSopenharmony_ciErrors 4315bd8deadSopenharmony_ci 4325bd8deadSopenharmony_ci None 4335bd8deadSopenharmony_ci 4345bd8deadSopenharmony_ciNew State 4355bd8deadSopenharmony_ci 4365bd8deadSopenharmony_ci None 4375bd8deadSopenharmony_ci 4385bd8deadSopenharmony_ciRevision History 4395bd8deadSopenharmony_ci 4405bd8deadSopenharmony_ci Rev. Date Author Changes 4415bd8deadSopenharmony_ci ---- -------- --------- ---------------------------------------- 4425bd8deadSopenharmony_ci 8 03/04/14 mjk RCC decimal value corrections 443