1Name 2 3 EXT_gpu_shader4 4 5Name Strings 6 7 GL_EXT_gpu_shader4 8 9Contact 10 11 Barthold Lichtenbelt, NVIDIA (blichtenbelt 'at' nvidia.com) 12 Pat Brown, NVIDIA (pbrown 'at' nvidia.com) 13 14Status 15 16 Multi vendor extension 17 18 Shipping for GeForce 8 Series (November 2006) 19 20Version 21 22 Last Modified Date: 12/14/2009 23 Author revision: 16 24 25Number 26 27 326 28 29Dependencies 30 31 OpenGL 2.0 is required. 32 33 This extension is written against the OpenGL 2.0 specification and version 34 1.10.59 of the OpenGL Shading Language specification. 35 36 This extension trivially interacts with ARB_texture_rectangle. 37 38 This extension trivially interacts with GL_EXT_texture_array. 39 40 This extension trivially interacts with GL_EXT_texture_integer. 41 42 This extension trivially interacts with GL_EXT_geometry_shader4 43 44 This extension trivially interacts with GL_EXT_texture_buffer_object. 45 46 NV_primitive_restart trivially affects the definition of this extension. 47 48 ARB_color_buffer_float affects the definition of this extension. 49 EXT_draw_instanced affects the definition of this extension. 50 51Overview 52 53 This extension provides a set of new features to the OpenGL Shading 54 Language and related APIs to support capabilities of new hardware. In 55 particular, this extension provides the following functionality: 56 57 * New texture lookup functions are provided that allow shaders to 58 access individual texels using integer coordinates referring to the 59 texel location and level of detail. No filtering is performed. These 60 functions allow applications to use textures as one-, two-, and 61 three-dimensional arrays. 62 63 * New texture lookup functions are provided that allow shaders to query 64 the dimensions of a specific level-of-detail image of a texture 65 object. 66 67 * New texture lookup functions variants are provided that allow shaders 68 to pass a constant integer vector used to offset the texel locations 69 used during the lookup to assist in custom texture filtering 70 operations. 71 72 * New texture lookup functions are provided that allow shaders to 73 access one- and two-dimensional array textures. The second, or third, 74 coordinate is used to select the layer of the array to access. 75 76 * New "Grad" texture lookup functions are provided that allow shaders 77 to explicitely pass in derivative values which are used by the GL to 78 compute the level-of-detail when performing a texture lookup. 79 80 * A new texture lookup function is provided to access a buffer texture. 81 82 * The existing absolute LOD texture lookup functions are no longer 83 restricted to the vertex shader only. 84 85 * The ability to specify and use cubemap textures with a 86 DEPTH_COMPONENT internal format. This also enables shadow mapping on 87 cubemaps. The 'q' coordinate is used as the reference value for 88 comparisons. A set of new texture lookup functions is provided to 89 lookup into shadow cubemaps. 90 91 * The ability to specify if varying variables are interpolated in a 92 non-perspective correct manner, if they are flat shaded or, if 93 multi-sampling, if centroid sampling should be performed. 94 95 * Full signed integer and unsigned integer support in the OpenGL 96 Shading Language: 97 98 - Integers are defined as 32 bit values using two's complement. 99 100 - Unsigned integers and vectors thereof are added. 101 102 - New texture lookup functions are provided that return integer 103 values. These functions are to be used in conjunction with new 104 texture formats whose components are actual integers, rather 105 than integers that encode a floating-point value. To support 106 these lookup functions, new integer and unsigned-integer 107 sampler types are introduced. 108 109 - Integer bitwise operators are now enabled. 110 111 - Several built-in functions and operators now operate on 112 integers or vectors of integers. 113 114 - New vertex attribute functions are added that load integer 115 attribute data and can be referenced in a vertex shader as 116 integer data. 117 118 - New uniform loading commands are added to load unsigned integer 119 data. 120 121 - Varying variables can now be (unsigned) integers. If declared 122 as such, they have to be flat shaded. 123 124 - Fragment shaders can define their own output variables, and 125 declare them to be of type floating-point, integer or unsigned 126 integer. These variables are bound to a fragment color index 127 with the new API command BindFragDataLocationEXT(), and directed 128 to buffers using the existing DrawBuffer or DrawBuffers API 129 commands. 130 131 * Added new built-in functions truncate() and round() to the shading 132 language. 133 134 * A new built-in variable accessible from within vertex shaders that 135 holds the index <i> implicitly passed to ArrayElement to specify the 136 vertex. This is called the vertex ID. 137 138 * A new built-in variable accessible from within fragment and geometry 139 shaders that hold the index of the currently processed 140 primitive. This is called the primitive ID. 141 142 This extension also briefly mentions a new shader type, called a geometry 143 shader. A geometry shader is run after vertices are transformed, but 144 before clipping. A geometry shader begins with a single primitive (point, 145 line, triangle. It can read the attributes of any of the vertices in the 146 primitive and use them to generate new primitives. A geometry shader has a 147 fixed output primitive type (point, line strip, or triangle strip) and 148 emits vertices to define a new primitive. Geometry shaders are discussed 149 in detail in the GL_EXT_geometry_shader4 specification. 150 151New Procedures and Functions 152 153 void VertexAttribI1iEXT(uint index, int x); 154 void VertexAttribI2iEXT(uint index, int x, int y); 155 void VertexAttribI3iEXT(uint index, int x, int y, int z); 156 void VertexAttribI4iEXT(uint index, int x, int y, int z, int w); 157 158 void VertexAttribI1uiEXT(uint index, uint x); 159 void VertexAttribI2uiEXT(uint index, uint x, uint y); 160 void VertexAttribI3uiEXT(uint index, uint x, uint y, uint z); 161 void VertexAttribI4uiEXT(uint index, uint x, uint y, uint z, 162 uint w); 163 164 void VertexAttribI1ivEXT(uint index, const int *v); 165 void VertexAttribI2ivEXT(uint index, const int *v); 166 void VertexAttribI3ivEXT(uint index, const int *v); 167 void VertexAttribI4ivEXT(uint index, const int *v); 168 169 void VertexAttribI1uivEXT(uint index, const uint *v); 170 void VertexAttribI2uivEXT(uint index, const uint *v); 171 void VertexAttribI3uivEXT(uint index, const uint *v); 172 void VertexAttribI4uivEXT(uint index, const uint *v); 173 174 void VertexAttribI4bvEXT(uint index, const byte *v); 175 void VertexAttribI4svEXT(uint index, const short *v); 176 void VertexAttribI4ubvEXT(uint index, const ubyte *v); 177 void VertexAttribI4usvEXT(uint index, const ushort *v); 178 179 void VertexAttribIPointerEXT(uint index, int size, enum type, 180 sizei stride, const void *pointer); 181 182 void GetVertexAttribIivEXT(uint index, enum pname, int *params); 183 void GetVertexAttribIuivEXT(uint index, enum pname, 184 uint *params); 185 186 void Uniform1uiEXT(int location, uint v0); 187 void Uniform2uiEXT(int location, uint v0, uint v1); 188 void Uniform3uiEXT(int location, uint v0, uint v1, uint v2); 189 void Uniform4uiEXT(int location, uint v0, uint v1, uint v2, 190 uint v3); 191 192 void Uniform1uivEXT(int location, sizei count, const uint *value); 193 void Uniform2uivEXT(int location, sizei count, const uint *value); 194 void Uniform3uivEXT(int location, sizei count, const uint *value); 195 void Uniform4uivEXT(int location, sizei count, const uint *value); 196 197 void GetUniformuivEXT(uint program, int location, uint *params); 198 199 void BindFragDataLocationEXT(uint program, uint colorNumber, 200 const char *name); 201 int GetFragDataLocationEXT(uint program, const char *name); 202 203New Tokens 204 205 Accepted by the <pname> parameters of GetVertexAttribdv, 206 GetVertexAttribfv, GetVertexAttribiv, GetVertexAttribIuivEXT and 207 GetVertexAttribIivEXT: 208 209 VERTEX_ATTRIB_ARRAY_INTEGER_EXT 0x88FD 210 211 Returned by the <type> parameter of GetActiveUniform: 212 213 SAMPLER_1D_ARRAY_EXT 0x8DC0 214 SAMPLER_2D_ARRAY_EXT 0x8DC1 215 SAMPLER_BUFFER_EXT 0x8DC2 216 SAMPLER_1D_ARRAY_SHADOW_EXT 0x8DC3 217 SAMPLER_2D_ARRAY_SHADOW_EXT 0x8DC4 218 SAMPLER_CUBE_SHADOW_EXT 0x8DC5 219 UNSIGNED_INT 0x1405 220 UNSIGNED_INT_VEC2_EXT 0x8DC6 221 UNSIGNED_INT_VEC3_EXT 0x8DC7 222 UNSIGNED_INT_VEC4_EXT 0x8DC8 223 INT_SAMPLER_1D_EXT 0x8DC9 224 INT_SAMPLER_2D_EXT 0x8DCA 225 INT_SAMPLER_3D_EXT 0x8DCB 226 INT_SAMPLER_CUBE_EXT 0x8DCC 227 INT_SAMPLER_2D_RECT_EXT 0x8DCD 228 INT_SAMPLER_1D_ARRAY_EXT 0x8DCE 229 INT_SAMPLER_2D_ARRAY_EXT 0x8DCF 230 INT_SAMPLER_BUFFER_EXT 0x8DD0 231 UNSIGNED_INT_SAMPLER_1D_EXT 0x8DD1 232 UNSIGNED_INT_SAMPLER_2D_EXT 0x8DD2 233 UNSIGNED_INT_SAMPLER_3D_EXT 0x8DD3 234 UNSIGNED_INT_SAMPLER_CUBE_EXT 0x8DD4 235 UNSIGNED_INT_SAMPLER_2D_RECT_EXT 0x8DD5 236 UNSIGNED_INT_SAMPLER_1D_ARRAY_EXT 0x8DD6 237 UNSIGNED_INT_SAMPLER_2D_ARRAY_EXT 0x8DD7 238 UNSIGNED_INT_SAMPLER_BUFFER_EXT 0x8DD8 239 240 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 241 and GetDoublev: 242 243 MIN_PROGRAM_TEXEL_OFFSET_EXT 0x8904 244 MAX_PROGRAM_TEXEL_OFFSET_EXT 0x8905 245 246Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL 247Operation) 248 249 Modify Section 2.7 "Vertex Specification", p.20 250 251 Insert before last paragraph, p.22: 252 253 The VertexAttrib* commands described so far should not be used to load 254 data for vertex attributes declared as signed or unsigned integers or 255 vectors thereof in a vertex shader. If they are used to load signed or 256 unsigned integer vertex attributes, the value in those attributes are 257 undefined. Instead use the commands 258 259 void VertexAttribI[1234]{i,ui}EXT(uint index, T values); 260 void VertexAttribI[1234]{i,ui}vEXT(uint index, T values); 261 void VertexAttribI4{b,s,ub,us}vEXT(uint index, T values); 262 263 to specify fixed-point attributes that are not converted to 264 floating-point. These attributes can be accessed in vertex shaders that 265 declare attributes as signed or unsigned integers or vectors. The 266 VertexAttribI4* commands extend the data passed in to a full signed or 267 unsigned integer. If a VertexAttribI* command is used that does not match 268 the type of the attribute declared in a vertex shader, the values in the 269 attributes are undefined. This means that the unsigned versions of the 270 VertexAttribI* commands need to be used to load data for unsigned integer 271 vertex attributes or vectors, and the signed versions of the 272 VertexAttribI* commands for signed integer vertex attributes or 273 vectors. Note that this also means that the VertexAttribI* commands should 274 not be used to load data for a vertex attribute declared as a float, float 275 vector or matrix, otherwise their values are undefined. 276 277 Insert at end of function list, p.24: 278 279 void VertexAttribIPointerEXT(uint index, int size, enum type, 280 sizei stride, const void *pointer); 281 282 (modify last paragraph, p.24) The <index> parameter in the 283 VertexAttribPointer and VertexAttribIPointerEXT commands identify the 284 generic vertex attribute array being described. The error INVALID_VALUE is 285 generated if <index> is greater than or equal to 286 MAX_VERTEX_ATTRIBS. Generic attribute arrays with integer <type> arguments 287 can be handled in one of three ways: converted to float by normalizing to 288 [0,1] or [-1,1] as specified in table 2.9, converted directly to float, or 289 left as integers. Data for an array specified by VertexAttribPointer will 290 be converted to floating-point by normalizing if the <normalized> 291 parameter is TRUE, and converted directly to floating-point 292 otherwise. Data for an array specified by VertexAttribIPointerEXT will 293 always be left as integer values. 294 295 (modify Table 2.4, p. 25) 296 Integer 297 Command Sizes Handling Types 298 ---------------------- ------- --------- ----------------- 299 VertexPointer 2,3,4 cast ... 300 NormalPointer 3 normalize ... 301 ColorPointer 3,4 normalize ... 302 SecondaryColorPointer 3 normalize ... 303 IndexPointer 1 cast ... 304 FogCoordPointer 1 n/a ... 305 TexCoordPointer 1,2,3,4 cast ... 306 EdgeFlagPointer 1 integer ... 307 VertexAttribPointer 1,2,3,4 flag ... 308 VertexAttribIPointerEXT 1,2,3,4 integer byte, ubyte, 309 short, ushort, 310 int, uint 311 312 Table 2.4: Vertex array sizes (values per vertex) and data types. The 313 "integer handling" column indicates how fixed-point data types are 314 handled: "cast" means that they converted to floating-point directly, 315 "normalize" means that they are converted to floating-point by normalizing 316 to [0,1] (for unsigned types) or [-1,1] (for signed types), "integer" 317 means that they remain as integer values, and "flag" means that either 318 "cast" or "normalized" applies, depending on the setting of the 319 <normalized> flag in VertexAttribPointer. 320 321 (modify end of pseudo-code, pp. 27-28) 322 323 for (j = 1; j < genericAttributes; j++) { 324 if (generic vertex attribute j array enabled) { 325 if (generic vertex attribute j array is a pure integer array) 326 { 327 VertexAttribI[size][type]vEXT(j, generic vertex attribute j 328 array element i); 329 } else if (generic vertex attribute j array normalization 330 flag is set and <type> is not FLOAT or DOUBLE) { 331 VertexAttrib[size]N[type]v(j, generic verex attribute j 332 array element i); 333 } else { 334 VertexAttrib[size][type]v(j, generic verex attribute j 335 array element i); 336 } 337 } 338 } 339 340 if (generic vertex attribute 0 array enabled) { 341 if (generic vertex attribute 0 array is a pure integer array) { 342 VertexAttribI[size][type]vEXT(0, generic verex attribute 0 343 array element i); 344 } else if (generic vertex attribute 0 array normalization flag 345 is set and <type> is not FLOAT or DOUBLE) { 346 VertexAttrib[size]N[type]v(0, generic verex attribute 0 347 array element i); 348 } else { 349 VertexAttrib[size][type]v(0, generic verex attribute 0 350 array element i); 351 } 352 } 353 354 Modify section 2.14.7, "Flatshading", p. 69 355 356 Add a new paragraph at the end of the section on p. 70 as follows: 357 358 If a vertex or geometry shader is active, the flat shading control 359 described so far applies to the built-in varying variables gl_FrontColor, 360 gl_BackColor, gl_FrontSecondaryColor and gl_BackSecondaryColor. Through 361 the OpenGL Shading Language varying qualifier flat any vertex attribute 362 can be flagged to be flat-shaded. See the OpenGL Shading Language 363 Specification section 4.3.6 for more information. 364 365 Modify section 2.14.8, "Color and Associated Data Clipping", p. 71 366 367 Add to the end of this section: 368 369 For vertex shader varying variables specified to be interpolated without 370 perspective correction (using the noperspective keyword), the value of t 371 used to obtain the varying value associated with P will be adjusted to 372 produce results that vary linearly in screen space. 373 374 Modify section 2.15.3, "Shader Variables", page 75 375 376 Add the following new return types to the description of GetActiveUniform 377 on p. 81. 378 379 SAMPLER_1D_ARRAY_EXT, 380 SAMPLER_2D_ARRAY_EXT, 381 SAMPLER_1D_ARRAY_SHADOW_EXT, 382 SAMPLER_2D_ARRAY_SHADOW_EXT, 383 SAMPLER_CUBE_SHADOW_EXT, 384 SAMPLER_BUFFER_EXT, 385 386 INT_SAMPLER_1D_EXT, 387 INT_SAMPLER_2D_EXT, 388 INT_SAMPLER_3D_EXT, 389 INT_SAMPLER_CUBE_EXT, 390 INT_SAMPLER_2D_RECT_EXT, 391 INT_SAMPLER_1D_ARRAY_EXT, 392 INT_SAMPLER_2D_ARRAY_EXT, 393 INT_SAMPLER_BUFFER_EXT, 394 395 UNSIGNED_INT, 396 UNSIGNED_INT_VEC2_EXT, 397 UNSIGNED_INT_VEC3_EXT, 398 UNSIGNED_INT_VEC4_EXT, 399 UNSIGNED_INT_SAMPLER_1D_EXT, 400 UNSIGNED_INT_SAMPLER_2D_EXT, 401 UNSIGNED_INT_SAMPLER_3D_EXT, 402 UNSIGNED_INT_SAMPLER_CUBE_EXT, 403 UNSIGNED_INT_SAMPLER_2D_RECT_EXT, 404 UNSIGNED_INT_SAMPLER_1D_ARRAY_EXT, 405 UNSIGNED_INT_SAMPLER_2D_ARRAY_EXT, 406 UNSIGNED_INT_SAMPLER_BUFFER_EXT. 407 408 Add the following uniform loading command prototypes on p. 81 as follows: 409 410 void Uniform{1234}uiEXT(int location, T value); 411 void Uniform{1234}uivEXT(int location, sizei count, T value); 412 413 (add the following paragraph to the description of the above 414 commands) 415 416 The Uniform*ui{v} commands will load count sets of one to four unsigned 417 integer values into a uniform location defined as a unsigned integer, an 418 unsigned integer vector, an array of unsigned integers or an array of 419 unsigned integer vectors. 420 421 (change the first sentence of the last paragraph as follows) 422 423 When loading values for a uniform declared as a Boolean, the Uniform*i{v}, 424 Uniform*ui{v} and Uniform*f{v} set of commands can be used to load boolean 425 values. 426 427 Modify section 2.15.4 Shader execution, p. 84. 428 429 Add a new section "2.15.4.1 Shader Only Texturing" before the sub- 430 section "Texture Access" on p. 85 431 432 This section describes texture functionality that is only accessible 433 through vertex, geometry or fragment shaders. Also refer to the OpenGL 434 Shading Language Specification, section 8.7 and Section 3.8 of the OpenGL 435 2.0 specification. 436 437 Note: For unextended OpenGL 2.0 and the OpenGL Shading Language version 438 1.20, all supported texture internal formats store unsigned integer values 439 but return floating-point results in the range [0, 1] and are considered 440 unsigned "normalized" integers. The ARB_texture_float extension 441 introduces floating-point internal format where components are both stored 442 and returned as floating-point values, and are not clamped. The 443 EXT_texture_integer extension introduces formats that store either signed 444 or unsigned integer values. 445 446 This extension defines additional OpenGL Shading Language texture lookup 447 functions, see section 8.7 of the OpenGL Shading Language, that return 448 either signed or unsigned integer values if the internal format of the 449 texture is signed or unsigned, respectively. 450 451 Texel Fetches 452 453 The OpenGL Shading Language texel fetch functions provide the ability to 454 extract a single texel from a specified texture image. The integer 455 coordinates passed to the texel fetch functions are used directly as the 456 texel coordinates (i, j, k) into the texture image. This in turn means the 457 texture image is point-sampled (no filtering is performed). 458 459 The level of detail accessed is computed by adding the specified 460 level-of-detail parameter <lod> to the base level of the texture, 461 level_base. 462 463 The texel fetch functions can not perform depth comparisons or access cube 464 maps. Unlike filtered texel accesses, texel fetches do not support LOD 465 clamping or any texture wrap mode, and require a mipmapped minification 466 filter to access any level of detail other than the base level. 467 468 The results of the texel fetch are undefined: 469 470 * if the computed LOD is less than the texture's base level 471 (level_base) or greater than the maximum level (level_max), 472 473 * if the computed LOD is not the texture's base level and the texture's 474 minification filter is NEAREST or LINEAR, 475 476 * if the layer specified for array textures is negative or greater than 477 the number of layers in the array texture, 478 479 * if the texel at (i,j,k) coordinates refer to a border texel outside 480 the defined extents of the specified LOD, where 481 482 i < -b_s, j < -b_s, k < -b_s, 483 i >= w_s - b_s, j >= h_s - b_s, or k >= d_s - b_s, 484 485 where the size parameters (w_s, h_s, d_s, and b_s) refer to the 486 width, height, depth, and border size of the image, as in equations 487 3.15, 3.16, and 3.17, or 488 489 . if the texture being accessed is not complete (or cube complete for 490 cubemaps). 491 492 Texture Size Query 493 494 The OpenGL Shading Language texture size functions provide the ability to 495 query the size of a texture image. The LOD value <lod> passed in as an 496 argument to the texture size functions is added to the level_base of the 497 texture to determine a texture image level. The dimensions of that image 498 level, excluding a possible border, are then returned. If the computed 499 texture image level is outside the range [level_base, level_max], the 500 results are undefined. When querying the size of an array texture, both 501 the dimensions and the layer count are returned. Note that buffer textures 502 do not support mipmapping, therefore the previous lod discussion does not 503 apply to buffer textures 504 505 Make the section "Texture Access" a subsection of 2.15.4.1 506 507 Modify the first paragraph on p. 86 as follows: 508 509 Texture lookups involving textures with depth component data can either 510 return the depth data directly or return the results of a comparison with 511 the R value (see section 3.8.14) used to perform the lookup. The 512 comparison operation is requested in the shader by using any of the shadow 513 sampler and in the texture using the TEXTURE COMPARE MODE parameter. These 514 requests must be consistent; the results of a texture lookup are undefined 515 if: 516 517 * The sampler used in a texture lookup function is not one of the 518 shadow sampler types, and the texture object's internal format is 519 DEPTH COMPONENT, and the TEXTURE COMPARE MODE is not NONE. 520 521 * The sampler used in a texture lookup function is one of the shadow 522 sampler types, and the texture object's internal format is DEPTH 523 COMPONENT, and the TEXTURE COMPARE MODE is NONE. 524 525 * The sampler used in a texture lookup function is one of the shadow 526 sampler types, and the texture object's internal format is not DEPTH 527 COMPONENT. 528 529 Add a new section "2.15.4.2 Shader Inputs" before "Position 530 Invariance" on p. 86 531 532 Besides having access to vertex attributes and uniform variables, 533 vertex shaders can access the read-only built-in variables 534 gl_VertexID and gl_InstanceID. The gl_VertexID variable holds the 535 integer index <i> implicitly passed to ArrayElement() to specify 536 the vertex. The variable gl_InstanceID holds the integer index of 537 the current primitive in an instanced draw call. See also section 538 7.1 of the OpenGL Shading Language Specification. 539 540 Add a new section "2.15.4.3 Shader Outputs" 541 542 A vertex shader can write to built-in as well as user-defined varying 543 variables. These values are expected to be interpolated across the 544 primitive it outputs, unless they are specified to be flat shaded. Refer 545 to section 2.15.3 and the OpenGL Shading Language specification sections 546 4.3.6, 7.1 and 7.6 for more detail. 547 548 The built-in output variables gl_FrontColor, gl_BackColor, 549 gl_FrontSecondaryColor, and gl_BackSecondaryColor hold the front and back 550 colors for the primary and secondary colors for the current vertex. 551 552 The built-in output variable gl_TexCoord[] is an array and holds the set 553 of texture coordinates for the current vertex. 554 555 The built-in output variable gl_FogFragCoord is used as the "c" value, as 556 described in section 3.10 "Fog" of the OpenGL 2.0 specification. 557 558 The built-in special variable gl_Position is intended to hold the 559 homogeneous vertex position. Writing gl_Position is optional. 560 561 The built-in special variable gl_ClipVertex holds the vertex coordinate 562 used in the clipping stage, as described in section 2.12 "Clipping" of the 563 OpenGL 2.0 specification. 564 565 The built in special variable gl_PointSize, if written, holds the size of 566 the point to be rasterized, measured in pixels. 567 568 Number section "Position Invariance", "Validation" and "Undefined 569 Behavior" as sections 2.15.4.4, 2.15.4.5, and 2.15.4.6 respectively. 570 571Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 572 573 Modify Section 3.8.1, Texture Image Specification, p. 150 574 575 (modify 4th paragraph, p. 151 -- add cubemaps to the list of texture 576 targets that can be used with DEPTH_COMPONENT textures) 577 578 Textures with a base internal format of DEPTH_COMPONENT are supported by 579 texture image specification commands only if <target> is TEXTURE_1D, 580 TEXTURE_2D, TEXTURE_CUBE_MAP, TEXTURE_RECTANGLE_ARB, PROXY_TEXTURE_1D, 581 PROXY_TEXTURE_2D, PROXY_TEXTURE_CUBE_MAP, or 582 PROXY_TEXTURE_RECTANGLE_ARB. Using this format in conjunction with any 583 other target will result in an INVALID_OPERATION error. 584 585 586 Delete Section 3.8.7, Texture Wrap Modes. (The language in this section 587 is folded into updates to the following section, and is no longer needed 588 here.) 589 590 591 Modify Section 3.8.8, Texture Minification: 592 593 (replace the last paragraph, p. 171): Let s(x,y) be the function that 594 associates an s texture coordinate with each set of window coordinates 595 (x,y) that lie within a primitive; define t(x,y) and r(x,y) analogously. 596 Let 597 598 u(x,y) = w_t * s(x,y) + offsetu_shader, 599 v(x,y) = h_t * t(x,y) + offsetv_shader, 600 w(x,y) = d_t * r(x,y) + offsetw_shader, and 601 602 where w_t, h_t, and d_t are as defined by equations 3.15, 3.16, and 3.17 603 with w_s, h_s, and d_s equal to the width, height, and depth of the image 604 array whose level is level_base. (offsetu_shader, offsetv_shader, 605 offsetw_shader) is the texel offset specified in the OpenGL Shading 606 Language texture lookup functions that support offsets. If the texture 607 function used does not support offsets, or for fixed-function texture 608 accesses, all three shader offsets are taken to be zero. For 609 fixed-function texture accesses, all three shader offsets are taken to be 610 zero. For a one-dimensional texture, define v(x,y) == 0 and w(x,y) === 0; 611 for two-dimensional textures, define w(x,y) == 0. 612 613 After u(x,y), v(x,y), and w(x,y) are generated, they are clamped if the 614 corresponding texture wrap modes are CLAMP or MIRROR_CLAMP_EXT. Let 615 616 u'(x,y) = clamp(u(x,y), 0, w_t), if TEXTURE_WRAP_S is CLAMP 617 clamp(u(x,y), -w_t, w_t), if TEXTURE_WRAP_S is 618 MIRROR_CLAMP_EXT, or 619 u(x,y), otherwise 620 v'(x,y) = clamp(v(x,y), 0, w_t), if TEXTURE_WRAP_T is CLAMP 621 clamp(v(x,y), -w_t, w_t), if TEXTURE_WRAP_T is 622 MIRROR_CLAMP_EXT, or 623 v(x,y), otherwise 624 w'(x,y) = clamp(w(x,y), 0, w_t), if TEXTURE_WRAP_R is CLAMP 625 clamp(w(x,y), -w_t, w_t), if TEXTURE_WRAP_R is 626 MIRROR_CLAMP_EXT, or 627 w(x,y), otherwise, 628 629 where clamp(<a>,<b>,<c>) returns <b> if <a> is less than <b>, <c> if a is 630 greater than <c>, and <a> otherwise. 631 632 (start a new paragraph with "For a polygon, rho is given at a fragment 633 with window coordinates...", and then continue with the original spec 634 text.) 635 636 (replace text starting with the last paragraph on p. 172, continuing to 637 the end of p. 174) 638 639 When lambda indicates minification, the value assigned to 640 TEXTURE_MIN_FILTER is used to determine how the texture value for a 641 fragment is selected. 642 643 When TEXTURE_MIN_FILTER is NEAREST, the texel in the image array of level 644 level_base that is nearest (in Manhattan distance) to that specified by 645 (s,t,r) is obtained. Let i, j, and k be integers such that: 646 647 i = apply_wrap(floor(u'(x,y))), 648 j = apply_wrap(floor(v'(x,y))), and 649 k = apply_wrap(floor(w'(x,y))), 650 651 where the coordinate returned by apply_wrap() is as defined by Table X.19. 652 The values of i, j, and k are then modified according to the texture wrap 653 modes, as described in Table 3.19, to produce new values (i', j', and k'). 654 For a three-dimensional texture, the texel at location (i,j,k) becomes the 655 texture value. For a two-dimensional texture, k is irrelevant, and the 656 texel at location (i,j) becomes the texture value. For a one-dimensional 657 texture, j and k are irrelevant, and the texel at location i becomes the 658 texture value. 659 660 Wrap mode Result 661 -------------------------- ------------------------------------------ 662 CLAMP_TO_EDGE clamp(coord, 0, size-1) 663 CLAMP_TO_BORDER clamp(coord, -1, size) 664 CLAMP { clamp(coord, 0, size-1), 665 { for NEAREST filtering 666 { clamp(coord, -1, size), 667 { for LINEAR filtering 668 REPEAT mod(coord, size) 669 MIRROR_CLAMP_TO_EDGE_EXT clamp(mirror(coord), 0, size-1) 670 MIRROR_CLAMP_TO_BORDER_EXT clamp(mirror(size), 0, size) 671 MIRROR_CLAMP_EXT { clamp(mirror(coord), 0, size-1), 672 { for NEAREST filtering 673 { clamp(mirror(size), 0, size), 674 { for LINEAR filtering 675 MIRRORED_REPEAT (size-1) - mirror(mod(coord, 2*size)-size) 676 677 Table X.19: Texel location wrap mode application. mod(<a>,<b>) is 678 defined to return <a>-<b>*floor(<a>/<b>), and mirror(<a>) is defined to 679 return <a> if <a> is greater than or equal to zero or -(1+<a>) 680 otherwise. The values of "wrap mode" and size are TEXTURE_WRAP_S and 681 w_t, TEXTURE_WRAP_T and h_t, and TEXTURE_WRAP_R and d_t, for i, j, and k 682 coordinates, respectively. The coordinate clamp and MIRROR_CLAMP_EXT 683 depends on the filtering mode (NEAREST or LINEAR). 684 685 If the selected (i,j,k), (i,j), or i location refers to a border texel 686 that satisfies any of the following conditions: 687 688 i < -b_s, 689 j < -b_s, 690 k < -b_s, 691 i >= w_t + b_s, 692 j >= h_t + b_s, or 693 j >= d_t + b_s, 694 695 then the border values defined by TEXTURE_BORDER_COLOR are used in place 696 of the non-existent texel. If the texture contains color components, the 697 values of TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match 698 the texture's internal format in a manner consistent with table 3.15. If 699 the texture contains depth components, the first component of 700 TEXTURE_BORDER_COLOR is interpreted as a depth value. 701 702 When TEXTURE_MIN_FILTER is LINEAR, a 2x2x2 cube of texels in the image 703 array of level level_base is selected. Let: 704 705 i_0 = apply_wrap(floor(u' - 0.5)), 706 j_0 = apply_wrap(floor(v' - 0.5)), 707 k_0 = apply_wrap(floor(w' - 0.5)), 708 i_1 = apply_wrap(floor(u' - 0.5) + 1), 709 j_1 = apply_wrap(floor(v' - 0.5) + 1), 710 k_1 = apply_wrap(floor(w' - 0.5) + 1), 711 alpha = frac(u' - 0.5), 712 beta = frac(v' - 0.5), 713 gamma = frac(w' - 0.5), 714 715 where frac(<x>) denotes the fractional part of <x>. 716 717 For a three-dimensional texture, the texture value tau is found as... 718 719 (replace last paragraph, p.174) For any texel in the equation above that 720 refers to a border texel outside the defined range of the image, the texel 721 value is taken from the texture border color as with NEAREST filtering. 722 723 modify the last paragraph of section 3.8.8, p. 175, as follows: 724 725 The rules for NEAREST or LINEAR filtering are then applied to the selected 726 array. Specifically, the coordinate (u,v,w) is computed as in equation 727 3.20a, with w_s, h_s, and d_s equal to the width, height, and depth of the 728 image array whose level is 'd'. 729 730 Modify the second paragraph on p. 176 731 732 The rules for NEAREST or LINEAR filtering are then applied to each of the 733 selected arrays, yielding two corresponding texture valutes Tau1 and 734 Tau2. Specifically, for level d1, the coordinate (u,v,w) is computed as in 735 equation 3.20a, with w_s, h_s, and d_s equal to the width, height, and 736 depth of the image array whose level is 'd1'. For level d2 the coordinate 737 (u', v', w') is computed as in equation 3.20a, with w_s, h_s, and d_s 738 equal to the width, height, and depth of the image array whose level is 739 'd2'. 740 741 Modify the first paragraph of section 3.8.9 "Texture Magnification" as 742 follows: 743 744 When lambda indicates magnification, the value assigned to 745 TEXTURE_MAG_FILTER determines how the texture value is obtained. There are 746 two possible values for TEXTURE_MAG_FILTER: NEAREST and LINEAR. NEAREST 747 behaves exactly as NEAREST for TEXTURE_MIN_FILTER and LINEAR behaves 748 exactly as LINEAR for TEXTURE_MIN_FILTER, as described in the previous 749 section, including the wrapping calculations. The level-of-detail 750 level_base texture array is always used for magnification. 751 752 Modify Section 3.8.14, Texture Comparison Modes (p. 185) 753 754 (modify 2nd paragraph, p. 188, indicating that the Q texture coordinate is 755 used for depth comparisons on cubemap textures) 756 757 Let D_t be the depth texture value, in the range [0, 1]. For 758 fixed-function texture lookups, let R be the interpolated <r> texture 759 coordinate, clamped to the range [0, 1]. For texture lookups generated by 760 an OpenGL Shading Language lookup function, let R be the reference value 761 for depth comparisons provided in the lookup function, also clamped to [0, 762 1]. Then the effective texture value L_t, I_t, or A_t is computed as 763 follows: 764 765 Modify section 3.11, Fragment Shaders, p. 193 766 767 Modify the third paragraph on p. 194 as follows: 768 769 Additionally, when a vertex shader is active, it may define one or more 770 varying variables (see section 2.15.3 and the OpenGL Shading Language 771 Specification). These values are, if not flat shaded, interpolated across 772 the primitive being rendered. The results of these interpolations are 773 available when varying variables of the same name are defined in the 774 fragment shader. 775 776 Add the following paragraph to the end of section 3.11.1, p. 194 777 778 A fragment shader can also write to varying out variables. Values written 779 to these variables are used in the subsequent per-fragment operations. 780 Varying out variables can be used to write floating-point, integer or 781 unsigned integer values destined for buffers attached to a framebuffer 782 object, or destined for color buffers attached to the default 783 framebuffer. The subsection 'Shader Outputs' of the next section describes 784 API how to direct these values to buffers. 785 786 Add a new paragraph at the beginning of the section "Texture 787 Access", p. 194 788 789 Section 2.15.4.1 describes texture lookup functionality accessible to a 790 vertex shader. The texel fetch and texture size query functionality 791 described there also applies to fragment shaders. 792 793 Modify the second paragraph on p. 195 as follows: 794 795 Texture lookups involving textures with depth component data can either 796 return the depth data directly or return the results of a comparison with 797 the R value (see section 3.8.14) used to perform the lookup. The 798 comparison operation is requested in the shader by using any of the shadow 799 sampler and in the texture using the TEXTURE COMPARE MODE parameter. These 800 requests must be consistent; the results of a texture lookup are undefined 801 if: 802 803 * The sampler used in a texture lookup function is not one of the 804 shadow sampler types, and the texture object's internal format is 805 DEPTH COMPONENT, and the TEXTURE COMPARE MODE is not NONE. 806 807 * The sampler used in a texture lookup function is one of the shadow 808 sampler types, and the texture object's internal format is DEPTH 809 COMPONENT, and the TEXTURE COMPARE MODE is NONE. 810 811 * The sampler used in a texture lookup function is one of the shadow 812 sampler types, and the texture object's internal format is not DEPTH 813 COMPONENT. 814 815 Add the following paragraph to the section Shader Inputs, p. 196 816 817 If a geometry shader is active, the built-in variable gl_PrimitiveID 818 contains the ID value emitted by the geometry shader for the provoking 819 vertex. If no geometry shader is active, gl_PrimitiveID is filled with the 820 number of primitives processed by the rasterizer since the last time Begin 821 was called (directly or indirectly via vertex array functions). The first 822 primitive generated after a Begin is numbered zero, and the primitive ID 823 counter is incremented after every individual point, line, or polygon 824 primitive is processed. For polygons drawn in point or line mode, the 825 primitive ID counter is incremented only once, even though multiple points 826 or lines may be drawn. For QUADS and QUAD_STRIP primitives that are 827 decomposed into triangles, the primitive ID is incremented after each 828 complete quad is processed. For POLYGON primitives, the primitive ID 829 counter is undefined. The primitive ID is undefined for fragments 830 generated by DrawPixels or Bitmap. Restarting a primitive topology using 831 the primitive restart index has no effect on the primitive ID counter. 832 833 Modify the first paragraph of the section Shader Outputs, p. 196 as 834 follows 835 836 The OpenGL Shading Language specification describes the values that may be 837 output by a fragment shader. These outputs are split into two 838 categories. User-defined varying out variables and built-in variables. The 839 built-in variables are gl_FragColor, gl_FragData[n], and gl_FragDepth. If 840 fragment clamping is enabled, the final fragment color values or the final 841 fragment data values or the final varying out variable values written by a 842 fragment shader are clamped to the range [0,1] and then may be converted 843 to fixed-point as described in section 2.14.9. Only user-defined varying 844 out variables declared as a floating-point type are clamped and may be 845 converted. If fragment clamping is disabled, the final fragment color 846 values or the final fragment data values or the final varying output 847 variable values are not modified. The final fragment depth written... 848 849 Modify the second paragraph of the section Shader Outputs, p. 196 850 as follows 851 852 ...A fragment shader may not statically assign values to more than one of 853 gl_FragColor, gl_FragData or any user-defined varying output variable. In 854 this case, a compile or link error will result. A shader statically... 855 856 Add the following to the end of the section Shader Outputs, p. 197 857 858 The values of user-defined varying out variables are directed to a color 859 buffer in a two step process. First the varying out variable is bound to a 860 fragment color by using its number. The GL will assign a number to each 861 varying out variable, unless overridden by the command 862 BindFragDataLocationEXT(). The number of the fragment color assigned for 863 each user-defined varying out variable can be queried with 864 GetFragDataLocationEXT(). Next, the DrawBuffer or DrawBuffers commands (see 865 section 4.2.1) direct each fragment color to a particular buffer. 866 867 The binding of a user-defined varying out variable to a fragment color 868 number can be specified explicitly. The command 869 870 void BindFragDataLocationEXT(uint program, uint colorNumber, 871 const char *name); 872 873 specifies that the varying out variable name in program should be bound to 874 fragment color colorNumber when the program is next linked. If name was 875 bound previously, its assigned binding is replaced with colorNumber. name 876 must be a null terminated string. The error INVALID_VALUE is generated if 877 colorNumber is equal or greater than MAX_DRAW_BUFFERS. 878 BindFragDataLocationEXT has no effect until the program is linked. In 879 particular, it doesn't modify the bindings of varying out variables in a 880 program that has already been linked. The error INVALID OPERATION is 881 generated if name starts with the reserved "gl_" prefix. 882 883 When a program is linked, any varying out variables without a binding 884 specified through BindFragDataLocationEXT will automatically be bound to 885 fragment colors by the GL. Such bindings can be queried using the command 886 GetFragDataLocationEXT. LinkProgram will fail if the assigned binding of a 887 varying out variable would cause the GL to reference a non-existant 888 fragment color number (one greater than or equal to MAX DRAW_BUFFERS). 889 LinkProgram will also fail if more than one varying out variable is bound 890 to the same number. This type of aliasing is not allowed. 891 892 BindFragDataLocationEXT may be issued before any shader objects are 893 attached to a program object. Hence it is allowed to bind any name (except 894 a name starting with "gl_") to a color number, including a name that is 895 never used as a varying out variable in any fragment shader 896 object. Assigned bindings for variables that do not exist are ignored. 897 898 After a program object has been linked successfully, the bindings of 899 varying out variable names to color numbers can be queried. The command 900 901 int GetFragDataLocationEXT(uint program, const char *name); 902 903 returns the number of the fragment color that the varying out variable 904 name was bound to when the program object program was last linked. name 905 must be a null terminated string. If program has not been successfully 906 linked, the error INVALID OPERATION is generated. If name is not a varying 907 out variable, or if an error occurs, -1 will be returned. 908 909Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 910Operations and the Frame Buffer) 911 912 Modify Section 4.2.1, Selecting a Buffer for Writing (p. 212) 913 914 (modify next-to-last paragraph, p. 213) If a fragment shader writes to 915 gl_FragColor, DrawBuffers specifies a set of draw buffers into which the 916 single fragment color defined by gl_FragColor is written. If a fragment 917 shader writes to gl_FragData or a user-defined varying out variable, 918 DrawBuffers specifies a set of draw buffers into which each of the 919 multiple output colors defined by these variables are separately written. 920 If a fragment shader writes to neither gl_FragColor, nor gl FragData, nor 921 any user-defined varying out variables, the values of the fragment colors 922 following shader execution are undefined, and may differ for each fragment 923 color. 924 925Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 926 927 Change section 5.4 Display Lists, p. 237 928 929 Add the commands VertexAttribIPointerEXT and BindFragDataLocationEXT to 930 the list of commands that are not compiled into a display list, but 931 executed immediately, under "Program and Shader Objects", p. 241 932 933Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State 934Requests) 935 936 Modify section 6.1.14 "Shader and Program Queries", p. 256 937 938 Modify 2nd paragraph, p.259: 939 940 Add the following to the list of GetVertexAttrib* commands: 941 942 void GetVertexAttribIivEXT(uint index, enum pname, int *params); 943 void GetVertexAttribIuivEXT(uint index, enum pname, uint *params); 944 945 obtain the... <pname> must be one of VERTEX_ATTRIB_ARRAY_ENABLED ,., 946 VERTEX_ATTRIB_ARRAY_NORMALIZED, VERTEX_ATTRIB_ARRAY_INTEGER_EXT, or 947 CURRENT_VERTEX_ATTRIB. ... 948 949 Split 3rd paragraph, p.259 950 951 ... The size, stride, type, normalized flag, and unconverted integer flag 952 are set by the commands VertexAttribPointer and VertexAttribIPointerEXT. 953 The normalized flag is always set to FALSE by by VertexAttribIPointerEXT. 954 The unconverted integer flag is always set to FALSE by VertexAttribPointer 955 and TRUE by VertexAttribIPointerEXT. 956 957 The query CURRENT_VERTEX_ATTRIB returns the current value for the generic 958 attribute <index>. GetVertexAttribdv and GetVertexAttribfv read and 959 return the current attribute values as floating-point values; 960 GetVertexAttribiv reads them as floating-point values and converts them 961 to integer values; GetVertexAttribIivEXT reads and returns them as 962 integers; GetVertexAttribIuivEXT reads and returns them as unsigned 963 integers. The results of the query are undefined if the current attribute 964 values are read using one data type but were specified using a different 965 one. The error INVALID_OPERATION is generated if <index> is zero. 966 967 Change the prototypes in the first paragraph on page 260 as 968 follows: 969 970 void GetUniformfv(uint program, int location, float *params); 971 void GetUniformiv(uint program, int location, int *params); 972 void GetUniformuivEXT(uint program, int location, uint *params); 973 974Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 975 976 None. 977 978Additions to the AGL/GLX/WGL Specifications 979 980 None. 981 982Interactions with GL_ARB_color_buffer_float 983 984 If the GL_ARB_color_buffer_float extension is not supported then any 985 reference to fragment clamping in section 3.11.2 "Shader Execution" needs 986 to be deleted. 987 988Interactions with GL_ARB_texture_rectangle 989 990 If the GL_ARB_texture_rectangle extension is not supported then all 991 references to texture lookup functions with 'Rect' in the name need to be 992 deleted. 993 994Interactions with GL_EXT_texture_array 995 996 If the GL_EXT_texture_array extension is not supported, all references to 997 one- and two-dimensional array texture sampler types (e.g., 998 sampler1DArray, sampler2DArray) and the texture lookup functions that use 999 them need to be deleted. 1000 1001Interactions with GL_EXT_geometry_shader4 1002 1003 If the GL_EXT_geometry_shader4 extension is not supported, all references 1004 to a geometry shader need to be deleted. 1005 1006Interactions with GL_NV_primitive_restart 1007 1008 The spec describes the behavior that primitive restart does not affect the 1009 primitive ID counter, including for POLYGON primitives (where one could 1010 argue that the restart index starts a new primitive without a new Begin to 1011 reset the count). If NV_primitive_restart is not supported, references to 1012 that extension in the discussion of the primitive ID counter should be 1013 removed. 1014 1015 If NV_primitive_restart is supported, index values causing a primitive 1016 restart are not considered as specifying an End command, followed by 1017 another Begin. Primitive restart is therefore not guaranteed to 1018 immediately update material properties when a vertex shader is active. The 1019 spec language on p.64 of the OpenGL 2.0 specification says "changes are 1020 not guaranteed to update material parameters, defined in table 2.11, until 1021 the following End command." 1022 1023Interactions with EXT_texture_integer 1024 1025 If the EXT_texture_integer spec is not supported, the discussion about 1026 this spec in section 2.15.4.1 needs to be removed. All texture lookup 1027 functions that return integers or unsigned integers, as discussed in 1028 section 8.7 of the OpenGL Shading Language specification, also need to be 1029 removed. 1030 1031Interactions with EXT_texture_buffer_object 1032 1033 If EXT_texture_buffer_object is not supported, references to buffer 1034 textures, as well as the texelFetchBuffer and texelSizeBuffer lookup 1035 functions and samplerBuffer types, need to be removed. 1036 1037Interactions with EXT_draw_instanced 1038 1039 If EXT_draw_instanced is not supported, the value of gl_InstanceID 1040 is always zero. 1041 1042GLX Protocol 1043 1044 The following rendering commands are sent to the server as part of a 1045 glXRender request: 1046 1047 Uniform1uiEXT 1048 1049 2 12 rendering command length 1050 2 269 rendering command opcode 1051 4 INT32 location 1052 4 CARD32 v0 1053 1054 Uniform2uiEXT 1055 1056 2 16 rendering command length 1057 2 270 rendering command opcode 1058 4 INT32 location 1059 4 CARD32 v0 1060 4 CARD32 v1 1061 1062 Uniform3uiEXT 1063 1064 2 20 rendering command length 1065 2 271 rendering command opcode 1066 4 INT32 location 1067 4 CARD32 v0 1068 4 CARD32 v1 1069 4 CARD32 v2 1070 1071 Uniform4uiEXT 1072 1073 2 24 rendering command length 1074 2 272 rendering command opcode 1075 4 INT32 location 1076 4 CARD32 v0 1077 4 CARD32 v1 1078 4 CARD32 v2 1079 4 CARD32 v3 1080 1081 BindFragDataLocationEXT 1082 1083 2 12+n+p rendering command length 1084 2 273 rendering command opcode 1085 4 CARD32 program 1086 4 CARD32 color 1087 n LISTofBYTE name, n = strlen(name) + 1 1088 p padding, p=pad(n) 1089 1090 The following rendering commands are sent sent to the server as part 1091 of a glXRender request or as a glXRenderLarge request. 1092 1093 Uniform1uivEXT 1094 1095 2 12+count*4 rendering command length 1096 2 274 rendering command opcode 1097 4 INT32 location 1098 4 CARD32 count 1099 4*count LISTofCARD32 value 1100 1101 If the command is encoded in a glXRenderLarge request, the 1102 command opcode and command length fields above are expanded to 1103 4 bytes each: 1104 1105 4 16+count*4 rendering command length 1106 4 274 rendering command opcode 1107 1108 Uniform2uivEXT 1109 1110 2 12+count*4*2 rendering command length 1111 2 275 rendering command opcode 1112 4 INT32 location 1113 4 CARD32 count 1114 2*4*count LISTofCARD32 value 1115 1116 If the command is encoded in a glXRenderLarge request, the 1117 command opcode and command length fields above are expanded to 1118 4 bytes each: 1119 1120 4 16+count*4*2 rendering command length 1121 4 275 rendering command opcode 1122 1123 Uniform3uivEXT 1124 1125 2 12+count*4*3 rendering command length 1126 2 276 rendering command opcode 1127 4 INT32 location 1128 4 CARD32 count 1129 3*4*count LISTofCARD32 value 1130 1131 If the command is encoded in a glXRenderLarge request, the 1132 command opcode and command length fields above are expanded to 1133 4 bytes each: 1134 1135 4 16+count*4 rendering command length 1136 4 276 rendering command opcode 1137 1138 Uniform4uivEXT 1139 1140 2 12+count*4*4 rendering command length 1141 2 277 rendering command opcode 1142 4 INT32 location 1143 4 CARD32 count 1144 4*4*count LISTofCARD32 value 1145 1146 If the command is encoded in a glXRenderLarge request, the 1147 command opcode and command length fields above are expanded to 1148 4 bytes each: 1149 1150 4 16+count*4*4 rendering command length 1151 4 277 rendering command opcode 1152 1153 The following non-rendering commands are added. 1154 1155 GetUniformuivEXT 1156 1157 1 CARD8 opcode (X assigned) 1158 1 182 GLX opcode 1159 2 4 request length 1160 4 GLX_CONTEXT_TAG context tag 1161 4 CARD32 program 1162 4 INT32 location 1163 => 1164 1 1 reply 1165 1 unused 1166 2 CARD16 sequence number 1167 4 m reply length, m = (n == 1 ? 0 : n) 1168 4 CARD32 unused 1169 4 CARD32 n 1170 1171 if (n = 1) this follows: 1172 1173 4 CARD32 params 1174 12 unused 1175 1176 otherwise this follows: 1177 1178 16 CARD32 unused 1179 4*n CARD32 params 1180 1181 Note that n may be zero, indicating that a GL error occured. 1182 1183 GetFragDataLocationEXT 1184 1185 1 CARD8 opcode (X assigned) 1186 1 183 GLX opcode 1187 2 3+(n+p)/4 request length 1188 4 GLX_CONTEXT_TAG context tag 1189 4 CARD32 program 1190 n LISTofBYTE name, n = strlen(name) + 1 1191 p padding, p=pad(n) 1192 => 1193 1 1 reply 1194 1 unused 1195 2 CARD16 sequence number 1196 4 0 reply length 1197 4 CARD32 retval 1198 20 unused 1199 1200 GLX protocol for following commands is defined in the 1201 NV_vertex_program4 extension: 1202 1203 VertexAttribI1iEXT, VertexAttribI2iEXT, VertexAttribI3iEXT, 1204 VertexAttribI4iEXT, VertexAttribI1uiEXT, VertexAttribI2uiEXT, 1205 VertexAttribI3uiEXT, VertexAttribI4uiEXT, VertexAttribI1ivEXT, 1206 VertexAttribI2ivEXT, VertexAttribI3ivEXT, VertexAttribI4ivEXT, 1207 VertexAttribI1uivEXT, VertexAttribI2uivEXT, VertexAttribI3uivEXT, 1208 VertexAttribI4uivEXT, VertexAttribI4bvEXT, VertexAttribI4svEXT, 1209 VertexAttribI4ubvEXT, VertexAttribI4usvEXT, GetVertexAttribIivEXT, 1210 GetVertexAttribIuivEXT 1211 1212 VertexAttribIPointerEXT is an entirely client-side command. 1213 1214Errors 1215 1216 The error INVALID_VALUE is generated by BindFragDataLocationEXT() if 1217 colorNumber is equal or greater than MAX_DRAW_BUFFERS. 1218 1219 The error INVALID OPERATION is generated by BindFragDataLocationEXT() if 1220 name starts with the reserved "gl_" prefix. 1221 1222 The error INVALID_OPERATION is generated by BindFragDataLocationEXT() or 1223 GetFragDataLocationEXT if program is not the name of a program object. 1224 1225 The error INVALID_OPERATION is generated by GetFragDataLocationEXT() if 1226 program has not been successfully linked. 1227 1228New State 1229 1230 (add to table 6.7, p. 268) 1231 Initial 1232 Get Value Type Get Command Value Description Sec. Attribute 1233 --------- ---- --------------- ------- -------------------- ---- --------- 1234 VERTEX_ATTRIB_ARRAY 16+xB GetVertexAttrib FALSE vertex attrib array 2.8 vertex-array 1235 INTEGER_EXT has unconverted ints 1236 1237New Implementation Dependent State 1238 1239 Minimum 1240 Get Value Type Get Command Value Description Sec. Attrib 1241 -------------------------------- ---- --------------- ------- --------------------- ------ ------ 1242 MIN_PROGRAM_TEXEL_OFFSET_EXT Z GetIntegerv -8 minimum texel offset 2.x.4.4 - 1243 allowed in lookup 1244 MAX_PROGRAM_TEXEL_OFFSET_EXT Z GetIntegerv +7 maximum texel offset 2.x.4.4 - 1245 allowed in lookup 1246 1247Modifications to The OpenGL Shading Language Specification, Version 1.10.59 1248 1249 Including the following line in a shader can be used to control the 1250 language features described in this extension: 1251 1252 #extension GL_EXT_gpu_shader4 : <behavior> 1253 1254 where <behavior> is as specified in section 3.3. 1255 1256 A new preprocessor #define is added to the OpenGL Shading Language: 1257 1258 #define GL_EXT_gpu_shader4 1 1259 1260 Add to section 3.6 "Keywords" 1261 1262 Add the following keywords: 1263 1264 noperspective, flat, centroid 1265 1266 Remove the unsigned keyword from the list of keywords reserved for future 1267 use, and add it to the list of keywords. 1268 1269 The following new vector types are added: 1270 1271 uvec2, uvec3, uvec4 1272 1273 The following new sampler types are added: 1274 1275 sampler1DArray, sampler2DArray, sampler1DArrayShadow, 1276 sampler2DArrayShadow, samplerCubeShadow 1277 1278 isampler1D, isampler2D, isampler3D, isamplerCube, isampler2DRect, 1279 isampler1DArray, isampler2DArray 1280 1281 usampler1D, usampler2D, usampler3D, usamplerCube, usampler2DRect, 1282 usampler1DArray, usampler2DArray 1283 1284 samplerBuffer, isamplerBuffer, usamplerBuffer 1285 1286 Add to section 4.1 "Basic Types" 1287 1288 Break the table in this section up in several tables. The first table 1289 4.1.1 is named "scalar, vector and matrix data types". It includes the 1290 first row through the 'mat4" row. 1291 1292 Add the following to the first section of this table: 1293 1294 unsigned int An unsigned integer 1295 uvec2 A two-component unsigned integer vector 1296 uvec3 A three-component unsigned integer vector 1297 uvec4 A four-component unsigned integer vector 1298 1299 Break out the sampler types in a separate table, and name that table 4.1.2 1300 "default sampler types". Add the following sampler types to this new 1301 table: 1302 1303 sampler1DArray handle for accessing a 1D array texture 1304 sampler2DArray handle for accessing a 2D array texture 1305 sampler1DArrayShadow handle for accessing a 1D array depth texture 1306 with comparison 1307 sampler2DArrayShadow handle for accessing a 2D array depth texture 1308 with comparison 1309 samplerBuffer handle for accessing a buffer texture 1310 1311 Add a table 4.1.3 called "integer sampler types": 1312 1313 isampler1D handle for accessing an integer 1D texture 1314 isampler2D handle for accessing an integer 2D texture 1315 isampler3D handle for accessing an integer 3D texture 1316 isamplerCube handle for accessing an integer cube map texture 1317 isampler2DRect handle for accessing an integer rectangle texture 1318 isampler1DArray handle for accessing an integer 1D array texture 1319 isampler2DArray handle for accessing an integer 2D array texture 1320 isamplerBuffer handle for accessing an integer buffer texture 1321 1322 Add a table 4.1.4 called "unsigned integer sampler types": 1323 1324 usampler1D handle for accessing an unsigned integer 1325 1D texture 1326 usampler2D handle for accessing an unsigned integer 1327 2D texture 1328 usampler3D handle for accessing an unsigned integer 1329 3D texture 1330 usamplerCube handle for accessing an unsigned integer 1331 cube map texture 1332 usampler2DRect handle for accessing an unsigned integer 1333 rectangle texture 1334 usampler1DArray handle for accessing an unsigned integer 1D 1335 array texture 1336 usampler2DArray handle for accessing an unsigned integer 2D 1337 array texture 1338 usamplerBuffer handle for accessing an unsigned integer 1339 buffer texture 1340 1341 Change section 4.1.3 "Integers" 1342 1343 Remove the first two paragraphs and replace with the following: 1344 1345 Signed, as well as unsigned integers, are fully supported. Integers hold 1346 whole numbers. Integers have at least 32 bits of precision, including a 1347 sign bit. Signed integers are stored using a two's complement 1348 representation. 1349 1350 Integers are declared and optionally initialized with integer expressions 1351 as in the following example: 1352 1353 int i, j = 42; 1354 unsigned int k = 3u; 1355 1356 Literal integer constants can be expressed in decimal (base 10), octal 1357 (base 8), or hexadecimal (base 16) as follows. 1358 1359 integer-constant: 1360 decimal-constant integer-suffix_opt 1361 octal-constant integer-suffix_opt 1362 hexadecimal-constant integer-suffix_opt 1363 1364 integer-suffix: one of 1365 u U 1366 1367 Change section 4.3 "Type Qualifiers" 1368 1369 Change the "varying" and "out" qualifier as follows: 1370 1371 varying - linkage between a vertex shader and fragment shader, or between 1372 a fragment shader and the back end of the OpenGL pipeline. 1373 1374 out - for function parameters passed back out of a function, but not 1375 initialized for use when passed in. Also for output varying variables 1376 (fragment only). 1377 1378 In the qualifier table, add the following sub-qualifiers under the varying 1379 qualifier: 1380 1381 flat varying 1382 noperspective varying 1383 centroid varying 1384 1385 Change section 4.3.4 "Attribute" 1386 1387 Change the sentence: 1388 1389 The attribute qualifier can be used only with the data types float, vec2, 1390 vec3, vec4, mat2, mat3, and mat4. 1391 1392 To: 1393 1394 The attribute qualifier can be used only with the data types int, ivec2, 1395 ivec3, ivec4, unsigned int, uvec2, uvec3, uvec4, float, vec2, vec3, vec4, 1396 mat2, mat3, and mat4. 1397 1398 Change the fourth paragraph to: 1399 1400 It is expected that graphics hardware will have a small number of fixed 1401 locations for passing vertex attributes. Therefore, the OpenGL Shading 1402 language defines each non-matrix attribute variable as having space for up 1403 to four integer or floating-point values (i.e., a vec4, ivec4 or 1404 uvec4). There is an implementation dependent limit on the number of 1405 attribute variables that can be used and if this is exceeded it will cause 1406 a link error. (Declared attribute variables that are not used do not count 1407 against this limit.) A scalar attribute counts the same amount against 1408 this limit as a vector of size four, so applications may want to consider 1409 packing groups of four unrelated scalar attributes together into a vector 1410 to better utilize the capabilities of the underlying hardware. A mat4 1411 attribute will... 1412 1413 Change section 4.3.6 "Varying" 1414 1415 Change the first paragraph to: 1416 1417 Varying variables provide the interface between the vertex shader, the 1418 fragment shader, and the fixed functionality between the vertex and 1419 fragment shader, as well as the interface from the fragment shader to the 1420 back-end of the OpenGL pipeline. 1421 1422 The vertex shader will compute values per vertex (such as color, texture 1423 coordinates, etc.) and write them to variables declared with the varying 1424 qualifier. A vertex shader may also read varying variables, getting back 1425 the same values it has written. Reading a varying variable in a vertex 1426 shader returns undefined values if it is read before being written. 1427 1428 The fragment shader will compute values per fragment and write them to 1429 variables declared with the varying out qualifier. A fragment shader may 1430 also read varying variables, getting back the same result it has 1431 written. Reading a varying variable in a fragment shader returns undefined 1432 values if it is read before being written. 1433 1434 Varying variables may be written more than once. If so, the last value 1435 assigned is the one used. 1436 1437 Change the second paragraph to: 1438 1439 Varying variables that are set per vertex are interpolated by default in a 1440 perspective-correct manner over the primitive being rendered, unless the 1441 varying is further qualified with noperspective. Interpolation in a 1442 perspective correct manner is specified in equations 3.6 and 3.8 in the 1443 OpenGL 2.0 specification. When noperspective is specified, interpolation 1444 must be linear in screen space, as described in equation 3.7 and the 1445 approximation that follows equation 3.8. 1446 1447 If single-sampling, the value is interpolated to the pixel's center, and 1448 the centroid qualifier, if present, is ignored. If multi-sampling, and the 1449 varying is not qualified with centroid, then the value must be 1450 interpolated to the pixel's center, or anywhere within the pixel, or to 1451 one of the pixel's samples. If multi-sampling and the varying is qualified 1452 with centroid, then the value must be interpolated to a point that lies in 1453 both the pixel and in the primitive being rendered, or to one of the 1454 pixel's samples that falls within the primitive. 1455 1456 [NOTE: Language for centroid sampling taken from the GLSL 1.20.4 1457 specification] 1458 1459 Varying variables, set per vertex, can be computed on a per-primitive 1460 basis (flat shading), or interpolated over a line or polygon primitive 1461 (smooth shading). By default, a varying variable is smooth shaded, unless 1462 the varying is further qualified with flat. When smooth shading, the 1463 varying is interpolated over the primitive. When flat shading, the varying 1464 is constant over the primitive, and is taken from the single provoking 1465 vertex of the primitive, as described in Section 2.14.7 of the OpenGL 2.0 1466 specification. 1467 1468 Change the fourth paragraph to: 1469 1470 The type and any qualifications (flat, noperspective, centroid) of varying 1471 variables with the same name declared in both the vertex and fragment 1472 shaders must match, otherwise the link command will fail. Note that 1473 built-in varying variables, which have names starting with "gl_", can not 1474 be further qualified with flat, noperspective or centroid. The flat 1475 keyword cannot be used together with either the noperspective or centroid 1476 keywords to further qualify a single varying variable, otherwise a compile 1477 error will occur. When using the keywords centroid, flat or noperspective, 1478 it must immediately precede the varying keyword. When using both centroid 1479 and noperspective keywords, either one can be specified first. Only those 1480 varying variables used (i.e. read) in the fragment shader must be written 1481 to by the vertex shader; declaring superfluous varying variables in the 1482 vertex shader is permissible. Varying out variables, set per fragment, can 1483 not be further qualified with flat, noperspective or centroid. 1484 1485 Fragment shaders output values to the back-end of the OpenGL pipeline 1486 using either user-defined varying out variables or built-in variables, as 1487 described in section 7.2, unless the discard keyword is executed. If the 1488 back-end of the OpenGL pipeline consumes a user-defined varying out 1489 variable and an execution of a fragment shader does not write a value to 1490 that variable, then the value consumed is undefined. If the back-end of 1491 the OpenGL pipeline consumes a varying out variable and a fragment shader 1492 either writes values into less components of the variable, or if the 1493 variable is declared to have less components, than needed, the values of 1494 the missing component(s) are undefined. The OpenGL specification, section 1495 3.x.x, describes API to route varying output variables to color buffers. 1496 1497 Add the following examples: 1498 1499 noperspective varying float temperature; 1500 flat varying vec3 myColor; 1501 centroid varying vec2 myTexCoord; 1502 centroid noperspective varying vec2 myTexCoord; 1503 varying out ivec3 foo; 1504 1505 Change the third paragraph on p. 25 as follows: 1506 1507 The "varying" qualifier can be used only with the data types float, vec2, 1508 vec3, vec4, mat2, mat3, and mat4, int, ivec2, ivec3, ivec4, unsigned int, 1509 uvec2, uvec3, uvec4 or arrays of these. Structures cannot be varying. If 1510 the varying is declared as one of the integer or unsigned integer data 1511 type variants, then it has to also be qualified as being flat shaded, 1512 otherwise a compile error will occur. 1513 1514 The "varying out" qualifier can be used only with the data types float, 1515 vec2, vec3, vec4, int, ivec2, ivec3, ivec4, unsigned int, uvec2, uvec3 or 1516 uvec4. Structures or arrays cannot be declared as varying out. 1517 1518 Change section 5.1 "Operators" 1519 1520 Remove the "reserved" qualifications from the following operator 1521 precedence table entries: 1522 1523 Precedence Operator class 1524 ---------- ----------------------------------- 1525 3 (tilde is reserved) 1526 4 (modulus reserved) 1527 6 bit-wise shift (reserved) 1528 9 bit-wise and (reserved) 1529 10 bit-wise exclusive or (reserved) 1530 11 bit-wise inclusive or (reserved) 1531 16 (modulus, shift, and bit-wise are reserved) 1532 1533 Change section 5.8 "Assignments" 1534 1535 Change the first bullet from: 1536 1537 * The arithmetic assignments add into (+=).. 1538 1539 To: 1540 1541 * The arithmetic assignments add into (+=), subtract from (- 1542 =), multiply into (*=), and divide into (/=) as well as the 1543 assignments modulus into (%=), left shift by (<<=), right 1544 shift by (>>=), and into (&=), inclusive or into (|=), 1545 exclusive or into (^=). The expression 1546 1547 Delete the last bullet in this paragraph. 1548 1549 Remove the second bullet in the section starting with: The assignments 1550 modulus into.. 1551 1552 Change section 5.9 "Expressions" 1553 1554 Change the bullet: The operator modulus (%) is reserved for future 1555 use to: 1556 1557 * The arithmetic operator % that operates on signed or unsigned integer 1558 typed expressions (including vectors). The two operands must be of the 1559 same type, or one can be a signed or unsigned integer scalar and the 1560 other a signed or unsigned integer vector. If the second operand is 1561 zero, results are undefined. If one operand is scalar and the other is a 1562 vector, the scalar is applied component-wise to the vector, resulting in 1563 the same type as the vector. If both operands are non-negative, then the 1564 remainder is non-negative. Results are undefined if one, or both, 1565 operands are negative. 1566 1567 Change the last bullet: "Operators and (&), or (|), exclusive or (^), not 1568 (~), right-shift (>>), left shift (<<). These operators are reserved for 1569 future use." To the following bullets: 1570 1571 * The one's complement operator ~. The operand must be of type signed or 1572 unsigned integer (including vectors), and the result is the one's 1573 complement of its operand. If the operand is a vector, the operator is 1574 applied component-wise to the vector. If the operand is unsigned, the 1575 result is computed by subtracting the value from the largest unsigned 1576 integer value. If the operand is signed, the result is computed by 1577 converting the operand to an unsigned integer, applying ~, and 1578 converting back to a signed integer. 1579 1580 * The shift operators << and >>. For both operators, the operands must be 1581 of type signed or unsigned integer (including vectors). If the first 1582 operand is a scalar, the second operand has to be a scalar as well. The 1583 result is undefined if the right operand is negative, or greater than or 1584 equal to the number of bits in the left expression's type. The value of 1585 E1 << E2 is E1 (interpreted as a bit pattern) left-shifted by E2 1586 bits. The value of E1 >> E2 is E1 right-shifted by E2 bit positions. If 1587 E1 is a signed integer, the right-shift will extend the sign bit. If E1 1588 is an unsigned integer, the right-shift will zero-extend. 1589 1590 * The bitwise AND operator &. The operands must be of type signed or 1591 unsigned integer (including vectors). The two operands must be of the 1592 same type, or one can be a signed or unsigned integer scalar and the 1593 other a signed or unsigned integer vector. If one operand is a scalar 1594 and the other a vector, the scalar is applied component-wise to the 1595 vector, resulting in the same type as the vector. The result is the 1596 bitwise AND function of the operands. 1597 1598 * The bitwise exclusive OR operator ^. The operands must be of type signed 1599 or unsigned integer (including vectors). The two operands must be of the 1600 same type, or one can be a signed or unsigned integer scalar and the 1601 other a signed or unsigned integer vector. If one operand is a scalar 1602 and the other a vector, the scalar is applied component-wise to the 1603 vector, resulting in the same type as the vector. The result is the 1604 bitwise exclusive OR function of the operands. 1605 1606 * The bitwise inclusive OR operator |. The operands must be of type signed 1607 or unsigned integer (including vectors). The two operands must be of the 1608 same type, or one can be a signed or unsigned integer scalar and the 1609 other a signed or unsigned integer vector. If one operand is a scalar 1610 and the other a vector, the scalar is applied component-wise to the 1611 vector, resulting in the same type as the vector. The result is the 1612 bitwise inclusive OR function of the operands. 1613 1614 Change Section 7.1 "Vertex Shader Special Variables" 1615 1616 Add the following definition to the list of built-in variable definitions: 1617 1618 int gl_VertexID // read-only 1619 int gl_InstanceID // read-only 1620 1621 Add the following paragraph at the end of the section: 1622 1623 The variable gl_VertexID is available as a read-only variable from within 1624 vertex shaders and holds the integer index <i> implicitly passed to 1625 ArrayElement() to specify the vertex. The value of gl_VertexID is defined 1626 if and only if: 1627 1628 * the vertex comes from a vertex array command that specifies a complete 1629 primitive (e.g. DrawArrays, DrawElements), 1630 1631 * all enabled vertex arrays have non-zero buffer object bindings, and 1632 1633 * the vertex does not come from a display list, even if the display list 1634 was compiled using DrawArrays / DrawElements with data sourced from 1635 buffer objects. 1636 1637 The variable gl_InstanceID is availale as a read-only variable from within 1638 vertex shaders and holds holds the integer index of the current primitive 1639 in an instanced draw call (DrawArraysInstancedEXT, 1640 DrawElementsInstancedEXT). If the current primitive does not come from an 1641 instanced draw call, the value of gl_InstanceID is zero. 1642 1643 Change Section 7.2 "Fragment Shader Special Variables" 1644 1645 Change the 8th and 9th paragraphs on p. 43 as follows: 1646 1647 If a shader statically assigns a value to gl_FragColor, it may not assign 1648 a value to any element of gl_FragData nor to any user-defined varying 1649 output variable (section 4.3.6). If a shader statically writes a value to 1650 any element of gl_FragData, it may not assign a value to gl_FragColor nor 1651 to any user-defined varying output variable. That is, a shader may assign 1652 values to either gl_FragColor, gl_FragData, or any user-defined varying 1653 output variable, but not to a combination of the three options. 1654 1655 If a shader executes the discard keyword, the fragment is discarded, and 1656 the values of gl_FragDepth, gl_FragColor, gl_FragData and any user-defined 1657 varying output variables become irrelevant. 1658 1659 Add the following paragraph to the top of p. 44: 1660 1661 The variable gl_PrimitiveID is available as a read-only variable from 1662 within fragment shaders and holds the id of the currently processed 1663 primitive. Section 3.11, subsection "Shader Inputs" of the OpenGL 2.0 1664 specification describes what value it holds based on the primitive type. 1665 1666 Add the following prototype to the list of built-in variables accessible 1667 from a fragment shader: 1668 1669 int gl_PrimitiveID; 1670 1671 Change Chapter 8, sixth paragraph on page 50: 1672 1673 Change the sentence: 1674 1675 When the built-in functions are specified below, where the input arguments 1676 (and corresponding output)can be float, vec2, vec3, or vec4, genType is 1677 used as the argument. 1678 1679 To: 1680 1681 When the built-in functions are specified below, where the input arguments 1682 (and corresponding output) can be float, vec2, vec3, or vec4, genType is 1683 used as the argument. Where the input arguments (and corresponding output) 1684 can be int, ivec2, ivec3 or ivec4, genIType is used as the argument. Where 1685 the input arguments (and corresponding output) can be unsigned int, uvec2, 1686 uvec3, or uvec4, genUType is used as the argument. 1687 1688 Add to section 8.3 "Common functions" 1689 1690 Add integer versions of the abs, sign, min, max and clamp functions, as 1691 follows: 1692 1693 Syntax: 1694 1695 genIType abs(genIType x) 1696 1697 genIType sign(genIType x) 1698 1699 genIType min(genIType x, genIType y) 1700 genIType min(genIType x, int y) 1701 genUType min(genUType x, genUType y) 1702 genUType min(genUType x, unsigned int y) 1703 1704 genIType max(genIType x, genIType y) 1705 genIType max(genIType x, int y) 1706 genUType max(genUType x, genUType y) 1707 genUType max(genUType x, unsigned int y) 1708 1709 genIType clamp(genIType x, genIType minval, genIType maxval) 1710 genIType clamp(genIType x, int minval, int maxval) 1711 genUType clamp(genUType x, genUType minval, genUType maxval) 1712 genUType clamp(genUType x, unsigned int minval, 1713 unsigned int maxval) 1714 1715 Add the following new functions: 1716 1717 Syntax: 1718 1719 genType truncate(genType x) 1720 1721 Description: 1722 1723 Returns a value equal to the integer closest to x whose absolute value 1724 is not larger than the absolute value of x. 1725 1726 Syntax: 1727 1728 genType round(genType x) 1729 1730 Description: 1731 1732 Returns a value equal to the closest integer to x. If the fractional 1733 portion of the operand is 0.5, the nearest even integer is returned. For 1734 example, round (1.0) returns 1.0. round(-1.5) returns -2.0. round(3.5) 1735 and round (4.5) both return 4.0. 1736 1737 Add to section 8.6 "Vector Relational Functions" 1738 1739 Change the sentence: 1740 1741 Below, "bvec" is a placeholder for one of bvec2, bvec3, or bvec4, "ivec" 1742 is a placeholder for one of ivec2, ivec3, or ivec4, and "vec" is a 1743 placeholder for vec2, vec3, or vec4. 1744 1745 To: 1746 1747 Below, "bvec" is a placeholder for one of bvec2, bvec3, or bvec4, "ivec" 1748 is a placeholder for one of ivec2, ivec3, or ivec4, "uvec" is a 1749 placeholder for one of uvec2, uvec3 or uvec4 and "vec" is a placeholder 1750 for vec2, vec3, or vec4. 1751 1752 Add uvec versions of all but the any, all and not functions to the table 1753 in this section, as follows: 1754 1755 bvec lessThan(uvec x, uvec y) 1756 bvec lessThanEqual(uvec x, uvec y) 1757 1758 bvec greaterThan(uvec x, uvec y) 1759 bvec greaterThanEqual(uvec x, uvec y) 1760 1761 bvec equal(uvec x, uvec y) 1762 bvec notEqual(uvec x, uvec y) 1763 1764 Add to section 8.7 "Texture Lookup Functions" 1765 1766 Remove the first sentence in the last paragraph: 1767 1768 "The built-ins suffixed with "Lod" are allowed only in a vertex shader.". 1769 1770 Add to this section: 1771 1772 Texture data can be stored by the GL as floating point, unsigned 1773 normalized integer, unsigned integer or signed integer data. This is 1774 determined by the type of the internal format of the texture. Texture 1775 lookups on unsigned normalized integer and floating point data return 1776 floating point values in the range [0, 1]. See also section 2.15.4.1 of 1777 the OpenGL specification. 1778 1779 Texture lookup functions are provided that can return their result as 1780 floating point, unsigned integer or signed integer, depending on the 1781 sampler type passed to the lookup function. Care must be taken to use the 1782 right sampler type for texture access. Table 8.xxx lists the supported 1783 combinations of sampler types and texture internal formats. 1784 1785 texture 1786 internal default (float) integer unsigned integer 1787 format sampler sampler sampler 1788 float vec4 n/a n/a 1789 normalized vec4 n/a n/a 1790 signed int n/a ivec4 n/a 1791 unsigned int n/a n/a uvec4 1792 1793 Table 8.xxx Valid combinations of the type of the internal format of a 1794 texture and the type of the sampler used to access the texture. Each cell 1795 in the table indicates the type of the return value of a texture 1796 lookup. N/a means this combination is not supported. A texture lookup 1797 using a n/a combination will return undefined values. The exceptions to 1798 this table are the "textureSize" lookup functions, which will return an 1799 integer or integer vector, regardless of the sampler type. 1800 1801 If a texture with a signed integer internal format is accessed, one of the 1802 signed integer sampler types must be used. If a texture with an unsigned 1803 integer internal format is accessed, one of the unsigned integer sampler 1804 types must be used. Otherwise, one of the default (float) sampler types 1805 must be used. If the types of a sampler and the corresponding texture 1806 internal format do not match, the result of a texture lookup is undefined. 1807 1808 If an integer sampler type is used, the result of a texture lookup is an 1809 ivec4. If an unsigned integer sampler type is used, the result of a 1810 texture lookup is a uvec4. If a default sampler type is used, the result 1811 of a texture lookup is a vec4, where each component is in the range [0, 1812 1]. 1813 1814 Integer and unsigned integer functions of all the texture lookup functions 1815 described in this section are also provided, except for the "shadow" 1816 versions, using function overloading. Their prototypes, however, are not 1817 listed separately. These overloaded functions use the integer or 1818 unsigned-integer versions of the sampler types and will return an ivec4 or 1819 an uvec4 respectively, except for the "textureSize" functions, which will 1820 always return an integer, or integer vector. Refer also to table 8.xxxx 1821 for valid combinations of texture internal formats and sampler types. For 1822 example, for the texture1D function, the complete set of prototypes is: 1823 1824 vec4 texture1D(sampler1D sampler, float coord 1825 [, float bias]) 1826 ivec4 texture1D(isampler1D sampler, float coord 1827 [, float bias]) 1828 uvec4 texture1D(usampler1D sampler, float coord 1829 [, float bias]) 1830 1831 Add the following new texture lookup functions: 1832 1833 Syntax: 1834 1835 vec4 texelFetch1D(sampler1D sampler, int coord, int lod) 1836 vec4 texelFetch2D(sampler2D sampler, ivec2 coord, int lod) 1837 vec4 texelFetch3D(sampler3D sampler, ivec3 coord, int lod) 1838 vec4 texelFetch2DRect(sampler2DRect sampler, ivec2 coord) 1839 vec4 texelFetch1DArray(sampler1DArray sampler, ivec2 coord, int lod) 1840 vec4 texelFetch2DArray(sampler2DArray sampler, ivec3 coord, int lod) 1841 1842 Description: 1843 1844 Use integer texture coordinate <coord> to lookup a single texel from the 1845 level-of-detail <lod> on the texture bound to <sampler> as described in 1846 section 2.15.4.1 of the OpenGL specification "Texel Fetches". For the 1847 "array" versions, the layer of the texture array to access is either 1848 coord.t or coord.p, depending on the use of the 1D or 2D texel fetch 1849 lookup, respectively. Note that texelFetch2DRect does not take a 1850 level-of-detail input. 1851 1852 Syntax: 1853 1854 vec4 texelFetchBuffer(samplerBuffer sampler, int coord) 1855 1856 Description: 1857 1858 Use integer texture coordinate <coord> to lookup into the buffer texture 1859 bound to <sampler>. 1860 1861 Syntax: 1862 1863 int textureSizeBuffer(samplerBuffer sampler) 1864 int textureSize1D(sampler1D sampler, int lod) 1865 ivec2 textureSize2D(sampler2D sampler, int lod) 1866 ivec3 textureSize3D(sampler3D sampler, int lod) 1867 ivec2 textureSizeCube(samplerCube sampler, int lod) 1868 ivec2 textureSize2DRect(sampler2DRect sampler, int lod) 1869 ivec2 textureSize1DArray(sampler1DArray sampler, int lod) 1870 ivec3 textureSize2DArray(sampler2DArray sampler, int lod) 1871 1872 Description: 1873 1874 Returns the dimensions, width, height, depth, and number of layers, of 1875 level <lod> for the texture bound to <sampler>, as described in section 1876 2.15.4.1 of the OpenGL specification section "Texture Size Query". For the 1877 textureSize1DArray function, the first (".x") component of the returned 1878 vector is filled with the width of the texture image and the second 1879 component with the number of layers in the texture array. For the 1880 textureSize2DArray function, the first two components (".x" and ".y") of 1881 the returned vector are filled with the width and height of the texture 1882 image respectively. The third component (".z") is filled with the number 1883 of layers in the texture array. 1884 1885 Syntax: 1886 1887 vec4 texture1DArray(sampler1DArray sampler, vec2 coord 1888 [, float bias]) 1889 vec4 texture1DArrayLod(sampler1DArray sampler, vec2 coord, 1890 float lod) 1891 1892 Description: 1893 1894 Use the first element (coord.s) of texture coordinate coord to do a 1895 texture lookup in the layer indicated by the second coordinate coord.t of 1896 the 1D texture array currently bound to sampler. The layer to access is 1897 computed by layer = max (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is 1898 the depth of the texture array. 1899 1900 Syntax: 1901 1902 vec4 texture2DArray(sampler2DArray sampler, vec3 coord 1903 [, float bias]) 1904 vec4 texture2DArrayLod(sampler2DArray sampler, vec3 coord, 1905 float lod) 1906 Description: 1907 1908 Use the first two elements (coord.s, coord.t) of texture coordinate coord 1909 to do a texture lookup in the layer indicated by the third coordinate 1910 coord.p of the 2D texture array currently bound to sampler. The layer to 1911 access is computed by layer = max (0, min(d - 1, floor (coord.p + 0.5)) 1912 where 'd' is the depth of the texture array. 1913 1914 Syntax: 1915 1916 vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord, 1917 [float bias]) 1918 vec4 shadow1DArrayLod(sampler1DArrayShadow sampler, 1919 vec3 coord, float lod) 1920 Description: 1921 1922 Use texture coordinate coord.s to do a depth comparison lookup on an array 1923 layer of the depth texture bound to sampler, as described in section 1924 3.8.14 of version 2.0 of the OpenGL specification. The layer to access is 1925 indicated by the second coordinate coord.t and is computed by layer = max 1926 (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is the depth of the 1927 texture array. The third component of coord (coord.p) is used as the R 1928 value. The texture bound to sampler must be a depth texture, or results 1929 are undefined. 1930 1931 Syntax: 1932 1933 vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord) 1934 1935 Description: 1936 1937 Use texture coordinate (coord.s, coord.t) to do a depth comparison lookup 1938 on an array layer of the depth texture bound to sampler, as described in 1939 section 3.8.14 of version 2.0 of the OpenGL specification. The layer to 1940 access is indicated by the third coordinate coord.p and is computed by 1941 layer = max (0, min(d - 1, floor (coord.p + 0.5)) where 'd' is the depth 1942 of the texture array. The fourth component of coord (coord.q) is used as 1943 the R value. The texture bound to sampler must be a depth texture, or 1944 results are undefined. 1945 1946 Syntax: 1947 1948 vec4 shadowCube(samplerCubeShadow sampler, vec4 coord) 1949 1950 Description: 1951 1952 Use texture coordinate (coord.s, coord.t, coord.p) to do a depth 1953 comparison lookup on the depth cubemap bound to sampler, as described in 1954 section 3.8.14. The direction of the vector (coord.s, coord.t, coord.p) is 1955 used to select which face to do a two-dimensional texture lookup in, as 1956 described in section 3.8.6 of the OpenGL 2.0 specification. The fourth 1957 component of coord (coord.q) is used as the R value. The texture bound to 1958 sampler must be a depth cubemap, otherwise results are undefined. 1959 1960 Syntax: 1961 1962 vec4 texture1DGrad(sampler1D sampler, float coord, 1963 float ddx, float ddy); 1964 vec4 texture1DProjGrad(sampler1D sampler, vec2 coord, 1965 float ddx, float ddy); 1966 vec4 texture1DProjGrad(sampler1D sampler, vec4 coord, 1967 float ddx, float ddy); 1968 vec4 texture1DArrayGrad(sampler1DArray sampler, vec2 coord, 1969 float ddx, float ddy); 1970 1971 vec4 texture2DGrad(sampler2D sampler, vec2 coord, 1972 vec2 ddx, vec2 ddy); 1973 vec4 texture2DProjGrad(sampler2D sampler, vec3 coord, 1974 vec2 ddx, vec2 ddy); 1975 vec4 texture2DProjGrad(sampler2D sampler, vec4 coord, 1976 vec2 ddx, vec2 ddy); 1977 vec4 texture2DArrayGrad(sampler2DArray sampler, vec3 coord, 1978 vec2 ddx, vec2 ddy); 1979 1980 vec4 texture3DGrad(sampler3D sampler, vec3 coord, 1981 vec3 ddx, vec3 ddy); 1982 vec4 texture3DProjGrad(sampler3D sampler, vec4 coord, 1983 vec3 ddx, vec3 ddy); 1984 1985 vec4 textureCubeGrad(samplerCube sampler, vec3 coord, 1986 vec3 ddx, vec3 ddy); 1987 1988 vec4 shadow1DGrad(sampler1DShadow sampler, vec3 coord, 1989 float ddx, float ddy); 1990 vec4 shadow1DProjGrad(sampler1DShadow sampler, vec4 coord, 1991 float ddx, float ddy); 1992 vec4 shadow1DArrayGrad(sampler1DArrayShadow sampler, vec3 coord, 1993 float ddx, float ddy); 1994 1995 vec4 shadow2DGrad(sampler2DShadow sampler, vec3 coord, 1996 vec2 ddx, vec2 ddy); 1997 vec4 shadow2DProjGrad(sampler2DShadow sampler, vec4 coord, 1998 vec2 ddx, vec2 ddy); 1999 vec4 shadow2DArrayGrad(sampler2DArrayShadow sampler, vec4 coord, 2000 vec2 ddx, vec2 ddy); 2001 2002 vec4 texture2DRectGrad(sampler2DRect sampler, vec2 coord, 2003 vec2 ddx, vec2 ddy); 2004 vec4 texture2DRectProjGrad(sampler2DRect sampler, vec3 coord, 2005 vec2 ddx, vec2 ddy); 2006 vec4 texture2DRectProjGrad(sampler2DRect sampler, vec4 coord, 2007 vec2 ddx, vec2 ddy); 2008 2009 vec4 shadow2DRectGrad(sampler2DRectShadow sampler, vec3 coord, 2010 vec2 ddx, vec2 ddy); 2011 vec4 shadow2DRectProjGrad(sampler2DRectShadow sampler, vec4 coord, 2012 vec2 ddx, vec2 ddy); 2013 2014 vec4 shadowCubeGrad(samplerCubeShadow sampler, vec4 coord, 2015 vec3 ddx, vec3 ddy); 2016 2017 Description: 2018 2019 The "Grad" functions map the partial derivatives ddx and ddy to ds/dx, 2020 dt/dx, dr/dx, and ds/dy, dt/dy, dr/dy respectively and use texture 2021 coordinate "coord" to do a texture lookup as described for their non 2022 "Grad" counterparts. The derivatives ddx and ddy are used as the explicit 2023 derivate of "coord" with respect to window x and window y respectively and 2024 are used to compute lambda_base(x,y) as in equation 3.18 in the OpenGL 2.0 2025 specification. For the "Proj" versions, it is assumed that the partial 2026 derivatives ddx and ddy are already projected. I.e. the GL assumes that 2027 ddx and ddy represent d(s/q)/dx, d(t/q)/dx, d(r/q)/dx and d(s/q)/dy, 2028 d(t/q)/dy, d(r/q)/dy respectively. For the "Cube" versions, the partial 2029 derivatives ddx and ddy are assumed to be in the coordinate system used 2030 before texture coordinates are projected onto the appropriate cube 2031 face. The partial derivatives of the post-projection texture coordinates, 2032 which are used for level-of-detail and anisotropic filtering 2033 calculations, are derived from coord, ddx and ddy in an 2034 implementation-dependent manner. 2035 2036 NOTE: Except for the "array" and shadowCubeGrad() functions, these 2037 functions are taken from the ARB_shader_texture_lod spec and are 2038 functionally equivalent. 2039 2040 Syntax: 2041 2042 vec4 texture1DOffset(sampler1D sampler, float coord, 2043 int offset [,float bias]) 2044 vec4 texture1DProjOffset(sampler1D sampler, vec2 coord, 2045 int offset [,float bias]) 2046 vec4 texture1DProjOffset(sampler1D sampler, vec4 coord, 2047 int offset [,float bias]) 2048 vec4 texture1DLodOffset(sampler1D sampler, float coord, 2049 float lod, int offset) 2050 vec4 texture1DProjLodOffset(sampler1D sampler, vec2 coord, 2051 float lod, int offset) 2052 vec4 texture1DProjLodOffset(sampler1D sampler, vec4 coord, 2053 float lod, int offset) 2054 2055 vec4 texture2DOffset(sampler2D sampler, vec2 coord, 2056 ivec2 offset [,float bias]) 2057 vec4 texture2DProjOffset(sampler2D sampler, vec3 coord, 2058 ivec2 offset [,float bias]) 2059 vec4 texture2DProjOffset(sampler2D sampler, vec4 coord, 2060 ivec2 offset [,float bias]) 2061 vec4 texture2DLodOffset(sampler2D sampler, vec2 coord, 2062 float lod, ivec2 offset) 2063 vec4 texture2DProjLodOffset(sampler2D sampler, vec3 coord, 2064 float lod, ivec2 offset) 2065 vec4 texture2DProjLodOffset(sampler2D sampler, vec4 coord, 2066 float lod, ivec2 offset) 2067 2068 vec4 texture3DOffset(sampler3D sampler, vec3 coord, 2069 ivec3 offset [,float bias]) 2070 vec4 texture3DProjOffset(sampler3D sampler, vec4 coord, 2071 ivec3 offset [,float bias]) 2072 vec4 texture3DLodOffset(sampler3D sampler, vec3 coord, 2073 float lod, ivec3 offset) 2074 vec4 texture3DProjLodOffset(sampler3D sampler, vec4 coord, 2075 float lod, ivec3 offset) 2076 2077 vec4 shadow1DOffset(sampler1DShadow sampler, vec3 coord, 2078 int offset [,float bias]) 2079 vec4 shadow2DOffset(sampler2DShadow sampler, vec3 coord, 2080 ivec2 offset [,float bias]) 2081 vec4 shadow1DProjOffset(sampler1DShadow sampler, vec4 coord, 2082 int offset [,float bias]) 2083 vec4 shadow2DProjOffset(sampler2DShadow sampler, vec4 coord, 2084 ivec2 offset [,float bias]) 2085 vec4 shadow1DLodOffset(sampler1DShadow sampler, vec3 coord, 2086 float lod, int offset) 2087 vec4 shadow2DLodOffset(sampler2DShadow sampler, vec3 coord, 2088 float lod, ivec2 offset) 2089 vec4 shadow1DProjLodOffset(sampler1DShadow sampler, vec4 coord, 2090 float lod, int offset) 2091 vec4 shadow2DProjLodOffset(sampler2DShadow sampler, vec4 coord, 2092 float lod, ivec2 offset) 2093 2094 vec4 texture2DRectOffset(sampler2DRect sampler, vec2 coord, 2095 ivec2 offset) 2096 vec4 texture2DRectProjOffset(sampler2DRect sampler, vec3 coord, 2097 ivec2 offset) 2098 vec4 texture2DRectProjOffset(sampler2DRect sampler, vec4 coord, 2099 ivec2 offset) 2100 vec4 shadow2DRectOffset(sampler2DRectShadow sampler, vec3 coord, 2101 ivec2 offset) 2102 vec4 shadow2DRectProjOffset(sampler2DRectShadow sampler, vec4 coord, 2103 ivec2 offset) 2104 2105 vec4 texelFetch1DOffset(sampler1D sampler, int coord, int lod, 2106 int offset) 2107 vec4 texelFetch2DOffset(sampler2D sampler, ivec2 coord, int lod, 2108 ivec2 offset) 2109 vec4 texelFetch3DOffset(sampler3D sampler, ivec3 coord, int lod, 2110 ivec3 offset) 2111 vec4 texelFetch2DRectOffset(sampler2DRect sampler, ivec2 coord, 2112 ivec2 offset) 2113 vec4 texelFetch1DArrayOffset(sampler1DArray sampler, ivec2 coord, 2114 int lod, int offset) 2115 vec4 texelFetch2DArrayOffset(sampler2DArray sampler, ivec3 coord, 2116 int lod, ivec2 offset) 2117 2118 vec4 texture1DArrayOffset(sampler1DArray sampler, vec2 coord, 2119 int offset [, float bias]) 2120 vec4 texture1DArrayLodOffset(sampler1DArray sampler, vec2 coord, 2121 float lod, int offset) 2122 2123 vec4 texture2DArrayOffset(sampler2DArray sampler, vec3 coord, 2124 ivec2 offset [, float bias]) 2125 vec4 texture2DArrayLodOffset(sampler2DArray sampler, vec3 coord, 2126 float lod, ivec2 offset) 2127 2128 vec4 shadow1DArrayOffset(sampler1DArrayShadow sampler, vec3 coord, 2129 int offset, [float bias]) 2130 vec4 shadow1DArrayLodOffset(sampler1DArrayShadow sampler, vec3 coord, 2131 float lod, int offset) 2132 2133 vec4 shadow2DArrayOffset(sampler2DArrayShadow sampler, 2134 vec4 coord, ivec2 offset) 2135 2136 vec4 texture1DGradOffset(sampler1D sampler, float coord, 2137 float ddx, float ddy, int offset); 2138 vec4 texture1DProjGradOffset(sampler1D sampler, vec2 coord, 2139 float ddx, float ddy, int offset); 2140 vec4 texture1DProjGradOffset(sampler1D sampler, vec4 coord, 2141 float ddx, float ddy, int offset); 2142 vec4 texture1DArrayGradOffset(sampler1DArray sampler, vec2 coord, 2143 float ddx, float ddy, int offset); 2144 2145 vec4 texture2DGradOffset(sampler2D sampler, vec2 coord, 2146 vec2 ddx, vec2 ddy, ivec2 offset); 2147 vec4 texture2DProjGradOffset(sampler2D sampler, vec3 coord, 2148 vec2 ddx, vec2 ddy, ivec2 offset); 2149 vec4 texture2DProjGradOffset(sampler2D sampler, vec4 coord, 2150 vec2 ddx, vec2 ddy, ivec2 offset); 2151 vec4 texture2DArrayGradOffset(sampler2DArray sampler, vec3 coord, 2152 vec2 ddx, vec2 ddy, ivec2 offset); 2153 2154 vec4 texture3DGradOffset(sampler3D sampler, vec3 coord, 2155 vec3 ddx, vec3 ddy, ivec3 offset); 2156 vec4 texture3DProjGradOffset(sampler3D sampler, vec4 coord, 2157 vec3 ddx, vec3 ddy, ivec3 offset); 2158 2159 vec4 shadow1DGradOffset(sampler1DShadow sampler, vec3 coord, 2160 float ddx, float ddy, int offset); 2161 vec4 shadow1DProjGradOffset(sampler1DShadow sampler, 2162 vec4 coord, float ddx, float ddy, 2163 int offset); 2164 vec4 shadow1DArrayGradOffset(sampler1DArrayShadow sampler, 2165 vec3 coord, float ddx, float ddy, 2166 int offset); 2167 2168 vec4 shadow2DGradOffset(sampler2DShadow sampler, vec3 coord, 2169 vec2 ddx, vec2 ddy, ivec2 offset); 2170 vec4 shadow2DProjGradOffset(sampler2DShadow sampler, vec4 coord, 2171 vec2 ddx, vec2 ddy, ivec2 offset); 2172 vec4 shadow2DArrayGradOffset(sampler2DArrayShadow sampler, 2173 vec4 coord, vec2 ddx, vec2 ddy, 2174 ivec2 offset); 2175 2176 vec4 texture2DRectGradOffset(sampler2DRect sampler, vec2 coord, 2177 vec2 ddx, vec2 ddy, ivec2 offset); 2178 vec4 texture2DRectProjGradOffset(sampler2DRect sampler, vec3 coord, 2179 vec2 ddx, vec2 ddy, ivec2 offset); 2180 vec4 texture2DRectProjGradOffset(sampler2DRect sampler, vec4 coord, 2181 vec2 ddx, vec2 ddy, ivec2 offset); 2182 2183 vec4 shadow2DRectGradOffset(sampler2DRectShadow sampler, 2184 vec3 coord, vec2 ddx, vec2 ddy, 2185 ivec2 offset); 2186 vec4 shadow2DRectProjGradOffset(sampler2DRectShadow sampler, 2187 vec4 coord, vec2 ddx, vec2 ddy, 2188 ivec2 offset); 2189 2190 Description: 2191 2192 The "offset" version of each function provides an extra parameter <offset> 2193 which is added to the (u,v,w) texel coordinates before looking up each 2194 texel. The offset value must be a constant expression. A limited range 2195 of offset values are supported; the minimum and maximum offset values are 2196 implementation-dependent and given by MIN_PROGRAM_TEXEL_OFFSET_EXT and 2197 MAX_PROGRAM_TEXEL_OFFSET_EXT, respectively. Note that <offset> does not 2198 apply to the layer coordinate for texture arrays. This is explained in 2199 detail in section 3.8.7 of the OpenGL Specification. Note that texel 2200 offsets are also not supported for cubemaps or buffer textures. 2201 2202 Add to section 9 "Grammar" 2203 2204 type_qualifer: 2205 CONST 2206 ATTRIBUTE // Vertex only 2207 varying-modifier_opt VARYING 2208 UNIFORM 2209 2210 varying-modifier: 2211 FLAT 2212 CENTROID 2213 NOPERSPECTIVE 2214 2215 type_specifier: 2216 VOID 2217 FLOAT 2218 INT 2219 UNSIGNED_INT 2220 BOOL 2221 2222Issues 2223 2224 1. Should we support shorts in GLSL? 2225 2226 DISCUSSION: 2227 2228 RESOLUTION: UNRESOLVED 2229 2230 2. Do bitwise shifts, AND, exclusive OR and inclusive OR support all 2231 combinations of scalars and vectors for each operand? 2232 2233 DISCUSSION: It seems sense to support scalar OP scalar, vector OP scalar 2234 and vector OP vector. But what about scalar OP vector? Should the scalar 2235 be promoted to a vector first? 2236 2237 RESOLUTION: RESOLVED. Yes, this should work essentially as the '+' 2238 operator. The scalar is applied to each component of the vector. 2239 2240 3. Which built-in functions should also operate on integers? 2241 2242 DISCUSSION: There are several that don't make sense to define to operate 2243 on integers at all, but the following can be debated: pow, sqrt, dot (and 2244 the functions that use dot), cross. 2245 2246 RESOLUTION: RESOLVED. Integer versions of the abs, sign, min, max and 2247 clamp functions are defined. Note that the modulus operator % has been 2248 defined for integer operands. 2249 2250 4. Do we need to support integer matrices? 2251 2252 DISCUSSION: 2253 2254 RESOLUTION: RESOLVED No, not at the moment. 2255 2256 5. Which texture array lookup functions do we need to support? 2257 2258 DISCUSSION: We don't want to support lookup functions that need more than 2259 four components passed as parameters. Components can be used for texture 2260 coordinates, layer selection, 'R' depth compare and the 'q' coordinate 2261 for projection. However, texture projection might be relatively easy to 2262 support through code-generation, thus we might be able to support 2263 functions that need five components, as long as one of them is 'q' for 2264 projective texturing. Specifically, should we support: 2265 2266 vec4 texture2DArrayProjLod(sampler2DArray sampler, vec4 coord, 2267 float lod) 2268 vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord, 2269 [float bias]) 2270 vec4 shadow1DArrayProj(sampler1DArrayShadow sampler, vec4 coord, 2271 [float bias]) 2272 vec4 shadow1DArrayLod(sampler1DArrayShadow sampler, vec3 coord, 2273 float lod) 2274 vec4 shadow1DArrayProjLod(sampler1DArrayShadow sampler, 2275 vec4 coord, float lod) 2276 vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord) 2277 vec4 shadow2DArrayProj(sampler2DArrayShadow sampler, vec4 coord, 2278 float refValue) 2279 2280 RESOLUTION: RESOLVED, We'll support all but the "Proj" versions. The 2281 assembly spec (NV_gpu_program4) doesn't support the equivalent 2282 functionality, either. 2283 2284 6. How do we handle conversions between integer and unsigned 2285 integers? 2286 2287 DISCUSSION: Do we allow automatic type conversions between signed and 2288 unsigned integers? 2289 2290 RESOLUTION: RESOLVED. We will not add this until GLSL version 1.20 has 2291 been defined, and the implicit conversion rules have been established 2292 there. If we do this, we would likely only support implicit conversion 2293 from int to unsigned int, just like C does. 2294 2295 7. Should varying modifiers (flat, noperspective) apply to built-in 2296 varying variables also? 2297 2298 DISCUSSION: There is API to control flat vs smooth shading for colors 2299 through glShadeModel(). There is also API to hint if colors should be 2300 interpolated perspective correct, or not, through glHint(). These API 2301 commands apply to the built-in color varying variables (gl_FrontColor 2302 etc). If the varying modifiers in a shader also apply to the color 2303 built-ins, which has precedence? 2304 2305 RESOLUTION: RESOLVED. It is simplest and cleanest to only allow the 2306 varying modifiers to apply to user-defined varying variables. The 2307 behavior of the built-in color varying variables can still be controlled 2308 through the API. 2309 2310 8. How should perspective-incorrect interpolation (linear in screen space) 2311 and clipping interact? 2312 2313 RESOLVED: Primitives with attributes specified to be perspective- 2314 incorrect should be clipped so that the vertices introduced by clipping 2315 should have attribute values consistent with the interpolation mode. We 2316 do not want to have large color shifts introduced by clipping a 2317 perspective-incorrect attribute. For example, a primitive that 2318 approaches, but doesn't cross, a frustum clip plane should look pretty 2319 much identical to a similar primitive that just barely crosses the clip 2320 plane. 2321 2322 Clipping perspective-incorrect interpolants that cross the W==0 plane is 2323 very challenging. The attribute clipping equation provided in the spec 2324 effectively projects all the original vertices to screen space while 2325 ignoring the X and Y frustum clip plane. As W approaches zero, the 2326 projected X/Y window coordinates become extremely large. When clipping 2327 an edge with one vertex inside the frustum and the other out near 2328 infinity (after projection, due to W approaching zero), the interpolated 2329 attribute for the entire visible portion of the edge should almost 2330 exactly match the attribute value of the visible vertex. 2331 2332 If an outlying vertex approaches and then goes past W==0, it can be said 2333 to go "to infinity and beyond" in screen space. The correct answer for 2334 screen-linear interpolation is no longer obvious, at least to the author 2335 of this specification. Rather than trying to figure out what the 2336 "right" answer is or if one even exists, the results of clipping such 2337 edges is specified as undefined. 2338 2339 9. Do we need to support a non-MRT fragment shader writing to (unsigned) 2340 integer outputs? 2341 2342 DISCUSSION: Fragment shaders with only one fragment output are 2343 considered non-MRT shaders. This means that the output of the shader 2344 gets smeared across all color buffers attached to the 2345 framebuffer. Fragment shaders with multiple fragment outputs are MRT 2346 shaders. Each output is directed to a color buffer using the DrawBuffers 2347 API (for gl_FragData) and a combination of the BindFragDataLocationEXT 2348 and DrawBuffers API (for varying out variables). Before this extension, 2349 a non-MRT shader would write to gl_Color only. A shader writing to 2350 gl_FragData[] is a MRT shader. With the addition of varying out 2351 variables in this extension, any shader writing to a variable out 2352 variable is a MRT shader. It is not possible to construct a non-MRT 2353 shader writing to varying out variables. Varying out variables can be 2354 declared to be of type integer or unsigned integer. In order to support 2355 a non-MRT shader that can write to (unsigned) integer outputs, we could 2356 define two new built-in variables: 2357 2358 ivec4 gl_FragColorInt; 2359 uvec4 gl_FragColorUInt; 2360 2361 Or we could add a special rule stating that if the program object writes 2362 to exactly one varying out variable, it is considered to be non-MRT. 2363 2364 RESOLUTION: NO. We don't care enough to support this. 2365 2366 10. Is section 2.14.8, "Color and Associated Data Clipping" in the core 2367 specification still correct? 2368 2369 DISCUSSION: This section is in need of some updating, now that varying 2370 variables can be interpolated without perspective correction. Some (not 2371 so precise) language has been added in the spec body, suggesting that 2372 the interpolation needs to be performed in such a way as to produce 2373 results that vary linearly in screen space. However, we could define the 2374 exact interpolation method required to achieve this. A suggested updated 2375 paragraph follows, but we'll leave updating section 2.14.8 to a future 2376 edit of the core specification, not this extension. 2377 2378 Replace Section 2.14.8, and rename it to "Vertex Attribute Clipping" 2379 2380 After lighting, clamping or masking and possible flatshading, vertex 2381 attributes, including colors, texture and fog coordinates, shader 2382 varying variables, and point sizes computed on a per vertex basis, are 2383 clipped. Those attributes associated with a vertex that lies within the 2384 clip volume are unaffected by clipping. If a primitive is clipped, 2385 however, the attributes assigned to vertices produced by clipping are 2386 produced by interpolating attributes along the clipped edge. 2387 2388 Let the attributes assigned to the two vertices P_1 and P_2 of an 2389 unclipped edge be a_1 and a_2. The value of t (section 2.12) for a 2390 clipped point P is used to obtain the attribute associated with P as 2391 2392 a = t * a_1 + (1-t) * a_2 2393 2394 unless the attribute is specified to be interpolated without perspective 2395 correction in a shader (using the noperspective keyword). In that case, 2396 the attribute associated with P is 2397 2398 a = t' * a_1 + (1-t') * a_2 2399 2400 where 2401 2402 t' = (t * w_1) / (t * w_1 + (1-t) * w_2) 2403 2404 and w_1 and w_2 are the w clip coordinates of P_1 and P_2, 2405 respectively. If w_1 or w_2 is either zero or negative, the value of the 2406 associated attribute is undefined. 2407 2408 For a color index color, multiplying a color by a scalar means 2409 multiplying the index by the scalar. For a vector attribute, it means 2410 multiplying each vector component by the scalar. Polygon clipping may 2411 create a clipped vertex along an edge of the clip volume's 2412 boundary. This situation is handled by noting that polygon clipping 2413 proceeds by clipping against one plane of the clip volume's boundary at 2414 a time. Attribute clipping is done in the same way, so that clipped 2415 points always occur at the intersection of polygon edges (possibly 2416 already clipped) with the clip volume's boundary. 2417 2418 11. When and where in the texture filtering process are texel offsets 2419 applied? 2420 2421 DISCUSSION: Texel offsets are applied to the (u,v,w) coordinates of the 2422 base level of the texture if the texture filter mode does not indicate 2423 mipmapping. Otherwise, texel offsets are applied to the (u,v,w) 2424 coordinates of the mipmap level 'd', as found by equation 3.27 or to 2425 mipmap levels 'd1' and 'd2' as found by equation 3.28 in the OpenGL 2.0 2426 specification. In other words, texel offsets are applied to the 2427 (u,v,w) coordinate of whatever mipmap level is accessed. 2428 2429 12. Why is writing to the built-in output variable "gl_Position" in a vertex 2430 shader now optional? 2431 2432 DISCUSSION: Before this specification, writing to gl_Position in a 2433 vertex shader was mandatory. The GL pipeline required a vertex position 2434 to be written in order to produce well-defined output. This is still the 2435 case if the GL pipeline indeed needs a vertex position. However, with 2436 fourth-generation programmable hardware there are now cases where the GL 2437 pipeline no longer requires a vertex position in order to produce 2438 well-defined results. If a geometry shader is present, the vertex shader 2439 does not need to write to gl_Position anymore. Instead, the geometry 2440 shader can compute a vertex position and write to its gl_Position 2441 output. In case of transform-feedback, where the output of a vertex or 2442 geometry shader is streamed to one or more buffer objects, perfectly 2443 valid results can be obtained without either the vertex shader nor 2444 geometry shader writing to gl_Position. The transform-feedback 2445 specification adds a new enable to discard primitives right before 2446 rasterization, making it potentially unnecessary to write to 2447 gl_Position. 2448 2449 13. How does this extension interact with ARB_shader_texture_lod? 2450 2451 DISCUSSION: This extension adds "Grad" functions which are functionally 2452 equivalent to those defined by ARB_shader_texture_lod, but do not have 2453 an ARB suffix. 2454 2455 RESOLUTION: There is no interaction. If both extensions are supported, 2456 both sets of functions are available and can be controlled independently 2457 via the #extension mechanism. 2458 2459 2460Revision History 2461 2462 Rev. Date Author Changes 2463 ---- -------- -------- ----------------------------------------- 2464 16 12/14/09 mgodse Added GLX protocol. 2465 2466 15 04/09/09 pbrown Fixed a typo in the texture size query spec 2467 language - returns a layer count, not "index". 2468 2469 14 07/29/08 pbrown Discovered additional issues with texture wrap 2470 handling, replaced with logic that applies wrap 2471 modes per sample. 2472 2473 13 04/04/08 pbrown Added issue 13, concerning the (non-)interaction 2474 with ARB_shader_texture_lod. 2475 2476 12 02/04/08 pbrown Fix errors in texture wrap mode handling. 2477 Added a missing clamp to avoid sampling border 2478 in REPEAT mode. Fixed incorrectly specified 2479 weights for LINEAR filtering. 2480 2481 11 05/08/07 pbrown Add VertexAttribIPointerEXT to the list of 2482 commands that can't go in display lists. 2483 2484 10 01/23/07 pbrown Fix prototypes for a variety of functions 2485 that were specified with an incorrect sampler 2486 type. 2487 2488 9 12/15/06 pbrown Documented that the '#extension' token 2489 for this extension should begin with "GL_", 2490 as apparently called for per convention. 2491 2492 8 -- Pre-release revisions. 2493 2494