1Name 2 3 ARB_fragment_shader 4 5Name Strings 6 7 GL_ARB_fragment_shader 8 9Contributors 10 11 Dave Baldwin 12 Pat Brown 13 Evan Hart 14 Phil Huxley 15 Dale Kirkland 16 John Kessenich 17 Steve Koren 18 Jon Leech 19 Bill Licea-Kane 20 Benjamin Lipchak 21 Barthold Lichtenbelt 22 Kent Lin 23 Jeremy Morris 24 Teri Morrison 25 Glenn Ortner 26 Randi Rost 27 Jeremy Sandmel 28 29 The ARB_fragment_program working group members. Several concepts and 30 chunks of text are copied from the ARB_fragment_program specification. 31 32Contact 33 34 Barthold Lichtenbelt, 3Dlabs, Inc. (barthold 'at' 3dlabs.com) 35 Randi Rost, 3Dlabs, Inc. (rost 'at' 3dlabs.com) 36 37Notice 38 39 Copyright (c) 2003-2013 The Khronos Group Inc. Copyright terms at 40 http://www.khronos.org/registry/speccopyright.html 41 42Specification Update Policy 43 44 Khronos-approved extension specifications are updated in response to 45 issues and bugs prioritized by the Khronos OpenGL Working Group. For 46 extensions which have been promoted to a core Specification, fixes will 47 first appear in the latest version of that core Specification, and will 48 eventually be backported to the extension document. This policy is 49 described in more detail at 50 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 51 52IP Status 53 54 As described in the Contributor License, which can be found at 55 http://www.3dlabs.com/support/developer/ogl2/specs/3dlabs_contributor.pdf. 56 57Status 58 59 Complete. Approved by the ARB on June 11, 2003. 60 Updated revision 0.79 approved by the ARB on June 17, 2004. 61 62Version 63 64 Last Modified Date: December 12, 2006 65 Author Revision: 0.80 66 67Number 68 69 ARB Extension #32 70 71Dependencies 72 73 OpenGL 1.0 is required. 74 75 This extension is written against version 1.10 of the OpenGL Shading 76 Language Specification. 77 78 The extension is written against the OpenGL 1.4 Specification. 79 80 The ARB_shader_objects extension is required. 81 82 This extension interacts with the ARB_vertex_shader extension. 83 84Overview 85 86 This extension adds functionality to define fragment shader objects. A 87 fragment shader object is a shader object (see the ARB_shader_objects 88 extension) that, when attached to a program object, can be compiled and 89 linked to produce an executable that runs on the fragment processor in 90 OpenGL. The fragment processor is a programmable unit that replaces the 91 OpenGL 1.4 fixed-function texturing, color sum and fog stages. This 92 extension also defines how such an executable interacts with the fixed 93 functionality fragment processing of OpenGL 1.4. The language used to 94 write fragment shaders is not discussed here. That language is defined 95 in the OpenGL Shading Language specification as the Fragment Shading 96 Language. 97 98Issues 99 1) Can you clarify texture unit, texture image unit and texture 100 coordinate sets please? 101 102 DISCUSSION: In 'old style' GL a texture unit consists of a texture 103 coordinate processing unit (consisting of a texture matrix stack and 104 texture coordinate generation state), and a texture image unit, with all 105 the texture state defined in section 3.8, as well as texture environment 106 state, as defined in section 3.8.12. The implementation dependent number 107 of supported texture units in 'old style' GL is MAX_TEXTURE_UNITS. 108 109 In this specification a texture unit consist of one or both of a texture 110 image unit, and a texture coordinate set. The implementation dependent 111 number of supported texture image units is MAX_TEXTURE_IMAGE_UNITS_ARB 112 and the number of supported texture coordinate sets is 113 MAX_TEXTURE_COORDS_ARB. 114 115 The maximum available multi-texture stages (to the fixed-function 116 pipeline) are MAX_TEXTURE_UNITS. A fragment shader has access to at 117 least MAX_TEXTURE_UNITS texture image units, and possibly more, up to 118 MAX_TEXTURE_IMAGE_UNITS_ARB. Where MAX_TEXTURE_IMAGE_UNITS_ARB is equal 119 or greater than MAX_TEXTURE_UNITS. 120 121 RESOLUTION: Yes 122 123 2) Should we split the number of available texture coordinate sets and 124 texture units? 125 126 DISCUSSION: Some implementations might provide for more texture image 127 units than texture coordinate sets. Texture coordinates for the 'new' 128 texture image units can be derived from other texture coordinates, or 129 provided through a texture lookup. These new texture coordinates can be 130 used to index different textures bound to different texture image units. 131 132 RESOLUTION: YES, splitting this is useful. 133 134 3) Is the texture environment state associated with all texture image 135 units? 136 137 DISCUSSION: A fragment shader has access to the texture environment 138 color through the shader built-in array gl_TexEnvColor. This array has 139 MAX_TEXTURE_IMAGE_UNITS_ARB elements. It is also possible, and useful, 140 to set the texture environment state TEXTURE_LOD_BIAS for all texture 141 image units. All other texture environment state is not accessible to a 142 fragment shader (for example, TEXTURE_ENV_MODE, COMBINE_RGB etc). 143 However, an application can still set this state (and query it). 144 145 Note that fixed-function GL caps the number of supported texture stages 146 to MAX_TEXTURE_UNITS. This limit is generally below the number of 147 texture image units available to a fragment shader. Each of these 148 MAX_TEXTURE_UNITS texture stages need all texture environment state for 149 the multi-texture pipeline to function correctly. Texture units above 150 this limit still have all the texture environment state associated with 151 it, even although this state is not accessible in a fragment shader. 152 153 Note that ARB_fragment_program also does this, except that it caps 154 access to the texture environment state to the first MAX_TEXTURE_UNITS 155 texture image units. 156 157 RESOLUTION: Yes. 158 159 4) What to do about invariance rules (Appendix A)? 160 161 DISCUSSION: Numerous rules and proposals have been discussed. In the 162 end, simplicity is an important goal. It is always possible to later add 163 more invariance rules, if it turns out to be desirable. 164 165 RESOLUTION: The same shader will produce the same result when run 166 multiple times with the same input. The wording 'the same shader' means 167 a program object that is populated with the same source strings, which 168 are compiled and then linked, possibly multiple times. This program 169 object is executed using the same GL state vector. 170 171 Besides the above general statement, we will limit this specification to 172 one invariance rule with respect to depth produced by a fragment shader: 173 174 All shaders that either conditionally or unconditionally copy the input 175 gl_FragCoord.z to the output gl_FragDepth are depth-invariant with 176 respect to each other, for those fragments where this copy actually is 177 done. 178 179 Note that a fragment shader that does not write to gl_FragDepth is 180 depth-invariant with fixed function (since fixed function depth will be 181 used for the fragment when gl_FragDepth is not written). 182 183 See also Appendix A. 184 185 5) Should the output from the pixel rectangle rasterization and bitmap 186 rasterization stages feed into a fragment shader? 187 188 DISCUSSION: See also Issue 2 in the OpenGL Shading Language 189 specification. Future API additions could make the operations DrawPixels 190 performs programmable. For the list of specific operations that could be 191 replaced see Section 3.6.4, Figure 3.7 in the OpenGL 1.4 specification. 192 Combined with the proposed pack/unpack language, and the proposed pack 193 and unpack processors, such a future extension will become an extremely 194 powerful and flexible imaging pipeline. 195 196 Most of the harder parts to implement the functionality in Figure 3.7 197 result from the imaging subset. A conceivable way to implement this 198 functionality is by using the programmable fragment unit. However, if 199 the results from the pixel rectangle and bitmap rasterization stages did 200 feed into the fragment shader, then implementing all the functionality 201 in Figure 3.7 might become hard or impossible, when a fragment shader is 202 also active. A possibility that was considered was to say that if a 203 fragment shader was active, pixel transfer functionality such as scale 204 and bias, color matrix, lookup, etc., was disabled. A fragment shader 205 could perform these kinds of operations, after all. 206 207 ARB_fragment_program does feed the result of pixel rectangle and bitmap 208 rasterization into the fragment shader. 209 210 RESOLUTION: Yes, this allows fragment shaders to do image processing 211 type of operations on pixel rectangles and bitmaps. 212 213 Note that a fragment shader that is processing fragments resulting from 214 rasterization of pixel rectangles or bitmaps, can only reference 215 built-in varying variables starting with "gl_" (gl_Color, 216 gl_SecondaryColor, gl_TexCoord[] and gl_FogFragCoord). The fragments 217 produced as a result of rasterizing a pixel rectangle or bitmap have 218 associated values for those varying variables. If the fragment shader 219 uses a user-defined varying, results are undefined. 220 221 6) What about clamping and conversion for color and depth output 222 variables? 223 224 DISCUSSION: The output variables gl_FragDepth and gl_FragColor are in 225 floating point format. However, the GL 1.4 pipeline following the 226 fragment shader expects these values to be in fixed-point, and clamped 227 to the range [0,1]. 228 229 RESOLUTION: Color and depth values written by the fragment shader will 230 be automatically clamped to the range [0,1] and then converted, as 231 appropriate, to a fixed-point representation. See section 3.11.6. 232 233 7) What about clamping and conversion for color and depth input varying 234 variables? 235 236 DISCUSSION: This ties in with issue 18 in the ARB_vertex_shader 237 specification. There are three cases to consider: 238 239 1) An ARB_vertex_shader shader writing colors that are consumed by an 240 ARB_fragment_shader shader. 241 2) An ARB_vertex_program shader writing colors that are consumed by an 242 ARB_fragment_shader shader. 243 3) Fixed functionality vertex processing outputting colors that are 244 consumed by an ARB_fragment_shader shader. 245 246 Fixed function vertex processing as well as ARB_vertex_shader and 247 ARB_vertex_program do clamp colors automatically to [0,1]. In all three 248 cases colors are next converted to fixed-point (section 2.13.9). 249 250 RESOLUTION: Depth and color values will be converted to floating-point 251 before entering the fragment shader. 252 253 8) What controls the value of the shader built-in Boolean 254 gl_FrontFacing? 255 256 DISCUSSION: The OpenGL Shading Language says the following: "The 257 fragment shader has access to the read-only built-in variable 258 gl_FrontFacing whose value is true if the fragment belongs to a 259 front-facing primitive." 260 261 This specification defines when a fragment is considered front-facing. 262 263 A fragment derives its facing direction from the primitive that 264 generates the fragment. All fragments generated by primitives other than 265 polygons, triangles, or quadrilaterals are considered to be front 266 facing. For all other fragments (including ones resulting from point- 267 and line-mode polygons) the determination is made by examining the sign 268 of the area computed by equation 2.6 of section 2.13.1 (including the 269 possible reversal of this sign as indicated by the last call to 270 FrontFace). If the sign is positive then the fragments are front facing; 271 otherwise, they are back facing. 272 273 ARB_vertex_shader has an enable called VERTEX_PROGRAM_TWO_SIDE_ARB. If 274 false, the front color is always selected. However, this enable does not 275 apply to the front or back facing determination of a fragment. The value 276 of VERTEX_PROGRAM_TWO_SIDE_ARB does not affect the value of 277 gl_FrontFacing. Thus you can have the following situation: 278 279 * VERTEX_PROGRAM_TWO_SIDE_ARB = FALSE. Which forces the front color to 280 always be selected. Thus gl_Color and gl_SecondaryColor (read-only 281 accessible in the fragment shader) have the values of the varyings 282 gl_FrontColor and gl_FrontSecondaryColor (written by the vertex 283 shader). 284 * The primitive is a polygon and is determined to be back-facing. 285 gl_FrontFacing therefore = FALSE. 286 287 RESOLUTION: Depending on the primitive type it is either always front 288 facing, or it is determined by he sign of the polygon's area computed in 289 window coordinates. 290 291 9) OpenGL provides a hierarchy of texture enables (cube map, 3D, 2D, 292 1D). Should samplers override that hierarchy and select specific 293 texture targets? 294 295 DISCUSSION: How samplers work is explained in issue 25 of the 296 ARB_shader_objects specification. 297 298 RESOLUTION: Yes. This removes a potential pitfall for developers: 299 Leaving the hierarchy of enables in an undesired state. It makes shaders 300 more readable as the intent of the code is more obvious. It allows 301 compilers to be more aggressive as to which texture coordinate 302 components are "don't cares" without having to recompile programs when 303 fixed-function texture enables change. 304 305 Note that the ARB_shader_objects specification states that it is not 306 allowed to have samplers of different types point to the same texture 307 image unit. For example, it is not possible to request a 2D and a 3D 308 texture lookup using the same texture image unit within a program 309 object. 310 311 10) Is Depth Offset applied to the window z value before it enters the 312 fragment shader? 313 314 DISCUSSION: Depth Offset (polygon offset) is discussed in section 3.5.5 315 of the GL 1.4 spec. Depth offset is considered part of the rasterization 316 stage, which happens prior to processing of a fragment shader. 317 318 RESOLUTION: As in the base OpenGL specification, the depth offset 319 generated by polygon offset is added during polygon rasterization. The 320 depth value provided to shaders in the built-in gl_FragCoord.z already 321 includes polygon offset, if enabled. If the depth value is replaced by a 322 fragment shader, the polygon offset value will NOT be recomputed and 323 added back after shader execution. 324 325 NOTE: This is probably not desirable for fragment shaders that modify 326 depth values since the partials used to generate the offset may not 327 match the partials of the computed depth value. 328 329 11) Should gl_FragColor be aliased to gl_FragData[0]? 330 331 RESOLUTION: No. A shader should write either gl_FragColor, or 332 gl_FragData[n], but not both. 333 334 12) Should gl_FragData[n] be clamped? 335 336 RESOLUTION: gl_FragData[] is basically an array of colors. The values in 337 this array might or might not be actual color data, just as is true for 338 the output variable gl_FragColor. The data assigned to gl_FragData[n] 339 will be clamped to [0,1]. This restriction can be lifted by a separate 340 extension, for example by the proposed color_clamp_control extension. 341 342 13) What texture operations are not affected by a fragment shader 343 performing a texture lookup? 344 345 RESOLUTION: Whether or not a fragment shader is active, the following 346 operations still behave as specified: 347 348 * texture image specification (pp. 119-128) 349 * alternate texture image specification (pp. 128-132) 350 * compressed texture image specification (pp. 132-135) 351 * texture parameters behave as specified even when a texture is 352 accessed from within a fragment shader (pp. 135-147) 353 * texture state and proxy state (pp. 148-149) 354 * texture object specification (pp. 149-152) 355 * texture comparison modes (p. 157) 356 357 14) What is the interaction with a possible MRT (Multiple Render Target) 358 extension? 359 360 The OpenGL Shading Language defines the array gl_FragData[] to output 361 values to multiple buffers. There are two situations to consider. 362 363 1) There is no MRT extension support. A shader can statically assign a 364 value to either gl_FragColor or gl_FragData[0] (but not both). 365 Either way the same buffer will be targeted. 366 2) There is MRT support. In this case what happens is defined in the 367 relevant MRT extension documentation. 368 369New Procedures and Functions 370 371 None 372 373New Tokens 374 375 Accepted by the <shaderType> argument of CreateShaderObjectARB and 376 returned by the <params> parameter of GetObjectParameter{fi}vARB: 377 378 FRAGMENT_SHADER_ARB 0x8B30 379 380 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 381 GetFloatv, and GetDoublev: 382 383 MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB 0x8B49 384 MAX_TEXTURE_COORDS_ARB 0x8871 385 MAX_TEXTURE_IMAGE_UNITS_ARB 0x8872 386 387 Accepted by the <target> parameter of Hint and the <pname> parameter of 388 GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev: 389 390 FRAGMENT_SHADER_DERIVATIVE_HINT_ARB 0x8B8B 391 392Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) 393 394 Modify Section 2.1.1, Floating-Point Computation (p. 6) 395 396 (modify first paragraph, p. 6) ... are accurate to about 1 part in 10^5. 397 The maximum representable magnitude of a floating-point number used to 398 represent positional, normal or texture coordinates must be at least 399 2^32. The maximum representable magnitude for colors must be at least 400 2^10. The maximum representable magnitude for all other floating-point 401 values must be at least 2^32. 402 403 Modify Section 2.7, Vertex Specification (p. 19) 404 405 (modify second paragraph, p. 20) Implementations support more than one 406 set of texture coordinates. The commands 407 408 void MultiTexCoord{1234}{sifd}(enum texture, T coords) 409 void MultiTexCoord{1234}{sifd}v(enum texture, T coords) 410 411 take the coordinate set to be modified as the <texture> parameter. 412 <texture> is a symbolic constant of the form TEXTUREi, indicating that 413 texture coordinate set i is to be modified. The constants obey TEXTUREi 414 = TEXTURE0 + i (i is in the range 0 to k-1, where k is the 415 implementation-dependent number of texture units defined by 416 MAX_TEXTURE_COORDS_ARB). 417 418 Modify Section 2.8, Vertex Arrays (p. 23) 419 420 (modify first paragraph, p. 23) ... The client may specify up to 7 plus 421 the value of MAX_TEXTURE_COORDS_ARB arrays: one each to store vertex 422 coordinates... 423 424 (modify first paragraph, p. 25) The command 425 426 void ClientActiveTexture(enum texture) 427 428 is used to select the vertex array client state parameters to be 429 modified by the TexCoordPointer command and the array affected by 430 EnableClientState and DisableClientState with parameter 431 TEXTURE_COORD_ARRAY. This command sets the client state variable 432 CLIENT_ACTIVE_TEXTURE. Each texture coordinate set has a client state 433 vector which is selected when this command is invoked. This state vector 434 includes the vertex array state. This call also selects the texture 435 coordinate set state used for queries of client state. 436 437 438 (modify first paragraph, p. 30) If the number of supported texture 439 coordinate sets (the value of MAX_TEXTURE_COORDS_ARB) is k, ... 440 441 Modify Section 2.10.2, Matrices (p. 33) 442 443 (modify first paragraph, p. 37) For each texture coordinate set, a 4x4 444 matrix is applied to the corresponding texture coordinates. This matrix 445 is applied as... 446 447 (modify third and fourth paragraphs, p. 37) The command 448 449 void ActiveTexture(enum texture) 450 451 specifies the active texture unit selector, ACTIVE_TEXTURE. Each texture 452 unit contains up to two distinct sub-units: a texture coordinate 453 processing unit (consisting of a texture matrix stack and texture 454 coordinate generation state) and a texture image unit (consisting of all 455 the texture state defined in Section 3.8). In implementations with a 456 different number of supported texture coordinate sets and texture image 457 units, some texture units may consist of only one of the two sub-units. 458 459 The active texture unit selector specifies the texture coordinate set 460 accessed by commands involving texture coordinate processing. Such 461 commands include those accessing the current matrix stack (if 462 MATRIX_MODE is TEXTURE), TexGen (section 2.10.4), Enable/Disable (if any 463 texture coordinate generation enum is selected), as well as queries of 464 the current texture coordinates and current raster texture coordinates. 465 If the texture coordinate set number corresponding to the current value 466 of ACTIVE_TEXTURE is greater than or equal to the 467 implementation-dependent constant MAX_TEXTURE_COORDS_ARB, the error 468 INVALID_OPERATION is generated by any such command. 469 470 The active texture unit selector also selects the texture image unit 471 accessed by commands involving texture image processing (section 3.8). 472 Such commands include all variants of TexEnv, TexParameter, and TexImage 473 commands, BindTexture, Enable/Disable for any texture target (e.g., 474 TEXTURE_2D), and queries of all such state. If the texture image unit 475 number corresponding to the current value of ACTIVE_TEXTURE is greater 476 than or equal to the implementation-dependent constant 477 MAX_TEXTURE_IMAGE_UNITS_ARB, the error INVALID_OPERATION is generated by 478 any such command. 479 480 ActiveTexture generates the error INVALID_ENUM if an invalid <texture> 481 is specified. <texture> is a symbolic constant of the form TEXTUREi, 482 indicating that texture unit i is to be modified. The constants obey 483 TEXTUREi = TEXTURE0 + i (i is in the range 0 to k-1, where k is the 484 larger of the MAX_TEXTURE_COORDS_ARB and MAX_TEXTURE_IMAGE_UNITS_ARB). 485 486 For compatibility with old OpenGL specifications, the 487 implementation-dependent constant MAX_TEXTURE_UNITS specifies the number 488 of conventional texture units supported by the implementation. Its value 489 must be no larger than the minimum of MAX_TEXTURE_COORDS_ARB and 490 MAX_TEXTURE_IMAGE_UNITS_ARB. 491 492 (modify third paragraph, p. 38) The state required to implement 493 transformations consists of a 4-valued integer indicating the current 494 matrix mode, one stack of at least two 4x4 matrices for each of COLOR, 495 PROJECTION, each texture coordinate set, and TEXTURE and a stack of at 496 least 32 4x4 matrices for MODELVIEW. Each matrix stack has an associated 497 stack pointer. Initially, there is only one matrix on each stack, and 498 all matrices are set to the identity. The initial matrix mode is 499 MODELVIEW. The initial value of ACTIVE_TEXTURE is TEXTURE0. 500 501Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) 502 503 (Modify first paragraph, p. 61)... Figure 3.1 diagrams the rasterization 504 process. The color value assigned to a fragment is initially determined 505 by the rasterization operations (sections 3.3 through 3.7) and modified 506 by either the execution of the texturing, color sum, and fog operations 507 as defined in sections 3.8, 3.9, and 3.10, or of a fragment shader 508 defined in section 3.11. The final depth value is initially determined 509 by the rasterization operations and may be modified or replaced by a 510 fragment shader. The results from rasterizing a point, line, polygon, 511 pixel rectangle or bitmap can be routed through a fragment shader. 512 513 (modify Figure 3.1) 514 515 516 _ +---------------+ switch depending on a 517 /|| Point |\ fragment shader being active 518 / | Rasterization | \ o-------------+ 519 / +---------------+ -++-++--->o | 520 From / +---------------+ / | || o | 521 Primitive ---> | Line |/ | || | | 522 Assembly \ | Rasterization | / || | | 523 \ +---------------+ / || | | 524 \ +---------------+/ || +-----+-----+ +----+-----+ 525 \|| Polygon | || | Texturing | | Fragment | 526 - | Rasterization | / | +-----+-----+ | Shader | 527 +---------------+ / | | +----+-----+ 528 +---------------+ / | +-----+-----+ | 529 | Pixel | / | | Color Sum | | 530 DrawPixels --> | Rectangle |/ / +-----+-----+ | 531 | Rasterization | / | V 532 +---------------+ / +-----+-----+ 533 +---------------+ / | Fog |---> Fragments 534 Bitmap ----> | Bitmap | / +-----------+ 535 | Rasterization |/ 536 +---------------+ 537 538 Modify Section 3.3.1, Basic Point Rasterization (p. 67) 539 540 (modify last paragraph, p. 67) All fragments produced in rasterizing a 541 non-antialiased point are assigned the same associated data, which are 542 those of the vertex corresponding to the point. If a fragment shader is 543 active (see section 3.11) the texture coordinates s, t, r, and q are 544 passed on directly. Otherwise, the texture coordinates s, t, and r are 545 replaced by s/q, t/q, and r/q, respectively, and if q is less than or 546 equal to zero, the results are undefined. 547 548 (modify second paragraph p. 68) If antialiasing is enabled, then point 549 rasterization produces a fragment for each fragment square that 550 intersects the region lying within the circle having diameter equal to 551 the current point width and centered at the point's (Xw, Yw) (figure 552 3.3). The coverage value for each fragment in the window coordinate area 553 of the intersection of the circular region with the corresponding 554 fragment square (but see section 3.2). This value is saved and used in 555 the final step of rasterization (section 3.12). The data associated with 556 each fragment are otherwise the data associated with the point being 557 rasterized, with the exception of the texture coordinates. If a fragment 558 shader is active, texture coordinates s, t, r, and q are passed on 559 directly. Otherwise, the texture coordinates s, t, and r are replaced by 560 s/q, t/q, and r/q, respectively, and if q is less than or equal to zero, 561 the results are undefined. 562 563 Modify Section 3.4.1, Basic Line Segment Rasterization (p. 71) 564 565 (modify last paragraph, p. 72) ... or the s, t, r, or q texture 566 coordinate or the clip w coordinate (the depth value, window z, must be 567 found using equation 3.5, below), is found as 568 569 (Equation 3.4) 570 571 where fa and fb are the data associated with the starting and ending 572 endpoints of the segment, respectively; wa and wb are the clip w 573 coordinates of the starting and ending endpoints of the segments, 574 respectively. When there is no fragment shader active (see section 575 3.11), alpha a = alpha b = 1 for all data except texture coordinates, in 576 which case alpha a = qa and alpha b = qb (qa and qb are the homogeneous 577 texture coordinates at the starting and ending endpoints of the segment; 578 results are undefined if either of these is less than or equal to 0). 579 When a fragment shader is active, alpha a = alpha b = 1 for all 580 components (i.e., q is interpolated along with s, t, and r). Note that 581 linear interpolation would use ... 582 583 ... A GL implementation may choose to approximate equation 3.4 with 3.5, 584 but this will normally lead to unacceptable distortion effects when 585 interpolating texture coordinates or clip w coordinates. 586 587 Modify Section 3.5.1, Basic Polygon Rasterization (p. 77) 588 589 (modify fourth paragraph, p. 78) ... When no fragment shader is active 590 (section 3.11), alpha a = alpha b = alpha c = 1 except for texture s, t, 591 and r coordinates, for which alpha a = qa, alpha b = qb, and alpha c = 592 qc (if any of qa, qb, or qc are less than or equal to zero, results are 593 undefined). When a fragment shader is active, alpha a = alpha b = alpha 594 c = 1 for all components (i.e., q is interpolated along with s, t, and 595 r). ... 596 597 (modify first paragraph p. 79) this may yield acceptable results for 598 color values (it must be used for depth values), but will normally lead 599 to unacceptable distortion effects if used for texture coordinates or 600 clip w coordinates. 601 602 Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 95) 603 604 (modify third paragraph, p. 106) A fragment arising from a group 605 consisting of color data ...,and texture coordinates are taken from the 606 current raster position's associated texture coordinates. If a fragment 607 shader is active (see section 3.11) the texture coordinates s, t, r, and 608 q are passed on directly. Otherwise, the texture coordinates s, t, and r 609 are replaced by s/q, t/q, and r/q, respectively, and if q is less than 610 or equal to zero, the results are undefined. Groups arising from 611 DrawPixels ... 612 613 Modify Section 3.7, Bitmaps (p. 116) 614 615 (modify first paragraph, p. 118) ...The associated data for each 616 fragment are those associated with the current raster position. If a 617 fragment shader is active (see section 3.11) the texture coordinates s, 618 t, r, and q are passed on directly. Otherwise, the texture coordinates 619 s, t, and r are replaced by s/q, t/q, and r/q, respectively, and if q is 620 less than or equal to zero, the results are undefined. Once the 621 fragments have been produced,... 622 623 Modify Section 3.8, Texturing (p. 118) 624 625 (change the first full paragraph on p. 119) The GL provides two ways to 626 specify the details of how texturing of a primitive is effected. The 627 first is referred to as fixed functionality, and is described in this 628 section. The second is referred to as a fragment shader, and is 629 described in section 3.11. The specification of the image to be texture 630 mapped and the means by which the image is filtered when applied to the 631 primitive are common to both methods and are discussed in this section. 632 The fixed functionality method for determining what RGBA value is 633 produced is also described in this section. If a fragment shader is 634 active, the method for determining the RGBA value is specified by an 635 application-supplied fragment shader as described in the OpenGL Shading 636 Language Specification. 637 638 Modify Section 3.8.8, Texture Minification (p. 140) 639 640 (change the first paragraph of the "Scale Factor and Level of Detail" 641 section) 642 643 The choice is governed by a scale factor rho(x,y) and the level of 644 detail parameter lambda(x,y), defined as 645 646 lambda_base(x,y) = log2[rho(x,y)] 3.16a 647 648 lambda'(x,y) = lambda_base(x,y) + 3.16b 649 clamp(texobj_bias + texunit_bias + fragshader_bias) 650 651 |------- lod_max lambda' > lod_max 652 lambda(x,y) = | lambda' lod_min <= lambda' <= lod_max 3.16c 653 | lod_min lambda' < lod_min 654 |------- undefined lod_min > lod_max 655 656 texobj_bias is the value of TEXTURE_LOD_BIAS for the bound texture 657 object (as described in section 3.8.4), and texunit_bias is the value of 658 TEXTURE_LOD_BIAS for the current texture unit (as described in section 659 3.8.13). fragshader_bias is the value of the optional bias parameter in 660 the texture lookup functions available to a fragment shader. If a 661 fragment shader is active, but the bias parameter is not provided, or if 662 no fragment shader is active, then fragshader_bias is zero. The sum of 663 these values is clamped to the range [-max_bias, max_bias] where 664 max_bias is the value of the implementation defined constant 665 MAX_TEXTURE_LOD_BIAS. 666 667 Modify Section 3.8.15, Texture Application (p. 158) 668 669 (modify fifth paragraph, p. 158) Texturing is enabled and disabled 670 individually for each texture unit. If texturing is disabled for one of 671 the units, then the fragment resulting from the previous unit is passed 672 unaltered to the following unit. Individual texture units beyond those 673 specified by MAX_TEXTURE_UNITS are always treated as disabled. 674 675 Modify Section 3.9, Color Sum (p. 160) 676 677 (add a new sentence before first paragraph, p. 160) If no fragment 678 shader is active (see Section 3.11), a color sum operation is performed 679 involving the primary and secondary colors. 680 681 (change the last sentence of the section, p. 160) Color sum has no 682 effect in color index mode or if a fragment shader is active. 683 684 Modify Section 3.10, Fog (p. 160) 685 686 (Change the first sentence, p. 160) If no fragment shader is active (see 687 Section 3.11) and fog is enabled, an operation is performed that blends 688 a fog color with a rasterized fragment's .... 689 690 Modify Section 3.11, Antialiasing Application 691 692 Rename this section to Section 3.12. 693 694 Add Section 3.11, Fragment Shaders 695 696 The sequence of operations that are applied to fragments that result 697 from rasterizing a point, line segment, polygon, pixel rectangle or 698 bitmap as described in Sections 3.8 through 3.10 is a 699 fixed-functionality method for processing such fragments. Applications 700 can more generally describe the operations that occur on such fragments 701 by using a "fragment shader". 702 703 A fragment shader is an array of strings containing source code for the 704 operations that are meant to occur on each fragment that results from 705 rasterizing a point, line segment, polygon, pixel rectangle or bitmap. 706 The language used for fragment shaders is described in the OpenGL 707 Shading Language Specification. 708 709 A fragment shader only applies when the GL is in RGBA mode. Its 710 operation in color index mode is undefined. 711 712 Section 3.11.1 Creating and Using a Fragment Shader 713 714 In order to create a fragment shader, call CreateShaderObjectARB with a 715 <shaderType> of FRAGMENT_SHADER_ARB. The source code for the fragment 716 shader can be specified using the ShaderSourceARB command. A fragment 717 shader is compiled by calling CompileShaderARB and attached to a program 718 object by calling AttachObjectARB. When LinkProgramARB is issued, all of 719 the attached shader objects of type FRAGMENT_SHADER_ARB are linked 720 together to create an executable program that can be used to process 721 fragments that arise from rasterizing points, line segments, polygons, 722 pixel rectangles or bitmpas. This executable program will become part of 723 current state when UseProgramObjectARB is issued. 724 725 CreateShaderObjectARB will set the object specific parameter 726 OBJECT_SUBTYPE_ARB to FRAGMENT_SHADER_ARB. 727 728 Section 3.11.2 Uniform Variables 729 730 A fragment shader may define one or more "uniform" variables. These 731 values are expected to remain constant over a primitive or a sequence of 732 primitives. The OpenGL Shading Language Specification defines a set of 733 built-in uniform variables for fragment shaders that correspond to the 734 state that GL manages for the purpose of processing fragments that are 735 generated by the rasterization of points, line segments, and polygons. 736 The amount of storage that is available for fragment shader uniform 737 variables is specified by the implementation dependent constant 738 MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB. This value represents the number of 739 individual floating point values, or individual integer values, or 740 individual Boolean values that can be held in uniform variable storage 741 for a fragment shader. A link error will be generated if an attempt is 742 made to utilize more than the space available for fragment shader 743 uniform variables. 744 745 Section 3.11.3 Varying Variables 746 747 A fragment shader consumes the data produced as a result of the 748 rasterization of points, line segments, polygons, pixel rectangles or 749 bitmaps. If no vertex shader is active, the data that is available to 750 the fragment shader at each fragment consists of the same types of data 751 that are normally associated with a fragment for fixed functionality 752 fragment processing, namely, the fragment's coordinate, color, secondary 753 color, texture coordinates, fog coordinate, and eyeZ. The OpenGL Shading 754 Language Specification defines a set of built-in varying variables that 755 can be used to access these values within a fragment shader. 756 757 When a vertex shader is active, it may define one or more "varying" 758 variables (see Section 2.15.4 and the OpenGL Shading Language 759 Specification). These values are expected to be interpolated across the 760 primitive being rendered. The results of these interpolations are 761 available within a fragment shader through varying variables that are 762 defined as varying variables in the fragment shader with the same names 763 as those defined in the vertex shader. 764 765 Section 3.11.4 Fragment Shader Execution Environment 766 767 If a fragment shader is active, the executable version of the fragment 768 shader is used to process incoming fragment values that are the result 769 of point, line segment, polygon, pixel rectangle or bitmap rasterization 770 rather than the fixed functionality fragment processing described in 771 Sections 3.8-3.10. In particular, 772 773 * the texture environments and texture functions described in Section 774 3.8.13 are not applied (pp. 152-157) 775 * texture application as described in Section 3.8.15 is not applied. 776 (pp. 158- 160) 777 * color sum as described in Section 3.9 is not applied (p. 160) 778 * fog as described in Section 3.10 is not applied (p. 160-162) 779 780 When a texture lookup is performed in a fragment shader, the GL computes 781 the filtered texture value ? in the manner described in sections 3.8.8 782 and 3.8.9, and converts it to a texture source color C_s according to 783 table 3.21 (section 3.8.13). The GL returns a four-component vector 784 (R_s, G_s, B_s, A_s) to the fragment shader. For the purposes of 785 level-of-detail calculations, the derivates du/dx, du/dy, dv/dx, dv/dy, 786 dw/dx and dw/dy may be approximated by a differencing algorithm as 787 detailed in section 8.8 of the OpenGL Shading Language specification. 788 789 Texture comparison requires the fragment shader to use the shadow 790 versions of the texture lookup functions. This in turn means that 791 samplers of type sampler1DShadow or sampler2DShadow or 792 sampler2DRectShadow need to be used to indicate the texture image unit 793 that has a depth texture bound to it. 794 795 The results of a texture lookup function are undefined if: 796 797 * The sampler used in a texture lookup function is of type sampler1D 798 or sampler2D or sampler2DRect, and the texture object's internal 799 format is DEPTH_COMPONENT, and the TEXTURE_COMPARE_MODE is not NONE. 800 * The sampler used in a texture lookup function is of type 801 sampler1DShadow or sampler2DShadow or sampler2DRectShadow, and the 802 texture object's internal format is DEPTH_COMPONENT, and the 803 TEXTURE_COMPARE_MODE is NONE. 804 * The sampler used in a texture lookup function is of type 805 sampler1DShadow or sampler2DShadow or sampler2DRectShadow, and the 806 texture object's internal format is not DEPTH_COMPONENT_ARB. 807 808 If a fragment shader uses a sampler which associated texture object is 809 not complete, as defined in section 3.8.10, the texture image unit will 810 return (R, G, B, A) = (0, 0, 0, 1). 811 812 The number of separate texture units that can be accessed from within a 813 fragment shader during the rendering of a single primitive is specified 814 by the implementation- dependent constant MAX_TEXTURE_IMAGE_UNITS_ARB. 815 816 A fragment shader has access to the read-only built-in variable 817 gl_FrontFacing whose value is true if the fragment belongs to a 818 front-facing primitive. A fragment derives its facing direction from the 819 primitive that generates the fragment. All fragments generated by 820 primitives other than polygons, triangles, or quadrilaterals are 821 considered to be front facing. For all other fragments (including ones 822 resulting from point- and line-mode polygons) the determination is made 823 by examining the sign of the area computed by equation 2.6 of section 824 2.13.1 (including the possible reversal of this sign as indicated by the 825 last call to FrontFace). If the sign is positive then the fragments are 826 front facing; otherwise, they are back facing. 827 828 When processing fragments resulting from the rasterization of a pixel 829 rectangle or bitmap, results are undefined if the fragment shader uses a 830 varying variable that is not a built-in varying variable (see Section 831 7.6 of the Shading Language Specification for a list). 832 833 Section 3.11.5 Fragment Shader Input 834 835 The OpenGL Shading Language specification describes the values that are 836 available as inputs to the fragment shader. This section is concerned 837 with the built-in variables gl_FragCood, gl_Color and gl_SecondaryColor. 838 839 The built-in gl_FragCoord holds the window relative coordinates x, y, z, 840 and 1/w for the fragment. The "z" component of gl_FragCoord undergoes an 841 implied conversion to floating point. This conversion must leave the 842 values 0 and 1 invariant. Note that this "z" component already has a 843 polygon offset added in, if enabled. The 1/w value is computed from the 844 Wc coordinate (see Section 2.10), which is the result of the product of 845 the projection matrix and the vertex's eye coordinates. 846 847 The built-in variables gl_Color and gl_SecondaryColor hold the "r", "g", 848 "b", and "a" components, respectively, of the fragment color and 849 secondary color. Each fixed-point color component undergoes an implied 850 conversion to floating point. This conversion must leave the values 0 851 and 1 invariant. 852 853 Section 3.11.6 Fragment Shader Output 854 855 The OpenGL Shading Language specification describes the values that may 856 be output by a fragment shader. These are gl_FragColor, gl_FragData[n], 857 and gl_FragDepth. The final fragment color values or the final fragment 858 data values written by a fragment shader are clamped to the range [0,1] 859 and then converted to fixed-point as described in section 2.13.9, Final 860 Color Processing. The final fragment depth written by a fragment shader 861 is first clamped to [0,1] and then converted to fixed-point as if it 862 were a window z value. See Section 2.10.1, Controlling the Viewport. 863 Note that the depth range computation is NOT applied here, only the 864 conversion to fixed-point. 865 866 The OpenGL Shading Language specification defines what happens when 867 color, fragment data and/or depth are not written. Those rules are 868 repeated here. 869 870 Writing to gl_FragColor specifies the fragment color that will be used 871 by the subsequent fixed functionality pipeline. If subsequent fixed 872 functionality consumes fragment color and an execution of a fragment 873 shader does not write a value to gl_FragColor then the fragment color 874 consumed is undefined. 875 876 The variable gl_FragData is an array. Writing to gl_FragData[n] 877 specifies the fragment data that will be used by the subsequent fixed 878 functionality pipeline for data n. If subsequent fixed functionality 879 consumes fragment data and an execution of a fragment shader does not 880 write a value to it, then the fragment data consumed is undefined. 881 882 If a shader statically assigns a value to gl_FragColor, it may not 883 assign a value to any element of gl_FragData. If a shader statically 884 writes a value to any element of gl_FragData, it may not assign a value 885 to gl_FragColor. That is, a shader may assign values to either 886 gl_FragColor or gl_FragData, but not both.. 887 888 Writing to gl_FragDepth will establish the depth value for the fragment 889 being processed. If depth buffering is enabled, and a shader does not 890 write gl_FragDepth, then the fixed function value for depth will be used 891 as the fragment's depth value. If a shader statically assigns a value to 892 gl_FragDepth, and there is an execution path through the shader that 893 does not set gl_FragDepth, then the value of the fragment's depth may be 894 undefined for some executions of the shader. That is, if a shader 895 statically contains a write to gl_FragDepth, then it is responsible for 896 always writing it. 897 898 Note, a shader contains a static assignment to a variable x if, after 899 pre-processing, the shader contains a statement that would write to x, 900 whether or not run-time flow of control will cause that statement to be 901 executed. 902 903 Section 3.11.7 Required State 904 905 Besides the required state outlined in the ARB_shader_objects extension 906 document, the following state per program object is also required: 907 908 * An array of MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB words that holds 909 uniform values. 910 911 Modify Section 3.12, Multisample Point Fade 912 913 Rename this section to Section 3.13. 914 915 916Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment 917Operations and the Frame Buffer) 918 919 None 920 921Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) 922 923 Modify Section 5.6, Hints (p. 203) 924 925 (add to the paragraph describing the hints)... the desired quality and 926 performance of compressing texture images; 927 FRAGMENT_SHADER_DERIVATIVE_HINT_ARB, indicating the desired derivative 928 accuracy for the fragment processing built-in functions dFdx, dFdy and 929 fwidth. Hint must be one of FASTEST, ... 930 931Additions to Chapter 6 of the OpenGL 1.4 Specification (State and State Requests) 932 933 Modify Section 6.1.2, Data Conversions (p. 205) 934 935 (add to end of last paragraph, p. 206) Queries of texture state 936 variables corresponding to a texture coordinate processing unit (namely, 937 TexGen state and enables, and matrices) will produce an 938 INVALID_OPERATION error if the value of ACTIVE_TEXTURE is greater than 939 or equal to MAX_TEXTURE_COORDS_ARB. All other texture state queries will 940 result in an INVALID_OPERATION error if the value of ACTIVE_TEXTURE is 941 greater than or equal to MAX_TEXTURE_IMAGE_UNITS_ARB. 942 943 Modify section 6.1.12 Object Queries. 944 945 The commands 946 947 void GetObjectParameter{if}vARB(handleARB obj, enum pname, T params) 948 949 return object specific parameter values for object <obj> in <params>. 950 The parameter value to return is specified by <pname>. 951 952 If <pname> is OBJECT_TYPE_ARB, GetObjectParameter{if}vARB returns 953 PROGRAM_OBJECT_ARB if <obj> references a program object. It returns 954 SHADER_OBJECT_ARB if <obj> references any shader object. If <obj> is not 955 of type PROGRAM_OBJECT_ARB or SHADER_OBJECT_ARB, the error 956 INVALID_OPERATION is generated. 957 958 If <pname> is OBJECT_SUBTYPE_ARB, GetObjectParameter{if}vARB returns 959 FRAGMENT_SHADER_ARB if <obj> references a shader object. If <obj> is not 960 of type SHADER_OBJECT_ARB, the error INVALID_OPERATION is generated. 961 962 963Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) 964 965 Add to end of Section A.3 (p. 250): 966 967 The same fragment shader will produce the same result when run multiple 968 times with the same input. The wording 'the same shader' means a program 969 object that is populated with the same source strings, which are 970 compiled and then linked, possibly multiple times. This program object 971 is then executed using the same GL state vector. 972 973 All fragment shaders that either conditionally or unconditionally assign 974 gl_FragCoord.z to gl_FragDepth are depth-invariant with respect to each 975 other, for those fragments where the assignment to gl_FragDepth actually 976 is done. 977 978Additions to the AGL/GLX/WGL Specifications 979 980 None 981 982Interactions with ARB_vertex_program and ARB_fragment_program 983 984 Mixing a high level ARB_fragment_shader shader with a low level 985 ARB_vertex_program shader is allowed. However, a high level 986 ARB_fragment_shader shader and a low level ARB_fragment_program shader 987 cannot be active at the same time. 988 989Interactions with ARB_fragment_program 990 991 Enabling an ARB_fragment_shader shader by issuing the command 992 UseProgramObjectARB(), with a handle which is not zero, results in any 993 low level fragment shader to be ignored and overrides the enable 994 FRAGMENT_PROGRAM_ARB. Note that the value for FRAGMENT_PROGRAM_ARB does 995 not change by installing an ARB_fragment_shader shader. 996 997 The following enumerants are borrowed from ARB_fragment_program. Their 998 usage and meaning has stayed the same: 999 1000 MAX_TEXTURE_COORDS_ARB 0x8871 1001 MAX_TEXTURE_IMAGE_UNITS_ARB 0x8872 1002 1003Interactions with ARB_vertex_shader 1004 1005 If ARB_vertex_shader is present, then this extension does not also 1006 define the new token SHADER_OBJECT_ARB. 1007 1008 If ARB_vertex_shader is not present, the wording of Section 3.11.3 1009 Varying Variables needs to be modified to omit references to the vertex 1010 shader. 1011 1012Errors 1013 1014 The error INVALID_OPERATION is generated by any command accessing 1015 texture coordinate processing state if the texture unit number 1016 corresponding to the current value of ACTIVE_TEXTURE is greater than or 1017 equal to the implementation-dependent constant MAX_TEXTURE_COORDS_ARB. 1018 1019 The error INVALID_OPERATION is generated by any command accessing 1020 texture image processing state if the texture unit number corresponding 1021 to the current value of ACTIVE_TEXTURE is greater than or equal to the 1022 implementation-dependent constant MAX_TEXTURE_IMAGE_UNITS_ARB. 1023 1024 The error INVALID_VALUE is generated by any command that takes one or 1025 more handles as input, and one or more of these handles are not an 1026 object handle generated by OpenGL. 1027 1028 The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB 1029 if <pname> is OBJECT_TYPE_ARB and <obj> is not of type 1030 PROGRAM_OBJECT_ARB or SHADER_OBJECT_ARB. 1031 1032 The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB 1033 if <pname> is OBJECT_SUBTYPE_ARB and <obj> is not of type 1034 SHADER_OBJECT_ARB. 1035 1036New State 1037 Initial 1038 Get Value Type Get Command Value Description Sec. Attribute 1039 --------- ----- ----------------------- ------------- ----------- ---- --------- 1040 OBJECT_TYPE_ARB Z2 GetObjectParameterivARB SHADER_OBJECT Type of object 3.11.1 - 1041 OBJECT_SUBTYPE_ARB Z2 GetObjectParameterivARB FRAGMENT_SHADER Sub type of object 3.11.1 - 1042 1043 Table X Shader object state. 1044 1045 (Add the following hint to Table 6.26, p. 241.) 1046 1047 Initial 1048 Get Value Type Get Command Value Description Sec. Attribute 1049 --------- ----- ----------------------- ------------- ----------- ---- --------- 1050 FRAGMENT_SHADER_DERIVATIVE_HINT fragment shader 1051 Z3 GetIntegerv DONT_CARE derivative accuracy 5.6 hint 1052 hint 1053 1054New Implementation Dependent State 1055 Minimum 1056 Get Value Type Get Command Value Description Sec. Attr. 1057 --------- ---- ----------- ------- ----------- ---- ----- 1058 MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB Z+ GetIntegerv 64 Number of words 3.11.2 - 1059 for fragment shader 1060 uniform variables 1061 MAX_TEXTURE_IMAGE_UNITS_ARB Z+ GetIntegerv 2 Number of separate 3.11.4 - 1062 texture image units 1063 MAX_TEXTURE_COORDS_ARB Z+ GetIntegerv 2 number of texture 2.7 - 1064 coordinate sets 1065 1066Sample Usage 1067 1068 The code below is taken from the sample section in ARB_vertex_shader and 1069 expanded to include a fragment shader. 1070 1071 GLboolean init(GLcharARB *vertexShader, GLcharARB *fragmentShader) 1072 { 1073 const GLcharARB *pInfoLog; 1074 GLboolean compiled = GL_FALSE; 1075 GLboolean linked = GL_FALSE; 1076 GLint length; 1077 1078 // 1079 // Create shader and program objects. 1080 // 1081 ProgramObject = glCreateProgramObjectARB(); 1082 VertexShaderObject = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB); 1083 FragmentShaderObject = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB); 1084 1085 1086 length = strlen(vertexShader); 1087 glShaderSourceARB(VertexShaderObject, 1, &vertexShader, &length); 1088 glShaderSourceARB(FragmentShaderObject, 1, &fragmentShader, NULL); 1089 1090 // 1091 // OpenGL made a copy of the shaders, we can free our copy 1092 // 1093 free(vertexShader); 1094 free(fragmentShader); 1095 1096 // 1097 // Compile the vertex and fragment shader, and print out the 1098 // compiler log file. 1099 // 1100 glCompileShaderARB(VertexShaderObject); 1101 glGetObjectParameterivARB(VertexShaderObject, 1102 GL_OBJECT_COMPILE_STATUS_ARB, &compiled); 1103 1104 glGetObjectParameterivARB(VertexShaderObject, 1105 GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength); 1106 pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB)); 1107 glGetInfoLogARB(VertexShaderObject, maxLength, &length, pInfoLog); 1108 printf("%s", pInfoLog); 1109 free(pInfoLog); 1110 1111 if (!compiled) { 1112 printf("Compile failed\n"); 1113 return GL_FALSE; 1114 } 1115 1116 glCompileShaderARB(FragmentShaderObject); 1117 glGetObjectParameterivARB(FragmentShaderObject, 1118 GL_OBJECT_COMPILE_STATUS_ARB, &compiled); 1119 1120 glGetObjectParameterivARB(FragmentShaderObject, 1121 GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength); 1122 pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB)); 1123 glGetInfoLogARB(FragmentShaderObject, maxLength, NULL, pInfoLog); 1124 printf("%s", pInfoLog); 1125 free(pInfoLog); 1126 1127 if (!compiled) { 1128 printf("Compile failed\n"); 1129 return GL_FALSE; 1130 } 1131 1132 // 1133 // Populate the program object with the compiled shadera 1134 // 1135 glAttachObjectARB(ProgramObject, VertexShaderObject); 1136 glAttachObjectARB(ProgramObject, FragmentShaderObject); 1137 1138 // 1139 // We want the shader objects to go away as soon as it is detached 1140 // from the program object it is attached to. We can simply call 1141 // delete now to achieve that. Note that calling delete on a program 1142 // object will result in all shaders attached to that program object 1143 // to be detached. If delete has been called for the shader objects, 1144 // calling delete on the program object will result in the shader 1145 // objects being deleted as well. 1146 // 1147 glDeleteObjectARB(VertexShaderObject); 1148 glDeleteObjectARB(FragmentShaderObject); 1149 1150 // 1151 // Link the program object and print out the linker log file 1152 // 1153 glLinkProgramARB(ProgramObject); 1154 glGetObjectParameterivARB(ProgramObject, 1155 GL_OBJECT_LINK_STATUS_ARB, &linked); 1156 1157 glGetObjectParameterivARB(ProgramObject, 1158 GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength); 1159 pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB)); 1160 glGetInfoLogARB(ProgramObject, maxLength, NULL, pInfoLog); 1161 1162 printf("%s\n", pInfoLog); 1163 free(pInfoLog); 1164 1165 // 1166 // If all went well, make the program object part of the current state 1167 // 1168 if (linked) { 1169 glUseProgramObjectARB(ProgramObject); 1170 return GL_TRUE; 1171 } else { 1172 return GL_FALSE; 1173 } 1174 } 1175 1176Revision History 1177 1178 Revision 0.5, 6/6/2002 1179 - First draft for circulation 1180 Revision 0.51, 6/10/2002 1181 - Listed all varyings that a fragment shader can access 1182 - Clarified section 3.11.6 1183 - Added more to the 'Interaction with GL2_vertex_shader' section 1184 Revision 0.52, 6/12/2002 1185 - Now references V1.0 of the OpenGL Shading Language Specification 1186 - Fixed minor typos 1187 - Accepted by the GL2 working group 1188 Revision 0.52, 10/17/2002 1189 - Removed IsObjectGL2() 1190 - Expanded GetObjectParameter{if}GL2. Added OBJECT_SUBTYPE_GL2. 1191 Revision 0.53, 10/18/2002 1192 - Forgot to add _GL2 to the end of MAX_FP_TEXTURE_UNITS_GL2. 1193 - Added language disallowing mixing GL2 high level vertex shader with 1194 low level ARB vertex program or fragment program. 1195 Revision 0.54, 10/24/2002 1196 - Removed the resource limit section and move it to GL2_shader_objects 1197 - Clarified some sections across the document 1198 - Based on ARB_fragment_program split a texture unit into two sub 1199 units. This resulted in expanding Section 2 significantly. 1200 - Expanded section 6 1201 - Expanded Errors section 1202 - Added sample usage 1203 Revision 0.6, 10/29/2002 1204 - Now written against the OpenGL 1.4 specification. 1205 - Second distribution to the GL2 working group. 1206 Revision 0.61, 11/26/2002 1207 - Renamed MAX_FP_TEXTURE_UNITS to MAX_FRAGMENT_TEXTURE_UNITS. 1208 - Updated list of contributors. 1209 - Allowed mixing of a high level GL2 fragment shader with a low level 1210 ARB_vertex_program shader. 1211 Revision 0.62, 12/04/2002 1212 - Changed issue 3 wording to make the number of texture image units 1213 and coordinates units independent from each other. 1214 - Changed MAX_FRAGMENT_UNIFORM_FLOATS_GL2 to 1215 MAX_FRAGMENT_UNIFORM_WORDS_GL2. Also changed language in paragraph 1216 3.11.2 clarifying this new constant. 1217 - Added issue number 5. 1218 Revision 0.63, 02/13/2003 1219 - Consistently used 'texture coordinate set' 1220 - Changed 3.11.5, fragment shader output. Colors are clamped, and 1221 depths are clamped then converted to fixed point. 1222 - Added Section 3.11.4.1 Fragment Shader Texturing 1223 Revision 0.64, 02/21/2003 1224 - Modified section 2.10.1 1225 - Added color conversion to fixed-point to the values written to 1226 gl_FragColor. Section 3.11.5. 1227 Revision 0.65, 03/06/2003 1228 - Added a third LOD bias parameter to section 3.8.8 (comes from the 1229 texture lookup functions). 1230 - Added issues 6 and 7. 1231 - Added clip w coordinate interpolation for lines and polygons. 1232 - Upgraded colors and texture coordinates to be full floating point 1233 citizens, section 2.1.1. 1234 - Updated the interactions section. 1235 - Renamed MAX_FRAGMENT_TEXTURE_UNITS_GL2 to 1236 MAX_TEXTURE_IMAGE_UNITS_ARB 1237 Revision 0.66, 03/26/2003 1238 - Expanded issues 2 and 3. 1239 - Added modification to section 3.8.15. 1240 - Updated contributors list. Who else? 1241 - Updated IP Status section to point to the contributors agreement. 1242 Revision 0.67, 04/09/2003 1243 - Added required state section. 1244 - Renamed handle to handleGL2 1245 Revision 0.68, 05/08/2003 1246 - Changed MAX_FRAGMENT_UNIFORM_WORDS_GL2 to 1247 MAX_FRAGMENT_UNIFORM_COMPONENTS_GL2 1248 - Updated example section to reflect the latest API changes 1249 - Changed the location of the Contributors License to a publicly 1250 accessible place on www.3dlabs.com. 1251 - Re-worded the introduction. 1252 - Added OBJECT_TYPE_GL2 to the list of new tokens. 1253 - Moved issue 3 up to be issue 1. 1254 - Re-wrote section 3.8, introduction. 1255 - Added issue 8. 1256 - Added front/back facing language to section 3.11.4 1257 - Re-wrote issue 3. 1258 - Added language to appendix A. Invariance. 1259 - Added section 3.11.5 Fragment Shader Input 1260 - Added issue 9 1261 - Fixed section 3.11.4. Texture enables are ignored. 1262 - Added issue 10. 1263 - Added a note about polygon offset to section 3.11.5. 1264 - Reversed the resolution of issue 5. Changed chapter 3 to reflect 1265 this. 1266 - Updated sample code to reflect latest API names. 1267 - Updated errors section. 1268 - Numerous small fixes based on Pat's comments. 1269 - Depth values are converted to floating point before entering the 1270 fragment shader. Updated issue 7 to reflect this. 1271 - Fixed up the state tables. 1272 - Updated section 3.11.4. Clarified depth texture comparison mode when 1273 a fragment shader is active. 1274 - Added Jon Leech, Evan Hart, Benjamin Lipchak and Jeremy Sandmel to 1275 the list of contributors. 1276 Revision 0.69, 05/09/2003 1277 - Added to issue 5. In this case fragment shader should only reference 1278 built- in varying variables s (starting with "gl_"). Also added spec 1279 language to section 3.11.4. 1280 - Added one more paragraph to issue 4, invariance. If you do not write 1281 to gl_FragDepth you're depth invariant with fixed-function. 1282 - Explained 'statically assigned' 1283 - Assigned enum values. 1284 - Version approved by the ARB-GL2 working group. 1285 Revision 0.70, 05/14/2003 1286 - Section 3.8.15 clarified. 1287 - Issue 8 intended to explain what happens when 1288 VERTEX_PROGRAM_TWO_SIDE_ARB is false, not true. Fixed. 1289 - Clarified fragment front/back facing selection when in polygon point 1290 or line mode. 1291 - Fixed typos. 1292 - Renamed all GL2 occurrences to ARB. 1293 - Added SHADER_OBJECT_ARB to the list of new tokens. 1294 - Deleted reference to AppendShader (this call no longer exist). 1295 Revision 0.71, 06/30/2003 1296 - Removed section 2.13.9. It no longer applies. 1297 - The dynamic range of colors is left at 2^10, only texture 1298 coordinates are upgraded to 2^32 (Section 2.1.1). 1299 - Updated Sample Usage section. 1300 - Added fixed-point conversion rule for color and secondary color. 1301 Section 3.11.5. 1302 - General language cleanup. 1303 - Version approved as ARB extension 1304 Revision 0.72, 02/23/2004 1305 - Fixed the last part of section 3.4.1, basic line segment 1306 rasterization. 1307 - Removed SHADER_OBJECT_ARB, OBJECT_TYPE_ARB and OBJECT_SUBTYPE_ARB 1308 tokens from the New Tokens section. They are already defined in 1309 ARB_shader_objects. Also removed references to these in Chapter 6, 1310 GetObjectParameter{fi}v and the Errors section. 1311 - Added the official extension number (32). Edited the Status 1312 paragraph. 1313 Revision 0.73, 03/11/2004 1314 - Added language to specify when texture lookups are undefined when 1315 mixing shadow and non shadow samplers with texture objects with or 1316 without depth components and different texture compare modes set. 1317 Revision 0.74, 03/12/2004 1318 - Added sampler2DRect and sampler2DRectShadow to the previous changes. 1319 Revision 0.75, 03/16/2004 1320 - Fixed up the sampler language from version 0.74. 1321 - Updated section 3.11.6, Fragment Shader Output to incorporate the 1322 new gl_FragData[] output array. Added related issues 11 and 12. 1323 Revision 0.76, 03/19/2004 1324 - Added a hint DERIVATIVE_ACCURACY_HINT to section 5.6 and the New 1325 Tokens section. 1326 Revision 0.77, 03/31/2004 1327 - Added language to section 3.11.4 specifying that derivatives for LOD 1328 calculations may be approximated. 1329 - Moved spec language related to texture operations not affected by a 1330 fragment shader from section 3.11.4 to issue 13. 1331 - Added language to section 3.11.4, copied from the vertex shader, how 1332 the filtered texture value is computed. Also added language that the 1333 LOD could be computed using derivatives computed using a 1334 differencing algorithm. 1335 - Renamed DERIVATIVE_ACCURACY_HINT_ARB to 1336 FRAGMENT_SHADER_DERIVATIVE_HINT_ARB and added it to the state 1337 tables. 1338 - Updated issue 12. gl_FragData will be clamped to [0,1] 1339 - Added issue 14, explaining the interaction with MRT. 1340 - Updated the shading language version this spec references to version 1341 100.53. 1342 - Added clamping to [0,1] for output color and fragData back into 1343 section 3.11.6. Also updated the language in 3.11.6 to be the same 1344 as in the OpenGL Shading Language document. 1345 - Version voted on and approved by the workgroup. 1346 Revision 0.78, 04/06/2004 1347 - Minor language changes to issues 12 and 14. 1348 - Updated the Shading Language Version referenced to the now official 1349 version 1.10. 1350 Revision 0.79, 05/14/2004 1351 - Listed that FRAGMENT_SHADER_DERIVATIVE_HINT is also accepted by the 1352 Get* commands under the New Tokens section. 1353 - Updated issue 14. Punted most of it to the MRT extension document. 1354 Revision 0.80, 12/12/2006 1355 - Fixed spelling of glGetObjectParameterivARB in sample code. 1356