1Name 2 3 ARB_fragment_coord_conventions 4 5Name Strings 6 7 GL_ARB_fragment_coord_conventions 8 9Contributors 10 11 Jason Green, TransGaming 12 Daniel Koch, TransGaming 13 Gavriel State, TransGaming 14 Ryan Gordon, Destineer 15 Nicholas Vining, Destineer 16 John Kessenich, Intel 17 18Contact 19 20 Mark Kilgard, NVIDIA (mjk 'at' nvidia.com) 21 Daniel Koch, TransGaming (daniel 'at' transgaming.com) 22 23Notice 24 25 Copyright (c) 2009-2013 The Khronos Group Inc. Copyright terms at 26 http://www.khronos.org/registry/speccopyright.html 27 28Specification Update Policy 29 30 Khronos-approved extension specifications are updated in response to 31 issues and bugs prioritized by the Khronos OpenGL Working Group. For 32 extensions which have been promoted to a core Specification, fixes will 33 first appear in the latest version of that core Specification, and will 34 eventually be backported to the extension document. This policy is 35 described in more detail at 36 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 37 38Status 39 40 Complete. Approved by the ARB on July 3, 2009. 41 42Version 43 44 Last Modified Date: August 2, 2009 45 Version: 10 46 47Number 48 49 ARB Extension #63 50 51Dependencies 52 53 This extension is written against the OpenGL 3.1 Specification but 54 can apply to prior specifications. 55 56 This extension interacts with ARB_fragment_program. 57 58 This extension interacts with ARB_fragment_shader. 59 60 This extension interacts with NV_fragment_program. 61 62 This extension interacts with NV_fragment_program_option. 63 64 This extension interacts with NV_fragment_program2. 65 66 This extension interacts with NV_fragment_program4. 67 68Overview 69 70 This extension provides alternative conventions for the fragment 71 coordinate XY location available for programmable fragment processing. 72 73 The scope of this extension deals *only* with how the fragment 74 coordinate XY location appears during programming fragment processing. 75 Beyond the scope of this extension are coordinate conventions used 76 for rasterization or transformation. 77 78 In the case of the coordinate conventions for rasterization and 79 transformation, some combination of the viewport, depth range, culling 80 state, and projection matrix state can be reconfigured to adopt other 81 arbitrary clip-space and window-space coordinate space conventions. 82 Adopting other clip-space and window-space conventions involves 83 adjusting existing OpenGL state. However it is non-trivial to massage 84 an arbitrary fragment shader or program to adopt a different 85 window-space coordinate system because such shaders are encoded in 86 various textual representations. 87 88 The dominant 2D and 3D rendering APIs make two basic choices of 89 convention when locating fragments in window space. 90 91 The two choices are: 92 93 1) Is the origin nearest the lower-left- or upper-left-most pixel 94 of the window? 95 96 2) Is the (x,y) location of the pixel nearest the origin at (0,0) 97 or (0.5,0.5)? 98 99 OpenGL assumes a lower-left origin for window coordinates and assumes 100 pixel centers are located at half-pixel coordinates. This means 101 the XY location (0.5,0.5) corresponds to the lower-left-most pixel 102 in a window. 103 104 Other window coordinate conventions exist for other rendering APIs. 105 X11, GDI, and Direct3D version through DirectX 9 assume an upper-left 106 window origin and locate pixel centers at integer XY values. 107 By this alternative convention, the XY location (0,0) corresponds 108 to the upper-left-most pixel in a window. 109 110 Direct3D for DirectX 10 assumes an upper-left origin (as do prior 111 DirectX versions) yet assumes half-pixel coordinates (unlike prior 112 DirectX versions). By the DirectX 10 convention, the XY location 113 (0.5,0.5) corresponds to the upper-left-most pixel in a window. 114 115 Fragment shaders can directly access the location of a given 116 processed fragment in window space. We call this location the 117 "fragment coordinate". 118 119 This extension provides a means for fragment shaders written in GLSL 120 or OpenGL assembly extensions to specify alternative conventions 121 for determining the fragment coordinate value accessed during 122 programmable fragment processing. 123 124 The motivation for this extension is to provide an easy, efficient 125 means for fragment shaders accessing a fragment's window-space 126 location to adopt the fragment coordinate convention for which the 127 shader was originally written. 128 129New Procedures and Functions 130 131 None 132 133New Tokens 134 135 None 136 137Additions to Chapter 2 of the OpenGL 3.1 Specification (OpenGL Operation) 138 139 None 140 141Additions to Chapter 3 of the OpenGL 3.1 Specification (Rasterization) 142 143 Modify Section 3.9.2, "Shader Execution" 144 145 In subsection "Shader Inputs" replace the paragraph beginning "The 146 built-in variable gl_FragCoord ..." with: 147 148 "The built-in variable gl_FragCoord holds the fragment coordinate 149 (x_f,y_f,z_f,w_f) for the fragment. Computing the fragment coordinate 150 depends on the fragment processing pixel-center and origin conventions 151 (discussed below) as follows: 152 153 { x_w - 0.5, if the fragment processing pixel-center 154 x_f = { convention is integer 155 { x_w, otherwise 156 157 { H - y_w, if the fragment processing origin 158 y_f' = { convention is upper-left 159 { y_w, otherwise 160 161 { y_f' - 0.5, if the fragment processing pixel-center 162 y_f = { convention is integer 163 { y_f', otherwise 164 165 z_f = z_w 166 167 w_f = 1 / w_c 168 169 where (x_w, y_w, z_w) is the fragment's window-space position, w_c 170 is the w component of the fragment's clip-space position, and H is 171 the window's height in pixels. Note that the value of z_w already 172 has a polygon offset added in, if enabled (see section 3.6.4). Also 173 z_f must be precisely 0 or 1 in the case where z_w is either 0 or 1 174 respectively. The 1/w is computed from the w_c coordinate (see 175 section 2.12), which is the result of the product of the projection 176 matrix and the vertex's eye coordinates. 177 178 Unless otherwise specified by layout qualifiers in the fragment 179 shader (see section 4.3.x.1 "Input Layout Qualifier" of the OpenGL 180 Shading Language Specification), the fragment processing 181 pixel-center convention is half-integer and the fragment processing 182 origin convention is lower-left." 183 184Additions to Chapter 4 of the OpenGL 3.1 Specification (Per-Fragment 185Operations and the Frame Buffer) 186 187 None 188 189Additions to Chapter 5 of the OpenGL 3.1 Specification (Special 190Functions) 191 192 None 193 194Additions to Chapter 6 of the OpenGL 3.1 Specification (State and 195State Requests) 196 197 None 198 199Additions to the AGL/GLX/WGL Specifications 200 201 None 202 203Additions to version 1.40.07 of the OpenGL Shading Language Specification 204 205 "A new preprocessor #define is added to the OpenGL Shading Language: 206 207 #define GL_ARB_fragment_coord_conventions 1 208 209 Including the following line in a shader can be used to control the 210 language features described in this extension: 211 212 #extension GL_ARB_fragment_coord_conventions : <behavior> 213 214 where <behavior> is as specified in section 3.3." 215 216Additions to Chapter 4 of the OpenGL Shadering Language (Variables and Types) 217version 1.40.07 218 219 Add a new Section 4.3.x (Layout Qualifiers) as follows: 220 221 "4.3.x Layout Qualifiers 222 223 Layout qualifiers can appear with an individual variable declared with 224 an interface qualifier: 225 226 <layout-qualifier> <interface-qualifier> <declaration>; 227 228 <layout-qualifier>: 229 layout( <layout-qualifier-id-list> ) 230 231 <layout-qualifier-id-list>: 232 comma separated list of <layout-qualifier-id> 233 234 <interface-qualifier>: 235 in 236 out 237 uniform 238 239 Declarations of layouts can only be made at global scope, and only 240 where indicated in the following subsection; their details are 241 specific to what the interface qualifier is, and are discussed 242 individually. 243 244 The tokens in any <layout-qualifier-id-list> are identifiers, not 245 keywords. Generally they can be listed in any order. Order-dependent 246 meanings exist only if explicitly called out below. Similarily, 247 these identifiers are not case-sensitive, unless explicitly noted 248 otherwise. 249 250 4.3.x.1 Input Layout Qualifiers 251 252 Vertex shaders do not have any input layout qualifiers. 253 254 Fragment shaders can have an input layout only for redeclaring the 255 built-in variable gl_FragCoord (see section 7.2). The layout 256 qualifier identifiers for gl_FragCoord are 257 258 <layout-qualifier-id> 259 origin_upper_left 260 pixel_center_integer 261 262 By default, gl_FragCoord assumes a lower-left origin for window 263 coordinates and assumes pixel centers are located at half-pixel 264 coordinates. For example, the (x, y) location (0.5, 0.5) is returned 265 for the lower-left-most pixel in a window. The origin can be changed 266 by redeclaring gl_FragCoord with the <origin_upper_left> identifier, 267 moving the origin of gl_FragCoord to the upper left of the window, 268 with y increasing in value toward the bottom of the window. The 269 values returned can also be shifted by half a pixel in both x and y 270 by the <pixel_center_integer> identifier so it appears the pixels 271 are centered at whole number pixel offsets. This moves the (x, y) 272 value returned by gl_FragCoord of (0.5, 0.5) by default, to (0.0, 273 0.0) with <pixel_center_integer>. Redeclarations are done as follows 274 275 in vec4 gl_FragCoord; // redeclaration that changes nothing is allowed 276 277 // All the following are allowed redeclarations that change behavior 278 layout(origin_upper_left) in vec4 gl_FragCoord; 279 layout(pixel_center_integer) in vec4 gl_FragCoord; 280 layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord; 281 282 If gl_FragCoord is redeclared in any fragment shader in a program, 283 it must be redeclared in all the fragment shaders in that program 284 that have a static use of gl_FragCoord. All redeclarations of 285 gl_FragCoord in all fragment shaders in a single program must have 286 the same set of qualifiers. Within any shader, the first 287 redeclarations of gl_FragCoord must appear before any use of 288 gl_FragCoord. The built-in gl_FragCoord is only predeclared in 289 fragment shaders, so redeclaring it in any other shader language 290 will be illegal. 291 292 Redeclaring gl_FragCoord with <origin_upper_left> and/or 293 <pixel_center_integer> qualifiers only affects gl_FragCoord.x and 294 gl_FragCoord.y. It has no affect on rasterization, transformation, 295 or any other part of the OpenGL pipeline or language features." 296 297 298Dependencies on ARB_fragment_program extension 299 300 3.11.3.1 Fragment Attributes 301 302 Modify this paragraph: 303 304 "If a fragment attribute binding matches "fragment.position", the "x" 305 and "y" components of the fragment attribute variable are filled 306 with the (x,y) window coordinates of the fragment center, relative 307 to the lower left corner of the window. The "z" component is filled 308 with the fragment's z window coordinate. This z window coordinate 309 undergoes an implied conversion to floating point. This conversion 310 must leave the values 0 and 1 invariant. The "w" component is 311 filled with the reciprocal of the fragment's clip w coordinate." 312 313 to read: 314 315 "If a fragment attribute binding matches "fragment.position", the "x", 316 "y", "z", and "w" components of the fragment attribute variable are 317 filled with the (f_x,f_y,f_z,f_w) components respectively of the 318 fragment coordinate for the fragment." 319 320 Add this section: 321 322 "3.11.4.5.3 Fragment Coordinate Conventions Fragment Program Options 323 324 These options affect the fragment coordinate conventions specified 325 in the "Shader Inputs" subsection of section 3.11. 326 327 If a fragment program specifies one of the option 328 "ARB_fragment_coord_origin_upper_left", the fragment processing origin 329 convention is upper-left (and otherwise is lower-left) for purposes of 330 computing the fragment coordinate when the fragment program executes. 331 332 If a fragment program specifies one of the option 333 "ARB_fragment_coord_pixel_center_integer", the fragment processing 334 pixel-center convention is integer (and otherwise is half-integer) 335 for purposes of computing the fragment coordinate when the fragment 336 program executes." 337 338Dependencies on NV_fragment_program extension 339 340 When this extension is supported, modify the NV_fragment_program 341 grammar to include: 342 343 <program> ::= <progPrefix> <optionSequence> <instructionSequence> "END" 344 345 <optionSequence> ::= <optionSequence> <option> 346 | "" 347 348 <option> ::= "OPTION" "ARB_fragment_coord_origin_upper_left" ";" 349 | "OPTION" "ARB_fragment_coord_pixel_center_integer" ";" 350 351 352 Section 3.11.1.1, Fragment Program Attribute Registers 353 354 Modify this paragraph: 355 356 "f[WPOS].x and f[WPOS].y hold the (x,y) window coordinates of the 357 fragment center, and relative to the lower left corner of the window. 358 f[WPOS].z holds the associated z window coordinate, normally in the 359 range [0,1]. f[WPOS].w holds the reciprocal of the associated clip 360 w coordinate." 361 362 to read: 363 364 "The f[WPOS] register holds the components (x_f,y_f,z_f,w_f) 365 respectively of the fragment coordinate described in the "Shader 366 Inputs" subsection of section 3.11 (Fragment Shaders). 367 368 If the ARB_fragment_coord_origin_upper_left OPTION is specified, the 369 fragment processing origin convention is upper-left (and otherwise 370 is lower-left) for purposes of computing the fragment coordinate 371 when the fragment program executes. 372 373 If the ARB_fragment_coord_pixel_center_integer OPTION is specified, 374 the fragment processing pixel-center convention is integer (and 375 otherwise is half-integer) for purposes of computing the fragment 376 coordinate when the fragment program executes." 377 378Dependencies on NV_fragment_program4 extension 379 380 The language this extension adds for the ARB_fragment_program extension 381 also applies to the NV_fragment_program4 extension. Specifically: 382 383 The language added to section 3.11.3.1 (Fragment Attributes) 384 replaces corresponding language in section 2.X.3.2 (Program Attribute 385 Variables). 386 387 The language added to section 3.11.4.5.3 (Fragment Coordinate 388 Conventions Fragment Program Options) belongs in section 2.X.5.Y 389 (Fragment Program Options) of the NV_fragment_program4 extension. 390 391Dependencies on ARB_compatibility 392 393 If ARB_compatibility is not supported, delete the clause 394 "which is the result of the product of the projection matrix and the 395 vertex's eye coordinates" in the sentence describing the computation of 396 1/w, in section 3.9.2. 397 398Errors 399 400 None 401 402New State 403 404 None 405 406New Implementation Dependent State 407 408 None 409 410Issues 411 412 1. What should this extension be called? 413 414 RESOLVED: ARB_fragment_coord_conventions. 415 416 We use "fragment" instead of "frag" in the name because other 417 extension names (ARB_fragment_program, ARB_fragment_shader) 418 use the term fragment. 419 420 We use "coord" to match the EXT_fog_coord extension's naming. 421 422 We use "conventions" because the extension provides two alternative 423 choices of convention: upper-left origin (instead of lower-left) 424 and integer pixel center locations (instead of half-integer). 425 426 2. To what scope of OpenGL functionality should this extension apply? 427 428 RESOLVED: This extension is limited to how the XY window-space 429 coordinates available to fragment shaders and programs are 430 computed. 431 432 This extension does NOT affect other 2D window coordinates such 433 as those passed to the glViewport, glReadPixels, glCopyPixels, 434 or glWindowsPos commands. 435 436 3. What is the primary goal of this extension have? 437 438 RESOLVED: The goal is to increase the cross-API portability 439 of fragment shaders. Most fragment shader inputs (texture 440 coordinate sets, colors) are treated identically among OpenGL 441 and other 3D APIs such as the various versions of Direct3D. 442 The chief exception is the fragment coordinate XY values which 443 depend on the 3D API's particular window space conventions. 444 445 We seek to avoid situations where shader source code must 446 be non-trivially modified to support differing window-space 447 conventions. We also want minimize the performance effect on 448 fragment shader execution. Rather than an application modifying 449 the shader source to add extra operations and parameters/uniforms 450 to adjust the native window coordinate origin, we want to control 451 the hardware's underlying convention for how the window origin 452 is provided to the shader. 453 454 4. Should this extension provide an API for programmatically 455 specifying a global or per-program/shader setting for the window 456 coordinate origin? 457 458 RESOLVED: No, the fragment coordinate conventions are specified 459 within the GLSL fragment shader or assembly source text only. 460 461 The choice of convention for the fragment coordinate is best 462 specified within the program. 463 464 Having a hierarchy of alternative ways to specify the window 465 coordinate origin makes this extension more cumbersome than 466 necessary and increases driver validation overhead. 467 468 The expectation is that a fragment shader authored for an API 469 with alternative fragment coordinate conventions is converted 470 into an OpenGL fragment shader. In this case, it's natural to 471 simply provide a way within the shader to express the originally 472 intended fragment coordinate convention. 473 474 5. Should this extension allow the pixel-center and origin choices 475 to be specified orthogonally? 476 477 RESOLVED: Yes. 478 479 Direct3D versions prior to DirectX 10 have an integer pixel-center 480 convention while DirectX 10 has a half-integer pixel-center 481 convention though all Direct3D versions use the upper-left origin. 482 483 While RenderMan lacks access to a fragment coordinate during 484 shading, it uses an upper-left origin while the half-integer 485 pixel-center convention is most consistent with RenderMan's 486 rendering operation. 487 488 The upper-left origin convention in combination with the 489 half-integer pixel-center convention is also interesting for 490 developing compositing window systems since window systems 491 typically assume an upper-left origin but compositing operations 492 based on texture mapping works best with half-integer pixel-center 493 convention. 494 495 6. Should there be pragmas and OPTIONs for specifying both the OpenGL 496 convention and the non-OpenGL convention? 497 498 RESOLVED: Just provide pragmas and OPTIONS for the non-OpenGL 499 conventions. This avoids have to specify how multiple inconsistent 500 conventions are resolved. Inconsistent conventions are more 501 problematic for GLSL because multiple shader objects may be 502 specified with inconsistent conventions and the inconsistency is 503 then deferred until program object linking. 504 505 Just allowing the non-OpenGL convention to be specified is simpler. 506 For GLSL, if any shader object has a non-OpenGL convention 507 specified, the convention applies to the linked program object. 508 509 7. Does this extension apply to the NV_fragment_program_option and 510 NV_fragment_program2 extensions? 511 512 RESOLVED: Yes. These two extensions depend on the 513 ARB_fragment_program extension grammar which this extension 514 amends. 515 516 8. Should there be any API for querying the fragment coordinate 517 conventions a given GLSL fragment shader or assembly fragment 518 program requests? 519 520 RESOLVED: No. 521 522 There are not queries for other pragmas and OPTIONs. 523 524 The text for the shader or program can be queried and it is easy 525 enough to parse the text to determine the behavior of the program. 526 527 9. This extension adds no new command or new tokens. Is that ok? 528 529 RESOLVED: Yes. The functionality of this extension is exercised 530 by enabling extensions and OPTIONs in fragment shader/program source 531 text. If the extension string is advertised, you can assume the 532 specified syntax is parsed and put into effect. 533 534 10. Does the window origin convention apply to EXT_framebuffer_object 535 (FBO) and pixel buffer (pbuffer) rendering as well as window 536 rendering? 537 538 RESOLVED: Yes. 539 540 11. Should this instead be a global state at the API level? This 541 means that, among other things, it will also affect the fixed 542 function pipeline? 543 544 RESOLVED: The scope of this extension deals *only* with how the 545 fragment coordinate XY location appears during programming 546 fragment processing. 547 548 See the Overview's third paragraph for the rationale for this 549 extension's scope. 550 551 12. For an implementation that does compile-time compilation (as 552 opposed to link-time or on-the-fly compilation), this would 553 appear to require the compiler to emit code to do the 554 transformation using internal uniforms regardless of whether it 555 is needed or not, because any other shader that it is linked 556 against may enable the pragma. 557 558 Some possible alternatives, none of which is caveat-free: 559 a) Require all fragment shaders to be consistent in the presence 560 or absence of the pragma. That makes it impossible to link a 561 shader written with the pragma against a stock shader that 562 doesn't do anything with gl_FragCoord. 563 b) Apply the pragma only within the shader it appears in. That 564 removes the spooky action at a distance (where linking another 565 shader in changes the behaviour of an existing one) - but if 566 your hardware has some magic knobs to implement these pragmas, 567 that may no longer be sufficient if there are multiple 568 flavours of gl_FragCoord in the same program. 569 c) Make this global state. See Issue 11. 570 571 RESOLVED: Because this extension's pragmas only support requesting 572 a half-pixel fragment coordinate system and/or an upper-left 573 coordinate system, there is no way for multiple fragment shader 574 objects to specify an inconsistent fragment coordinate system. 575 This means for a given set of fragment shaders being linked 576 into a program object, there is exactly one fragment coordinate 577 convention. 578 579 (Fragment coordinate conventions are parsed and ignored for 580 non-fragment shader objects. Generating a warning in the info 581 log when the pragma is ignored by non-fragment shader objects is 582 a reasonable response in this situation.) 583 584 Option b is not desirable because there should be exactly one 585 convention within a single linked program object. Each fragment 586 shader object linked within a program object should not be allowed 587 its own convention. The expected usage is shaders written for 588 DirectX 9 or 10 will be compiled with these pragmas appropriately; 589 such shaders only need one convention. This extension assumes 590 implementations supporting this extension likely have hardware 591 modes that support both the OpenGL, DirectX 9, and DirectX 10 592 conventions for a given fragment shader without require extra 593 hidden uniforms. 594 595 Option c is not desirable because the fragment coordinate 596 convention really is a property of each shader rather than 597 global state. A shader assuming OpenGL's conventional lower-left 598 convention expects to be able to add (0,1) to the fragment's 599 (x,y) location and move "up" a pixel. Whereas a similar shader 600 coded for Direct3D would assume adding (0,1) to the fragment's 601 (x,y) would move "down" a pixel. Controlling the fragment 602 coordinate convention from a global state setting is irrelevant to 603 fixed-function processing (where the fragment coordinate position 604 is never available). 605 606 NOTE: much of the above discussion is largely irrelevant now that 607 this extension uses layout qualifiers. As noted in the 608 shading language additions above, all redeclarations of gl_FragCoord 609 must use the same set of qualifiers. If a shader does not have a 610 static use of gl_FragCoord it doesn't need to redeclare it. It is 611 link-time error if multiple compilation units have inconsistent 612 qualifiers. 613 614 13. Is this "pragma" enough to provide DX compatibility? The 615 following items may need to be addressed as well: 616 a) edge rule: because of the y-inversion, rendering in DX mode or 617 OGL mode is not equivalent (upper and lower edges are not 618 rendered the same) 619 b) gl_FragCoord value: this is addressed by this proposal 620 c) viewport/scissor: if the shader is changed, it seems that 621 there will be a mismatch with the value given to 622 viewport/scissor which need to have the y-inversion as well. 623 d) face ordering: if this adjusts the viewport, it will 624 implicitly toggle the face ordering between CW and CCW. 625 e) sample position? 626 627 RESOLVED: The scope of this extension deals *only* with how 628 the fragment coordinate XY location appears during programming 629 fragment processing. 630 631 Trying to address these is a much bigger undertaking than was 632 intended here, and is precisely why it was speced this way (to 633 avoid touching these issues). 634 635 See the Overview's third paragraph for the rationale for this 636 extension's scope. 637 638 14. Could this instead be done with functions (built-in or otherwise) 639 in GLSL? Since the purpose of this extension seems to be to 640 *ONLY* modify the gl_FragCoord when accessed in the fragment 641 shader, couldn't one just write a GLSL function which does the 642 same thing? 643 644 RESOLVED: The scope of this extension is really limited to 645 support the straightforward translation of shaders written assuming 646 Direct3D's fragment coordinate conventions into OpenGL. 647 648 The intent is NOT to allow multiple conventions to be used with 649 in the fragment domain of a single program object. 650 651 The intent is also to support Direct3D's fragment coordinate 652 conventions in a way that can leverage existing hardware modes 653 used to support both OpenGL and Direct3D. This is desirable 654 because it avoids the introduction of extra "hidden" uniforms 655 (to store a value such as the current window height). 656 657 If you support a "different" gl_FragCoord or provide a function 658 to return a Direct3D-style fragment coordinate, that introduces 659 the possibility that multiple fragment coordinate conventions can 660 exist in the same fragment shader program. The pragma approach 661 precludes this. 662 663 15. Is the intent that the window origin convention is automatically 664 adjusted for onscreen (in a window) vs offscreen rendering (FBOs 665 or pbuffers)? ie if you have a fragment shader which is used with 666 both onscreen and offscreen rendering is it the application's 667 responsibility to track this and specify the appropriate window 668 convention (and potentially recompile the shader), or does this 669 happen automatically. 670 671 RESOLVED: The fragment coordinate convention is specified with 672 respect to OpenGL window coordinates. 673 674 This means developers don't need to be aware if they are rendering 675 to a framebuffer object (FBO), pixel buffer (pbuffer), or window. 676 677 The application doesn't have to "track" how the fragment shader 678 is used. 679 680 The expectation is that there is no need to recompile a fragment 681 shader as the expectation is hardware modes exist to control the 682 window space origin appropriately. 683 684 16. Is there another way this could be specified other than a 685 #pragma? Some people aren't keen on the use of a pragma for this. 686 Other possibilities include providing a renamed gl_FragCoord with 687 the different semantics, or allowing gl_FragCoord to be redefined 688 in the shader with the desired qualifiers (similar to the 689 invariant qualifier)? 690 691 RESOLVED: Yes. This has been recast to use layout qualifiers 692 originally introduced in GLSL 1.40 and extended in GLSL 1.50. 693 However note that it is the intent of this extension to stand 694 separately from the GLSL 1.40/1.50 and it is desinged to be 695 implementable against GLSL 1.10 or 1.20. 696 697 17. If this extension doesn't actually change how the window space 698 positions are calculated and *only* modifies the gl_FragCoord 699 which is visible in the fragment shader/program, how does this 700 actually help an application which is using shaders which have 701 the assumption of integer pixel centers baked in (and thus 702 manually adjusting for the 0.5 offset) and which aren't accessing 703 gl_FragCoord (or equivalent) directly? 704 705 RESOLVED: The scope of this extension deals *only* with how 706 the fragment coordinate XY location appears during programming 707 fragment processing. 708 709 See the Overview's third paragraph for the rationale for this 710 extension's scope. 711 712 This extension simplifies the complicating task of converting 713 OpenGL-style (lower-left, half-pixel) fragment coordinates to 714 Direct3D-style fragment coordinates in a way that allows existing 715 hardware mechanisms to support both OpenGL and Direct3D's 716 conventions to be leveraged. In particular, "hidden" uniforms to 717 track the current window height can be avoided when this is often 718 already maintained by the hardware. 719 720Revision History 721 722 Rev. Date Author Changes 723 ---- -------- --------- ---------------------------------------- 724 1 1/08/07 mjk Initial version 725 2 11/5/08 mjk Feedback from Destineer 726 3 3/27/09 dgkoch Add issue 11 727 4 5/01/09 dgkoch fix typo, add discussion on issue 11 728 add issues 12,13 based on comments from PB and BM 729 5 5/07/09 dgkoch Update issue 13, add issues 14-17 730 6 5/11/09 mjk Work with Daniel Koch too: 731 Improve overview to clarify the extension's scope 732 Add resolutions to issues 11 through 17 733 Change language to make clear that pragmas apply 734 to fragment shaders only; they are accepted but 735 totally ignored for other shader types 736 7 5/15/09 dgkoch fix date and a few typos 737 8 5/19/09 dgkoch renamed as ARB extension 738 9 6/26/09 dgkoch add #extension mechanism 739 recast GLSL using layout qualifiers as in GLSL 1.50 740 synced up with GL3.2 changes/rebased on GL3.1 741 updated some issue resolutions 742 added interactions with ARB_compatibility 743 10 8/02/09 Jon Leech Reformat to 80 columns and assign ARB 744 extension number. 745 746