1Name 2 3 NV_vertex_program 4 5Name Strings 6 7 GL_NV_vertex_program 8 9Contact 10 11 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 12 13Notice 14 15 Copyright NVIDIA Corporation, 2000, 2001, 2002, 2003, 2004. 16 17IP Status 18 19 NVIDIA Proprietary. 20 21Status 22 23 Shipping, spec at version 1.10. 24 25Version 26 27 NVIDIA Date: March 31, 2009 28 Revision: 1.10 29 30Number 31 32 233 33 34Dependencies 35 36 Written based on the wording of the OpenGL 1.2.1 specification and 37 requires OpenGL 1.2.1. 38 39 Requires support for the ARB_multitexture extension with at least 40 two texture units. 41 42 EXT_point_parameters affects the definition of this extension. 43 44 EXT_secondary_color affects the definition of this extension. 45 46 EXT_fog_coord affects the definition of this extension. 47 48 EXT_vertex_weighting affects the definition of this extension. 49 50 ARB_imaging affects the definition of this extension. 51 52Overview 53 54 Unextended OpenGL mandates a certain set of configurable per-vertex 55 computations defining vertex transformation, texture coordinate 56 generation and transformation, and lighting. Several extensions 57 have added further per-vertex computations to OpenGL. For example, 58 extensions have defined new texture coordinate generation modes 59 (ARB_texture_cube_map, NV_texgen_reflection, NV_texgen_emboss), new 60 vertex transformation modes (EXT_vertex_weighting), new lighting modes 61 (OpenGL 1.2's separate specular and rescale normal functionality), 62 several modes for fog distance generation (NV_fog_distance), and 63 eye-distance point size attenuation (EXT_point_parameters). 64 65 Each such extension adds a small set of relatively inflexible 66 per-vertex computations. 67 68 This inflexibility is in contrast to the typical flexibility provided 69 by the underlying programmable floating point engines (whether 70 micro-coded vertex engines, DSPs, or CPUs) that are traditionally used 71 to implement OpenGL's per-vertex computations. The purpose of this 72 extension is to expose to the OpenGL application writer a significant 73 degree of per-vertex programmability for computing vertex parameters. 74 75 For the purposes of discussing this extension, a vertex program is 76 a sequence of floating-point 4-component vector operations that 77 determines how a set of program parameters (defined outside of 78 OpenGL's begin/end pair) and an input set of per-vertex parameters 79 are transformed to a set of per-vertex output parameters. 80 81 The per-vertex computations for standard OpenGL given a particular 82 set of lighting and texture coordinate generation modes (along with 83 any state for extensions defining per-vertex computations) is, in 84 essence, a vertex program. However, the sequence of operations is 85 defined implicitly by the current OpenGL state settings rather than 86 defined explicitly as a sequence of instructions. 87 88 This extension provides an explicit mechanism for defining vertex 89 program instruction sequences for application-defined vertex programs. 90 In order to define such vertex programs, this extension defines 91 a vertex programming model including a floating-point 4-component 92 vector instruction set and a relatively large set of floating-point 93 4-component registers. 94 95 The extension's vertex programming model is designed for efficient 96 hardware implementation and to support a wide variety of vertex 97 programs. By design, the entire set of existing vertex programs 98 defined by existing OpenGL per-vertex computation extensions can be 99 implemented using the extension's vertex programming model. 100 101Issues 102 103 What should this extension be called? 104 105 RESOLUTION: NV_vertex_program. DirectX 8 refers to its similar 106 functionality as "vertex shaders". This is a confusing term 107 because shaders are usually assumed to operate at the fragment or 108 pixel level, not the vertex level. 109 110 Conceptually, what the extension defines is an application-defined 111 program (admittedly limited by its sequential execution model) for 112 processing vertices so the "vertex program" term is more accurate. 113 114 Additionally, some of the API machinery in this extension for 115 describing programs could be useful for extending other OpenGL 116 operations with programs (though other types of programs would 117 likely look very different from vertex programs). 118 119 What terms are important to this specification? 120 121 vertex program mode - when vertex program mode is enabled, vertices 122 are transformed by an application-defined vertex program. 123 124 conventional GL vertex transform mode - when vertex program mode 125 is disabled (or the extension is not supported), vertices are 126 transformed by GL's conventional texgen, lighting, and transform 127 state. 128 129 provoke - the verb that denotes the beginning of vertex 130 transformation by either vertex program mode or conventional GL 131 vertex transform mode. Vertices are provoked when either glVertex 132 or glVertexAttribNV(0, ...) is called. 133 134 program target - a type or class of program. This extension 135 supports two program targets: the vertex program and the vertex 136 state program. Future extensions could add other program targets. 137 138 vertex program - an application-defined vertex program used to 139 transform vertices when vertex program mode is enabled. 140 141 vertex state program - a program similar to a vertex program. 142 Unlike a vertex program, a vertex state program runs outside of 143 a glBegin/glEnd pair. Vertex state programs do not transform 144 a vertex. They just update program parameters. 145 146 vertex attribute - one of 16 4-component per-vertex parameters 147 defined by this extension. These attributes alias with the 148 conventional per-vertex parameters. 149 150 per-vertex parameter - a vertex attribute or a conventional 151 per-vertex parameter such as set by glNormal3f or glColor3f. 152 153 program parameter - one of 96 4-component registers available 154 to vertex programs. The state of these registers is shared 155 among all vertex programs. 156 157 What part of OpenGL do vertex programs specifically bypass? 158 159 Vertex programs bypass the following OpenGL functionality: 160 161 o Normal transformation and normalization 162 163 o Color material 164 165 o Per-vertex lighting 166 167 o Texture coordinate generation 168 169 o The texture matrix 170 171 o The normalization of AUTO_NORMAL evaluated normals 172 173 o The modelview and projection matrix transforms 174 175 o The per-vertex processing in EXT_point_parameters 176 177 o The per-vertex processing in NV_fog_distance 178 179 o Raster position transformation 180 181 o Client-defined clip planes 182 183 Operations not subsumed by vertex programs 184 185 o The view frustum clip 186 187 o Perspective divide (division by w) 188 189 o The viewport transformation 190 191 o The depth range transformation 192 193 o Clamping the primary and secondary color to [0,1] 194 195 o Primitive assembly and subsequent operations 196 197 o Evaluator (except the AUTO_NORMAL normalization) 198 199 How specific should this specification be about precision? 200 201 RESOLUTION: Reasonable precision requirements are incorporated 202 into the specification beyond the often vague requirements of the 203 core OpenGL specification. 204 205 This extension essentially defines an instruction set and its 206 corresponding execution environment. The instruction set specified 207 may find applications beyond the traditional purposes of 3D vertex 208 transformation, lighting, and texture coordinate generation that 209 have fairly lax precision requirements. To facilitate such 210 possibly unexpected applications of this functionality, minimum 211 precision requirements are specified. 212 213 The minimum precision requirements in the specification are meant 214 to serve as a baseline so that application developers can write 215 vertex programs with minimal worries about precision issues. 216 217 What about when the "execution environment" involves support for 218 other extensions? 219 220 This extension assumes support for functionality that includes 221 a fog distance, secondary color, point parameters, and multiple 222 texture coordinates. 223 224 There is a trade-off between requiring support for these extensions 225 to guarantee a particular extended execution environment and 226 requiring lots of functionality that everyone might not support. 227 228 Application developers will desire a high baseline of functionality 229 so that OpenGL applications using vertex programs can work in 230 the full context of OpenGL. But if too much is required, the 231 implementation burden mandated by the extension may limit the 232 number of available implementations. 233 234 Clearly we do not want to require support for 8 texture units 235 even if the machinery is there for it. Still multitexture is a 236 common and important feature for using vertex programs effectively. 237 Requiring at least two texture units seems reasonable. 238 239 What do we say about the alpha component of the secondary color? 240 241 RESOLUTION: When vertex program mode is enabled, the alpha 242 component of csec used for the color sum state is assumed always 243 zero. Another downstream extension may actually make the alpha 244 component written into the COL1 (or BFC1) vertex result register 245 available. 246 247 Should client-defined clip planes operate when vertex program mode is 248 enabled? 249 250 RESOLUTION. No. 251 252 OpenGL's client-defined clip planes are specified in eye-space. 253 Vertex programs generate homogeneous clip space positions. 254 Unlike the conventional OpenGL vertex transformation mode, vertex 255 program mode requires no semantic equivalent to eye-space. 256 257 Applications that require client-defined clip planes can simulate 258 OpenGL-style client-defined clip planes by generating texture 259 coordinates and using alpha testing or other per-fragment tests 260 such as NV_texture_shader's CULL_FRAGMENT_NV program to discard 261 fragments. In many ways, these schemes provide a more flexible 262 mechanism for clipping than client-defined clip planes. 263 264 Unfortunately, vertex programs used in conjunction with selection 265 or feedback will not have a means to support client-defined clip 266 planes because the per-fragment culling mechanisms described in the 267 previous paragraph are not available in the selection or feedback 268 render modes. Oh well. 269 270 Finally, as a practical concern, client-defined clip planes 271 greatly complicate clipping for various hardware rasterization 272 architectures. 273 274 How are edge flags handled? 275 276 RESOLUTION: Passed through without the ability to be modified by 277 a vertex program. Applications are free to send edge flags when 278 vertex program mode is enabled. 279 280 Should vertex attributes alias with conventional per-vertex 281 parameters? 282 283 RESOLUTION. YES. 284 285 This aliasing should make it easy to use vertex programs with 286 existing OpenGL code that transfers per-vertex parameters using 287 conventional OpenGL per-vertex calls. 288 289 It also minimizes the number of per-vertex parameters that the 290 hardware must maintain. 291 292 See Table X.2 for the aliasing of vertex attributes and conventional 293 per-vertex parameters. 294 295 How should vertex attribute arrays interact with conventional vertex 296 arrays? 297 298 RESOLUTION: When vertex program mode is enabled, a particular 299 vertex attribute array will be used if enabled, but if disabled, 300 and the corresponding aliased conventional vertex array is enabled 301 (assuming that there is a corresponding aliased conventional vertex 302 array for the particular vertex array), the conventional vertex 303 array will be used. 304 305 This matches the way immediate mode per-vertex parameter aliasing 306 works. 307 308 This does slightly complicate vertex array validation in program 309 mode, but programmers using vertex arrays can simply enable vertex 310 program mode without reconfiguring their conventional vertex arrays 311 and get what they expect. 312 313 Note that this does create an asymmetry between immediate mode 314 and vertex arrays depending on whether vertex program mode is 315 enabled or not. The immediate mode vertex attribute commands 316 operate unchanged whether vertex program mode is enabled or not. 317 However the vertex attribute vertex arrays are used only when 318 vertex program mode is enabled. 319 320 Supporting vertex attribute vertex arrays when vertex program mode 321 is disabled would create a large implementation burden for existing 322 OpenGL implementations that have heavily optimized conventional 323 vertex arrays. For example, the normal array can be assumed to 324 always contain 3 and only 3 components in conventional OpenGL 325 vertex transform mode, but may contain 1, 2, 3, or 4 components 326 in vertex program mode. 327 328 There is not any additional functionality gained by supporting 329 vertex attribute arrays when vertex program mode is disabled, but 330 there is lots of implementation overhead. In any case, it does not 331 seem something worth encouraging so it is simply not supported. 332 So vertex attribute arrays are IGNORED when vertex program mode 333 is not enabled. 334 335 Ignoring VertexAttribute commands or treating VertexAttribute 336 commands as an error when vertex program mode is enabled 337 would likely add overhead for such a conditional check. The 338 implementation overhead for supporting VertexAttribute commands 339 when vertex program mode is disabled is not that significant. 340 Additionally, it is likely that setting persistent vertex attribute 341 state while vertex program mode is disabled may be useful to 342 applications. So vertex attribute immediate mode commands are 343 PERMITTED when vertex program mode is not enabled. 344 345 Colors and normals specified as ints, uints, shorts, ushorts, bytes, 346 and ubytes are converted to floating-point ranges when supplied to 347 core OpenGL as described in Table 2.6. Other per-vertex attributes 348 such as texture coordinates and positions are not converted. 349 How does this mix with vertex programs where all vertex attributes 350 are supposedly treated identically? 351 352 RESOLUTION: Vertex attributes specified as bytes and ubytes are 353 always converted as described in Table 2.6. All other formats are 354 not converted according to Table 2.6 but simply converted directly 355 to floating-point. 356 357 The ubyte type is converted because those types seem more useful 358 for passing colors in the [0,1] range. 359 360 If an application desires a conversion, the conversion can be 361 incorporated into the vertex program itself. 362 363 This also applies to vertex attribute arrays. However, by enabling 364 a color or normal vertex array and not enabling the corresponding 365 aliased vertex attribute array, programmers can get the conventional 366 conversions for color and normal arrays (but only for the vertex 367 attribute arrays that alias to the conventional color and normal 368 arrays and only with the sizes/types supported by these color and 369 normal arrays). 370 371 Should programs be C-style null-terminated strings? 372 373 RESOLUTION: No. Programs should be specified as an array of 374 GLubyte with an explicit length parameter. OpenGL has no precedent 375 for passing null-terminated strings into the API (though glGetString 376 returns null-terminated strings). Null-terminated strings are 377 problematic for some languages. 378 379 Should all existing OpenGL transform functionality and extensions 380 be implementable as vertex programs? 381 382 RESOLUTION: Yes. Vertex programs should be a complete superset 383 of what you can do with OpenGL 1.2 and existing vertex transform 384 extensions. 385 386 To implement EXT_point_parameters, the 387 GL_VERTEX_PROGRAM_POINT_SIZE_NV enable is introduced. 388 389 To implement two-sided lighting, the GL_VERTEX_PROGRAM_TWO_SIDE_NV 390 enable is introduced. 391 392 How does glPointSize work with vertex programs? 393 394 RESOLUTION: If GL_VERTEX_PROGRAM_POINT_SIZE_NV is disabled, the size 395 of points is determine by the glPointSize state. If enabled, 396 the point size is determined per-vertex by the clamped value of 397 the vertex result PSIZ register. 398 399 Can the currently bound vertex program object name be deleted or 400 reloaded? 401 402 RESOLUTION. Yes. When a vertex program object name is deleted 403 or reloaded when it is the currently bound vertex program object, 404 it is as if a rebind occurs after the deletion or reload. 405 406 In the case of a reload, the new vertex program object will be 407 used from then on. In the case of a deletion, the current vertex 408 program object will be treated as if it is nonexistent. 409 410 Should program objects have a mechanism for managing program 411 residency? 412 413 RESOLUTION: Yes. Vertex program instruction memory is a limited 414 hardware resource. glBindProgramNV will be faster if binding to 415 a resident program. Applications are likely to want to quickly 416 switch between a small collection of programs. 417 418 glAreProgramsResidentNV allows the residency status of a 419 group of programs to be queried. This mimics 420 glAreTexturesResident. 421 422 Instead of adopting the glPrioritizeTextures mechanism, a new 423 glRequestResidentProgramsNV command is specified instead. 424 Assigning priorities to textures has always been a problematic 425 endeavor and few OpenGL implementations implemented it effectively. 426 For the priority mechanism to work well, it requires the client 427 to routinely update the priorities of textures. 428 429 The glRequestResidentProgramsNV indicates to the GL that a 430 set of programs are intended for use together. Because all 431 the programs are requesting residency as a group, drivers 432 should be able to attempt to load all the requested programs 433 at once (and remove from residency programs not in the group if 434 necessary). Clients can use glAreProgramsResidentNV to query the 435 relative success of the request. 436 437 glRequestResidentProgramsNV should be superior to loading programs 438 on-demand because fragmentation can be avoided. 439 440 What happens when you execute a nonexistent or invalid program? 441 442 RESOLUTION: glBegin will fail with a GL_INVALID_OPERATION if the 443 currently bound vertex program is nonexistent or invalid. The same 444 applies to glRasterPos and any command that implies a glBegin. 445 446 Because the glVertex and glVertexAttribNV(0, ...) are ignored 447 outside of a glBegin/glEnd pair (without generating an error) it 448 is impossible to provoke a vertex program if the current vertex 449 program is nonexistent or invalid. Other per-vertex parameters 450 (for examples those set by glColor, glNormal, and glVertexAttribNV 451 when the attribute number is not zero) are recorded since they 452 are legal outside of a glBegin/glEnd. 453 454 For vertex state programs, the problem is simpler because 455 glExecuteProgramNV can immediately fail with a GL_INVALID_OPERATION 456 when the named vertex state program is nonexistent or invalid. 457 458 What happens when a matrix has been tracked into a set of program 459 parameters, but then glTrackMatrixNV(GL_VERTEX_PROGRAM_NV, addr, 460 GL_NONE, GL_IDENTITY_NV) is performed? 461 462 RESOLUTION: The specified program parameters stop tracking a 463 matrix, but they retain the values of the matrix they were last 464 tracking. 465 466 Can rows of tracked matrices be queried by querying the program 467 parameters that track them? 468 469 RESOLUTION: Yes. 470 471 Discussing matrices is confusing because of row-major versus 472 column-major issues. Can you give an example of how a matrix is 473 tracked? 474 475 // When loaded, the first row is "1, 2, 3, 4", because of column-major 476 // (OpenGL spec) vs. row-major (C) differences. 477 GLfloat matrix[16] = { 1, 5, 9, 13, 478 2, 6, 10, 14, 479 3, 7, 11, 15, 480 4, 8, 12, 16 }; 481 GLfloat row1[4], row2[4]; 482 483 glMatrixMode(GL_MATRIX0_NV); 484 glLoadMatrixf(matrix); 485 glTrackMatrixNV(GL_VERTEX_PROGRAM_NV, 4, GL_MATRIX0_NV, GL_IDENTITY_NV); 486 glTrackMatrixNV(GL_VERTEX_PROGRAM_NV, 8, GL_MATRIX0_NV, GL_TRANSPOSE_NV); 487 glGetProgramParameterfvNV(GL_VERTEX_PROGRAM_NV, 5, 488 GL_PROGRAM_PARAMETER_NV, row1); 489 /* row1 is now [ 5 6 7 8 ] */ 490 glGetProgramParameterfvNV(GL_VERTEX_PROGRAM_NV, 9, 491 GL_PROGRAM_PARAMETER_NV, row2); 492 /* row2 is now [ 2 6 10 14 ] because the tracked matrix is transposed */ 493 494 Should evaluators be extended to evaluate arbitrary vertex 495 attributes? 496 497 RESOLUTION: Yes. We'll support 32 new maps (16 for MAP1 and 16 498 for MAP2) that take priority over the conventional maps that they 499 might alias to (only when vertex program mode is enabled). 500 501 These new maps always evaluate all four components. The rationale 502 for this is that if we supported 1, 2, 3, or 4 components, that 503 would add 128 (16*4*2) enumerants which is too many. In addition, 504 if you wanted to evaluate two 2-component vertex attributes, you 505 could instead generate one 4-component vertex attribute and use 506 the vertex program with swizzling to treat this as two-components. 507 508 Moreover, we are assuming 4-component vector instructions so less 509 than 4-component evaluations might not be any more efficient 510 than 4-component evaluations. Implementations that use vector 511 instructions such as Intel's SSE instructions will be easier to 512 implement since they can focus on optimizing just the 4-component 513 case. 514 515 How should GL_AUTO_NORMAL work with vertex programs? 516 517 RESOLUTION: GL_AUTO_NORMAL should NOT guarantee that the generated 518 analytical normal be normalized. In vertex program mode, the 519 current vertex program can easily normalize the normal if required. 520 521 This can lead to greater efficiency if the vertex program transforms 522 the normal to another coordinate system such as eye-space with a 523 transform that preserves vector length. Then a single normalize 524 after transform is more efficient than normalizing after evaluation 525 and also normalizing after transform. 526 527 Conceptually, the normalize mandated for AUTO_NORMAL in section 528 5.1 is just one of the many transformation operations subsumed by 529 vertex programs. 530 531 Should the new vertex program related enables push/pop with 532 GL_ENABLE_BIT? 533 534 RESOLUTION: Yes. Pushing and popping enable bits is easy. 535 This includes the 32 new evaluator map enable bits. These evaluator 536 enable bits are also pushed and popped using GL_EVAL_BIT. 537 538 Should all the vertex attribute state push/pop with GL_CURRENT_BIT? 539 540 RESOLUTION: Yes. The state is aliased with the conventional 541 per-vertex parameter state so it really should push/pop. 542 543 Should all the vertex attrib vertex array state push/pop with 544 GL_CLIENT_VERTEX_ARRAY_BIT? 545 546 RESOLUTION: Yes. 547 548 Should all the other vertex program-related state push/pop somehow? 549 550 RESOLUTION: No. 551 552 The other vertex program doesn't fit well with the existing bits. 553 To be clear, GL_ALL_ATTRIB_BITS does not push/pop vertex program 554 state other than enables. 555 556 Should we generate a GL_INVALID_OPERATION operation if updating 557 a vertex attribute greater than 15? 558 559 RESOLUTION: Yes. 560 561 The other option would be to mask or modulo the vertex attribute 562 index with 16. This is cheap, but it would make it difficult to 563 increase the number of vertex attributes in the future. 564 565 If we check for the error, it should be a well predicted branch 566 for immediate mode calls. For vertex arrays, the check is only 567 required at vertex array specification time. 568 569 Hopefully this will encourage people to use vertex arrays over 570 immediate mode. 571 572 Should writes to program parameter registers during a vertex program 573 be supported? 574 575 RESOLUTION. No. 576 577 Writes to program parameter registers from within a vertex program 578 would require the execution of vertex programs to be serialized 579 with respect to each other. This would create an unwarranted 580 implementation penalty for parallel vertex program execution 581 implementations. 582 583 However vertex state programs may write to program parameter 584 registers (that is the whole point of vertex state programs). 585 586 Should we support variously sized immediate mode byte and ubyte 587 commands? How about for vertex arrays? 588 589 RESOLUTION. Only support the 4ub mode. 590 591 There are simply too many glVertexAttribNV routines. Passing less 592 than 4 bytes at a time is inefficient. We expect the main use 593 for bytes to be for colors where these will be unsigned bytes. 594 So let's just support 4ub mode for bytes. This applies to 595 vertex arrays too. 596 597 Should we support integer, unsigned integer, and unsigned short 598 formats for vertex attributes? 599 600 RESOLUTION: No. It's just too many immediate mode entry points, 601 most of which are not that useful. Signed shorts are supported 602 however. We expect signed shorts to be useful for passing compact 603 texture coordinates. 604 605 Should we support doubles for vertex attributes? 606 607 RESOLUTION: Yes. Some implementation of the extension might 608 support double precision. Lots of math routines output double 609 precision. 610 611 Should there be a way to determine where in a loaded program 612 string the first parse error occurs? 613 614 RESOLUTION: Yes. You can query PROGRAM_ERROR_POSITION_NV. 615 616 Should program objects be shared among rendering contexts in the 617 same manner as display lists and texture objects? 618 619 RESOLUTION: Yes. 620 621 How should this extension interact with color material? 622 623 RESOLUTION: It should not. Color material is a conventional 624 OpenGL vertex transform mode. It does not have a place for vertex 625 programs. If you want to emulate color material with vertex 626 programs, you would simply write a program where the material 627 parameters feed from the color vertex attribute. 628 629 Should there be a glMatrixMode or glActiveTextureARB style selector 630 for vertex attributes? 631 632 RESOLUTION: No. While this would let us reduce a lot of 633 enumerants down, it would make programming a hassle in lots 634 of cases. Consider having to change the vertex attribute 635 mode to enable a set of vertex arrays. 636 637 How should gets for vertex attribute array pointers? 638 639 RESOLUTION: Add new get commands. Using the existing calls 640 would require adding 4 sets of 16 enumerants stride, type, size, 641 and pointer. That's too many gets. 642 643 Instead add glGetVertexAttribNV and glGetVertexAttribPointervNV. 644 glGetVertexAttribNV is also useful for querying the current vertex 645 attribute. 646 647 glGet and glGetPointerv will not return vertex attribute array 648 pointers. 649 650 Why is the address register numbered and why is it a vector 651 register? 652 653 In the future, A0.y and A0.z and A0.w may exist. For this 654 extension, only A0.x is useful. Also in the future, there may be 655 more than one address register. 656 657 There's a nice consistency in thinking about all the registers 658 as 4-component vectors even if the address register has only one 659 usable component. 660 661 Should vertex programs and vertex state programs be required to 662 have a header token and an end token? 663 664 RESOLUTION: Yes. 665 666 The "!!VP1.0" and "!!VSP1.0" tokens start vertex programs and 667 vertex state programs respectively. Both types of programs must 668 end with the "END" token. 669 670 The initial header token reminds the programmer what type of program 671 they are writing. If vertex programs and vertex state programs are 672 ever read from disk files, the header token can serve as a magic 673 number for identifying vertex programs and vertex state programs. 674 675 The target type for vertex programs and vertex state programs can be 676 distinguished based on their respective grammars independent of the 677 initial header tokens, but the initial header tokens will make it 678 easier for programmers to distinguish the two program target types. 679 680 We expect programs to often be generated by concatenation of 681 program fragments. The "END" token will hopefully reduce bugs 682 due to specifying an incorrectly concatenated program. 683 684 It's tempting to make these additional header and end tokens 685 optional, but if there is a sanity check value in header and end 686 tokens, that value is undermined if the tokens are optional. 687 688 What should be said about rendering invariances? 689 690 RESOLUTION: See the Appendix A additions below. 691 692 The justification for the two rules cited is to support multi-pass 693 rendering when using vertex programs. Different rendering passes 694 will likely use different programs so there must be some means of 695 guaranteeing that two different programs can generate particular 696 identical vertex results between different passes. 697 698 In practice, this does limit the type of vertex program 699 implementations that are possible. 700 701 For example, consider a limited hardware implementation of vertex 702 programs that uses a different floating-point implementation 703 than the CPU's floating-point implementation. If the limited 704 hardware implementation can only run small vertex programs (say 705 the hardware provides on 4 temporary registers instead of the 706 required 12), the implementation is incorrect and non-conformant 707 if programs that only require 4 temporary registers use the vertex 708 program hardware, but programs that require more than 4 temporary 709 registers are implemented by the CPU. 710 711 This is a very important practical requirement. Consider a 712 multi-pass rendering algorithm where one pass uses a vertex program 713 that uses only 4 temporary registers, but a different pass uses a 714 vertex program that uses 5 temporary registers. If two programs 715 have instruction sequences that given the same input state compute 716 identical resulting vertex positions, the multi-pass algorithm 717 should generate identically positioned primitives for each pass. 718 But given the non-conformant vertex program implementation described 719 above, this could not be guaranteed. 720 721 This does not mean that schemes for splitting vertex program 722 implementations between dedicated hardware and CPUs are impossible. 723 If the CPU and dedicated vertex program hardware used IDENTICAL 724 floating-point implementations and therefore generated exactly 725 identical results, the above described could work. 726 727 While these invariance rules are vital for vertex programs operating 728 correctly for multi-pass algorithms, there is no requirement that 729 conventional OpenGL vertex transform mode will be invariant with 730 vertex program mode. A multi-pass algorithm should not assume 731 that one pass using vertex program mode and another pass using 732 conventional GL vertex transform mode will generate identically 733 positioned primitives. 734 735 Consider that while the conventional OpenGL vertex program mode 736 is repeatable with itself, the exact procedure used to transform 737 vertices is not specified nor is the procedure's precision 738 specified. The GL specification indicates that vertex coordinates 739 are transformed by the modelview matrix and then transformed by the 740 projection matrix. Some implementations may perform this sequence 741 of transformations exactly, but other implementations may transform 742 vertex coordinates by the composite of the modelview and projection 743 matrices (one matrix transform instead of two matrix transforms 744 in sequence). Given this implementation flexibility, there is no 745 way for a vertex program author to exactly duplicate the precise 746 computations used by the conventional OpenGL vertex transform mode. 747 748 The guidance to OpenGL application programs is clear. If you are 749 going to implement multi-pass rendering algorithms that require 750 certain invariances between the multiple passes, choose either 751 vertex program mode or the conventional OpenGL vertex transform 752 mode for your rendering passes, but do not mix the two modes. 753 754 What range of relative addressing offsets should be allowed? 755 756 RESOLUTION: -64 to 63. 757 758 Negative offsets are useful for accessing a table centered at zero 759 without extra bias instructions. Having the offsets support much 760 larger magnitudes just seems to increase the required instruction 761 widths. The -64 to 63 range seems like a reasonable compromise. 762 763 When EXT_secondary_color is supported, how does the GL_COLOR_SUM_EXT 764 enable affect vertex program mode? 765 766 RESOLUTION: The GL_COLOR_SUM_EXT enable has no affect when vertex 767 program mode is enabled. 768 769 When vertex program mode is enabled, the color sum operation is 770 always in operation. A program can "avoid" the color sum operation 771 by not writing the COL1 (or BFC1 when GL_VERTEX_PROGRAM_TWO_SIDE_NV) 772 vertex result registers because the default values of all vertex 773 result registers is (0,0,0,1). For the color sum operation, 774 the alpha value is always assumed zero. So by not writing the 775 secondary color vertex result registers, the program assures that 776 zero is added as part of the color sum operation. 777 778 If there is a cost to the color sum operation, OpenGL 779 implementations may be smart enough to determine at program bind 780 time whether a secondary color vertex result is generated and 781 implicitly disable the color sum operation. 782 783 Why must RCP of 1.0 always be 1.0? 784 785 This is important for 3D graphics so that non-projective textures 786 and orthogonal projections work as expected. Basically when q or 787 w is 1.0, things should work as expected. 788 789 Stronger requirements such as "RCP of -1.0 must always be -1.0" 790 are encouraged, but there is no compelling reason to state such 791 requirements explicitly as is the case for "RCP of 1.0 must always 792 be 1.0". 793 794 What happens when the source scalar value for the ARL instruction 795 is an extremely positive or extremely negative floating-point value? 796 Is there a problem mapping the value to a constrained integer range? 797 798 RESOLUTION: It is not a problem. Relative addressing can by offset 799 by a limited range of offsets (-64 to 63). Relative addressing 800 that falls outside of the 0 to 95 range of program parameter 801 registers is automatically mapped to (0,0,0,0). 802 803 Clamping the source scalar value for ARL to the range -64 to 160 804 inclusive is sufficient to ensure that relative addressing is out 805 of range. 806 807 How do you perform a 3-component normalize in three instructions? 808 809 # 810 # R1 = (nx,ny,nz) 811 # 812 # R0.xyz = normalize(R1) 813 # R0.w = 1/sqrt(nx*nx + ny*ny + nz*nz) 814 # 815 DP3 R0.w, R1, R1; 816 RSQ R0.w, R0.w; 817 MUL R0.xyz, R1, R0.w; 818 819 How do you perform a 3-component cross product in two instructions? 820 821 # 822 # Cross product | i j k | into R2. 823 # | R0.x R0.y R0.z | 824 # | R1.x R1.y R1.z | 825 # 826 MUL R2, R0.zxyw, R1.yzxw; 827 MAD R2, R0.yzxw, R1.zxyw, -R2; 828 829 How do you perform a 4-component vector absolute value in one 830 instruction? 831 832 # 833 # Absolute value is the maximum of the negative and positive 834 # components of a vector. 835 # 836 # R1 = abs(R0) 837 # 838 MAX R1, R0, -R0; 839 840 How do you compute the determinant of a 3x3 matrix in three 841 instructions? 842 843 # 844 # Determinant of | R0.x R0.y R0.z | into R3 845 # | R1.x R1.y R1.z | 846 # | R2.x R2.y R2.z | 847 # 848 MUL R3, R1.zxyw, R2.yzxw; 849 MAD R3, R1.yzxw, R2.zxyw, -R3; 850 DP3 R3, R0, R3; 851 852 How do you transform a vertex position by a 4x4 matrix and then 853 perform a homogeneous divide? 854 855 # 856 # c[20] = modelview row 0 857 # c[21] = modelview row 1 858 # c[22] = modelview row 2 859 # c[23] = modelview row 3 860 # 861 # result = R5 862 # 863 DP4 R5.w, v[OPOS], c[23]; 864 DP4 R5.x, v[OPOS], c[20]; 865 DP4 R5.y, v[OPOS], c[21]; 866 DP4 R5.z, v[OPOS], c[22]; 867 RCP R11, R5.w; 868 MUL R5,R5,R11; 869 870 How do you perform a vector weighting of two vectors using a single 871 weight? 872 873 # 874 # R2 = vector 0 875 # R3 = vector 1 876 # v[WGHT].x = scalar weight to blend vectors 0 and 1 877 # result = R2 * v[WGHT].x + R3 * (1-v[WGHT]) 878 # 879 # this is because A*B + (1-A)*C = A*(B-C) + C 880 # 881 ADD R4, R2, -R3; 882 MAD R4, v[WGHT].x, R4, R3; 883 884 How do you reduce a value to some fundamental period such as 2*PI? 885 886 # 887 # c[36] = (1.0/(2*PI), 2*PI, 0.0, 0.0) 888 # 889 # R1.x = input value 890 # R2 = result 891 # 892 MUL R0, R1, c[36].x; 893 EXP R4, R0.x; 894 MUL R2, R4.y, c[36].y; 895 896 How do you implement a simple specular and diffuse lighting 897 computation with an eye-space normal? 898 899 !!VP1.0 900 # 901 # c[0-3] = modelview projection (composite) matrix 902 # c[4-7] = modelview inverse transpose 903 # c[32] = normalized eye-space light direction (infinite light) 904 # c[33] = normalized constant eye-space half-angle vector (infinite viewer) 905 # c[35].x = pre-multiplied monochromatic diffuse light color & diffuse material 906 # c[35].y = pre-multiplied monochromatic ambient light color & diffuse material 907 # c[36] = specular color 908 # c[38].x = specular power 909 # 910 # outputs homogenous position and color 911 # 912 DP4 o[HPOS].x, c[0], v[OPOS]; 913 DP4 o[HPOS].y, c[1], v[OPOS]; 914 DP4 o[HPOS].z, c[2], v[OPOS]; 915 DP4 o[HPOS].w, c[3], v[OPOS]; 916 DP3 R0.x, c[4], v[NRML]; 917 DP3 R0.y, c[5], v[NRML]; 918 DP3 R0.z, c[6], v[NRML]; # R0 = n' = transformed normal 919 DP3 R1.x, c[32], R0; # R1.x = Lpos DOT n' 920 DP3 R1.y, c[33], R0; # R1.y = hHat DOT n' 921 MOV R1.w, c[38].x; # R1.w = specular power 922 LIT R2, R1; # Compute lighting values 923 MAD R3, c[35].x, R2.y, c[35].y; # diffuse + emissive 924 MAD o[COL0].xyz, c[36], R2.z, R3; # + specular 925 END 926 927 Can you perturb transformed vertex positions with a vertex program? 928 929 Yes. Here is an example that performs an object-space diffuse 930 lighting computations and perturbs the vertex position based on 931 this lighting result. Do not take this example too seriously. 932 933 !!VP1.0 934 # 935 # c[0-3] = modelview projection (composite) matrix 936 # c[32] = normalized light direction in object-space 937 # c[35] = yellow diffuse material, (1.0, 1.0, 0.0, 1.0) 938 # c[64].x = 0.0 939 # c[64].z = 0.125, a scaling factor 940 # 941 # outputs diffuse illumination for color and perturbed position 942 # 943 DP3 R0, c[32], v[NRML]; # light direction DOT normal 944 MUL o[COL0].xyz, R0, c[35]; 945 MAX R0, c[64].x, R0; 946 MUL R0, R0, v[NRML]; 947 MUL R0, R0, c[64].z; 948 ADD R1, v[OPOS], -R0; # perturb object space position 949 DP4 o[HPOS].x, c[0], R1; 950 DP4 o[HPOS].y, c[1], R1; 951 DP4 o[HPOS].z, c[2], R1; 952 DP4 o[HPOS].w, c[3], R1; 953 END 954 955 What if more exponential precision is needed than provided by the 956 builtin EXP instruction? 957 958 A sequence of vertex program instructions can be used refine 959 the initial EXP approximation. The pseudo-macro below shows an 960 example of how to refine the EXP approximation. 961 962 The psuedo-macro requires 10 instructions, 1 temp register, 963 and 2 constant locations. 964 965 CE0 = { 9.61597636e-03, -1.32823968e-03, 1.47491097e-04, -1.08635004e-05 }; 966 CE1 = { 1.00000000e+00, -6.93147182e-01, 2.40226462e-01, -5.55036440e-02 }; 967 968 /* Rt != Ro && Rt != Ri */ 969 EXP_MACRO(Ro:vector, Ri:scalar, Rt:vector) { 970 EXP Rt, Ri.x; /* Use appropriate component of Ri */ 971 MAD Rt.w, c[CE0].w, Rt.y, c[CE0].z; 972 MAD Rt.w, Rt.w,Rt.y, c[CE0].y; 973 MAD Rt.w, Rt.w,Rt.y, c[CE0].x; 974 MAD Rt.w, Rt.w,Rt.y, c[CE1].w; 975 MAD Rt.w, Rt.w,Rt.y, c[CE1].z; 976 MAD Rt.w, Rt.w,Rt.y, c[CE1].y; 977 MAD Rt.w, Rt.w,Rt.y, c[CE1].x; 978 RCP Rt.w, Rt.w; 979 MUL Ro, Rt.w, Rt.x; /* Apply user write mask to Ro */ 980 } 981 982 Simulation gives |max abs error| < 3.77e-07 over the range (0.0 983 <= x < 1.0). Actual vertex program precision may be slightly 984 less accurate than this. 985 986 What if more exponential precision is needed than provided by the 987 builtin LOG instruction? 988 989 The pseudo-macro requires 10 instructions, 1 temp register, 990 and 3 constant locations. 991 992 CL0 = { 2.41873696e-01, -1.37531206e-01, 5.20646796e-02, -9.31049418e-03 }; 993 CL1 = { 1.44268966e+00, -7.21165776e-01, 4.78684813e-01, -3.47305417e-01 }; 994 CL2 = { 1.0, NA, NA, NA }; 995 996 /* Rt != Ro && Rt != Ri */ 997 LOG_MACRO(Ro:vector, Ri:scalar, Rt:vector) { 998 LOG Rt, Ri.x; /* Use appropriate component of Ri */ 999 ADD Rt.y, Rt.y, -c[CL2].x; 1000 MAD Rt.w, c[CL0].w, Rt.y, c[CL0].z; 1001 MAD Rt.w, Rt.w, Rt.y,c[CL0].y; 1002 MAD Rt.w, Rt.w, Rt.y,c[CL0].x; 1003 MAD Rt.w, Rt.w, Rt.y,c[CL1].w; 1004 MAD Rt.w, Rt.w, Rt.y,c[CL1].z; 1005 MAD Rt.w, Rt.w, Rt.y,c[CL1].y; 1006 MAD Rt.w, Rt.w, Rt.y,c[CL1].x; 1007 MAD Ro, Rt.w, Rt.y, Rt.x; /* Apply user write mask to Ro */ 1008 } 1009 1010 Simulation gives |max abs error| < 1.79e-07 over the range (1.0 1011 <= x < 2.0). Actual vertex program precision may be slightly 1012 less accurate than this. 1013 1014New Procedures and Functions 1015 1016 void BindProgramNV(enum target, uint id); 1017 1018 void DeleteProgramsNV(sizei n, const uint *ids); 1019 1020 void ExecuteProgramNV(enum target, uint id, const float *params); 1021 1022 void GenProgramsNV(sizei n, uint *ids); 1023 1024 boolean AreProgramsResidentNV(sizei n, const uint *ids, 1025 boolean *residences); 1026 1027 void RequestResidentProgramsNV(sizei n, uint *ids); 1028 1029 void GetProgramParameterfvNV(enum target, uint index, 1030 enum pname, float *params); 1031 void GetProgramParameterdvNV(enum target, uint index, 1032 enum pname, double *params); 1033 1034 void GetProgramivNV(uint id, enum pname, int *params); 1035 1036 void GetProgramStringNV(uint id, enum pname, ubyte *program); 1037 1038 void GetTrackMatrixivNV(enum target, uint address, 1039 enum pname, int *params); 1040 1041 void GetVertexAttribdvNV(uint index, enum pname, double *params); 1042 void GetVertexAttribfvNV(uint index, enum pname, float *params); 1043 void GetVertexAttribivNV(uint index, enum pname, int *params); 1044 1045 void GetVertexAttribPointervNV(uint index, enum pname, void **pointer); 1046 1047 boolean IsProgramNV(uint id); 1048 1049 void LoadProgramNV(enum target, uint id, sizei len, 1050 const ubyte *program); 1051 1052 void ProgramParameter4fNV(enum target, uint index, 1053 float x, float y, float z, float w) 1054 void ProgramParameter4dNV(enum target, uint index, 1055 double x, double y, double z, double w) 1056 1057 void ProgramParameter4dvNV(enum target, uint index, 1058 const double *params); 1059 void ProgramParameter4fvNV(enum target, uint index, 1060 const float *params); 1061 1062 void ProgramParameters4dvNV(enum target, uint index, 1063 sizei num, const double *params); 1064 void ProgramParameters4fvNV(enum target, uint index, 1065 sizei num, const float *params); 1066 1067 void TrackMatrixNV(enum target, uint address, 1068 enum matrix, enum transform); 1069 1070 void VertexAttribPointerNV(uint index, int size, enum type, sizei stride, 1071 const void *pointer); 1072 1073 void VertexAttrib1sNV(uint index, short x); 1074 void VertexAttrib1fNV(uint index, float x); 1075 void VertexAttrib1dNV(uint index, double x); 1076 void VertexAttrib2sNV(uint index, short x, short y); 1077 void VertexAttrib2fNV(uint index, float x, float y); 1078 void VertexAttrib2dNV(uint index, double x, double y); 1079 void VertexAttrib3sNV(uint index, short x, short y, short z); 1080 void VertexAttrib3fNV(uint index, float x, float y, float z); 1081 void VertexAttrib3dNV(uint index, double x, double y, double z); 1082 void VertexAttrib4sNV(uint index, short x, short y, short z, short w); 1083 void VertexAttrib4fNV(uint index, float x, float y, float z, float w); 1084 void VertexAttrib4dNV(uint index, double x, double y, double z, double w); 1085 void VertexAttrib4ubNV(uint index, ubyte x, ubyte y, ubyte z, ubyte w); 1086 1087 void VertexAttrib1svNV(uint index, const short *v); 1088 void VertexAttrib1fvNV(uint index, const float *v); 1089 void VertexAttrib1dvNV(uint index, const double *v); 1090 void VertexAttrib2svNV(uint index, const short *v); 1091 void VertexAttrib2fvNV(uint index, const float *v); 1092 void VertexAttrib2dvNV(uint index, const double *v); 1093 void VertexAttrib3svNV(uint index, const short *v); 1094 void VertexAttrib3fvNV(uint index, const float *v); 1095 void VertexAttrib3dvNV(uint index, const double *v); 1096 void VertexAttrib4svNV(uint index, const short *v); 1097 void VertexAttrib4fvNV(uint index, const float *v); 1098 void VertexAttrib4dvNV(uint index, const double *v); 1099 void VertexAttrib4ubvNV(uint index, const ubyte *v); 1100 1101 void VertexAttribs1svNV(uint index, sizei n, const short *v); 1102 void VertexAttribs1fvNV(uint index, sizei n, const float *v); 1103 void VertexAttribs1dvNV(uint index, sizei n, const double *v); 1104 void VertexAttribs2svNV(uint index, sizei n, const short *v); 1105 void VertexAttribs2fvNV(uint index, sizei n, const float *v); 1106 void VertexAttribs2dvNV(uint index, sizei n, const double *v); 1107 void VertexAttribs3svNV(uint index, sizei n, const short *v); 1108 void VertexAttribs3fvNV(uint index, sizei n, const float *v); 1109 void VertexAttribs3dvNV(uint index, sizei n, const double *v); 1110 void VertexAttribs4svNV(uint index, sizei n, const short *v); 1111 void VertexAttribs4fvNV(uint index, sizei n, const float *v); 1112 void VertexAttribs4dvNV(uint index, sizei n, const double *v); 1113 void VertexAttribs4ubvNV(uint index, sizei n, const ubyte *v); 1114 1115New Tokens 1116 1117 Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, 1118 and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 1119 and GetDoublev, and by the <target> parameter of BindProgramNV, 1120 ExecuteProgramNV, GetProgramParameter[df]vNV, GetTrackMatrixivNV, 1121 LoadProgramNV, ProgramParameter[s]4[df][v]NV, and TrackMatrixNV: 1122 1123 VERTEX_PROGRAM_NV 0x8620 1124 1125 Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, 1126 and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 1127 and GetDoublev: 1128 1129 VERTEX_PROGRAM_POINT_SIZE_NV 0x8642 1130 VERTEX_PROGRAM_TWO_SIDE_NV 0x8643 1131 1132 Accepted by the <target> parameter of ExecuteProgramNV and 1133 LoadProgramNV: 1134 1135 VERTEX_STATE_PROGRAM_NV 0x8621 1136 1137 Accepted by the <pname> parameter of GetVertexAttrib[dfi]vNV: 1138 1139 ATTRIB_ARRAY_SIZE_NV 0x8623 1140 ATTRIB_ARRAY_STRIDE_NV 0x8624 1141 ATTRIB_ARRAY_TYPE_NV 0x8625 1142 CURRENT_ATTRIB_NV 0x8626 1143 1144 Accepted by the <pname> parameter of GetProgramParameterfvNV 1145 and GetProgramParameterdvNV: 1146 1147 PROGRAM_PARAMETER_NV 0x8644 1148 1149 Accepted by the <pname> parameter of GetVertexAttribPointervNV: 1150 1151 ATTRIB_ARRAY_POINTER_NV 0x8645 1152 1153 Accepted by the <pname> parameter of GetProgramivNV: 1154 1155 PROGRAM_TARGET_NV 0x8646 1156 PROGRAM_LENGTH_NV 0x8627 1157 PROGRAM_RESIDENT_NV 0x8647 1158 1159 Accepted by the <pname> parameter of GetProgramStringNV: 1160 1161 PROGRAM_STRING_NV 0x8628 1162 1163 Accepted by the <pname> parameter of GetTrackMatrixivNV: 1164 1165 TRACK_MATRIX_NV 0x8648 1166 TRACK_MATRIX_TRANSFORM_NV 0x8649 1167 1168 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 1169 GetFloatv, and GetDoublev: 1170 1171 MAX_TRACK_MATRIX_STACK_DEPTH_NV 0x862E 1172 MAX_TRACK_MATRICES_NV 0x862F 1173 CURRENT_MATRIX_STACK_DEPTH_NV 0x8640 1174 CURRENT_MATRIX_NV 0x8641 1175 VERTEX_PROGRAM_BINDING_NV 0x864A 1176 PROGRAM_ERROR_POSITION_NV 0x864B 1177 1178 Accepted by the <matrix> parameter of TrackMatrixNV: 1179 1180 NONE 1181 MODELVIEW 1182 PROJECTION 1183 TEXTURE 1184 COLOR (if ARB_imaging is supported) 1185 MODELVIEW_PROJECTION_NV 0x8629 1186 TEXTUREi_ARB 1187 1188 where i is between 0 and n-1 where n is the number of texture units 1189 supported. 1190 1191 Accepted by the <matrix> parameter of TrackMatrixNV and by the 1192 <mode> parameter of MatrixMode: 1193 1194 MATRIX0_NV 0x8630 1195 MATRIX1_NV 0x8631 1196 MATRIX2_NV 0x8632 1197 MATRIX3_NV 0x8633 1198 MATRIX4_NV 0x8634 1199 MATRIX5_NV 0x8635 1200 MATRIX6_NV 0x8636 1201 MATRIX7_NV 0x8637 1202 1203 (Enumerants 0x8638 through 0x863F are reserved for further matrix 1204 enumerants 8 through 15.) 1205 1206 Accepted by the <transform> parameter of TrackMatrixNV: 1207 1208 IDENTITY_NV 0x862A 1209 INVERSE_NV 0x862B 1210 TRANSPOSE_NV 0x862C 1211 INVERSE_TRANSPOSE_NV 0x862D 1212 1213 Accepted by the <array> parameter of EnableClientState and 1214 DisableClientState, by the <cap> parameter of IsEnabled, and by 1215 the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and 1216 GetDoublev: 1217 1218 VERTEX_ATTRIB_ARRAY0_NV 0x8650 1219 VERTEX_ATTRIB_ARRAY1_NV 0x8651 1220 VERTEX_ATTRIB_ARRAY2_NV 0x8652 1221 VERTEX_ATTRIB_ARRAY3_NV 0x8653 1222 VERTEX_ATTRIB_ARRAY4_NV 0x8654 1223 VERTEX_ATTRIB_ARRAY5_NV 0x8655 1224 VERTEX_ATTRIB_ARRAY6_NV 0x8656 1225 VERTEX_ATTRIB_ARRAY7_NV 0x8657 1226 VERTEX_ATTRIB_ARRAY8_NV 0x8658 1227 VERTEX_ATTRIB_ARRAY9_NV 0x8659 1228 VERTEX_ATTRIB_ARRAY10_NV 0x865A 1229 VERTEX_ATTRIB_ARRAY11_NV 0x865B 1230 VERTEX_ATTRIB_ARRAY12_NV 0x865C 1231 VERTEX_ATTRIB_ARRAY13_NV 0x865D 1232 VERTEX_ATTRIB_ARRAY14_NV 0x865E 1233 VERTEX_ATTRIB_ARRAY15_NV 0x865F 1234 1235 Accepted by the <target> parameter of GetMapdv, GetMapfv, GetMapiv, 1236 Map1d and Map1f and by the <cap> parameter of Enable, Disable, and 1237 IsEnabled, and by the <pname> parameter of GetBooleanv, GetIntegerv, 1238 GetFloatv, and GetDoublev: 1239 1240 MAP1_VERTEX_ATTRIB0_4_NV 0x8660 1241 MAP1_VERTEX_ATTRIB1_4_NV 0x8661 1242 MAP1_VERTEX_ATTRIB2_4_NV 0x8662 1243 MAP1_VERTEX_ATTRIB3_4_NV 0x8663 1244 MAP1_VERTEX_ATTRIB4_4_NV 0x8664 1245 MAP1_VERTEX_ATTRIB5_4_NV 0x8665 1246 MAP1_VERTEX_ATTRIB6_4_NV 0x8666 1247 MAP1_VERTEX_ATTRIB7_4_NV 0x8667 1248 MAP1_VERTEX_ATTRIB8_4_NV 0x8668 1249 MAP1_VERTEX_ATTRIB9_4_NV 0x8669 1250 MAP1_VERTEX_ATTRIB10_4_NV 0x866A 1251 MAP1_VERTEX_ATTRIB11_4_NV 0x866B 1252 MAP1_VERTEX_ATTRIB12_4_NV 0x866C 1253 MAP1_VERTEX_ATTRIB13_4_NV 0x866D 1254 MAP1_VERTEX_ATTRIB14_4_NV 0x866E 1255 MAP1_VERTEX_ATTRIB15_4_NV 0x866F 1256 1257 Accepted by the <target> parameter of GetMapdv, GetMapfv, GetMapiv, 1258 Map2d and Map2f and by the <cap> parameter of Enable, Disable, and 1259 IsEnabled, and by the <pname> parameter of GetBooleanv, GetIntegerv, 1260 GetFloatv, and GetDoublev: 1261 1262 MAP2_VERTEX_ATTRIB0_4_NV 0x8670 1263 MAP2_VERTEX_ATTRIB1_4_NV 0x8671 1264 MAP2_VERTEX_ATTRIB2_4_NV 0x8672 1265 MAP2_VERTEX_ATTRIB3_4_NV 0x8673 1266 MAP2_VERTEX_ATTRIB4_4_NV 0x8674 1267 MAP2_VERTEX_ATTRIB5_4_NV 0x8675 1268 MAP2_VERTEX_ATTRIB6_4_NV 0x8676 1269 MAP2_VERTEX_ATTRIB7_4_NV 0x8677 1270 MAP2_VERTEX_ATTRIB8_4_NV 0x8678 1271 MAP2_VERTEX_ATTRIB9_4_NV 0x8679 1272 MAP2_VERTEX_ATTRIB10_4_NV 0x867A 1273 MAP2_VERTEX_ATTRIB11_4_NV 0x867B 1274 MAP2_VERTEX_ATTRIB12_4_NV 0x867C 1275 MAP2_VERTEX_ATTRIB13_4_NV 0x867D 1276 MAP2_VERTEX_ATTRIB14_4_NV 0x867E 1277 MAP2_VERTEX_ATTRIB15_4_NV 0x867F 1278 1279Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation) 1280 1281 -- Section 2.10 "Coordinate Transformations" 1282 1283 Add this initial discussion: 1284 1285 "Per-vertex parameters are transformed before the transformation 1286 results are used to generate primitives for rasterization, establish 1287 a raster position, or generate vertices for selection or feedback. 1288 1289 Each vertex's per-vertex parameters are transformed by one of 1290 two vertex transformation modes. The first vertex transformation mode 1291 is GL's conventional vertex transformation model. The second mode, 1292 known as 'vertex program' mode, transforms the vertex's per-vertex 1293 parameters by an application-supplied vertex program. 1294 1295 Vertex program mode is enabled and disabled, respectively, by 1296 1297 void Enable(enum target); 1298 1299 and 1300 1301 void Disable(enum target); 1302 1303 with target equal to VERTEX_PROGRAM_NV. When vertex program mode 1304 is enabled, vertices are transformed by the currently bound vertex 1305 program as discussed in section 2.14." 1306 1307 Update the original initial paragraph in the section to read: 1308 1309 "When vertex program mode is disabled, vertices, normals, and texture 1310 coordinates are transformed before their coordinates are used to 1311 produce an image in the framebuffer. We begin with a description 1312 of how vertex coordinates are transformed and how the transformation 1313 is controlled in the case when vertex program mode is disabled. The 1314 discussion that continues through section 2.13 applies when vertex 1315 program mode is disabled." 1316 1317 -- Section 2.10.2 "Matrices" 1318 1319 Change the first paragraph to read: 1320 1321 "The projection matrix and model-view matrix are set and modified 1322 with a variety of commands. The affected matrix is determined by 1323 the current matrix mode. The current matrix mode is set with 1324 1325 void MatrixMode(enum mode); 1326 1327 which takes one of the pre-defined constants TEXTURE, MODELVIEW, 1328 COLOR, PROJECTION, or MATRIXi_NV as the argument. In the case 1329 of MATRIXi_NV, i is an integer between 0 and n-1 indicating one 1330 of n tracking matrices where n is the value of the implementation 1331 defined constant MAX_TRACK_MATRICES_NV. TEXTURE is described 1332 later in section 2.10.2, and COLOR is described in section 3.6.3. 1333 The tracking matrices of the form MATRIXi_NV are described in 1334 section 2.14.5. If the current matrix mode is MODELVIEW, then 1335 matrix operations apply to the model-view matrix; if PROJECTION, 1336 then they apply to the projection matrix." 1337 1338 Change the last paragraph to read: 1339 1340 "The state required to implement transformations consists of a n-value 1341 integer indicating the current matrix mode (where n is 4 + the number 1342 of tracking matrices supported), a stack of at least two 4x4 matrices 1343 for each of COLOR, PROJECTION, and TEXTURE with associated stack 1344 pointers, n stacks (where n is at least 8) of at least one 4x4 matrix 1345 for each MATRIXi_NV with associated stack pointers, and a stack of at 1346 least 32 4x4 matrices with an associated stack pointer for MODELVIEW. 1347 Initially, there is only one matrix on each stack, and all matrices 1348 are set to the identity. The initial matrix mode is MODELVIEW." 1349 1350 -- NEW Section 2.14 "Vertex Programs" 1351 1352 "The conventional GL vertex transformation model described 1353 in sections 2.10 through 2.13 is a configurable but essentially 1354 hard-wired sequence of per-vertex computations based on a canonical 1355 set of per-vertex parameters and vertex transformation related 1356 state such as transformation matrices, lighting parameters, and 1357 texture coordinate generation parameters. 1358 1359 The general success and utility of the conventional GL vertex 1360 transformation model reflects its basic correspondence to the 1361 typical vertex transformation requirements of 3D applications. 1362 1363 However when the conventional GL vertex transformation model 1364 is not sufficient, the vertex program mode provides a substantially 1365 more flexible model for vertex transformation. The vertex program 1366 mode permits applications to define their own vertex programs. 1367 1368 2.14.1 The Vertex Program Execution Model 1369 1370 A vertex program is a sequence of floating-point 4-component vector 1371 operations that operate on per-vertex attributes and program 1372 parameters. Vertex programs execute on a per-vertex basis and 1373 operate on each vertex completely independently from the processing 1374 of other vertices. Vertex programs execute a finite fixed sequence 1375 of instructions with no branching or looping. Vertex programs 1376 execute without data hazards so results computed in one operation can 1377 be used immediately afterwards. The result of a vertex program is 1378 a set of vertex result vectors that becomes the transformed vertex 1379 parameters used by primitive assembly. 1380 1381 Vertex programs use a specific well-defined instruction set, register 1382 set, and operational model defined in the following sections. 1383 1384 The vertex program register set consists of five types of registers 1385 described in the following five sections. 1386 1387 2.14.1.1 The Vertex Attribute Registers 1388 1389 The Vertex Attribute Registers are sixteen 4-component 1390 vector floating-point registers containing the current vertex's 1391 per-vertex attributes. These registers are numbered 0 through 15. 1392 These registers are private to each vertex program invocation and are 1393 initialized at each vertex program invocation by the current vertex 1394 attribute state specified with VertexAttribNV commands. These registers 1395 are read-only during vertex program execution. The VertexAttribNV 1396 commands used to update the vertex attribute registers can be issued 1397 both outside and inside of Begin/End pairs. Vertex program execution 1398 is provoked by updating vertex attribute zero. Updating vertex 1399 attribute zero outside of a Begin/End pair is ignored without 1400 generating any error (identical to the Vertex command operation). 1401 1402 The commands 1403 1404 void VertexAttrib{1234}{sfd}NV(uint index, T coords); 1405 void VertexAttrib{1234}{sfd}vNV(uint index, T coords); 1406 void VertexAttrib4ubNV(uint index, T coords); 1407 void VertexAttrib4ubvNV(uint index, T coords); 1408 1409 specify the particular current vertex attribute indicated by index. 1410 The coordinates for each vertex attribute are named x, y, z, and w. 1411 The VertexAttrib1NV family of commands sets the x coordinate to the 1412 provided single argument while setting y and z to 0 and w to 1. 1413 Similarly, VertexAttrib2NV sets x and y to the specified values, 1414 z to 0 and w to 1; VertexAttrib3NV sets x, y, and z, with w set 1415 to 1, and VertexAttrib4NV sets all four coordinates. The error 1416 INVALID_VALUE is generated if index is greater than 15. 1417 1418 No conversions are applied to the vertex attributes specified as 1419 type short, float, or double. However, vertex attributes specified 1420 as type ubyte are converted as described by Table 2.6. 1421 1422 The commands 1423 1424 void VertexAttribs{1234}{sfd}vNV(uint index, sizei n, T coords[]); 1425 void VertexAttribs4ubvNV(uint index, sizei n, GLubyte coords[]); 1426 1427 specify a contiguous set of n vertex attributes. The effect of 1428 1429 VertexAttribs{1234}{sfd}vNV(index, n, coords) 1430 1431 is the same (assuming no errors) as the command sequence 1432 1433 #define NUM k /* where k is 1, 2, 3, or 4 components */ 1434 int i; 1435 for (i=n-1; i>=0; i--) { 1436 VertexAttrib{NUM}{sfd}vNV(i+index, &coords[i*NUM]); 1437 } 1438 1439 VertexAttribs4ubvNV behaves similarly. 1440 1441 The VertexAttribNV calls equivalent to VertexAttribsNV are issued in 1442 reverse order so that vertex program execution is provoked when index 1443 is zero only after all the other vertex attributes have first been 1444 specified. 1445 1446 2.14.1.2 The Program Parameter Registers 1447 1448 The Program Parameter Registers are ninety-six 4-component 1449 floating-point vector registers containing the vertex program 1450 parameters. These registers are numbered 0 through 95. This 1451 relatively large set of registers is intended to hold parameters 1452 such as matrices, lighting parameters, and constants required by 1453 vertex programs. Vertex program parameter registers can be updated 1454 in one of two ways: by the ProgramParameterNV commands outside 1455 of a Begin/End pair or by a vertex state program executed outside 1456 of a Begin/End pair (vertex state programs are discussed in section 1457 2.14.3). 1458 1459 The commands 1460 1461 void ProgramParameter4fNV(enum target, uint index, 1462 float x, float y, float z, float w) 1463 void ProgramParameter4dNV(enum target, uint index, 1464 double x, double y, double z, double w) 1465 1466 specify the particular program parameter indicated by index. 1467 The coordinates values x, y, z, and w are assigned to the respective 1468 components of the particular program parameter. target must be 1469 VERTEX_PROGRAM_NV. 1470 1471 The commands 1472 1473 void ProgramParameter4dvNV(enum target, uint index, double *params); 1474 void ProgramParameter4fvNV(enum target, uint index, float *params); 1475 1476 operate identically to ProgramParameter4fNV and ProgramParameter4dNV 1477 respectively except that the program parameters are passed as an 1478 array of four components. 1479 1480 The commands 1481 1482 void ProgramParameters4dvNV(enum target, uint index, 1483 uint num, double *params); 1484 void ProgramParameters4fvNV(enum target, uint index, 1485 uint num, float *params); 1486 1487 specify a contiguous set of num program parameters. target must 1488 be VERTEX_PROGRAM_NV. The effect is the same (assuming no errors) as 1489 1490 for (i=index; i<index+num; i++) { 1491 ProgramParameter4{fd}vNV(target, i, ¶ms[i*4]); 1492 } 1493 1494 The program parameter registers are shared to all vertex program 1495 invocations within a rendering context. ProgramParameterNV command 1496 updates and vertex state program executions are serialized with 1497 respect to vertex program invocations and other vertex state program 1498 executions. 1499 1500 Writes to the program parameter registers during vertex state program 1501 execution can be maskable on a per-component basis. 1502 1503 The error INVALID_VALUE is generated if any ProgramParameterNV has 1504 an index is greater than 95. 1505 1506 The initial value of all ninety-six program parameter registers is 1507 (0,0,0,0). 1508 1509 2.14.1.3 The Address Register 1510 1511 The Address Register is a single 4-component vector signed 32-bit 1512 integer register though only the x component of the vector is 1513 accessible. The register is private to each vertex program invocation 1514 and is initialized to (0,0,0,0) at every vertex program invocation. 1515 This register can be written during vertex program execution (but 1516 not read) and its value can be used for as a relative offset for 1517 reading vertex program parameter registers. Only the vertex program 1518 parameter registers can be read using relative addressing (writes 1519 using relative addressing are not supported). 1520 1521 See the discussion of relative addressing of program parameters 1522 in section 2.14.1.9 and the discussion of the ARL instruction in 1523 section 2.14.1.10.1. 1524 1525 2.14.1.4 The Temporary Registers 1526 1527 The Temporary Registers are twelve 4-component floating-point vector 1528 registers used to hold temporary results during vertex program 1529 execution. These registers are numbered 0 through 11. These 1530 registers are private to each vertex program invocation and 1531 initialized to (0,0,0,0) at every vertex program invocation. These 1532 registers can be read and written during vertex program execution. 1533 Writes to these registers can be maskable on a per-component basis. 1534 1535 2.14.1.5 The Vertex Result Register Set 1536 1537 The Vertex Result Registers are fifteen 4-component floating-point 1538 vector registers used to write the results of a vertex program. 1539 Each register value is initialized to (0,0,0,1) at the invocation 1540 of each vertex program. Writes to the vertex result registers can 1541 be maskable on a per-component basis. These registers are named in 1542 Table X.1 and further discussed below. 1543 1544 1545Vertex Result Component 1546Register Name Description Interpretation 1547-------------- --------------------------------- -------------- 1548 HPOS Homogeneous clip space position (x,y,z,w) 1549 COL0 Primary color (front-facing) (r,g,b,a) 1550 COL1 Secondary color (front-facing) (r,g,b,a) 1551 BFC0 Back-facing primary color (r,g,b,a) 1552 BFC1 Back-facing secondary color (r,g,b,a) 1553 FOGC Fog coordinate (f,*,*,*) 1554 PSIZ Point size (p,*,*,*) 1555 TEX0 Texture coordinate set 0 (s,t,r,q) 1556 TEX1 Texture coordinate set 1 (s,t,r,q) 1557 TEX2 Texture coordinate set 2 (s,t,r,q) 1558 TEX3 Texture coordinate set 3 (s,t,r,q) 1559 TEX4 Texture coordinate set 4 (s,t,r,q) 1560 TEX5 Texture coordinate set 5 (s,t,r,q) 1561 TEX6 Texture coordinate set 6 (s,t,r,q) 1562 TEX7 Texture coordinate set 7 (s,t,r,q) 1563 1564 Table X.1: Vertex Result Registers. 1565 1566 HPOS is the transformed vertex's homogeneous clip space position. 1567 The vertex's homogeneous clip space position is converted to 1568 normalized device coordinates and transformed to window coordinates 1569 as described at the end of section 2.10 and in section 2.11. 1570 Further processing (subsequent to vertex program termination) 1571 is responsible for clipping primitives assembled from vertex 1572 program-generated vertices as described in section 2.10 but all 1573 client-defined clip planes are treated as if they are disabled when 1574 vertex program mode is enabled. 1575 1576 Four distinct color results can be generated for each vertex. 1577 COL0 is the transformed vertex's front-facing primary color. 1578 COL1 is the transformed vertex's front-facing secondary color. 1579 BFC0 is the transformed vertex's back-facing primary color. BFC1 is 1580 the transformed vertex's back-facing secondary color. 1581 1582 Primitive coloring may operate in two-sided color mode. This behavior 1583 is enabled and disabled by calling Enable or Disable with the 1584 symbolic value VERTEX_PROGRAM_TWO_SIDE_NV. The selection between 1585 the back-facing colors and the front-facing colors depends on the 1586 primitive of which the vertex is a part. If the primitive is a 1587 point or a line segment, the front-facing colors are always selected. 1588 If the primitive is a polygon and two-sided color mode is disabled, 1589 the front-facing colors are selected. If it is a polygon and 1590 two-sided color mode is enabled, then the selection is based on the 1591 sign of the (clipped or unclipped) polygon's signed area computed in 1592 window coordinates. This facingness determination is identical to 1593 the two-sided lighting facingness determination described in section 1594 2.13.1. 1595 1596 The selected primary and secondary colors for each primitive are 1597 clamped to the range [0,1] and then interpolated across the assembled 1598 primitive during rasterization with at least 8-bit accuracy for each 1599 color component. 1600 1601 FOGC is the transformed vertex's fog coordinate. The register's 1602 first floating-point component is interpolated across the assembled 1603 primitive during rasterization and used as the fog distance to 1604 compute per-fragment the fog factor when fog is enabled. However, 1605 if both fog and vertex program mode are enabled, but the FOGC vertex 1606 result register is not written, the fog factor is overridden to 1.0. 1607 The register's other three components are ignored. 1608 1609 Point size determination may operate in program-specified point 1610 size mode. This behavior is enabled and disabled by calling Enable 1611 or Disable with the symbolic value VERTEX_PROGRAM_POINT_SIZE_NV. 1612 If the vertex is for a point primitive and the mode is enabled 1613 and the PSIZ vertex result is written, the point primitive's size 1614 is determined by the clamped x component of the PSIZ register. 1615 Otherwise (because vertex program mode is disabled, program-specified 1616 point size mode is disabled, or because the vertex program did not 1617 write PSIZ), the point primitive's size is determined by the point 1618 size state (the state specified using the PointSize command). 1619 1620 The PSIZ register's x component is clamped to the range zero through 1621 either the hi value of ALIASED_POINT_SIZE_RANGE if point smoothing 1622 is disabled or the hi value of the SMOOTH_POINT_SIZE_RANGE if 1623 point smoothing is enabled. The register's other three components 1624 are ignored. 1625 1626 If the vertex is not for a point primitive, the value of the 1627 PSIZ vertex result register is ignored. 1628 1629 TEX0 through TEX7 are the transformed vertex's texture coordinate 1630 sets for texture units 0 through 7. These floating-point coordinates 1631 are interpolated across the assembled primitive during rasterization 1632 and used for accessing textures. If the number of texture units 1633 supported is less than eight, the values of vertex result registers 1634 that do not correspond to existent texture units are ignored. 1635 1636 2.14.1.6 Semantic Meaning for Vertex Attributes and Program Parameters 1637 1638 One important distinction between the conventional GL vertex 1639 transformation mode and the vertex program mode is that per-vertex 1640 parameters and other state parameters in vertex program mode do 1641 not have dedicated semantic interpretations the way that they do 1642 with the conventional GL vertex transformation mode. 1643 1644 For example, in the conventional GL vertex transformation mode, 1645 the Normal command specifies a per-vertex normal. The semantic that 1646 the Normal command supplies a normal for lighting is established because 1647 that is how the per-vertex attribute supplied by the Normal command 1648 is used by the conventional GL vertex transformation mode. 1649 Similarly, other state parameters such as a light source position have 1650 semantic interpretations based on how the conventional GL vertex 1651 transformation model uses each particular parameter. 1652 1653 In contrast, vertex attributes and program parameters for vertex 1654 programs have no pre-defined semantic meanings. The meaning of 1655 a vertex attribute or program parameter in vertex program mode is 1656 defined by how the vertex attribute or program parameter is used by 1657 the current vertex program to compute and write values to the Vertex 1658 Result Registers. This is the reason that per-vertex attributes and 1659 program parameters for vertex programs are numbered instead of named. 1660 1661 For convenience however, the existing per-vertex parameters for the 1662 conventional GL vertex transformation mode (vertices, normals, 1663 colors, fog coordinates, vertex weights, and texture coordinates) are 1664 aliased to numbered vertex attributes. This aliasing is specified in 1665 Table X.2. The table includes how the various conventional components 1666 map to the 4-component vertex attribute components. 1667 1668Vertex 1669Attribute Conventional Conventional 1670Register Per-vertex Conventional Component 1671Number Parameter Per-vertex Parameter Command Mapping 1672--------- --------------- ----------------------------------- ------------ 1673 0 vertex position Vertex x,y,z,w 1674 1 vertex weights VertexWeightEXT w,0,0,1 1675 2 normal Normal x,y,z,1 1676 3 primary color Color r,g,b,a 1677 4 secondary color SecondaryColorEXT r,g,b,1 1678 5 fog coordinate FogCoordEXT fc,0,0,1 1679 6 - - - 1680 7 - - - 1681 8 texture coord 0 MultiTexCoord(GL_TEXTURE0_ARB, ...) s,t,r,q 1682 9 texture coord 1 MultiTexCoord(GL_TEXTURE1_ARB, ...) s,t,r,q 1683 10 texture coord 2 MultiTexCoord(GL_TEXTURE2_ARB, ...) s,t,r,q 1684 11 texture coord 3 MultiTexCoord(GL_TEXTURE3_ARB, ...) s,t,r,q 1685 12 texture coord 4 MultiTexCoord(GL_TEXTURE4_ARB, ...) s,t,r,q 1686 13 texture coord 5 MultiTexCoord(GL_TEXTURE5_ARB, ...) s,t,r,q 1687 14 texture coord 6 MultiTexCoord(GL_TEXTURE6_ARB, ...) s,t,r,q 1688 15 texture coord 7 MultiTexCoord(GL_TEXTURE7_ARB, ...) s,t,r,q 1689 1690Table X.2: Aliasing of vertex attributes with conventional per-vertex 1691parameters. 1692 1693 Only vertex attribute zero is treated specially because it is 1694 the attribute that provokes the execution of the vertex program; 1695 this is the attribute that aliases to the Vertex command's vertex 1696 coordinates. 1697 1698 The result of a vertex program is the set of post-transformation 1699 vertex parameters written to the Vertex Result Registers. 1700 All vertex programs must write a homogeneous clip space position, but 1701 the other Vertex Result Registers can be optionally written. 1702 1703 Clipping and culling are not the responsibility of vertex programs 1704 because these operations assume the assembly of multiple vertices 1705 into a primitive. View frustum clipping is performed subsequent to 1706 vertex program execution. Clip planes are not supported in vertex 1707 program mode. 1708 1709 2.14.1.7 Vertex Program Specification 1710 1711 Vertex programs are specified as an array of ubytes. The array is 1712 a string of ASCII characters encoding the program. 1713 1714 The command 1715 1716 LoadProgramNV(enum target, uint id, sizei len, 1717 const ubyte *program); 1718 1719 loads a vertex program when the target parameter is VERTEX_PROGRAM_NV. 1720 Multiple programs can be loaded with different names. id names the 1721 program to load. The name space for programs is the positive integers 1722 (zero is reserved). The error INVALID_VALUE occurs if a program is 1723 loaded with an id of zero. The error INVALID_OPERATION is generated 1724 if a program is loaded for an id that is currently loaded with a 1725 program of a different program target. Managing the program name 1726 space and binding to vertex programs is discussed later in section 1727 2.14.1.8. 1728 1729 program is a pointer to an array of ubytes that represents the 1730 program being loaded. The length of the array is indicated by len. 1731 1732 A second program target type known as vertex state programs is 1733 discussed in 2.14.4. 1734 1735 At program load time, the program is parsed into a set of tokens 1736 possibly separated by white space. Spaces, tabs, newlines, carriage 1737 returns, and comments are considered whitespace. Comments begin with 1738 the character "#" and are terminated by a newline, a carriage return, 1739 or the end of the program array. 1740 1741 The Backus-Naur Form (BNF) grammar below specifies the syntactically 1742 valid sequences for vertex programs. The set of valid tokens can be 1743 inferred from the grammar. The token "" represents an empty string 1744 and is used to indicate optional rules. A program is invalid if it 1745 contains any undefined tokens or characters. 1746 1747 <program> ::= "!!VP1.0" <instructionSequence> "END" 1748 1749 <instructionSequence> ::= <instructionSequence> <instructionLine> 1750 | <instructionLine> 1751 1752 <instructionLine> ::= <instruction> ";" 1753 1754 <instruction> ::= <ARL-instruction> 1755 | <VECTORop-instruction> 1756 | <SCALARop-instruction> 1757 | <BINop-instruction> 1758 | <TRIop-instruction> 1759 1760 <ARL-instruction> ::= "ARL" <addrReg> "," <scalarSrcReg> 1761 1762 <VECTORop-instruction> ::= <VECTORop> <maskedDstReg> "," <swizzleSrcReg> 1763 1764 <SCALARop-instruction> ::= <SCALARop> <maskedDstReg> "," <scalarSrcReg> 1765 1766 <BINop-instruction> ::= <BINop> <maskedDstReg> "," 1767 <swizzleSrcReg> "," <swizzleSrcReg> 1768 1769 <TRIop-instruction> ::= <TRIop> <maskedDstReg> "," 1770 <swizzleSrcReg> "," <swizzleSrcReg> "," 1771 <swizzleSrcReg> 1772 1773 <VECTORop> ::= "MOV" 1774 | "LIT" 1775 1776 <SCALARop> ::= "RCP" 1777 | "RSQ" 1778 | "EXP" 1779 | "LOG" 1780 1781 <BINop> ::= "MUL" 1782 | "ADD" 1783 | "DP3" 1784 | "DP4" 1785 | "DST" 1786 | "MIN" 1787 | "MAX" 1788 | "SLT" 1789 | "SGE" 1790 1791 <TRIop> ::= "MAD" 1792 1793 <scalarSrcReg> ::= <optionalSign> <srcReg> <scalarSuffix> 1794 1795 <swizzleSrcReg> ::= <optionalSign> <srcReg> <swizzleSuffix> 1796 1797 <maskedDstReg> ::= <dstReg> <optionalMask> 1798 1799 <optionalMask> ::= "" 1800 | "." "x" 1801 | "." "y" 1802 | "." "x" "y" 1803 | "." "z" 1804 | "." "x" "z" 1805 | "." "y" "z" 1806 | "." "x" "y" "z" 1807 | "." "w" 1808 | "." "x" "w" 1809 | "." "y" "w" 1810 | "." "x" "y" "w" 1811 | "." "z" "w" 1812 | "." "x" "z" "w" 1813 | "." "y" "z" "w" 1814 | "." "x" "y" "z" "w" 1815 1816 <optionalSign> ::= "-" 1817 | "" 1818 1819 <srcReg> ::= <vertexAttribReg> 1820 | <progParamReg> 1821 | <temporaryReg> 1822 1823 <dstReg> ::= <temporaryReg> 1824 | <vertexResultReg> 1825 1826 <vertexAttribReg> ::= "v" "[" vertexAttribRegNum "]" 1827 1828 <vertexAttribRegNum> ::= decimal integer from 0 to 15 inclusive 1829 | "OPOS" 1830 | "WGHT" 1831 | "NRML" 1832 | "COL0" 1833 | "COL1" 1834 | "FOGC" 1835 | "TEX0" 1836 | "TEX1" 1837 | "TEX2" 1838 | "TEX3" 1839 | "TEX4" 1840 | "TEX5" 1841 | "TEX6" 1842 | "TEX7" 1843 1844 <progParamReg> ::= <absProgParamReg> 1845 | <relProgParamReg> 1846 1847 <absProgParamReg> ::= "c" "[" <progParamRegNum> "]" 1848 1849 <progParamRegNum> ::= decimal integer from 0 to 95 inclusive 1850 1851 <relProgParamReg> ::= "c" "[" <addrReg> "]" 1852 | "c" "[" <addrReg> "+" <progParamPosOffset> "]" 1853 | "c" "[" <addrReg> "-" <progParamNegOffset> "]" 1854 1855 <progParamPosOffset> ::= decimal integer from 0 to 63 inclusive 1856 1857 <progParamNegOffset> ::= decimal integer from 0 to 64 inclusive 1858 1859 <addrReg> ::= "A0" "." "x" 1860 1861 <temporaryReg> ::= "R0" 1862 | "R1" 1863 | "R2" 1864 | "R3" 1865 | "R4" 1866 | "R5" 1867 | "R6" 1868 | "R7" 1869 | "R8" 1870 | "R9" 1871 | "R10" 1872 | "R11" 1873 1874 <vertexResultReg> ::= "o" "[" vertexResultRegName "]" 1875 1876 <vertexResultRegName> ::= "HPOS" 1877 | "COL0" 1878 | "COL1" 1879 | "BFC0" 1880 | "BFC1" 1881 | "FOGC" 1882 | "PSIZ" 1883 | "TEX0" 1884 | "TEX1" 1885 | "TEX2" 1886 | "TEX3" 1887 | "TEX4" 1888 | "TEX5" 1889 | "TEX6" 1890 | "TEX7" 1891 1892 <scalarSuffix> ::= "." <component> 1893 1894 <swizzleSuffix> ::= "" 1895 | "." <component> 1896 | "." <component> <component> 1897 <component> <component> 1898 1899 <component> ::= "x" 1900 | "y" 1901 | "z" 1902 | "w" 1903 1904 The <vertexAttribRegNum> rule matches both register numbers 0 through 1905 15 and a set of mnemonics that abbreviate the aliasing of conventional 1906 the per-vertex parameters to vertex attribute register numbers. 1907 Table X.3 shows the mapping from mnemonic to vertex attribute register 1908 number and what the mnemonic abbreviates. 1909 1910 Vertex Attribute 1911Mnemonic Register Number Meaning 1912-------- ---------------- -------------------- 1913 "OPOS" 0 object position 1914 "WGHT" 1 vertex weight 1915 "NRML" 2 normal 1916 "COL0" 3 primary color 1917 "COL1" 4 secondary color 1918 "FOGC" 5 fog coordinate 1919 "TEX0" 8 texture coordinate 0 1920 "TEX1" 9 texture coordinate 1 1921 "TEX2" 10 texture coordinate 2 1922 "TEX3" 11 texture coordinate 3 1923 "TEX4" 12 texture coordinate 4 1924 "TEX5" 13 texture coordinate 5 1925 "TEX6" 14 texture coordinate 6 1926 "TEX7" 15 texture coordinate 7 1927 1928Table X.3: The mapping between vertex attribute register numbers, 1929mnemonics, and meanings. 1930 1931 A vertex programs fails to load if it does not write at least one 1932 component of the HPOS register. 1933 1934 A vertex program fails to load if it contains more than 128 1935 instructions. 1936 1937 A vertex program fails to load if any instruction sources more than 1938 one unique program parameter register. 1939 1940 A vertex program fails to load if any instruction sources more than 1941 one unique vertex attribute register. 1942 1943 The error INVALID_OPERATION is generated if a vertex program fails 1944 to load because it is not syntactically correct or for one of the 1945 semantic restrictions listed above. 1946 1947 The error INVALID_OPERATION is generated if a program is loaded for 1948 id when id is currently loaded with a program of a different target. 1949 1950 A successfully loaded vertex program is parsed into a sequence of 1951 instructions. Each instruction is identified by its tokenized name. 1952 The operation of these instructions when executed is defined in 1953 section 2.14.1.10. 1954 1955 A successfully loaded program replaces the program previously assigned 1956 to the name specified by id. If the OUT_OF_MEMORY error is generated 1957 by LoadProgramNV, no change is made to the previous contents of the 1958 named program. 1959 1960 Querying the value of PROGRAM_ERROR_POSITION_NV returns a ubyte 1961 offset into the last loaded program string indicating where the first 1962 error in the program. If the program fails to load because of a 1963 semantic restriction that cannot be determined until the program 1964 is fully scanned, the error position will be len, the length of 1965 the program. If the program loads successfully, the value of 1966 PROGRAM_ERROR_POSITION_NV is assigned the value negative one. 1967 1968 2.14.1.8 Vertex Program Binding and Program Management 1969 1970 The current vertex program is invoked whenever vertex attribute 1971 zero is updated (whether by a VertexAttributeNV or Vertex command). 1972 The current vertex program is updated by 1973 1974 BindProgramNV(enum target, uint id); 1975 1976 where target must be VERTEX_PROGRAM_NV. This binds the vertex program 1977 named by id as the current vertex program. The error INVALID_OPERATION 1978 is generated if id names a program that is not a vertex program 1979 (for example, if id names a vertex state program as described in 1980 section 2.14.4). 1981 1982 Binding to a nonexistent program id does not generate an error. 1983 In particular, binding to program id zero does not generate an error. 1984 However, because program zero cannot be loaded, program zero is 1985 always nonexistent. If a program id is successfully loaded with a 1986 new vertex program and id is also the currently bound vertex program, 1987 the new program is considered the currently bound vertex program. 1988 1989 The INVALID_OPERATION error is generated when both vertex program 1990 mode is enabled and Begin is called (or when a command that performs 1991 an implicit Begin is called) if the current vertex program is 1992 nonexistent or not valid. A vertex program may not be valid for 1993 reasons explained in section 2.14.5. 1994 1995 Programs are deleted by calling 1996 1997 void DeleteProgramsNV(sizei n, const uint *ids); 1998 1999 ids contains n names of programs to be deleted. After a program 2000 is deleted, it becomes nonexistent, and its name is again unused. 2001 If a program that is currently bound is deleted, it is as though 2002 BindProgramNV has been executed with the same target as the deleted 2003 program and program zero. Unused names in ids are silently ignored, 2004 as is the value zero. 2005 2006 The command 2007 2008 void GenProgramsNV(sizei n, uint *ids); 2009 2010 returns n previously unused program names in ids. These names 2011 are marked as used, for the purposes of GenProgramsNV only, 2012 but they become existent programs only when the are first loaded 2013 using LoadProgramNV. The error INVALID_VALUE is generated if n 2014 is negative. 2015 2016 An implementation may choose to establish a working set of programs on 2017 which binding and ExecuteProgramNV operations (execute programs are 2018 explained in section 2.14.4) are performed with higher performance. 2019 A program that is currently part of this working set is said to 2020 be resident. 2021 2022 The command 2023 2024 boolean AreProgramsResidentNV(sizei n, const uint *ids, 2025 boolean *residences); 2026 2027 returns TRUE if all of the n programs named in ids are resident, 2028 or if the implementation does not distinguish a working set. If at 2029 least one of the programs named in ids is not resident, then FALSE is 2030 returned, and the residence of each program is returned in residences. 2031 Otherwise the contents of residences are not changed. If any of 2032 the names in ids are nonexistent or zero, FALSE is returned, the 2033 error INVALID_VALUE is generated, and the contents of residences 2034 are indeterminate. The residence status of a single named program 2035 can also be queried by calling GetProgramivNV with id set to the 2036 name of the program and pname set to PROGRAM_RESIDENT_NV. 2037 2038 AreProgramsResidentNV indicates only whether a program is 2039 currently resident, not whether it could not be made resident. 2040 An implementation may choose to make a program resident only on 2041 first use, for example. The client may guide the GL implementation 2042 in determining which programs should be resident by requesting a 2043 set of programs to make resident. 2044 2045 The command 2046 2047 void RequestResidentProgramsNV(sizei n, const uint *ids); 2048 2049 requests that the n programs named in ids should be made resident. 2050 While all the programs are not guaranteed to become resident, 2051 the implementation should make a best effort to make as many of 2052 the programs resident as possible. As a result of making the 2053 requested programs resident, program names not among the requested 2054 programs may become non-resident. Higher priority for residency 2055 should be given to programs listed earlier in the ids array. 2056 RequestResidentProgramsNV silently ignores attempts to make resident 2057 nonexistent program names or zero. AreProgramsResidentNV can be 2058 called after RequestResidentProgramsNV to determine which programs 2059 actually became resident. 2060 2061 2.14.1.9 Vertex Program Register Accesses 2062 2063 There are 17 vertex program instructions. The instructions and their 2064 respective input and output parameters are summarized in Table X.4. 2065 2066 Output 2067 Inputs (vector or 2068Opcode (scalar or vector) replicated scalar) Operation 2069------ ------------------ ------------------ -------------------------- 2070 ARL s address register address register load 2071 MOV v v move 2072 MUL v,v v multiply 2073 ADD v,v v add 2074 MAD v,v,v v multiply and add 2075 RCP s ssss reciprocal 2076 RSQ s ssss reciprocal square root 2077 DP3 v,v ssss 3-component dot product 2078 DP4 v,v ssss 4-component dot product 2079 DST v,v v distance vector 2080 MIN v,v v minimum 2081 MAX v,v v maximum 2082 SLT v,v v set on less than 2083 SGE v,v v set on greater equal than 2084 EXP s v exponential base 2 2085 LOG s v logarithm base 2 2086 LIT v v light coefficients 2087 2088Table X.4: Summary of vertex program instructions. "v" indicates a 2089vector input or output, "s" indicates a scalar input, and "ssss" indicates 2090a scalar output replicated across a 4-component vector. 2091 2092 Instructions use either scalar source values or swizzled source 2093 values, indicated in the grammar (see section 2.14.1.7) by the rules 2094 <scalarSrcReg> and <swizzleSrcReg> respectively. Either type of 2095 source value is negated when the <optionalSign> rule matches "-". 2096 2097 Scalar source register values select one of the source register's 2098 four components based on the <component> of the <scalarSuffix> rule. 2099 The characters "x", "y", "z", and "w" match the x, y, z, and 2100 w components respectively. The indicated component is used as a 2101 scalar for the particular source value. 2102 2103 Swizzled source register values may arbitrarily swizzle the source 2104 register's components based on the <swizzleSuffix> rule. In the case 2105 where the <swizzleSuffix> matches (ignoring whitespace) the pattern 2106 ".????" where each question mark is one of "x", "y", "z", or "w", 2107 this indicates the ith component of the source register value should 2108 come from the component named by the ith component in the sequence. 2109 For example, if the swizzle suffix is ".yzzx" and the source register 2110 contains [ 2.0, 8.0, 9.0, 0.0 ] the swizzled source register value 2111 used by the instruction is [ 8.0, 9.0, 9.0, 2.0 ]. 2112 2113 If the <swizzleSuffix> rule matches "", this is treated the same as 2114 ".xyzw". If the <swizzleSuffix> rule matches (ignoring whitespace) 2115 ".x", ".y", ".z", or ".w", these are treated the same as ".xxxx", 2116 ".yyyy", ".zzzz", and ".wwww" respectively. 2117 2118 The register sourced for either a scalar source register value or a 2119 swizzled source register value is indicated in the grammar by the rule 2120 <srcReg>. The <vertexAttribReg>, <progParamReg>, and <temporaryReg> 2121 sub-rules correspond to one of the vertex attribute registers, 2122 program parameter registers, or temporary register respectively. 2123 2124 The vertex attribute and temporary registers are accessed absolutely 2125 based on the numbered register. In the case of vertex attribute 2126 registers, if the <vertexAttribRegNum> corresponds to a mnemonic, 2127 the corresponding register number from Table X.3 is used. 2128 2129 Either absolute or relative addressing can be used to access the 2130 program parameter registers. Absolute addressing is indicated by 2131 the grammar by the <absProgParamReg> rule. Absolute addressing 2132 accesses the numbered program parameter register indicated by the 2133 <progParamRegNum> rule. Relative addressing accesses the numbered 2134 program parameter register plus an offset. The offset is the positive 2135 value of <progParamPosOffset> if the <progParamPosOffset> rule is 2136 matched, or the offset is the negative value of <progParamNegOffset> 2137 if the <progParamNegOffset> rule is matched, or otherwise the offset 2138 is zero. Relative addressing is available only for program parameter 2139 registers and only for reads (not writes). Relative addressing 2140 reads outside of the 0 to 95 inclusive range always read the value 2141 (0,0,0,0). 2142 2143 The result of all instructions except ARL is written back to a 2144 masked destination register, indicated in the grammar by the rule 2145 <maskedDstReg>. 2146 2147 Writes to each component of the destination register can be masked, 2148 indicated in the grammar by the <optionalMask> rule. If the optional 2149 mask is "", all components are written. Otherwise, the optional 2150 mask names particular components to write. The characters "x", 2151 "y", "z", and "w" match the x, y, z, and w components respectively. 2152 For example, an optional mask of ".xzw" indicates that the x, z, 2153 and w components should be written but not the y component. 2154 The grammar requires that the destination register mask components 2155 must be listed in "xyzw" order. 2156 2157 The actual destination register is indicated in the grammar by 2158 the rule <dstReg>. The <temporaryReg> and <vertexResultReg> 2159 sub-rules correspond to either the temporary registers or vertex 2160 result registers. The temporary registers are determined and accessed 2161 as described earlier. 2162 2163 The vertex result registers are accessed absolutely based on the 2164 named register. The <vertexResultRegName> rule corresponds to 2165 registers named in Table X.1. 2166 2167 2.14.1.10 Vertex Program Instruction Set Operations 2168 2169 The operation of the 17 vertex program instructions are described in 2170 this section. After the textual description of each instruction's 2171 operation, a register transfer level description is also presented. 2172 2173 The following conventions are used in each instruction's register 2174 transfer level description. The 4-component vector variables "t", 2175 "u", and "v" are assigned intermediate results. The destination 2176 register is called "destination". The three possible source registers 2177 are called "source0", "source1", and "source2" respectively. 2178 2179 The x, y, z, and w vector components are referred to with the suffixes 2180 ".x", ".y", ".z", and ".w" respectively. The suffix ".c" is used for 2181 scalar source register values and c represents the particular source 2182 register's selected scalar component. Swizzling of components is 2183 indicated with the suffixes ".c***", ".*c**", ".**c*", and ".***c" 2184 where c is meant to indicate the x, y, z, or w component selected for 2185 the particular source operand swizzle configuration. For example: 2186 2187 t.x = source0.c***; 2188 t.y = source0.*c**; 2189 t.z = source0.**c*; 2190 t.w = source0.***c; 2191 2192 This example indicates that t should be assigned the swizzled 2193 version of the source0 operand based on the source0 operand's swizzle 2194 configuration. 2195 2196 The variables "negate0", "negate1", and "negate2" are booleans 2197 that are true when the respective source value should be negated. 2198 The variables "xmask", "ymask", "zmask", and "wmask" are booleans 2199 that are true when the destination write mask for the respective 2200 component is enabled for writing. 2201 2202 Otherwise, the register transfer level descriptions mimic ANSI C 2203 syntax. 2204 2205 The idiom "IEEE(expression)" represents the s23e8 single-precision 2206 result of the expression if evaluated using IEEE single-precision 2207 floating point operations. The IEEE idiom is used to specify the 2208 maximum allowed deviation from IEEE single-precision floating-point 2209 arithmetic results. 2210 2211 The following abbreviations are also used: 2212 2213 +Inf floating-point representation of positive infinity 2214 -Inf floating-point representation of negative infinity 2215 +NaN floating-point representation of positive not a number 2216 -NaN floating-point representation of negative not a number 2217 NA not applicable or not used 2218 2219 2.14.1.10.1 ARL: Address Register Load 2220 2221 The ARL instruction moves value of the source scalar into the address 2222 register. Conceptually, the address register load instruction is 2223 a 4-component vector signed integer register, but the only valid 2224 address register component for writing and indexing is the x 2225 component. The only use for A0.x is as a base address for program 2226 parameter reads. The source value is a float that is truncated 2227 towards negative infinity into a signed integer. 2228 2229 t.x = source0.c; 2230 if (negate0) t.x = -t.x; 2231 A0.x = floor(t.x); 2232 2233 2.14.1.10.2 MOV: Move 2234 2235 The MOV instruction moves the value of the source vector into the 2236 destination register. 2237 2238 t.x = source0.c***; 2239 t.y = source0.*c**; 2240 t.z = source0.**c*; 2241 t.w = source0.***c; 2242 if (negate0) { 2243 t.x = -t.x; 2244 t.y = -t.y; 2245 t.z = -t.z; 2246 t.w = -t.w; 2247 } 2248 if (xmask) destination.x = t.x; 2249 if (ymask) destination.y = t.y; 2250 if (zmask) destination.z = t.z; 2251 if (wmask) destination.w = t.w; 2252 2253 2.14.1.10.3 MUL: Multiply 2254 2255 The MUL instruction multiplies the values of the two source vectors 2256 into the destination register. 2257 2258 t.x = source0.c***; 2259 t.y = source0.*c**; 2260 t.z = source0.**c*; 2261 t.w = source0.***c; 2262 if (negate0) { 2263 t.x = -t.x; 2264 t.y = -t.y; 2265 t.z = -t.z; 2266 t.w = -t.w; 2267 } 2268 u.x = source1.c***; 2269 u.y = source1.*c**; 2270 u.z = source1.**c*; 2271 u.w = source1.***c; 2272 if (negate1) { 2273 u.x = -u.x; 2274 u.y = -u.y; 2275 u.z = -u.z; 2276 u.w = -u.w; 2277 } 2278 if (xmask) destination.x = t.x * u.x; 2279 if (ymask) destination.y = t.y * u.y; 2280 if (zmask) destination.z = t.z * u.z; 2281 if (wmask) destination.w = t.w * u.w; 2282 2283 2.14.1.10.4 ADD: Add 2284 2285 The ADD instruction adds the values of the two source vectors into 2286 the destination register. 2287 2288 t.x = source0.c***; 2289 t.y = source0.*c**; 2290 t.z = source0.**c*; 2291 t.w = source0.***c; 2292 if (negate0) { 2293 t.x = -t.x; 2294 t.y = -t.y; 2295 t.z = -t.z; 2296 t.w = -t.w; 2297 } 2298 u.x = source1.c***; 2299 u.y = source1.*c**; 2300 u.z = source1.**c*; 2301 u.w = source1.***c; 2302 if (negate1) { 2303 u.x = -u.x; 2304 u.y = -u.y; 2305 u.z = -u.z; 2306 u.w = -u.w; 2307 } 2308 if (xmask) destination.x = t.x + u.x; 2309 if (ymask) destination.y = t.y + u.y; 2310 if (zmask) destination.z = t.z + u.z; 2311 if (wmask) destination.w = t.w + u.w; 2312 2313 2.14.1.10.5 MAD: Multiply and Add 2314 2315 The MAD instruction adds the value of the third source vector to the 2316 product of the values of the first and second two source vectors, 2317 writing the result to the destination register. 2318 2319 t.x = source0.c***; 2320 t.y = source0.*c**; 2321 t.z = source0.**c*; 2322 t.w = source0.***c; 2323 if (negate0) { 2324 t.x = -t.x; 2325 t.y = -t.y; 2326 t.z = -t.z; 2327 t.w = -t.w; 2328 } 2329 u.x = source1.c***; 2330 u.y = source1.*c**; 2331 u.z = source1.**c*; 2332 u.w = source1.***c; 2333 if (negate1) { 2334 u.x = -u.x; 2335 u.y = -u.y; 2336 u.z = -u.z; 2337 u.w = -u.w; 2338 } 2339 v.x = source2.c***; 2340 v.y = source2.*c**; 2341 v.z = source2.**c*; 2342 v.w = source2.***c; 2343 if (negate2) { 2344 v.x = -v.x; 2345 v.y = -v.y; 2346 v.z = -v.z; 2347 v.w = -v.w; 2348 } 2349 if (xmask) destination.x = t.x * u.x + v.x; 2350 if (ymask) destination.y = t.y * u.y + v.y; 2351 if (zmask) destination.z = t.z * u.z + v.z; 2352 if (wmask) destination.w = t.w * u.w + v.w; 2353 2354 2.14.1.10.6 RCP: Reciprocal 2355 2356 The RCP instruction inverts the value of the source scalar into 2357 the destination register. The reciprocal of exactly 1.0 must be 2358 exactly 1.0. 2359 2360 Additionally the reciprocal of negative infinity gives [-0.0, -0.0, 2361 -0.0, -0.0]; the reciprocal of negative zero gives [-Inf, -Inf, -Inf, 2362 -Inf]; the reciprocal of positive zero gives [+Inf, +Inf, +Inf, +Inf]; 2363 and the reciprocal of positive infinity gives [0.0, 0.0, 0.0, 0.0]. 2364 2365 t.x = source0.c; 2366 if (negate0) { 2367 t.x = -t.x; 2368 } 2369 if (t.x == 1.0f) { 2370 u.x = 1.0f; 2371 } else { 2372 u.x = 1.0f / t.x; 2373 } 2374 if (xmask) destination.x = u.x; 2375 if (ymask) destination.y = u.x; 2376 if (zmask) destination.z = u.x; 2377 if (wmask) destination.w = u.x; 2378 2379 where 2380 2381 | u.x - IEEE(1.0f/t.x) | < 1.0f/(2^22) 2382 2383 for 1.0f <= t.x <= 2.0f. The intent of this precision requirement is 2384 that this amount of relative precision apply over all values of t.x. 2385 2386 2.14.1.10.7 RSQ: Reciprocal Square Root 2387 2388 The RSQ instruction assigns the inverse square root of the 2389 absolute value of the source scalar into the destination register. 2390 2391 Additionally, RSQ(0.0) gives [+Inf, +Inf, +Inf, +Inf]; and both 2392 RSQ(+Inf) and RSQ(-Inf) give [0.0, 0.0, 0.0, 0.0]; 2393 2394 t.x = source0.c; 2395 if (negate0) { 2396 t.x = -t.x; 2397 } 2398 u.x = 1.0f / sqrt(fabs(t.x)); 2399 if (xmask) destination.x = u.x; 2400 if (ymask) destination.y = u.x; 2401 if (zmask) destination.z = u.x; 2402 if (wmask) destination.w = u.x; 2403 2404 where 2405 2406 | u.x - IEEE(1.0f/sqrt(fabs(t.x))) | < 1.0f/(2^22) 2407 2408 for 1.0f <= t.x <= 4.0f. The intent of this precision requirement is 2409 that this amount of relative precision apply over all values of t.x. 2410 2411 2.14.1.10.8 DP3: Three-Component Dot Product 2412 2413 The DP3 instruction assigns the three-component dot product of the 2414 two source vectors into the destination register. 2415 2416 t.x = source0.c***; 2417 t.y = source0.*c**; 2418 t.z = source0.**c*; 2419 if (negate0) { 2420 t.x = -t.x; 2421 t.y = -t.y; 2422 t.z = -t.z; 2423 } 2424 u.x = source1.c***; 2425 u.y = source1.*c**; 2426 u.z = source1.**c*; 2427 if (negate1) { 2428 u.x = -u.x; 2429 u.y = -u.y; 2430 u.z = -u.z; 2431 } 2432 v.x = t.x * u.x + t.y * u.y + t.z * u.z; 2433 if (xmask) destination.x = v.x; 2434 if (ymask) destination.y = v.x; 2435 if (zmask) destination.z = v.x; 2436 if (wmask) destination.w = v.x; 2437 2438 2.14.1.10.9 DP4: Four-Component Dot Product 2439 2440 The DP4 instruction assigns the four-component dot product of the 2441 two source vectors into the destination register. 2442 2443 t.x = source0.c***; 2444 t.y = source0.*c**; 2445 t.z = source0.**c*; 2446 t.w = source0.***c; 2447 if (negate0) { 2448 t.x = -t.x; 2449 t.y = -t.y; 2450 t.z = -t.z; 2451 t.w = -t.w; 2452 } 2453 u.x = source1.c***; 2454 u.y = source1.*c**; 2455 u.z = source1.**c*; 2456 u.w = source1.***c; 2457 if (negate1) { 2458 u.x = -u.x; 2459 u.y = -u.y; 2460 u.z = -u.z; 2461 u.w = -u.w; 2462 } 2463 v.x = t.x * u.x + t.y * u.y + t.z * u.z + t.w * u.w; 2464 if (xmask) destination.x = v.x; 2465 if (ymask) destination.y = v.x; 2466 if (zmask) destination.z = v.x; 2467 if (wmask) destination.w = v.x; 2468 2469 2.14.1.10.10 DST: Distance Vector 2470 2471 The DST instructions calculates a distance vector for the values 2472 of two source vectors. The first vector is assumed to be [NA, d*d, 2473 d*d, NA] and the second source vector is assumed to be [NA, 1.0/d, 2474 NA, 1.0/d], where the value of a component labeled NA is undefined. 2475 The destination vector is then assigned [1,d,d*d,1.0/d]. 2476 2477 t.y = source0.*c**; 2478 t.z = source0.**c*; 2479 if (negate0) { 2480 t.y = -t.y; 2481 t.z = -t.z; 2482 } 2483 u.y = source1.*c**; 2484 u.w = source1.***c; 2485 if (negate1) { 2486 u.y = -u.y; 2487 u.w = -u.w; 2488 } 2489 if (xmask) destination.x = 1.0; 2490 if (ymask) destination.y = t.y*u.y; 2491 if (zmask) destination.z = t.z; 2492 if (wmask) destination.w = u.w; 2493 2494 2.14.1.10.11 MIN: Minimum 2495 2496 The MIN instruction assigns the component-wise minimum of the two 2497 source vectors into the destination register. 2498 2499 t.x = source0.c***; 2500 t.y = source0.*c**; 2501 t.z = source0.**c*; 2502 t.w = source0.***c; 2503 if (negate0) { 2504 t.x = -t.x; 2505 t.y = -t.y; 2506 t.z = -t.z; 2507 t.w = -t.w; 2508 } 2509 u.x = source1.c***; 2510 u.y = source1.*c**; 2511 u.z = source1.**c*; 2512 u.w = source1.***c; 2513 if (negate1) { 2514 u.x = -u.x; 2515 u.y = -u.y; 2516 u.z = -u.z; 2517 u.w = -u.w; 2518 } 2519 if (xmask) destination.x = (t.x < u.x) ? t.x : u.x; 2520 if (ymask) destination.y = (t.y < u.y) ? t.y : u.y; 2521 if (zmask) destination.z = (t.z < u.z) ? t.z : u.z; 2522 if (wmask) destination.w = (t.w < u.w) ? t.w : u.w; 2523 2524 2.14.1.10.12 MAX: Maximum 2525 2526 The MAX instruction assigns the component-wise maximum of the two 2527 source vectors into the destination register. 2528 2529 t.x = source0.c***; 2530 t.y = source0.*c**; 2531 t.z = source0.**c*; 2532 t.w = source0.***c; 2533 if (negate0) { 2534 t.x = -t.x; 2535 t.y = -t.y; 2536 t.z = -t.z; 2537 t.w = -t.w; 2538 } 2539 u.x = source1.c***; 2540 u.y = source1.*c**; 2541 u.z = source1.**c*; 2542 u.w = source1.***c; 2543 if (negate1) { 2544 u.x = -u.x; 2545 u.y = -u.y; 2546 u.z = -u.z; 2547 u.w = -u.w; 2548 } 2549 if (xmask) destination.x = (t.x >= u.x) ? t.x : u.x; 2550 if (ymask) destination.y = (t.y >= u.y) ? t.y : u.y; 2551 if (zmask) destination.z = (t.z >= u.z) ? t.z : u.z; 2552 if (wmask) destination.w = (t.w >= u.w) ? t.w : u.w; 2553 2554 2.14.1.10.13 SLT: Set On Less Than 2555 2556 The SLT instruction performs a component-wise assignment of either 2557 1.0 or 0.0 into the destination register. 1.0 is assigned if the 2558 value of the first source vector is less than the value of the second 2559 source vector; otherwise, 0.0 is assigned. 2560 2561 t.x = source0.c***; 2562 t.y = source0.*c**; 2563 t.z = source0.**c*; 2564 t.w = source0.***c; 2565 if (negate0) { 2566 t.x = -t.x; 2567 t.y = -t.y; 2568 t.z = -t.z; 2569 t.w = -t.w; 2570 } 2571 u.x = source1.c***; 2572 u.y = source1.*c**; 2573 u.z = source1.**c*; 2574 u.w = source1.***c; 2575 if (negate1) { 2576 u.x = -u.x; 2577 u.y = -u.y; 2578 u.z = -u.z; 2579 u.w = -u.w; 2580 } 2581 if (xmask) destination.x = (t.x < u.x) ? 1.0 : 0.0; 2582 if (ymask) destination.y = (t.y < u.y) ? 1.0 : 0.0; 2583 if (zmask) destination.z = (t.z < u.z) ? 1.0 : 0.0; 2584 if (wmask) destination.w = (t.w < u.w) ? 1.0 : 0.0; 2585 2586 2.14.1.10.14 SGE: Set On Greater or Equal Than 2587 2588 The SGE instruction performs a component-wise assignment of either 2589 1.0 or 0.0 into the destination register. 1.0 is assigned if the 2590 value of the first source vector is greater than or equal the value 2591 of the second source vector; otherwise, 0.0 is assigned. 2592 2593 t.x = source0.c***; 2594 t.y = source0.*c**; 2595 t.z = source0.**c*; 2596 t.w = source0.***c; 2597 if (negate0) { 2598 t.x = -t.x; 2599 t.y = -t.y; 2600 t.z = -t.z; 2601 t.w = -t.w; 2602 } 2603 u.x = source1.c***; 2604 u.y = source1.*c**; 2605 u.z = source1.**c*; 2606 u.w = source1.***c; 2607 if (negate1) { 2608 u.x = -u.x; 2609 u.y = -u.y; 2610 u.z = -u.z; 2611 u.w = -u.w; 2612 } 2613 if (xmask) destination.x = (t.x >= u.x) ? 1.0 : 0.0; 2614 if (ymask) destination.y = (t.y >= u.y) ? 1.0 : 0.0; 2615 if (zmask) destination.z = (t.z >= u.z) ? 1.0 : 0.0; 2616 if (wmask) destination.w = (t.w >= u.w) ? 1.0 : 0.0; 2617 2618 2.14.1.10.15 EXP: Exponential Base 2 2619 2620 The EXP instruction generates an approximation of the exponential base 2621 2 for the value of a source scalar. This approximation is assigned 2622 to the z component of the destination register. Additionally, 2623 the x and y components of the destination register are assigned 2624 values useful for determining a more accurate approximation. The 2625 exponential base 2 of the source scalar can be better approximated 2626 by destination.x*FUNC(destination.y) where FUNC is some user 2627 approximation (presumably implemented by subsequent instructions in 2628 the vertex program) to 2^destination.y where 0.0 <= destination.y < 2629 1.0. 2630 2631 Additionally, EXP(-Inf) or if the exponential result underflows 2632 gives [0.0, 0.0, 0.0, 1.0]; and EXP(+Inf) or if the exponential result 2633 overflows gives [+Inf, 0.0, +Inf, 1.0]. 2634 2635 t.x = source0.c; 2636 if (negate0) { 2637 t.x = -t.x; 2638 } 2639 q.x = 2^floor(t.x); 2640 q.y = t.x - floor(t.x); 2641 q.z = q.x * APPX(q.y); 2642 if (xmask) destination.x = q.x; 2643 if (ymask) destination.y = q.y; 2644 if (zmask) destination.z = q.z; 2645 if (wmask) destination.w = 1.0; 2646 2647 where APPX is an implementation dependent approximation of exponential 2648 base 2 such that 2649 2650 | exp(q.y*log(2.0))-APPX(q.y) | < 1/(2^11) 2651 2652 for all 0 <= q.y < 1.0. 2653 2654 The expression "2^floor(t.x)" should overflow to +Inf and underflow 2655 to zero. 2656 2657 2.14.1.10.16 LOG: Logarithm Base 2 2658 2659 The LOG instruction generates an approximation of the logarithm base 2660 2 for the absolute value of a source scalar. This approximation 2661 is assigned to the z component of the destination register. 2662 Additionally, the x and y components of the destination register are 2663 assigned values useful for determining a more accurate approximation. 2664 The logarithm base 2 of the absolute value of the source scalar 2665 can be better approximated by destination.x+FUNC(destination.y) 2666 where FUNC is some user approximation (presumably implemented by 2667 subsequent instructions in the vertex program) of log2(destination.y) 2668 where 1.0 <= destination.y < 2.0. 2669 2670 Additionally, LOG(0.0) gives [-Inf, 1.0, -Inf, 1.0]; and both 2671 LOG(+Inf) and LOG(-Inf) give [+Inf, 1.0, +Inf, 1.0]. 2672 2673 t.x = source0.c; 2674 if (negate0) { 2675 t.x = -t.x; 2676 } 2677 if (fabs(t.x) != 0.0f) { 2678 if (fabs(t.x) == +Inf) { 2679 q.x = +Inf; 2680 q.y = 1.0; 2681 q.z = +Inf; 2682 } else { 2683 q.x = Exponent(t.x); 2684 q.y = Mantissa(t.x); 2685 q.z = q.x + APPX(q.y); 2686 } 2687 } else { 2688 q.x = -Inf; 2689 q.y = 1.0; 2690 q.z = -Inf; 2691 } 2692 if (xmask) destination.x = q.x; 2693 if (ymask) destination.y = q.y; 2694 if (zmask) destination.z = q.z; 2695 if (wmask) destination.w = 1.0; 2696 2697 where APPX is an implementation dependent approximation of logarithm 2698 base 2 such that 2699 2700 | log(q.y)/log(2.0) - APPX(q.y) | < 1/(2^11) 2701 2702 for all 1.0 <= q.y < 2.0. 2703 2704 The "Exponent(t.x)" function returns the unbiased exponent between 2705 -126 and 127. For example, "Exponent(1.0)" equals 0.0. (Note that 2706 the IEEE floating-point representation maintains the exponent as a 2707 biased value.) Larger or smaller exponents should generate +Inf or 2708 -Inf respectively. The "Mantissa(t.x)" function returns a value 2709 in the range [1.0f, 2.0). The intent of these functions is that 2710 fabs(t.x) is approximately "Mantissa(t.x)*2^Exponent(t.x)". 2711 2712 2.14.1.10.17 LIT: Light Coefficients 2713 2714 The LIT instruction is intended to compute ambient, diffuse, 2715 and specular lighting coefficients from a diffuse dot product, 2716 a specular dot product, and a specular power that is clamped to 2717 (-128,128) exclusive. The x component of the source vector is 2718 assumed to contain a diffuse dot product (unit normal vector dotted 2719 with a unit light vector). The y component of the source vector is 2720 assumed to contain a Blinn specular dot product (unit normal vector 2721 dotted with a unit half-angle vector). The w component is assumed 2722 to contain a specular power. 2723 2724 An implementation must support at least 8 fraction bits in the 2725 specular power. Note that because 0.0 times anything must be 0.0, 2726 taking any base to the power of 0.0 will yield 1.0. 2727 2728 t.x = source0.c***; 2729 t.y = source0.*c**; 2730 t.w = source0.***c; 2731 if (negate0) { 2732 t.x = -t.x; 2733 t.y = -t.y; 2734 t.w = -t.w; 2735 } 2736 if (t.w < -(128.0-epsilon)) t.w = -(128.0-epsilon); 2737 else if (t.w > 128-epsilon) t.w = 128-epsilon; 2738 if (t.x < 0.0) t.x = 0.0; 2739 if (t.y < 0.0) t.y = 0.0; 2740 if (xmask) destination.x = 1.0; 2741 if (ymask) destination.y = t.x; 2742 if (zmask) destination.z = (t.x > 0.0) ? EXP(t.w*LOG(t.y)) : 0.0; 2743 if (wmask) destination.w = 1.0; 2744 2745 where EXP and LOG are functions that approximate the exponential base 2746 2 and logarithm base 2 with the identical accuracy and special case 2747 requirements of the EXP and LOG instructions. epsilon is 1.0/256.0 2748 or approximately 0.0039 which would correspond to representing the 2749 specular power with a s8.8 representation. 2750 2751 2.14.1.11 Vertex Program Floating Point Requirements 2752 2753 All vertex program calculations are assumed to use IEEE single 2754 precision floating-point math with a format of s1e8m23 (one signed 2755 bit, 8 bits of exponent, 23 bits of magnitude) or better and the 2756 round-to-zero rounding mode. The only exceptions to this are the RCP, 2757 RSQ, LOG, EXP, and LIT instructions. 2758 2759 Note that (positive or negative) 0.0 times anything is (positive) 2760 0.0. 2761 2762 The RCP and RSQ instructions deliver results accurate to 1.0/(2^22) 2763 and the approximate output (the z component) of the EXP and LOG 2764 instructions only has to be accurate to 1.0/(2^11). The LIT 2765 instruction specular output (the z component) is allowed an error 2766 equivalent to the combination of the EXP and LOG combination to 2767 implement a power function. 2768 2769 The floor operations used by the ARL and EXP instructions must 2770 operate identically. Specifically, the EXP instruction's floor(t.x) 2771 intermediate result must exactly match the integer stored in the 2772 address register by the ARL instruction. 2773 2774 Since distance is calculated as (d^2)*(1/sqrt(d^2)), 0.0 multiplied 2775 by anything must be 0.0. This affects the MUL, MAD, DP3, DP4, DST, 2776 and LIT instructions. 2777 2778 Because if/then/else conditional evaluation is done by multiplying 2779 by 1.0 or 0.0 and adding, the floating point computations require: 2780 2781 0.0 * x = 0.0 for all x (including +Inf, -Inf, +NaN, and -NaN) 2782 1.0 * x = x for all x (including +Inf and -Inf) 2783 0.0 + x = x for all x (including +Inf and -Inf) 2784 2785 Including +Inf, -Inf, +NaN, and -NaN when applying the above three 2786 rules is recommended but not required. (The recommended inclusion 2787 of +Inf, -Inf, +NaN, and -NaN when applying the first rule is 2788 inconsistent with IEEE floating-point requirements.) 2789 2790 For the purpose of comparisons performed by the SGE and SLT 2791 instructions, -0.0 is less than +0.0, -NaN is less than -Inf, 2792 and +NaN is greater than +Inf. (This is inconsistent with IEEE 2793 floating-point requirements). 2794 2795 No floating-point exceptions or interrupts are generated. Denorms 2796 are not supported; if a denorm is input, it is treated as 0.0 (ie, 2797 denorms are flushed to zero). 2798 2799 Computations involving +NaN or -NaN generate +NaN, except for the 2800 requirement that zero times +NaN or -NaN must always be zero. (This 2801 exception is inconsistent with IEEE floating-point requirements). 2802 2803 2.14.2 Vertex Program Update for the Current Raster Position 2804 2805 When vertex programs are enabled, the raster position is determined 2806 by the current vertex program. The raster position specified by 2807 RasterPos is treated as if they were specified in a Vertex command. 2808 The contents of vertex result register set is used to update respective 2809 raster position state. 2810 2811 Assuming an existent program, the homogeneous clip-space coordinates 2812 are passed to clipping as if they represented a point and assuming no 2813 client-defined clip planes are enabled. If the point is not culled, 2814 then the projection to window coordinates is computed (section 2.10) 2815 and saved as the current raster position and the valid bit is set. 2816 If the current vertex program is nonexistent or the "point" is 2817 culled, the current raster position and its associated data become 2818 indeterminate and the raster position valid bit is cleared. 2819 2820 2.14.3 Vertex Arrays for Vertex Attributes 2821 2822 Data for vertex attributes in vertex program mode may be specified 2823 using vertex array commands. The client may specify and enable any 2824 of sixteen vertex attribute arrays. 2825 2826 The vertex attribute arrays are ignored when vertex program mode 2827 is disabled. When vertex program mode is enabled, vertex attribute 2828 arrays are used. 2829 2830 The command 2831 2832 void VertexAttribPointerNV(uint index, int size, enum type, 2833 sizei stride, const void *pointer); 2834 2835 describes the locations and organizations of the sixteen vertex 2836 attribute arrays. index specifies the particular vertex attribute 2837 to be described. size indicates the number of values per vertex 2838 that are stored in the array; size must be one of 1, 2, 3, or 4. 2839 type specifies the data type of the values stored in the array. 2840 type must be one of SHORT, FLOAT, DOUBLE, or UNSIGNED_BYTE and these 2841 values correspond to the array types short, int, float, double, and 2842 ubyte respectively. The INVALID_OPERATION error is generated if 2843 type is UNSIGNED_BYTE and size is not 4. The INVALID_VALUE error 2844 is generated if index is greater than 15. The INVALID_VALUE error 2845 is generated if stride is negative. 2846 2847 The one, two, three, or four values in an array that correspond to a 2848 single vertex attribute comprise an array element. The values within 2849 each array element at stored sequentially in memory. If the stride 2850 is specified as zero, then array elements are stored sequentially 2851 as well. Otherwise points to the ith and (i+1)st elements of an array 2852 differ by stride basic machine units (typically unsigned bytes), 2853 the pointer to the (i+1)st element being greater. pointer specifies 2854 the location in memory of the first value of the first element of 2855 the array being specified. 2856 2857 Vertex attribute arrays are enabled with the EnableClientState command 2858 and disabled with the DisableClientState command. The value of the 2859 argument to either command is VERTEX_ATTRIB_ARRAYi_NV where i is an 2860 integer between 0 and 15; specifying a value of i enables or 2861 disables the vertex attribute array with index i. The constants 2862 obey VERTEX_ATTRIB_ARRAYi_NV = VERTEX_ATTRIB_ARRAY0_NV + i. 2863 2864 When vertex program mode is enabled, the ArrayElement command operates 2865 as described in this section in contrast to the behavior described 2866 in section 2.8. Likewise, any vertex array transfer commands that 2867 are defined in terms of ArrayElement (DrawArrays, DrawElements, and 2868 DrawRangeElements) assume the operation of ArrayElement described 2869 in this section when vertex program mode is enabled. 2870 2871 When vertex program mode is enabled, the ArrayElement command 2872 transfers the ith element of particular enabled vertex arrays as 2873 described below. For each enabled vertex attribute array, it is 2874 as though the corresponding command from section 2.14.1.1 were 2875 called with a pointer to element i. For each vertex attribute, 2876 the corresponding command is VertexAttrib[size][type]v, where size 2877 is one of [1,2,3,4], and type is one of [s,f,d,ub], corresponding 2878 to the array types short, int, float, double, and ubyte respectively. 2879 2880 However, if a given vertex attribute array is disabled, but its 2881 corresponding aliased conventional per-vertex parameter's vertex 2882 array (as described in section 2.14.1.6) is enabled, then it is 2883 as though the corresponding command from section 2.7 or section 2884 2.6.2 were called with a pointer to element i. In this case, the 2885 corresponding command is determined as described in section 2.8's 2886 description of ArrayElement. 2887 2888 If the vertex attribute array 0 is enabled, it is as though 2889 VertexAttrib[size][type]v(0, ...) is executed last, after the 2890 executions of other corresponding commands. If the vertex attribute 2891 array 0 is disabled but the vertex array is enabled, it is as though 2892 Vertex[size][type]v is executed last, after the executions of other 2893 corresponding commands. 2894 2895 2.14.4 Vertex State Programs 2896 2897 Vertex state programs share the same instruction set as and a similar 2898 execution model to vertex programs. While vertex program are executed 2899 implicitly when a vertex transformation is provoked, vertex state 2900 programs are executed explicitly, independently of any vertices. 2901 Vertex state programs can write program parameter registers, but 2902 may not write vertex result registers. 2903 2904 The purpose of a vertex state program is to update program parameter 2905 registers by means of an application-defined program. Typically, 2906 an application will load a set of program parameters and then execute 2907 a vertex state program that reads and updates the program parameter 2908 registers. For example, a vertex state program might normalize a 2909 set of unnormalized vectors previously loaded as program parameters. 2910 The expectation is that subsequently executed vertex programs would 2911 use the normalized program parameters. 2912 2913 Vertex state programs are loaded with the same LoadProgramNV command 2914 (see section 2.14.1.7) used to load vertex programs except that the 2915 target must be VERTEX_STATE_PROGRAM_NV when loading a vertex state 2916 program. 2917 2918 Vertex state programs must conform to a more limited grammar than 2919 the grammar for vertex programs. The vertex state program grammar 2920 for syntactically valid sequences is the same as the grammar defined 2921 in section 2.14.1.7 with the following modified rules: 2922 2923 <program> ::= "!!VSP1.0" <instructionSequence> "END" 2924 2925 <dstReg> ::= <absProgParamReg> 2926 | <temporaryReg> 2927 2928 <vertexAttribReg> ::= "v" "[" "0" "]" 2929 2930 A vertex state program fails to load if it does not write at least 2931 one program parameter register. 2932 2933 A vertex state program fails to load if it contains more than 128 2934 instructions. 2935 2936 A vertex state program fails to load if any instruction sources more 2937 than one unique program parameter register. 2938 2939 A vertex state program fails to load if any instruction sources 2940 more than one unique vertex attribute register (this is necessarily 2941 true because only vertex attribute 0 is available in vertex state 2942 programs). 2943 2944 The error INVALID_OPERATION is generated if a vertex state program 2945 fails to load because it is not syntactically correct or for one 2946 of the other reasons listed above. 2947 2948 A successfully loaded vertex state program is parsed into a sequence 2949 of instructions. Each instruction is identified by its tokenized 2950 name. The operation of these instructions when executed is defined 2951 in section 2.14.1.10. 2952 2953 Executing vertex state programs is legal only outside a Begin/End 2954 pair. A vertex state program may not read any vertex attribute 2955 register other than register zero. A vertex state program may not 2956 write any vertex result register. 2957 2958 The command 2959 2960 ExecuteProgramNV(enum target, uint id, const float *params); 2961 2962 executes the vertex state program named by id. The target must be 2963 VERTEX_STATE_PROGRAM_NV and the id must be the name of program loaded 2964 with a target type of VERTEX_STATE_PROGRAM_NV. params points to 2965 an array of four floating-point values that are loaded into vertex 2966 attribute register zero (the only vertex attribute readable from a 2967 vertex state program). 2968 2969 The INVALID_OPERATION error is generated if the named program is 2970 nonexistent, is invalid, or the program is not a vertex state 2971 program. A vertex state program may not be valid for reasons 2972 explained in section 2.14.5. 2973 2974 2.14.5 Tracking Matrices 2975 2976 As a convenience to applications, standard GL matrix state can be 2977 tracked into program parameter vectors. This permits vertex programs 2978 to access matrices specified through GL matrix commands. 2979 2980 In addition to GL's conventional matrices, several additional matrices 2981 are available for tracking. These matrices have names of the form 2982 MATRIXi_NV where i is between zero and n-1 where n is the value 2983 of the MAX_TRACK_MATRICES_NV implementation dependent constant. 2984 The MATRIXi_NV constants obey MATRIXi_NV = MATRIX0_NV + i. The value 2985 of MAX_TRACK_MATRICES_NV must be at least eight. The maximum 2986 stack depth for tracking matrices is defined by the 2987 MAX_TRACK_MATRIX_STACK_DEPTH_NV and must be at least 1. 2988 2989 The command 2990 2991 TrackMatrixNV(enum target, uint address, enum matrix, enum transform); 2992 2993 tracks a given transformed version of a particular matrix into 2994 a contiguous sequence of four vertex program parameter registers 2995 beginning at address. target must be VERTEX_PROGRAM_NV (though 2996 tracked matrices apply to vertex state programs as well because both 2997 vertex state programs and vertex programs shared the same program 2998 parameter registers). matrix must be one of NONE, MODELVIEW, 2999 PROJECTION, TEXTURE, TEXTUREi_ARB (where i is between 0 and n-1 3000 where n is the number of texture units supported), COLOR (if 3001 the ARB_imaging subset is supported), MODELVIEW_PROJECTION_NV, 3002 or MATRIXi_NV. transform must be one of IDENTITY_NV, INVERSE_NV, 3003 TRANSPOSE_NV, or INVERSE_TRANSPOSE_NV. The INVALID_VALUE error is 3004 generated if address is not a multiple of four. 3005 3006 The MODELVIEW_PROJECTION_NV matrix represents the concatenation of 3007 the current modelview and projection matrices. If M is the current 3008 modelview matrix and P is the current projection matrix, then the 3009 MODELVIEW_PROJECTION_NV matrix is C and computed as 3010 3011 C = P M 3012 3013 Matrix tracking for the specified program parameter register and the 3014 next consecutive three registers is disabled when NONE is supplied 3015 for matrix. When tracking is disabled the previously tracked program 3016 parameter registers retain the state of their last tracked values. 3017 Otherwise, the specified transformed version of matrix is tracked into 3018 the specified program parameter register and the next three registers. 3019 Whenever the matrix changes, the transformed version of the matrix 3020 is updated in the specified range of program parameter registers. 3021 If TEXTURE is specified for matrix, the texture matrix for the current 3022 active texture unit is tracked. If TEXTUREi_ARB is specified for 3023 matrix, the <i>th texture matrix is tracked. 3024 3025 Matrices are tracked row-wise meaning that the top row of the 3026 transformed matrix is loaded into the program parameter address, 3027 the second from the top row of the transformed matrix is loaded into 3028 the program parameter address+1, the third from the top row of the 3029 transformed matrix is loaded into the program parameter address+2, 3030 and the bottom row of the transformed matrix is loaded into the 3031 program parameter address+3. The transformed matrix may be identical 3032 to the specified matrix, the inverse of the specified matrix, the 3033 transpose of the specified matrix, or the inverse transpose of the 3034 specified matrix, depending on the value of transform. 3035 3036 When matrix tracking is enabled for a particular program parameter 3037 register sequence, updates to the program parameter using 3038 ProgramParameterNV commands, a vertex program, or a vertex state 3039 program are not possible. The INVALID_OPERATION error is generated 3040 if a ProgramParameterNV command is used to update a program parameter 3041 register currently tracking a matrix. 3042 3043 The INVALID_OPERATION error is generated by ExecuteProgramNV when 3044 the vertex state program requested for execution writes to a program 3045 parameter register that is currently tracking a matrix because the 3046 program is considered invalid. 3047 3048 2.14.6 Required Vertex Program State 3049 3050 The state required for vertex programs consists of: 3051 3052 a bit indicating whether or not program mode is enabled; 3053 3054 a bit indicating whether or not two-sided color mode is enabled; 3055 3056 a bit indicating whether or not program-specified point size mode 3057 is enabled; 3058 3059 96 4-component floating-point program parameter registers; 3060 3061 16 4-component vertex attribute registers (though this state is 3062 aliased with the current normal, primary color, secondary color, 3063 fog coordinate, weights, and texture coordinate sets); 3064 3065 24 sets of matrix tracking state for each set of four sequential 3066 program parameter registers, consisting of a n-valued integer 3067 indicated the tracked matrix or GL_NONE (where n is 5 + the number 3068 of texture units supported + the number of tracking matrices 3069 supported) and a four-valued integer indicating the transformation 3070 of the tracked matrix; 3071 3072 an unsigned integer naming the currently bound vertex program 3073 3074 and the state must be maintained to indicate which integers 3075 are currently in use as program names. 3076 3077 Each existent program object consists of a target, a boolean indicating 3078 whether the program is resident, an array of type ubyte containing the 3079 program string, and the length of the program string array. Initially, 3080 no program objects exist. 3081 3082 Program mode, two-sided color mode, and program-specified point size 3083 mode are all initially disabled. 3084 3085 The initial state of all 96 program parameter registers is (0,0,0,0). 3086 3087 The initial state of the 16 vertex attribute registers is (0,0,0,1) 3088 except in cases where a vertex attribute register aliases to a 3089 conventional GL transform mode vertex parameter in which case 3090 the initial state is the initial state of the respective aliased 3091 conventional vertex parameter. 3092 3093 The initial state of the 24 sets of matrix tracking state is NONE 3094 for the tracked matrix and IDENTITY_NV for the transformation of the 3095 tracked matrix. 3096 3097 The initial currently bound program is zero. 3098 3099 The client state required to implement the 16 vertex attribute 3100 arrays consists of 16 boolean values, 16 memory pointers, 16 integer 3101 stride values, 16 symbolic constants representing array types, 3102 and 16 integers representing values per element. Initially, the 3103 boolean values are each disabled, the memory pointers are each null, 3104 the strides are each zero, the array types are each FLOAT, and the 3105 integers representing values per element are each four." 3106 3107Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization) 3108 3109 -- Section 3.3 "Points" 3110 3111 Change the first paragraph to read: 3112 3113 "When program vertex mode is disabled, the point size for rasterizing 3114 points is controlled with 3115 3116 void PointSize(float size); 3117 3118 size specifies the width or diameter of a point. The initial point size 3119 value is 1.0. A value less than or equal to zero results in the error 3120 INVALID_VALUE. When vertex program mode is enabled, the point size for 3121 rasterizing points is determined as described in section 2.14.1.5." 3122 3123 -- Section 3.9 "Color Sum" 3124 3125 Change the first paragraph to read: 3126 3127 "At the beginning of color sum, a fragment has two RGBA colors: a 3128 primary color cpri (which texturing, if enabled, may have modified) 3129 and a secondary color csec. If vertex program mode is disabled, csec 3130 is defined by the lighting equations in section 2.13.1. If vertex 3131 program mode is enabled, csec is the fragment's secondary color, 3132 obtained by interpolating the COL1 (or BFC1 if the primitive is a 3133 polygon, the vertex program two-sided color mode is enabled, and the 3134 polygon is back-facing) vertex result register RGB components for the 3135 vertices making up the primitive; the alpha component of csec when 3136 program mode is enabled is always zero. The components of these two 3137 colors are summed to produce a single post-texturing RGBA color c. 3138 The components of c are then clamped to the range [0,1]." 3139 3140 -- Section 3.10 "Fog" 3141 3142 Change the initial sentences in the second paragraph to read: 3143 3144 "This factor f may be computed according to one of three equations: 3145 3146 f = exp(-d*c) (3.24) 3147 f = exp(-(d*c)^2) (3.25) 3148 f = (e-c)/(e-s) (3.26) 3149 3150 If vertex program mode is enabled, then c is the fragment's fog 3151 coordinate, obtained by interpolating the FOGC vertex result register 3152 values for the vertices making up the primitive. When vertex program 3153 mode is disabled, the c is the eye-coordinate distance from the eye, 3154 (0,0,0,1) in eye-coordinates, to the fragment center." ... 3155 3156Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment 3157Operations and the Framebuffer) 3158 3159 None 3160 3161Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions) 3162 3163 -- Section 5.1 "Evaluators" 3164 3165 Add the following lines to the end of table 5.1 (page 165): 3166 3167 target k values 3168 ------------------------- --- ------------------------------ 3169 MAP1_VERTEX_ATTRIB0_4_NV 4 x, y, z, w vertex attribute 0 3170 MAP1_VERTEX_ATTRIB1_4_NV 4 x, y, z, w vertex attribute 1 3171 MAP1_VERTEX_ATTRIB2_4_NV 4 x, y, z, w vertex attribute 2 3172 MAP1_VERTEX_ATTRIB3_4_NV 4 x, y, z, w vertex attribute 3 3173 MAP1_VERTEX_ATTRIB4_4_NV 4 x, y, z, w vertex attribute 4 3174 MAP1_VERTEX_ATTRIB5_4_NV 4 x, y, z, w vertex attribute 5 3175 MAP1_VERTEX_ATTRIB6_4_NV 4 x, y, z, w vertex attribute 6 3176 MAP1_VERTEX_ATTRIB7_4_NV 4 x, y, z, w vertex attribute 7 3177 MAP1_VERTEX_ATTRIB8_4_NV 4 x, y, z, w vertex attribute 8 3178 MAP1_VERTEX_ATTRIB9_4_NV 4 x, y, z, w vertex attribute 9 3179 MAP1_VERTEX_ATTRIB10_4_NV 4 x, y, z, w vertex attribute 10 3180 MAP1_VERTEX_ATTRIB11_4_NV 4 x, y, z, w vertex attribute 11 3181 MAP1_VERTEX_ATTRIB12_4_NV 4 x, y, z, w vertex attribute 12 3182 MAP1_VERTEX_ATTRIB13_4_NV 4 x, y, z, w vertex attribute 13 3183 MAP1_VERTEX_ATTRIB14_4_NV 4 x, y, z, w vertex attribute 14 3184 MAP1_VERTEX_ATTRIB15_4_NV 4 x, y, z, w vertex attribute 15 3185 3186 Replace the four paragraphs on pages 167-168 that explain the 3187 operation of EvalCoord: 3188 3189 "EvalCoord operates differently depending on whether vertex program 3190 mode is enabled or not. We first discuss how EvalCoord operates when 3191 vertex program mode is disabled. 3192 3193 When one of the EvalCoord commands is issued and vertex program 3194 mode is disabled, all currently enabled maps (excluding the 3195 maps that correspond to vertex attributes, i.e. maps of the form 3196 MAPx_VERTEX_ATTRIBn_4_NV). ..." 3197 3198 Add a paragraph before the initial paragraph discussing AUTO_NORMAL: 3199 3200 "When one of the EvalCoord commands is issued and vertex program mode 3201 is enabled, the evaluation and the issuing of per-vertex parameter commands 3202 matches the discussion above, except that if any vertex attribute 3203 maps are enabled, the corresponding VertexAttribNV call for each enabled 3204 vertex attribute map is issued with the map's evaluated coordinates 3205 and the corresponding aliased per-vertex parameter map is ignored 3206 if it is also enabled, with one important difference. As is the case when 3207 vertex program mode is disabled, the GL uses evaluated values 3208 instead of current values for those evaluations that are enabled 3209 (otherwise the current values are used). The order of the effective 3210 commands is immaterial, except that Vertex or VertexAttribNV(0, 3211 ...) (the commands that issue provoke vertex program execution) 3212 must be issued last. Use of evaluators has no effect on the current 3213 vertex attributes or conventional per-vertex parameters. If a 3214 vertex attribute map is disabled, but its corresponding conventional 3215 per-vertex parameter map is enabled, the conventional per-vertex 3216 parameter map is evaluated and issued as when vertex program mode 3217 is not enabled." 3218 3219 Replace the two paragraphs discussing AUTO_NORMAL with: 3220 3221 "Finally, if either MAP2_VERTEX_3 or MAP2_VERTEX_4 is enabled or if 3222 both MAP2_VERTEX_ATTRIB0_4_NV and vertex program mode are enabled, 3223 then the normal to the surface is computed. Analytic computation, 3224 which sometimes yields normals of length zero, is one method which 3225 may be used. If automatic normal generation is enabled, then this 3226 computed normal is used as the normal associated with a generated 3227 vertex (when program mode is disabled) or as vertex attribute 2 3228 (when vertex program mode is enabled). Automatic normal generation 3229 is controlled with Enable and Disable with the symbolic constant 3230 AUTO_NORMAL. If automatic normal generation is disabled and vertex 3231 program mode is enabled, then vertex attribute 2 is evaluated 3232 as usual. If automatic normal generation and vertex program mode 3233 are disabled, then a corresponding normal map, if enabled, is used 3234 to produce a normal. If neither automatic normal generation nor 3235 a map corresponding to the normal per-vertex parameter (or vertex 3236 attribute 2 in program mode) are enabled, then no normal is sent with 3237 a vertex resulting from an evaluation (the effect is that the current 3238 normal is used). For MAP_VERTEX3, let q=p. For MAP_VERTEX_4 or 3239 MAP2_VERTEX_ATTRBI0_4_NV, let q = (x/w, y/w, z/w) where (x,y,z,w)=p. 3240 Then let 3241 3242 m = (partial q / partial u) cross (partial q / partial v) 3243 3244 Then when vertex program mode is disabled, the generated analytic 3245 normal, n, is given by n=m/||m||. However, when vertex program mode 3246 is enabled, the generated analytic normal used for vertex attribute 3247 2 is simply (mx,my,mz,1). In vertex program mode, the normalization 3248 of the generated analytic normal can be performed by the current 3249 vertex program." 3250 3251 Change the respective sentences of the last paragraph discussing 3252 required evaluator state to read: 3253 3254 "The state required for evaluators potentially consists of 9 3255 conventional one-dimensional map specifications, 16 vertex attribute 3256 one-dimensional map specifications, 9 conventional two-dimensional 3257 map specifications, and 16 vertex attribute two-dimensional map 3258 specifications indicating which are enabled. ... All vertex 3259 coordinate maps produce the coordinates (0,0,0,1) (or the appropriate 3260 subset); all normal coordinate maps produce (0,0,1); RGBA maps produce 3261 (1,1,1,1); color index maps produce 1.0; texture coordinate maps 3262 produce (0,0,0,1); and vertex attribute maps produce (0,0,0,1). ... 3263 If any evaluation command is issued when none of MAPn_VERTEX_3, 3264 MAPn_VERTEX_4, or MAPn_VERTEX_ATTRIB0_NV (where n is the map dimension 3265 being evaluated) are enabled, nothing happens." 3266 3267 -- Section 5.4 "Display Lists" 3268 3269 Add to the list of commands not compiled into display lists in the 3270 third to the last paragraph: 3271 3272 "AreProgramsResidentNV, IsProgramNV, GenProgramsNV, DeleteProgramsNV, 3273 VertexAttribPointerNV" 3274 3275Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and 3276State Requests) 3277 3278 -- Section 6.1.12 "Saving and Restoring State" 3279 3280 Only the enables and vertex array state introduced by this extension 3281 can be pushed and popped. 3282 3283 See the attribute column in table X.5 for determining what vertex 3284 program state can be pushed and popped with PushAttrib, PopAttrib, 3285 PushClientAttrib, and PopClientAttrib. 3286 3287 The new evaluator enables in table 6.22 can also be pushed and 3288 popped. 3289 3290 -- NEW Section 6.1.13 "Vertex Program Queries" 3291 3292 "The commands 3293 3294 void GetProgramParameterfvNV(enum target, uint index, 3295 enum pname, float *params); 3296 void GetProgramParameterdvNV(enum target, uint index, 3297 enum pname, double *params); 3298 3299 obtain the current program parameters for the given program 3300 target and parameter index into the array params. target must 3301 be VERTEX_PROGRAM_NV. pname must be PROGRAM_PARAMETER_NV. 3302 The INVALID_VALUE error is generated if index is greater than 95. 3303 Each program parameter is an array of four values. 3304 3305 The command 3306 3307 void GetProgramivNV(uint id, enum pname, int *params); 3308 3309 obtains program state named by pname for the program named id 3310 in the array params. pname must be one of PROGRAM_TARGET_NV, 3311 PROGRAM_LENGTH_NV, or PROGRAM_RESIDENT_NV. The INVALID_OPERATION 3312 error is generated if the program named id does not exist. 3313 3314 The command 3315 3316 void GetProgramStringNV(uint id, enum pname, 3317 ubyte *program); 3318 3319 obtains the program string for program id. pname must be 3320 PROGRAM_STRING_NV. n ubytes are returned into the array program 3321 where n is the length of the program in ubytes. GetProgramivNV with 3322 PROGRAM_LENGTH_NV can be used to query the length of a program's 3323 string. The INVALID_OPERATION error is generated if the program 3324 named id does not exist. 3325 3326 The command 3327 3328 void GetTrackMatrixivNV(enum target, uint address, 3329 enum pname, int *params); 3330 3331 obtains the matrix tracking state named by pname for the specified 3332 address in the array params. target must be VERTEX_PROGRAM_NV. pname 3333 must be either TRACK_MATRIX_NV or TRACK_MATRIX_TRANSFORM_NV. If the 3334 matrix tracked is a texture matrix, TEXTUREi_ARB is returned (never 3335 TEXTURE) where i indicates the texture unit of the particular tracked 3336 texture matrix. The INVALID_VALUE error is generated if address is 3337 not divisible by four and is not less than 96. 3338 3339 The commands 3340 3341 void GetVertexAttribdvNV(uint index, enum pname, double *params); 3342 void GetVertexAttribfvNV(uint index, enum pname, float *params); 3343 void GetVertexAttribivNV(uint index, enum pname, int *params); 3344 3345 obtain the vertex attribute state named by pname for the vertex 3346 attribute numbered index. pname must be one of ATTRIB_ARRAY_SIZE_NV, 3347 ATTRIB_ARRAY_STRIDE_NV, ATTRIB_ARRAY_TYPE_NV, or CURRENT_ATTRIB_NV. 3348 Note that all the queries except CURRENT_ATTRIB_NV return client 3349 state. The INVALID_VALUE error is generated if index is greater than 3350 15, or if index is zero and pname is CURRENT_ATTRIB_NV. 3351 3352 The command 3353 3354 void GetVertexAttribPointervNV(uint index, 3355 enum pname, void **pointer); 3356 3357 obtains the pointer named pname in the array params for vertex 3358 attribute numbered index. pname must be ATTRIB_ARRAY_POINTER_NV. 3359 The INVALID_VALUE error is generated if index greater than 15. 3360 3361 The command 3362 3363 boolean IsProgramNV(uint id); 3364 3365 returns TRUE if program is the name of a program object. If program 3366 is zero or is a non-zero value that is not the name of a program 3367 object, or if an error condition occurs, IsProgramNV returns FALSE. 3368 A name returned by GenProgramsNV but not yet loaded with a program 3369 is not the name of a program object." 3370 3371 -- NEW Section 6.1.14 "Querying Current Matrix State" 3372 3373 "Instead of providing distinct symbolic tokens for querying each 3374 matrix and matrix stack depth, the symbolic tokens CURRENT_MATRIX_NV 3375 and CURRENT_MATRIX_STACK_DEPTH_NV in conjunction with the GetBooleanv, 3376 GetIntegerv, GetFloatv, and GetDoublev return the respective state 3377 of the current matrix given the current matrix mode. 3378 3379 Querying CURRENT_MATRIX_NV and CURRENT_MATRIX_STACK_DEPTH_NV is 3380 the only means for querying the matrix and matrix stack depth of 3381 the tracking matrices described in section 2.14.5." 3382 3383Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance) 3384 3385 Add the following rule: 3386 3387 "Rule X Vertex program and vertex state program instructions not 3388 relevant to the calculation of any result must have no effect on 3389 that result. 3390 3391 Rules X+1 Vertex program and vertex state program instructions 3392 relevant to the calculation of any result must always produce the 3393 identical result. In particular, the same instruction with the same 3394 source inputs must produce the identical result whether executed by 3395 a vertex program or a vertex state program. 3396 3397 Instructions relevant to the calculation of a result are any 3398 instructions in a sequence of instructions that eventually determine 3399 the source values for the calculation under consideration. 3400 3401 There is no guaranteed invariance between vertices transformed by 3402 conventional GL vertex transform mode and vertices transformed by 3403 vertex program mode. Multi-pass rendering algorithms that require 3404 rendering invariances to operate correctly should not mix conventional 3405 GL vertex transform mode with vertex program mode for different 3406 rendering passes. However such algorithms will operate correctly 3407 if the algorithms limit themselves to a single mode of vertex 3408 transformation." 3409 3410Additions to the AGL/GLX/WGL Specifications 3411 3412 Program objects are shared between AGL/GLX/WGL rendering contexts if 3413 and only if the rendering contexts share display lists. No change 3414 is made to the AGL/GLX/WGL API. 3415 3416Dependencies on EXT_vertex_weighting 3417 3418 If the EXT_vertex_weighting extension is not supported, there is no 3419 aliasing between vertex attribute 1 and the current vertex weight. 3420 Replace the contents of the last three columns in row 5 of table 3421 X.2 with dashes. 3422 3423Dependencies on EXT_point_parameters 3424 3425 When EXT_point_parameters is supported, the amended discussion 3426 of point size determination should be further amended with the 3427 language from the EXT_point_parameters specification though the point 3428 parameters functionality only applies when vertex program mode is 3429 disabled. 3430 3431 Even if the EXT_point_parameters extension is not supported, the 3432 PSIZ vertex result register must operate as specified. 3433 3434Dependencies on ARB_multitexture 3435 3436 ARB_multitexture is required to support NV_vertex_program and the 3437 value of MAX_TEXTURE_UNITS_ARB must be at least 2. If more than 8 3438 texture units are supported, only the first 8 texture units can be 3439 assigned texture coordinates when vertex program mode is enabled. 3440 Texture units beyond 8 are implicitly disabled when vertex program 3441 mode is enabled. 3442 3443Dependencies on EXT_fog_coord 3444 3445 If the EXT_fog_coord extension is not supported, there is no 3446 aliasing between vertex attribute 5 and the current fog coordinate. 3447 Replace the contents of the last three columns in row 5 of table 3448 X.2 with dashes. 3449 3450 Even if the EXT_fog_coord extension is not supported, the FOGC 3451 vertex result register must operate as specified. Note that the 3452 FOGC vertex result register behaves identically to the EXT_fog_coord 3453 extension's FOG_COORDINATE_SOURCE_EXT being FOG_COORDINATE_EXT. 3454 This means that the functionality of EXT_fog_coord is required to 3455 implement NV_vertex_program even if the EXT_fog_coord extension is 3456 not supported. 3457 3458 If the EXT_fog_coord extension is supported, the state of 3459 FOG_COORDINATE_SOURCE_EXT only applies when vertex program mode is 3460 disabled and the discussion in section 3.10 is further amended by 3461 the discussion of FOG_COORDINATE_SOURCE_EXT in the EXT_fog_coord 3462 specification. 3463 3464Dependencies on EXT_secondary_color 3465 3466 If the EXT_secondary_color extension is not supported, there is no 3467 aliasing between vertex attribute 4 and the current secondary color. 3468 Replace the contents of the last three columns in row 4 of table 3469 X.2 with dashes. 3470 3471 Even if the EXT_secondary_color extension is not supported, the COL1 3472 and BFC1 vertex result registers must operate as specified. 3473 These vertex result registers are required to implement OpenGL 1.2's 3474 separate specular mode within a vertex program. 3475 3476GLX Protocol 3477 3478 Forty-five new GL commands are added. 3479 3480 The following thirty-five rendering commands are sent to the sever 3481 as part of a glXRender request: 3482 3483 BindProgramNV 3484 2 12 rendering command length 3485 2 4180 rendering command opcode 3486 4 ENUM target 3487 4 CARD32 id 3488 3489 ExecuteProgramNV 3490 2 12+4*n rendering command length 3491 2 4181 rendering command opcode 3492 4 ENUM target 3493 0x8621 n=4 GL_VERTEX_STATE_PROGRAM_NV 3494 else n=0 command is erroneous 3495 4 CARD32 id 3496 4*n LISTofFLOAT32 params 3497 3498 RequestResidentProgramsNV 3499 2 8+4*n rendering command length 3500 2 4182 rendering command opcode 3501 4 INT32 n 3502 n*4 CARD32 programs 3503 3504 LoadProgramNV 3505 2 16+n+p rendering command length 3506 2 4183 rendering command opcode 3507 4 ENUM target 3508 4 CARD32 id 3509 4 INT32 len 3510 n LISTofCARD8 n 3511 p unused, p=pad(n) 3512 3513 ProgramParameter4fvNV 3514 2 32 rendering command length 3515 2 4184 rendering command opcode 3516 4 ENUM target 3517 4 CARD32 index 3518 4 FLOAT32 params[0] 3519 4 FLOAT32 params[1] 3520 4 FLOAT32 params[2] 3521 4 FLOAT32 params[3] 3522 3523 ProgramParameter4dvNV 3524 2 44 rendering command length 3525 2 4185 rendering command opcode 3526 4 ENUM target 3527 4 CARD32 index 3528 8 FLOAT64 params[0] 3529 8 FLOAT64 params[1] 3530 8 FLOAT64 params[2] 3531 8 FLOAT64 params[3] 3532 3533 ProgramParameters4fvNV 3534 2 16+16*n rendering command length 3535 2 4186 rendering command opcode 3536 4 ENUM target 3537 4 CARD32 index 3538 4 CARD32 n 3539 16*n FLOAT32 params 3540 3541 ProgramParameters4dvNV 3542 2 16+32*n rendering command length 3543 2 4187 rendering command opcode 3544 4 ENUM target 3545 4 CARD32 index 3546 4 CARD32 n 3547 32*n FLOAT64 params 3548 3549 TrackMatrixNV 3550 2 20 rendering command length 3551 2 4188 rendering command opcode 3552 4 ENUM target 3553 4 CARD32 address 3554 4 ENUM matrix 3555 4 ENUM transform 3556 3557 VertexAttribPointerNV is an entirely client-side command 3558 3559 VertexAttrib1svNV 3560 2 12 rendering command length 3561 2 4265 rendering command opcode 3562 4 CARD32 index 3563 2 INT16 v[0] 3564 2 unused 3565 3566 VertexAttrib2svNV 3567 2 12 rendering command length 3568 2 4266 rendering command opcode 3569 4 CARD32 index 3570 2 INT16 v[0] 3571 2 INT16 v[1] 3572 3573 VertexAttrib3svNV 3574 2 12 rendering command length 3575 2 4267 rendering command opcode 3576 4 CARD32 index 3577 2 INT16 v[0] 3578 2 INT16 v[1] 3579 2 INT16 v[2] 3580 2 unused 3581 3582 VertexAttrib4svNV 3583 2 12 rendering command length 3584 2 4268 rendering command opcode 3585 4 CARD32 index 3586 2 INT16 v[0] 3587 2 INT16 v[1] 3588 2 INT16 v[2] 3589 2 INT16 v[3] 3590 3591 VertexAttrib1fvNV 3592 2 12 rendering command length 3593 2 4269 rendering command opcode 3594 4 CARD32 index 3595 4 FLOAT32 v[0] 3596 3597 VertexAttrib2fvNV 3598 2 16 rendering command length 3599 2 4270 rendering command opcode 3600 4 CARD32 index 3601 4 FLOAT32 v[0] 3602 4 FLOAT32 v[1] 3603 3604 VertexAttrib3fvNV 3605 2 20 rendering command length 3606 2 4271 rendering command opcode 3607 4 CARD32 index 3608 4 FLOAT32 v[0] 3609 4 FLOAT32 v[1] 3610 4 FLOAT32 v[2] 3611 3612 VertexAttrib4fvNV 3613 2 24 rendering command length 3614 2 4272 rendering command opcode 3615 4 CARD32 index 3616 4 FLOAT32 v[0] 3617 4 FLOAT32 v[1] 3618 4 FLOAT32 v[2] 3619 4 FLOAT32 v[3] 3620 3621 VertexAttrib1dvNV 3622 2 16 rendering command length 3623 2 4273 rendering command opcode 3624 4 CARD32 index 3625 8 FLOAT64 v[0] 3626 3627 VertexAttrib2dvNV 3628 2 24 rendering command length 3629 2 4274 rendering command opcode 3630 4 CARD32 index 3631 8 FLOAT64 v[0] 3632 8 FLOAT64 v[1] 3633 3634 VertexAttrib3dvNV 3635 2 32 rendering command length 3636 2 4275 rendering command opcode 3637 4 CARD32 index 3638 8 FLOAT64 v[0] 3639 8 FLOAT64 v[1] 3640 8 FLOAT64 v[2] 3641 3642 VertexAttrib4dvNV 3643 2 40 rendering command length 3644 2 4276 rendering command opcode 3645 4 CARD32 index 3646 8 FLOAT64 v[0] 3647 8 FLOAT64 v[1] 3648 8 FLOAT64 v[2] 3649 8 FLOAT64 v[3] 3650 3651 VertexAttrib4ubvNV 3652 2 12 rendering command length 3653 2 4277 rendering command opcode 3654 4 CARD32 index 3655 1 CARD8 v[0] 3656 1 CARD8 v[1] 3657 1 CARD8 v[2] 3658 1 CARD8 v[3] 3659 3660 VertexAttribs1svNV 3661 2 12+2*n+p rendering command length 3662 2 4202 rendering command opcode 3663 4 CARD32 index 3664 4 CARD32 n 3665 2*n INT16 v 3666 p unused, p=pad(2*n) 3667 3668 VertexAttribs2svNV 3669 2 12+4*n rendering command length 3670 2 4203 rendering command opcode 3671 4 CARD32 index 3672 4 CARD32 n 3673 4*n INT16 v 3674 3675 VertexAttribs3svNV 3676 2 12+6*n+p rendering command length 3677 2 4204 rendering command opcode 3678 4 CARD32 index 3679 4 CARD32 n 3680 6*n INT16 v 3681 p unused, p=pad(6*n) 3682 3683 VertexAttribs4svNV 3684 2 12+8*n rendering command length 3685 2 4205 rendering command opcode 3686 4 CARD32 index 3687 4 CARD32 n 3688 8*n INT16 v 3689 3690 VertexAttribs1fvNV 3691 2 12+4*n rendering command length 3692 2 4206 rendering command opcode 3693 4 CARD32 index 3694 4 CARD32 n 3695 4*n FLOAT32 v 3696 3697 VertexAttribs2fvNV 3698 2 12+8*n rendering command length 3699 2 4207 rendering command opcode 3700 4 CARD32 index 3701 4 CARD32 n 3702 8*n FLOAT32 v 3703 3704 VertexAttribs3fvNV 3705 2 12+12*n rendering command length 3706 2 4208 rendering command opcode 3707 4 CARD32 index 3708 4 CARD32 n 3709 12*n FLOAT32 v 3710 3711 VertexAttribs4fvNV 3712 2 12+16*n rendering command length 3713 2 4209 rendering command opcode 3714 4 CARD32 index 3715 4 CARD32 n 3716 16*n FLOAT32 v 3717 3718 VertexAttribs1dvNV 3719 2 12+8*n rendering command length 3720 2 4210 rendering command opcode 3721 4 CARD32 index 3722 4 CARD32 n 3723 8*n FLOAT64 v 3724 3725 VertexAttribs2dvNV 3726 2 12+16*n rendering command length 3727 2 4211 rendering command opcode 3728 4 CARD32 index 3729 4 CARD32 n 3730 16*n FLOAT64 v 3731 3732 VertexAttribs3dvNV 3733 2 12+24*n rendering command length 3734 2 4212 rendering command opcode 3735 4 CARD32 index 3736 4 CARD32 n 3737 24*n FLOAT64 v 3738 3739 VertexAttribs4dvNV 3740 2 12+32*n rendering command length 3741 2 4213 rendering command opcode 3742 4 CARD32 index 3743 4 CARD32 n 3744 32*n FLOAT64 v 3745 3746 VertexAttribs4ubvNV 3747 2 12+4*n rendering command length 3748 2 4214 rendering command opcode 3749 4 CARD32 index 3750 4 CARD32 n 3751 4*n CARD8 v 3752 3753 The remaining twelve commands are non-rendering commands. These commands 3754 are sent separately (i.e., not as part of a glXRender or glXRenderLarge 3755 request), using the glXVendorPrivateWithReply request: 3756 3757 AreProgramsResidentNV 3758 1 CARD8 opcode (X assigned) 3759 1 17 GLX opcode (glXVendorPrivateWithReply) 3760 2 4+n request length 3761 4 1293 vendor specific opcode 3762 4 GLX_CONTEXT_TAG context tag 3763 4 INT32 n 3764 n*4 LISTofCARD32 programs 3765 => 3766 1 1 reply 3767 1 unused 3768 2 CARD16 sequence number 3769 4 (n+p)/4 reply length 3770 4 BOOL32 return value 3771 20 unused 3772 n LISTofBOOL programs 3773 p unused, p=pad(n) 3774 3775 DeleteProgramsNV 3776 1 CARD8 opcode (X assigned) 3777 1 17 GLX opcode (glXVendorPrivateWithReply) 3778 2 4+n request length 3779 4 1294 vendor specific opcode 3780 4 GLX_CONTEXT_TAG context tag 3781 4 INT32 n 3782 n*4 LISTofCARD32 programs 3783 3784 GenProgramsNV 3785 1 CARD8 opcode (X assigned) 3786 1 17 GLX opcode (glXVendorPrivateWithReply) 3787 2 4 request length 3788 4 1295 vendor specific opcode 3789 4 GLX_CONTEXT_TAG context tag 3790 4 INT32 n 3791 => 3792 1 1 reply 3793 1 unused 3794 2 CARD16 sequence number 3795 4 n reply length 3796 24 unused 3797 n*4 LISTofCARD322 programs 3798 3799 GetProgramParameterfvNV 3800 1 CARD8 opcode (X assigned) 3801 1 17 GLX opcode (glXVendorPrivateWithReply) 3802 2 6 request length 3803 4 1319 vendor specific opcode 3804 4 GLX_CONTEXT_TAG context tag 3805 4 ENUM target 3806 4 CARD32 index 3807 4 ENUM pname 3808 => 3809 1 1 reply 3810 1 unused 3811 2 CARD16 sequence number 3812 4 m reply length, m=(n==1?0:n) 3813 4 unused 3814 4 CARD32 n 3815 3816 if (n=1) this follows: 3817 3818 4 FLOAT32 params 3819 12 unused 3820 3821 otherwise this follows: 3822 3823 16 unused 3824 n*4 LISTofFLOAT32 params 3825 3826 GetProgramParameterdvNV 3827 1 CARD8 opcode (X assigned) 3828 1 17 GLX opcode (glXVendorPrivateWithReply) 3829 2 6 request length 3830 4 1320 vendor specific opcode 3831 4 GLX_CONTEXT_TAG context tag 3832 4 ENUM target 3833 4 CARD32 index 3834 4 ENUM pname 3835 => 3836 1 1 reply 3837 1 unused 3838 2 CARD16 sequence number 3839 4 m reply length, m=(n==1?0:n*2) 3840 4 unused 3841 4 CARD32 n 3842 3843 if (n=1) this follows: 3844 3845 8 FLOAT64 params 3846 8 unused 3847 3848 otherwise this follows: 3849 3850 16 unused 3851 n*8 LISTofFLOAT64 params 3852 3853 GetProgramivNV 3854 1 CARD8 opcode (X assigned) 3855 1 17 GLX opcode (glXVendorPrivateWithReply) 3856 2 5 request length 3857 4 1298 vendor specific opcode 3858 4 GLX_CONTEXT_TAG context tag 3859 4 CARD32 id 3860 4 ENUM pname 3861 => 3862 1 1 reply 3863 1 unused 3864 2 CARD16 sequence number 3865 4 m reply length, m=(n==1?0:n) 3866 4 unused 3867 4 CARD32 n 3868 3869 if (n=1) this follows: 3870 3871 4 INT32 params 3872 12 unused 3873 3874 otherwise this follows: 3875 3876 16 unused 3877 n*4 LISTofINT32 params 3878 3879 GetProgramStringNV 3880 1 CARD8 opcode (X assigned) 3881 1 17 GLX opcode (glXVendorPrivateWithReply) 3882 2 5 request length 3883 4 1299 vendor specific opcode 3884 4 GLX_CONTEXT_TAG context tag 3885 4 CARD32 id 3886 4 ENUM pname 3887 => 3888 1 1 reply 3889 1 unused 3890 2 CARD16 sequence number 3891 4 (n+p)/4 reply length 3892 4 unused 3893 4 CARD32 n 3894 16 unused 3895 n STRING program 3896 p unused, p=pad(n) 3897 3898 GetTrackMatrixivNV 3899 1 CARD8 opcode (X assigned) 3900 1 17 GLX opcode (glXVendorPrivateWithReply) 3901 2 6 request length 3902 4 1300 vendor specific opcode 3903 4 GLX_CONTEXT_TAG context tag 3904 4 ENUM target 3905 4 CARD32 address 3906 4 ENUM pname 3907 => 3908 1 1 reply 3909 1 unused 3910 2 CARD16 sequence number 3911 4 m reply length, m=(n==1?0:n) 3912 4 unused 3913 4 CARD32 n 3914 3915 if (n=1) this follows: 3916 3917 4 INT32 params 3918 12 unused 3919 3920 otherwise this follows: 3921 3922 16 unused 3923 n*4 LISTofINT32 params 3924 3925 Note that ATTRIB_ARRAY_SIZE_NV, ATTRIB_ARRAY_STRIDE_NV, and 3926 ATTRIB_ARRAY_TYPE_NV may be queried by GetVertexAttribNV but generate 3927 no protocol and return client-side state. 3928 3929 GetVertexAttribdvNV 3930 1 CARD8 opcode (X assigned) 3931 1 17 GLX opcode (glXVendorPrivateWithReply) 3932 2 5 request length 3933 4 1301 vendor specific opcode 3934 4 GLX_CONTEXT_TAG context tag 3935 4 INT32 index 3936 4 ENUM pname 3937 => 3938 1 1 reply 3939 1 unused 3940 2 CARD16 sequence number 3941 4 m reply length, m=(n==1?0:n*2) 3942 4 unused 3943 4 CARD32 n 3944 3945 if (n=1) this follows: 3946 3947 8 FLOAT64 params 3948 8 unused 3949 3950 otherwise this follows: 3951 3952 16 unused 3953 n*8 LISTofFLOAT64 params 3954 3955 GetVertexAttribfvNV 3956 1 CARD8 opcode (X assigned) 3957 1 17 GLX opcode (glXVendorPrivateWithReply) 3958 2 5 request length 3959 4 1302 vendor specific opcode 3960 4 GLX_CONTEXT_TAG context tag 3961 4 INT32 index 3962 4 ENUM pname 3963 => 3964 1 1 reply 3965 1 unused 3966 2 CARD16 sequence number 3967 4 m reply length, m=(n==1?0:n) 3968 4 unused 3969 4 CARD32 n 3970 3971 if (n=1) this follows: 3972 3973 4 FLOAT32 params 3974 12 unused 3975 3976 otherwise this follows: 3977 3978 16 unused 3979 n*4 LISTofFLOAT32 params 3980 3981 GetVertexAttribivNV 3982 1 CARD8 opcode (X assigned) 3983 1 17 GLX opcode (glXVendorPrivateWithReply) 3984 2 5 request length 3985 4 1303 vendor specific opcode 3986 4 GLX_CONTEXT_TAG context tag 3987 4 INT32 index 3988 4 ENUM pname 3989 => 3990 1 1 reply 3991 1 unused 3992 2 CARD16 sequence number 3993 4 m reply length, m=(n==1?0:n) 3994 4 unused 3995 4 CARD32 n 3996 3997 if (n=1) this follows: 3998 3999 4 INT32 params 4000 12 unused 4001 4002 otherwise this follows: 4003 4004 16 unused 4005 n*4 LISTofINT32 params 4006 4007 GetVertexAttribPointervNV is an entirely client-side command 4008 4009 IsProgramNV 4010 1 CARD8 opcode (X assigned) 4011 1 17 GLX opcode (glXVendorPrivateWithReply) 4012 2 4 request length 4013 4 1304 vendor specific opcode 4014 4 GLX_CONTEXT_TAG context tag 4015 4 INT32 n 4016 => 4017 1 1 reply 4018 1 unused 4019 2 CARD16 sequence number 4020 4 0 reply length 4021 4 BOOL32 return value 4022 20 unused 4023 4024Errors 4025 4026 The error INVALID_VALUE is generated if VertexAttribNV is called 4027 where index is greater than 15. 4028 4029 The error INVALID_VALUE is generated if any ProgramParameterNV has 4030 an index is greater than 95. 4031 4032 The error INVALID_VALUE is generated if VertexAttribPointerNV 4033 is called where index is greater than 15. 4034 4035 The error INVALID_VALUE is generated if VertexAttribPointerNV 4036 is called where size is not one of 1, 2, 3, or 4. 4037 4038 The error INVALID_VALUE is generated if VertexAttribPointerNV 4039 is called where stride is negative. 4040 4041 The error INVALID_OPERATION is generated if VertexAttribPointerNV 4042 is called where type is UNSIGNED_BYTE and size is not 4. 4043 4044 The error INVALID_VALUE is generated if LoadProgramNV is used to load a 4045 program with an id of zero. 4046 4047 The error INVALID_OPERATION is generated if LoadProgramNV is used 4048 to load an id that is currently loaded with a program of a different 4049 program target. 4050 4051 The error INVALID_OPERATION is generated if the program passed to 4052 LoadProgramNV fails to load because it is not syntactically correct 4053 based on the specified target. The value of PROGRAM_ERROR_POSITION_NV 4054 is still updated when this error is generated. 4055 4056 The error INVALID_OPERATION is generated if LoadProgramNV has a 4057 target of VERTEX_PROGRAM_NV and the specified program fails to 4058 load because it does not write the HPOS register at least once. 4059 The value of PROGRAM_ERROR_POSITION_NV is still updated when this 4060 error is generated. 4061 4062 The error INVALID_OPERATION is generated if LoadProgramNV has a target 4063 of VERTEX_STATE_PROGRAM_NV and the specified program fails to load 4064 because it does not write at least one program parameter register. 4065 The value of PROGRAM_ERROR_POSITION_NV is still updated when this 4066 error is generated. 4067 4068 The error INVALID_OPERATION is generated if the vertex program 4069 or vertex state program passed to LoadProgramNV fails to load 4070 because it contains more than 128 instructions. The value of 4071 PROGRAM_ERROR_POSITION_NV is still updated when this error is 4072 generated. 4073 4074 The error INVALID_OPERATION is generated if a program is loaded with 4075 LoadProgramNV for id when id is currently loaded with a program of 4076 a different target. 4077 4078 The error INVALID_OPERATION is generated if BindProgramNV attempts 4079 to bind to a program name that is not a vertex program (for example, 4080 if the program is a vertex state program). 4081 4082 The error INVALID_VALUE is generated if GenProgramsNV is called 4083 where n is negative. 4084 4085 The error INVALID_VALUE is generated if AreProgramsResidentNV is 4086 called and any of the queried programs are zero or do not exist. 4087 4088 The error INVALID_OPERATION is generated if ExecuteProgramNV executes 4089 a program that does not exist. 4090 4091 The error INVALID_OPERATION is generated if ExecuteProgramNV executes 4092 a program that is not a vertex state program. 4093 4094 The error INVALID_OPERATION is generated if ExecuteProgramNV is called 4095 and the vertex state program to execute writes program parameters 4096 that are currently being tracked. 4097 4098 The error INVALID_VALUE is generated if TrackMatrixNV has a target 4099 of VERTEX_PROGRAM_NV and attempts to track an address is not a 4100 multiple of four. 4101 4102 The error INVALID_VALUE is generated if GetProgramParameterNV is 4103 called to query an index greater than 95. 4104 4105 The error INVALID_VALUE is generated if GetVertexAttribNV is called 4106 to query an <index> greater than 15, or if <index> is zero and <pname> 4107 is CURRENT_ATTRIB_NV. 4108 4109 The error INVALID_VALUE is generated if GetVertexAttribPointervNV 4110 is called to query an index greater than 15. 4111 4112 The error INVALID_OPERATION is generated if GetProgramivNV is called 4113 and the program named id does not exist. 4114 4115 The error INVALID_OPERATION is generated if GetProgramStringNV is called 4116 and the program named <program> does not exist. 4117 4118 The error INVALID_VALUE is generated if GetTrackMatrixivNV is called 4119 with an <address> that is not divisible by four and not less than 96. 4120 4121 The error INVALID_VALUE is generated if AreProgramsResidentNV, 4122 DeleteProgramsNV, GenProgramsNV, or RequestResidentProgramsNV are 4123 called where <n> is negative. 4124 4125 The error INVALID_VALUE is generated if LoadProgramNV is called 4126 where <len> is negative. 4127 4128 The error INVALID_VALUE is generated if ProgramParameters4dvNV or 4129 ProgramParameters4fvNV are called where <num> is negative. 4130 4131 The error INVALID_VALUE is generated if 4132 VertexAttribs{1,2,3,4}{d,f,s}vNV is called where <n> is negative. 4133 4134 The error INVALID_ENUM is generated if BindProgramNV, 4135 GetProgramParameterfvNV, GetProgramParameterdvNV, GetTrackMatrixivNV, 4136 ProgramParameter4fNV, ProgramParameter4dNV, ProgramParameter4fvNV, 4137 ProgramParameter4dvNV, ProgramParameters4fvNV, ProgramParameters4dvNV, 4138 or TrackMatrixNV are called where <target> is not VERTEX_PROGRAM_NV. 4139 4140 The error INVALID_ENUM is generated if LoadProgramNV or 4141 ExecuteProgramNV are called where <target> is not either 4142 VERTEX_PROGRAM_NV or VERTEX_STATE_PROGRAM_NV. 4143 4144New State 4145 4146update table 6.22 (page 212) so that all the "9"s are "25"s because there 4147are 9 conventional map targets and 16 vertex attribute map targets making 4148a total of 25. 4149 4150Get Value Type Get Command Initial Value Description Sec Attribute 4151---------------------------- ------ --------------------------- ------------- ------------------ -------- ------------ 4152VERTEX_PROGRAM_NV B IsEnabled False vertex program 2.10 enable 4153 enable 4154VERTEX_PROGRAM_POINT_SIZE_NV B IsEnabled False program-specified 2.14.1.5 enable 4155 point size mode 4156VERTEX_PROGRAM_TWO_SIDE_NV B IsEnabled False two-sided color 2.14.1.5 enable 4157 mode 4158PROGRAM_ERROR_POSITION_NV Z GetIntegerv -1 last program 2.14.1.7 - 4159 error position 4160PROGRAM_PARAMETER_NV 96xR4 GetProgramParameterNV (0,0,0,0) program parameters 2.14.1.2 - 4161CURRENT_ATTRIB_NV 16xR4 GetVertexAttribNV see 2.14.6 vertex attributes 2.14.1.1 current 4162 but zero cannot be queried, 4163 aliased with per-vertex 4164 parameters 4165TRACK_MATRIX_NV 24xZ8+ GetTrackMatrixivNV NONE track matrix 2.14.5 - 4166TRACK_MATRIX_TRANSFORM_NV 24xZ8+ GetTrackMatrixivNV IDENTITY_NV track matrix 2.14.5 - 4167 transform 4168VERTEX_PROGRAM_BINDING_NV Z+ GetIntegerv 0 bound vertex 2.14.1.8 - 4169 program 4170VERTEX_ATTRIB_ARRAYn_NV 16xB IsEnabled False vertex attrib 2.14.3 vertex-array 4171 array enable 4172ATTRIB_ARRAY_SIZE_NV 16xZ GetVertexAttribNV 4 vertex attrib 2.14.3 vertex-array 4173 array size 4174ATTRIB_ARRAY_STRIDE_NV 16xZ+ GetVertexAttribNV 0 vertex attrib 2.14.3 vertex-array 4175 array stride 4176ATTRIB_ARRAY_TYPE_NV 16xZ4 GetVertexAttribNV FLOAT vertex attrib 2.14.3 vertex-array 4177 array type 4178 4179Table X.5. New State Introduced by NV_vertex_program. 4180 4181 4182Get Value Type Get Command Initial Value Description Sec Attribute 4183------------------- ------ ------------------ ------------- ------------------ -------- --------- 4184PROGRAM_TARGET_NV Z2 GetProgramivNV 0 program target 6.1.13 - 4185PROGRAM_LENGTH_NV Z+ GetProgramivNV 0 program length 6.1.13 - 4186PROGRAM_RESIDENT_NV Z2 GetProgramivNV False program residency 6.1.13 - 4187PROGRAM_STRING_NV ubxn GetProgramStringNV "" program string 6.1.13 - 4188 4189Table X.6. Program Object State. 4190 4191 4192Get Value Type Get Command Initial Value Description Sec Attribute 4193--------- ------ ----------- ------------- ----------------------- -------- --------- 4194- 12xR4 - (0,0,0,0) temporary registers 2.14.1.4 - 4195- 15xR4 - (0,0,0,1) vertex result registers 2.14.1.4 - 4196 Z4 - (0,0,0,0) vertex program 2.14.1.3 - 4197 address register 4198 4199Table X.7. Vertex Program Per-vertex Execution State. 4200 4201 4202Get Value Type Get Command Initial Value Description Sec Attribute 4203----------------------------- -------- -------------- ------------- ------------------- ------- --------- 4204CURRENT_MATRIX_STACK_DEPTH_NV m*Z+ GetIntegerv 1 current stack depth 6.1.14 - 4205CURRENT_MATRIX_NV m*n*xM^4 GetFloatv Identity current matrix 6.1.14 - 4206 4207Table X.8. Current matrix state where m is the total number of matrices 4208including texture matrices and tracking matrices and n is the number of 4209matrices on each particular matrix stack. Note that this state is 4210aliased with existing matrix state. 4211 4212 4213New Implementation Dependent State 4214 Minimum 4215Get Value Type Get Command Value Description Sec Attribute 4216-------------------------------- ---- ----------- ---------- ------------------ ------ --------- 4217MAX_TRACK_MATRIX_STACK_DEPTH_NV Z+ GetIntegerv 1 maximum tracking 2.14.5 - 4218 matrix stack depth 4219MAX_TRACK_MATRICES_NV Z+ GetIntegerv 8 (not to maximum number of 2.14.5 - 4220 exceed 32) tracking matrices 4221 4222Table X.9. New Implementation-Dependent Values Introduced by NV_vertex_program. 4223 4224 4225Revision History 4226 4227 Version 1.1: 4228 4229 Added normalization example to Issues. 4230 4231 Fix explanation of EXP and ARL floor equivalence. 4232 4233 Clarify that vertex state programs fail if they load more than 4234 one vertex attribute (though only one is possible). 4235 4236 Version 1.2 4237 4238 Add GLX protocol for VertexAttrib4ubvNV and VertexAttribs4ubvNV 4239 4240 Add issue about TrackMatrixNV transform behavior with example 4241 4242 Fix the C code specifying VertexAttribsvNV 4243 4244 Version 1.3 4245 4246 Dropped support for INT typed vertex attrib arrays. 4247 4248 Clarify that when ArrayElement is executed and vertex program 4249 mode is enabled and the vertex attrib 0 array is enabled, the 4250 vertex attrib 0 array command is executed last. However when 4251 ArrayElement is executed and vertex program mode is enabled and the 4252 vertex attrib 0 array is disabled and the vertex array is enabled, 4253 the vertex array command is executed last. 4254 4255 Version 1.4 4256 4257 Allow TEXTUREi_ARB for the track matrix. This allows matrix 4258 tracking of a particular texture matrix without reference to active 4259 texture (set by glActiveTextureARB) state. 4260 4261 Early NVIDIA drivers (prior to October 5, 2001) have a bug 4262 in their handling of tracking matrices specified with TEXTURE. 4263 Rather than tracking the particular texture matrix indicated 4264 by the active texture state when TrackMatrixNV is called, these 4265 early drivers incorrectly track matrix the active texture's texture 4266 matrix _at track matrix validation time_. In practice this means, 4267 every tracked matrix defined with TEXTURE tracks the same matrix 4268 values; you cannot track distinct texture matrices at the same 4269 time and the texture matrix you actually track depends on the 4270 active texture matrix at validation time. This is a driver bug. 4271 4272 Drivers after October 5, 2001 properly track the texture matrix 4273 specified by active texture when TrackMatrix is called. 4274 4275 The new correct drivers can be distinguished from the old drivers 4276 at run time with the following code: 4277 4278 while (glGetError() != GL_NO_ERROR); // Clear any pre-existing OpenGL errors. 4279 glTrackMatrixNV(GL_VERTEX_PROGRAM_NV, 8, GL_TEXTURE0_ARB, GL_IDENTITY_NV); 4280 if (glGetError() != GL_NO_ERROR) { 4281 // Old buggy pre-version 1.4 drivers with GL_TEXTURE 4282 // glTrackMatrixNV bug. 4283 } else { 4284 // Correct new version 1.4 drivers (or later) with GL_TEXTURE 4285 // glTrackMatrixNV bug fixed and GL_TEXTUREi_NV support. 4286 4287 // Note: you may want to untrack the matrix at this point. 4288 } 4289 4290 Version 1.5 4291 4292 Earlier versions of this specification claimed for 4293 GetVertexAttribARB that it is an error to query any vertex attrib 4294 state for vertex attrib array zero. In fact, it should only be 4295 an error to query the CURRENT_ATTRIB_ARB state for vertex attrib 4296 zero; the size, stride, and type of vertex attrib array zero may 4297 be queried. Version 1.5 specifies the correct behavior. 4298 4299 Early NVIDIA drivers (prior to January 11, 2002) did not implement 4300 generate error when querying vertex attrib array zero state (ie, 4301 did the right thing for size, stride, and type) but not create an 4302 error when querying the current attribute values for vertex attrib 4303 array zero either. 4304 4305 Version 1.6 4306 4307 GLX opcodes and vendorpriv values assigned. 4308 4309 Version 1.7 4310 4311 Corrected matrix tracking example in the issues list to properly 4312 document row vs. column-major differences. 4313 4314 Version 1.8 4315 4316 Corrected EXP instruction; W component of result is always 1.0. 4317 4318 Version 1.9 4319 4320 Added language that for SGE and SLT, -NaN < -Inf and +NaN > +Inf. 4321 4322 Version 1.10 4323 4324 Fixed GLX protocol conflicts between ARB_vertex_program and 4325 NV_vertex_program. VertexAttrib* functions shared the same opcodes, but 4326 had different attribute aliasing behavior. In particular, setting 4327 attribute 3 changes the current color in NV_vertex program, may or may 4328 not change current color in ARB_vertex program, and may not change the 4329 current color with ARB_vertex_program as extended by ARB_vertex_shader. 4330 Renumbered the NV_vertex_program opcodes since they were not currently 4331 used by shipping GLX implementations. Also, fixed the aliasing between 4332 GetProgramParameter*NV and GetProgramEnvParameter*ARB, which have 4333 different prototypes -- the ARB functions do not use the <pname> 4334 parameter. Again, fixed by renumbering NV protocol. 4335