1Name 2 3 NV_fragment_program4 4 5Name Strings 6 7 (none) 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Status 14 15 Shipping for GeForce 8 Series (November 2006) 16 17Version 18 19 Last Modified Date: 05/26/09 20 NVIDIA Revision: 6 21 22Number 23 24 335 25 26Dependencies 27 28 OpenGL 1.1 is required. 29 30 NV_gpu_program4 is required. This extension is supported if 31 "GL_NV_gpu_program4" is found in the extension string. 32 33 ATI_draw_buffers and ARB_draw_buffers trivially affects the definition of 34 this specification. 35 36 ARB_fragment_program_shadow trivially affects the definition of this 37 specification. 38 39 NV_primitive_restart trivially affects the definition of this extension. 40 41 This extension is written against the OpenGL 2.0 specification. 42 43Overview 44 45 This extension builds on the common assembly instruction set 46 infrastructure provided by NV_gpu_program4, adding fragment 47 program-specific features. 48 49 This extension provides interpolation modifiers to fragment program 50 attributes allowing programs to specify that specified attributes be 51 flat-shaded (constant over a primitive), centroid-sampled (multisample 52 rendering), or interpolated linearly in screen space. The set of input 53 and output bindings provided includes all bindings supported by 54 ARB_fragment_program. Additional input bindings are provided to determine 55 whether fragments were generated by front- or back-facing primitives 56 ("fragment.facing"), to identify the individual primitive used to generate 57 the fragment ("primitive.id"), and to determine distances to user clip 58 planes ("fragment.clip[n]"). Additionally generic input attributes allow 59 a fragment program to receive a greater number of attributes from previous 60 pipeline stages than possible using only the pre-defined fixed-function 61 attributes. 62 63 By and large, programs written to ARB_fragment_program can be ported 64 directly by simply changing the program header from "!!ARBfp1.0" to 65 "!!NVfp4.0", and then modifying instructions to take advantage of the 66 expanded feature set. There are a small number of areas where this 67 extension is not a functional superset of previous fragment program 68 extensions, which are documented in the NV_gpu_program4 specification. 69 70New Procedures and Functions 71 72 None. 73 74New Tokens 75 76 None. 77 78Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 79 80 Modify Section 2.X, GPU Programs 81 82 (insert after second paragraph) 83 84 Fragment Programs 85 86 Fragment programs are used to compute the transformed attributes of a 87 fragment, in lieu of the set of fixed-function operations described in 88 sections 3.8 through 3.10. Fragment programs are run on a single fragment 89 at a time, and the state of neighboring fragments is not explicitly 90 available. (In practice, fragment programs may be run on a block of 91 fragments, and neighboring fragments' attributes may be used for texture 92 LOD calculations or partial derivative approximation.) The inputs 93 available to a fragment program are the interpolated attributes of a 94 fragment, which include (among other things) window-space position, 95 primary and secondary colors, and texture coordinates. The results of the 96 program are one (or more) colors and possibly a new window Z coordinate. 97 A fragment program can not modify the (X,Y) location of the fragment. 98 99 Modify Section 2.X.2, Program Grammar 100 101 (replace third paragraph) 102 103 Fragment programs are required to begin with the header string 104 "!!NVfp4.0". This header string identifies the subsequent program body as 105 being a fragment program and indicates that it should be parsed according 106 to the base NV_gpu_program4 grammar plus the additions below. Program 107 string parsing begins with the character immediately following the header 108 string. 109 110 (add the following grammar rules to the NV_gpu_program4 base grammar) 111 112 <instruction> ::= <SpecialInstruction> 113 114 <varModifier> ::= <interpModifier> 115 116 <SpecialInstruction> ::= "KIL" <opModifiers> <killCond> 117 | "DDX" <opModifiers> <instResult> "," 118 <instOperandV> 119 | "DDY" <opModifiers> <instResult> "," 120 <instOperandV> 121 122 <killCond> ::= <instOperandV> 123 124 <interpModifier> ::= "FLAT" 125 | "CENTROID" 126 | "NOPERSPECTIVE" 127 128 <attribBasic> ::= <fragPrefix> "fogcoord" 129 | <fragPrefix> "position" 130 | <fragPrefix> "facing" 131 | <attribTexCoord> <optArrayMemAbs> 132 | <attribClip> <arrayMemAbs> 133 | <attribGeneric> <arrayMemAbs> 134 | "primitive" "." "id" 135 136 <attribColor> ::= <fragPrefix> "color" 137 138 <attribMulti> ::= <attribTexCoord> <arrayRange> 139 | <attribClip> <arrayRange> 140 | <attribGeneric> <arrayRange> 141 142 <attribTexCoord> ::= <fragPrefix> "texcoord" 143 144 <attribClip> ::= <fragPrefix> "clip" 145 146 <attribGeneric> ::= <fragPrefix> "attrib" 147 148 <fragPrefix> ::= "fragment" "." 149 150 <resultBasic> ::= <resPrefix> "color" <resultOptColorNum> 151 | <resPrefix> "depth" 152 153 <resultOptColorNum> ::= /* empty */ 154 155 <resPrefix> ::= "result" "." 156 157 (add the following subsection to section 2.X.3.1, Program Variable Types) 158 159 Explicitly declared fragment program attribute variables may have one or 160 more interpolation modifiers that control how per-fragment values are 161 computed. 162 163 An attribute variable declared as "FLAT" will be flat-shaded. For such 164 variables, the value of the attribute will be constant over an entire 165 primitive and will taken from the provoking vertex of the primitive, as 166 described in Section 2.14.7. If "FLAT" is not specified, attributes will 167 be interpolated as described in Chapter 3, with the exception that 168 attribute variables bound to colors will still be flat-shaded if the shade 169 model (section 2.14.7) is FLAT. If an attribute variable declared as 170 "FLAT" corresponds to a texture coordinate replaced by a point sprite 171 (s,t) value (section 3.3.1), the value of the attribute is undefined. 172 173 An attribute variable declared as "CENTROID" will be interpolated using a 174 point on or inside the primitive, if possible, when doing multisample line 175 or polygon rasterization (sections 3.4.4 and 3.5.6). This method can 176 avoid artifacts during multisample rasterization when some samples of a 177 pixel are covered, but the sample location used is outside the primitive. 178 Note that when centroid sampling, the sample points used to generate 179 attribute values for adjacent pixels may not be evenly spaced, which can 180 lead to artifacts when evaluating partial derivatives or performing 181 texture LOD calculations needed for mipmapping. If "CENTROID" is not 182 specified, attributes may be sampled anywhere inside the pixel as 183 permitted by the specification, including at points outside the primitive. 184 185 An attribute variable declared as "NOPERSPECTIVE" will be interpolated 186 using a method that is linear in screen space, as described in equation 187 3.7 and the appoximation that follows equation 3.8. If "NOPERSPECTIVE" is 188 not specified, attributes must be interpolated with perspective 189 correction, as described in equations 3.6 and 3.8. When clipping lines or 190 polygons, an alternate method is used to compute the attributes of 191 vertices introduced by clipping when they are specified as "NOPERSPECTIVE" 192 (section 2.14.8). 193 194 Implicitly declared attribute variables (bindings used directly in a 195 program instruction) will inherit the interpolation modifiers of any 196 explicitly declared attribute variable using the same binding. If no such 197 variable exists, default interpolation modes will be used. 198 199 For fragments generated by point primitives, DrawPixels, and Bitmap, 200 interpolation modifiers have no effect. 201 202 Implementations are not required to support arithmetic interpolation of 203 integer values written by a previous pipeline stage. Integer fragment 204 program attribute variables must be flat-shaded; a program will fail to 205 load if it declares a variable with the "INT" or "UINT" data type 206 modifiers without the "FLAT" interpolation modifier. 207 208 There are several additional limitations on the use of interpolation 209 modifiers. A fragment program will fail to load: 210 211 * if an interpolation modifier is specified when declaring a 212 non-attribute variable, 213 214 * if the same interpolation modifier is specified more than once in a 215 single declaration (e.g., "CENTROID CENTROID ATTRIB"), 216 217 * if the "FLAT" modifier is used together with either "CENTROID" or 218 "NOPERSPECTIVE" in a single declaration, 219 220 * if any interpolation modifier is specified when declaring a variable 221 bound to a fragment's position, face direction, fog coordinate, or any 222 interpolated clip distance, 223 224 * if multiple attribute variables with different interpolation modifiers 225 are bound to the same fragment attribute, or 226 227 * if one variable is bound to the fragment's primary color and a second 228 variable with different interpolation modifiers is bound the the 229 fragment's secondary color. 230 231 (add the following subsection to section 2.X.3.2, Program Attribute 232 Variables) 233 234 Fragment program attribute variables describe the attributes of a fragment 235 produced during rasterization. The set of available bindings is 236 enumerated in Table X.X. 237 238 Most attributes correspond to per-vertex attributes that are interpolated 239 over a primitive; such attributes are subject to the interpolation 240 modifiers described in section 2.X.3.1. The fragment's position, facing, 241 and primitive IDs are the exceptions, and are generated specially during 242 rasterization. Since two-sided color selection occurs prior to 243 rasterization, there are no distinct "front" or "back" colors available to 244 fragment programs. A single set of colors is available, which corresponds 245 to interpolated front or back vertex colors. 246 247 If geometry programs are enabled, attributes will be obtained by 248 interpolating per-vertex outputs written by the geometry program. If 249 geometry programs are disabled, but vertex programs are enabled, 250 attributes will be obtained by interpolating per-vertex outputs written by 251 the vertex program. In either case, the fragment program attributes 252 should be read using the same component data type used to write the vertex 253 output attributes in the geometry or vertex program. The value of any 254 attribute corresponding to a vertex output not written by the geometry or 255 vertex program is undefined. 256 257 If neither geometry nor vertex programs are used, attributes will be 258 obtained by interpolating per-vertex values computed by fixed-function 259 vertex processing. All interpolated fragment attributes should be read as 260 floating-point values. 261 262 Fragment Attribute Binding Components Underlying State 263 -------------------------- ---------- ---------------------------- 264 fragment.color (r,g,b,a) primary color 265 fragment.color.primary (r,g,b,a) primary color 266 fragment.color.secondary (r,g,b,a) secondary color 267 fragment.texcoord (s,t,r,q) texture coordinate, unit 0 268 fragment.texcoord[n] (s,t,r,q) texture coordinate, unit n 269 fragment.fogcoord (f,-,-,-) fog distance/coordinate 270 * fragment.clip[n] (c,-,-,-) interpolated clip distance n 271 fragment.attrib[n] (x,y,z,w) generic interpolant n 272 fragment.texcoord[n..o] (s,t,r,q) texture coordinates n thru o 273 * fragment.clip[n..o] (c,-,-,-) clip distances n thru o 274 fragment.attrib[n..o] (x,y,z,w) generic interpolants n thru o 275 * fragment.position (x,y,z,1/w) window position 276 * fragment.facing (f,-,-,-) fragment facing 277 * primitive.id (id,-,-,-) primitive number 278 279 Table X.X: Fragment Attribute Bindings. The "Components" column 280 indicates the mapping of the state in the "Underlying State" column. 281 Bindings containing "[n]" require an integer value of <n> to select an 282 individual item. Interpolation modifiers are not supported on variables 283 that use bindings labeled with "*". 284 285 If a fragment attribute binding matches "fragment.color" or 286 "fragment.color.primary", the "x", "y", "z", and "w" components of the 287 fragment attribute variable are filled with the "r", "g", "b", and "a" 288 components, respectively, of the fragment's primary color. 289 290 If a fragment attribute binding matches "fragment.color.secondary", the 291 "x", "y", "z", and "w" components of the fragment attribute variable are 292 filled with the "r", "g", "b", and "a" components, respectively, of the 293 fragment's secondary color. 294 295 If a fragment attribute binding matches "fragment.texcoord" or 296 "fragment.texcoord[n]", the "x", "y", "z", and "w" components of the 297 fragment attribute variable are filled with the "s", "t", "r", and "q" 298 components, respectively, of the fragment texture coordinates for texture 299 unit <n>. If "[n]" is omitted, texture unit zero is used. 300 301 If a fragment attribute binding matches "fragment.fogcoord", the "x" 302 component of the fragment attribute variable is filled with either the 303 fragment eye distance or the fog coordinate, depending on whether the fog 304 source is set to FRAGMENT_DEPTH_EXT or FOG_COORDINATE_EXT, respectively. 305 The "y", "z", and "w" coordinates are undefined. 306 307 If a fragment attribute binding matches "fragment.clip[n]", the "x" 308 component of the fragment attribute variable is filled with the 309 interpolated value of clip distance <n>, as written by the vertex or 310 geometry program. The "y", "z", and "w" components of the variable are 311 undefined. If fixed-function vertex processing or position-invariant 312 vertex programs are used with geometry programs disabled, clip distances 313 are obtained by interpolating the per-clip plane dot product: 314 315 (p_1' p_2' p_3' p_4') dot (x_e y_e z_e w_e), 316 317 for clip plane <n> as described in section 2.12. The clip distance for 318 clip plane <n> is undefined if clip plane <n> is disabled. 319 320 If a fragment attribute binding matches "fragment.attrib[n]", the "x", 321 "y", "z", and "w" components of the fragment attribute variable are filled 322 with the "x", "y", "z", and "w" components of generic interpolant <n>. 323 All generic interpolants will be undefined when used with fixed-function 324 vertex processing with no geometry program enabled. 325 326 If a fragment attribute binding matches "fragment.texcoord[n..o]", 327 "fragment.clip[n..o]", or "fragment.attrib[n..o]", a sequence of 1+<o>-<n> 328 bindings is created. For texture coordinate bindings, it is as though the 329 sequence "fragment.texcoord[n], fragment.texcoord[n+1], 330 ... fragment.texcoord[o]" were specfied. These bindings are available 331 only in explicit declarations of array variables. A program will fail to 332 load if <n> is greater than <o>. 333 334 If a fragment attribute binding matches "fragment.position", the "x" and 335 "y" components of the fragment attribute variable are filled with the 336 floating-point (x,y) window coordinates of the fragment center, relative 337 to the lower left corner of the window. The "z" component is filled with 338 the fragment's z window coordinate. If z window coordinates are 339 represented internally by the GL as fixed-point values, the z window 340 coordinate undergoes an implied conversion to floating point. This 341 conversion must leave the values 0 and 1 invariant. The "w" component is 342 filled with the reciprocal of the fragment's clip w coordinate. 343 344 If a fragment attribute binding matches "fragment.facing", the "x" 345 component of the fragment attribute variable is filled with +1.0 or -1.0, 346 depending on the orientation of the primitive producing the fragment. If 347 the fragment is generated by a back-facing polygon (including point- and 348 line-mode polygons), the facing is -1.0; otherwise, the facing is +1.0. 349 The "y", "z", and "w" coordinates are undefined. 350 351 If a fragment attribute binding matches "primitive.id", the "x" component 352 of the fragment attribute variable is filled with a single integer. If a 353 geometry program is active, this value is obtained by taking the primitive 354 ID value emitted by the geometry program for the provoking vertex. If no 355 geometry program is active, the value is the number of primitives 356 processed by the rasterizer since the last time Begin was called (directly 357 or indirectly via vertex array functions). The first primitive generated 358 after a Begin is numbered zero, and the primitive ID counter is 359 incremented after every individual point, line, or polygon primitive is 360 processed. For polygons drawn in point or line mode, the primitive ID 361 counter is incremented only once, even though multiple points or lines may 362 be drawn. For QUADS and QUAD_STRIP primitives that are decomposed into 363 triangles, the primitive ID is incremented after each complete quad is 364 processed. For POLYGON primitives, the primitive ID counter is zero. The 365 primitive ID is zero for fragments generated by DrawPixels or Bitmap. 366 Restarting a primitive topology using the primitive restart index has no 367 effect on the primitive ID counter. The "y", "z", and "w" components of 368 the variable are always undefined. 369 370 (add the following subsection to section 2.X.3.5, Program Results.) 371 372 Fragment programs produce final fragment values, and the set of result 373 variables available to such programs correspond to the final attributes of 374 a fragment. Fragment program result variables may not be declared as 375 arrays. 376 377 The set of allowable result variable bindings is given in Table X.X. 378 379 Binding Components Description 380 ----------------------------- ---------- ---------------------------- 381 result.color (r,g,b,a) color 382 result.color[n] (r,g,b,a) color output n 383 result.depth (*,*,d,*) depth coordinate 384 385 Table X.X: Fragment Result Variable Bindings. 386 Components labeled "*" are unused. 387 388 If a result variable binding matches "result.color", updates to the "x", 389 "y", "z", and "w" components of the result variable modify the "r", "g", 390 "b", and "a" components, respectively, of the fragment's output color. 391 392 If a result variable binding matches "result.color[n]" and the 393 ARB_draw_buffers program option is specified, updates to the "x", "y", 394 "z", and "w" components of the color result variable modify the "r", "g", 395 "b", and "a" components, respectively, of the fragment output color 396 numbered <n>. If the ARB_draw_buffers program option is not specified, 397 the "result.color[n]" binding is unavailable. 398 399 If a result variable binding matches "result.depth", updates to the "z" 400 component of the result variable modify the fragment's output depth value. 401 If the "result.depth" binding is not in used in a variable written to by 402 any instruction in the fragment program, the interpolated depth value 403 produced by rasterization is used as if fragment program mode is not 404 enabled. Otherwise, the value written by the fragment program is used, 405 and the fragment's final depth value is undefined if the program did not 406 end up writing a depth value due to flow control or write masks. Writes 407 to any component of depth other than the "z" component have no effect. 408 409 (modify Table X.13 in section 2.X.4, Program Instructions, to include the 410 following.) 411 412 Modifiers 413 Instruction F I C S H D Inputs Out Description 414 ----------- - - - - - - ---------- --- -------------------------------- 415 DDX X - X X X F v v partial derivative relative to X 416 DDY X - X X X F v v partial derivative relative to Y 417 KIL X X - - X F vc - kill fragment 418 419 (add the following subsection to section 2.X.6, Program Options.) 420 421 Section 2.X.6.Y, Fragment Program Options 422 423 + Fixed-Function Fog Emulation (ARB_fog_exp, ARB_fog_exp2, ARB_fog_linear) 424 425 If a fragment program specifies one of the options "ARB_fog_exp", 426 "ARB_fog_exp2", or "ARB_fog_linear", the program will apply fog to the 427 program's final color using a fog mode of EXP, EXP2, or LINEAR, 428 respectively, as described in section 3.10. 429 430 When a fog option is specified in a fragment program, semantic 431 restrictions are added to indicate that a fragment program will fail to 432 load if the number of temporaries it contains exceeds the 433 implementation-dependent limit minus 1, if the number of attributes it 434 contains exceeds the implementation-dependent limit minus 1, or if the 435 number of parameters it contains exceeds the implementation-dependent 436 limit minus 2. 437 438 Additionally, when the ARB_fog_exp option is specified in a fragment 439 program, a semantic restriction is added to indicate that a fragment 440 program will fail to load if the number of instructions or ALU 441 instructions it contains exceeds the implementation-dependent limit minus 442 3. When the ARB_fog_exp2 option is specified in a fragment program, a 443 semantic restriction is added to indicate that a fragment program will 444 fail to load if the number of instructions or ALU instructions it contains 445 exceeds the implementation-dependent limit minus 4. When the 446 ARB_fog_linear option is specified in a fragment program, a semantic 447 restriction is added to indicate that a fragment program will fail to load 448 if the number of instructions or ALU instructions it contains exceeds the 449 implementation-dependent limit minus 2. 450 451 Only one fog application option may be specified by any given fragment 452 program. A fragment program that specifies more than one of the program 453 options "ARB_fog_exp", "ARB_fog_exp2", and "ARB_fog_linear", will fail to 454 load. 455 456 + Precision Hints (ARB_precision_hint_fastest, ARB_precision_hint_nicest) 457 458 Fragment program computations are carried out at an implementation- 459 dependent precision. However, some implementations may be able to perform 460 fragment program computations at more than one precision, and may be able 461 to trade off computation precision for performance. 462 463 If a fragment program specifies the "ARB_precision_hint_fastest" program 464 option, implementations should select precision to minimize program 465 execution time, with possibly reduced precision. If a fragment program 466 specifies the "ARB_precision_hint_nicest" program option, implementations 467 should maximize the precision, with possibly increased execution time. 468 469 Only one precision control option may be specified by any given fragment 470 program. A fragment program that specifies both the 471 "ARB_precision_hint_fastest" and "ARB_precision_hint_nicest" program 472 options will fail to load. 473 474 + Multiple Color Outputs (ARB_draw_buffers, ATI_draw_buffers) 475 476 If a fragment program specifies the "ARB_draw_buffers" or 477 "ATI_draw_buffers" option, it will generate multiple output colors, and 478 the result binding "result.color[n]" is allowed, as described in section 479 2.X.3.5. If this option is not specified, a fragment program that 480 attempts to bind "result.color[n]" will fail to load, and only 481 "result.color" will be allowed. 482 483 The multiple color outputs will typically be written to an ordered list of 484 draw buffers in the manner described in the ARB_draw_buffers extension 485 specification. 486 487 + Fragment Program Shadows (ARB_fragment_program_shadow) 488 489 The ARB_fragment_program_shadow option introduced a set of "SHADOW" 490 texture targets and made the results of depth texture lookups undefined 491 unless the texture format and compare mode were consistent with the target 492 provided in the fragment program instruction. This behavior is enabled by 493 default in NV_gpu_program4; specifying the option is not illegal but has 494 no additional effect. 495 496 (add the following subsection to section 2.X.7, Program Declarations.) 497 498 Section 2.X.7.Y, Fragment Program Declarations 499 500 No declarations are supported at present for fragment programs. 501 502 503 (add the following subsection to section 2.X.8, Program Instruction Set.) 504 505 Section 2.X.8.Z, DDX: Partial Derivative Relative to X 506 507 The DDX instruction computes approximate partial derivatives of the four 508 components of the single floating-point vector operand with respect to the 509 X window coordinate to yield a result vector. The partial derivatives are 510 evaluated at the sample location of the pixel. 511 512 f = VectorLoad(op0); 513 result = ComputePartialX(f); 514 515 Note that the partial derivates obtained by this instruction are 516 approximate, and derivative-of-derivate instruction sequences may not 517 yield accurate second derivatives. Note also that the sample locations 518 for attributes declared with the CENTROID interpolation modifier may not 519 be evenly spaced, which can lead to artifacts in derivative calculations. 520 521 DDX supports only floating-point data type modifiers and is available only 522 to fragment programs. 523 524 Section 2.X.8.Z, DDY: Partial Derivative Relative to Y 525 526 The DDY instruction computes approximate partial derivatives of the four 527 components of the single operand with respect to the Y window coordinate 528 to yield a result vector. The partial derivatives are evaluated at the 529 center of the pixel. 530 531 f = VectorLoad(op0); 532 result = ComputePartialY(f); 533 534 Note that the partial derivates obtained by this instruction are 535 approximate, and derivative-of-derivate instruction sequences may not 536 yield accurate second derivatives. Note also that the sample locations 537 for attributes declared with the CENTROID interpolation modifier may not 538 be evenly spaced, which can lead to artifacts in derivative calculations. 539 540 DDY supports only floating-point data type modifiers and is available only 541 to fragment programs. 542 543 Section 2.X.8.Z, KIL: Kill Fragment 544 545 The KIL instruction evaluates a condition and kills a fragment if the test 546 passes. A fragment killed by the KIL instruction is discarded, and will 547 not be seen by subsequent stages of the pipeline. 548 549 A KIL instruction may be specified using either a floating-point or 550 integer vector operand or a condition code test. 551 552 If a floating-point or integer vector is provided, the fragment is 553 discarded if any of its components are negative: 554 555 tmp = VectorLoad(op0); 556 if ((tmp.x < 0) || (tmp.y < 0) || 557 (tmp.z < 0) || (tmp.w < 0)) 558 { 559 exit; 560 } 561 562 Unsigned integer vector operands are permitted; however, KIL.U will have 563 no effect as no component is negative by definition. 564 565 If a condition code test is provided, the fragment is discarded if any 566 component of the test passes: 567 568 if (TestCC(rc.c***) || TestCC(rc.*c**) || 569 TestCC(rc.**c*) || TestCC(rc.***c)) 570 { 571 exit; 572 } 573 574 KIL supports all three data type modifiers. 575 576 KIL is available only to fragment programs. 577 578 Replace Section 2.14.8, and rename it to "Vertex Attribute Clipping" 579 (p. 70). 580 581 After lighting, clamping or masking and possible flatshading, vertex 582 attributes, including colors, texture and fog coordinates, shader varying 583 variables, and point sizes computed on a per vertex basis, are clipped. 584 Those attributes associated with a vertex that lies within the clip volume 585 are unaffected by clipping. If a primitive is clipped, however, the 586 attributes assigned to vertices produced by clipping are produced by 587 interpolating attributes along the clipped edge. 588 589 Let the attributes assigned to the two vertices P_1 and P_2 of an 590 unclipped edge be a_1 and a_2. The value of t (section 2.12) for a 591 clipped point P is used to obtain the attribute associated with P as 592 593 a = t * a_1 + (1-t) * a_2 594 595 unless the attribute is specified to be interpolated without perspective 596 correction in a fragment program. In that case, the attribute associated 597 with P is 598 599 a = t' * a_1 + (1-t') * a_2 600 601 where 602 603 t' = (t * w_1) / (t * w_1 + (1-t) * w_2) 604 605 and w_1 and w_2 are the w clip coordinates of P_1 and P_2, 606 respectively. If w_1 or w_2 is either zero or negative, the value of the 607 associated attribute is undefined. 608 609Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 610 611 None 612 613Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 614Operations and the Frame Buffer) 615 616 None 617 618Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 619 620 None 621 622Additions to Chapter 6 of the OpenGL 2.0 Specification (State and 623State Requests) 624 625 None 626 627Additions to the AGL/GLX/WGL Specifications 628 629 None 630 631Dependencies on ARB_draw_buffers and ATI_draw_buffers 632 633 If neither ARB_draw_buffers nor ATI_draw_buffers is supported, then the 634 discussion of the ARB_draw_buffers option in section 2.X.6.Y should be 635 removed, as well as the result bindings of the form "result.color[n]" and 636 "result.color[n..o]". 637 638Dependencies on ARB_fragment_program_shadow 639 640 If ARB_fragment_program_shadow is not supported, then the discussion of 641 the ARB_fragment_program_shadow option in section 2.X.6.Y should be 642 removed. 643 644Dependencies on NV_primitive_restart 645 646 The spec describes the behavior that primitive restart does not affect the 647 primitive ID counter, including for POLYGON primitives (where one could 648 argue that the restart index starts a new primitive without a new Begin to 649 reset the count. If NV_primitive_restart is not supported, references to 650 that extension in the discussion of the "primitive.id" attribute should be 651 removed. 652 653Errors 654 655 None 656 657New State 658 659 None 660 661New Implementation Dependent State 662 663 None 664 665Issues 666 667 (1) How should special interpolation controls be specified? 668 669 RESOLVED: As a special modifier to fragment program attribute variable 670 declarations. It was decided that the fragment program was the most 671 natural place to put the control. This wouldn't require making a large 672 number of related state changes controlling interpolation whenever the 673 fragment program used. The final mechanism using special interpolation 674 modifiers was chosen because it fit well with the other variable 675 modifiers (for data storage size and data type) provided by 676 NV_gpu_program4. Examples: 677 678 FLAT ATTRIB texcoords[4] = { fragment.texcoord[0..3] }; 679 CENTROID ATTRIB texcoord4 = fragment.texcoord[4]; 680 CENTROID NOPERSPECTIVE ATTRIB 681 attribs[3] = { fragment.attrib[0..2] }; 682 683 There were a variety of options considered, including: 684 685 * special declarations in vertex or geometry programs to specify the 686 interpolation type, 687 688 * special declarations in the fragment program to specify one or more 689 interpolation type modifiers per binding, such as: 690 691 INTERPOLATE fragment.texcoord[0..3], FLAT; 692 INTERPOLATE fragment.texcoord[4], CENTROID; 693 INTERPOLATE fragment.attrib[0..2], CENTROID, NOPERSPECTIVE; 694 695 * fixed-function state specifying the interpolation mode 696 697 glInterpolateAttribNV(GL_TEXTURE0, GL_FLAT); 698 glInterpolateAttribNV(GL_GENERIC_ATTRIB0, GL_CENTROID_NV); 699 700 Recent updates to GLSL provide similar functionality (for centroid) with 701 a similar approach, using a modifier on varying variable declarations. 702 703 (2) How should perspective-incorrect interpolation (linear in screen 704 space) and clipping interact? 705 706 RESOLVED: Primitives with attributes specified to be 707 perspective-incorrect should be clipped so that the vertices introduced 708 by clipping should have attribute values consistent with the 709 interpolation mode. We do not want to have large color shifts 710 introduced by clipping a perspective-incorrect attribute. For example, 711 a primitive that approaches, but doesn't cross, a frustum clip plane 712 should look pretty much identical to a similar primitive that just 713 barely crosses the clip plane. 714 715 Clipping perspective-incorrect interpolants that cross the W==0 plane is 716 very challenging. The attribute clipping equation provided in the spec 717 effectively projects all the original vertices to screen space while 718 ignoring the X and Y frustum clip plane. As W approaches zero, the 719 projected X/Y window coordinates become extremely large. When clipping 720 an edge with one vertex inside the frustum and the other out near 721 infinity (after projection, due to W approaching zero), the interpolated 722 attribute for the entire visible portion of the edge should almost 723 exactly match the attribute value of the visible vertex. 724 725 If an outlying vertex approaches and then goes past W==0, it can be said 726 to go "to infinity and beyond" in screen space. The correct answer for 727 screen-linear interpolation is no longer obvious, at least to the author 728 of this specification. Rather than trying to figure out what the 729 "right" answer is or if one even exists, the results of clipping such 730 edges is specified as undefined. 731 732 (3) If a shader wants to use interpolation modifiers without using 733 declared variables, is that possible? 734 735 RESOLVED: Yes. If "dummy" variables are declared, all interpolants 736 bound to that variable will get the variable's interpolation modifiers. 737 In the following program: 738 739 FLAT ATTRIB tc02[3] = { fragment.texcoord[0..2] }; 740 MOV R0, fragment.texcoord[1]; 741 MOV R1, fragment.texcoord[3]; 742 743 The variable R0 will get texture coordinate set 1, which will be 744 flat-shaded due to the declaration of "tc02". The variable R1 will get 745 texture coordinate set 3, which will be smooth shaded (default). 746 747 (4) Is it possible to read the same attribute with different interpolation 748 modifiers? 749 750 RESOLVED: No. A program that tries to do that will fail to compile. 751 752 (5) Why can't fragment program results be declared as arrays? 753 754 RESOLVED: This is a limitation of the programming model. If an 755 implementation needs to do run-time indexing of fragment program result 756 variables (effectively writing to "result.color[A0.x]"), code such as 757 the following can be used: 758 759 TEMP colors[4]; 760 ... 761 MOV colors[A0.x], R1; 762 MOV colors[3], 12.3; 763 ... 764 # end of the program 765 MOV result.color[0], colors[0]; 766 MOV result.color[1], colors[1]; 767 MOV result.color[2], colors[2]; 768 MOV result.color[3], colors[3]; 769 770 (6) Do clip distances require that the corresponding clip planes be 771 enabled to be read by a fragment program? 772 773 RESOLVED: No. 774 775 (7) How do primitive IDs work with fragment programs? 776 777 RESOLVED: If a geometry program is enabled, the primitive ID is 778 consumed by the geometry program and is not automatically available to 779 the fragment program. If the fragment program needs a primitive ID in 780 this case, the geometry program can write out a primitive ID using the 781 "result.primid" binding, and the fragment program will see the primitive 782 ID written for the provoking vertex. 783 784 If no geometry program is enabled, the primitive ID is automatically 785 available, and specifies the number of primitives (points, lines, or 786 triangles) processed by since the last explicit or implicit Begin call. 787 788 (8) What is the primitive ID for non-geometry commands that generate 789 fragments, such as DrawPixels, Bitmap, and CopyPixels. 790 791 RESOLVED: Zero. 792 793 (9) How does the FLAT interpolation modifier interact with point sprite 794 coordinate replacement? 795 796 RESOLVED: The value of such attributes are undefined. Specifying these 797 two operations together is self-contradictory -- FLAT asks for an 798 interpolant that is constant over a primitive, and point sprite 799 coordinate interpolation asks for an interpolant that is non-constant 800 over a point sprite. 801 802 803Revision History 804 805 Rev. Date Author Changes 806 ---- -------- -------- -------------------------------------------- 807 6 05/26/09 pbrown Fix documentation of KIL to support integer 808 operands, as indicated in the opcodes table 809 in NV_gpu_program4. 810 811 5 03/11/09 pbrown Fix section numbers for option/declaration 812 sections. 813 814 4 11/06/07 pbrown Documented interaction between the FLAT 815 interpolation modifier and point sprite 816 coordinate replacement. 817 818 1-3 pbrown Internal spec development. 819