1Name 2 3 EXT_shader_framebuffer_fetch 4 5Name Strings 6 7 GL_EXT_shader_framebuffer_fetch 8 GL_EXT_shader_framebuffer_fetch_non_coherent 9 10Contact 11 12 Benj Lipchak, Apple (lipchak 'at' apple.com) 13 14Contributors 15 16 Francisco Jerez, Intel 17 18Status 19 20 Complete 21 22Version 23 24 Last Modified Date: September 6, 2018 25 Author Revision: 8 26 27Number 28 29 OpenGL ES Extension #122 30 OpenGL Extension #520 31 32Dependencies 33 34 OpenGL 2.0 or OpenGL ES 2.0 is required. 35 36 This specification is written against the OpenGL ES 2.0.24 and OpenGL ES 37 3.0.4 specifications. This extension is written against the OpenGL ES 38 Shading Language 1.0.17 and OpenGL ES Shading Language 3.00.3 39 specifications. 40 41 OpenGL 2.0, OpenGL 3.0, OpenGL 4.0, OpenGL 4.5, OpenGL ES 2.0, OpenGL ES 42 3.0, OpenGL ES 3.1 and OpenGL ES 3.2 affect the definition of this 43 extension. 44 45 ARB_sample_shading and OES_sample_shading interact with this extension. 46 47Overview 48 49 Conventional OpenGL blending provides a configurable series of operations 50 that can be used to combine the output values from a fragment shader with 51 the values already in the framebuffer. While these operations are 52 suitable for basic image compositing, other compositing operations or 53 operations that treat fragment output as something other than a color 54 (normals, for instance) may not be expressible without multiple passes or 55 render-to-texture operations. 56 57 This extension provides a mechanism whereby a fragment shader may read 58 existing framebuffer data as input. This can be used to implement 59 compositing operations that would have been inconvenient or impossible with 60 fixed-function blending. It can also be used to apply a function to the 61 framebuffer color, by writing a shader which uses the existing framebuffer 62 color as its only input. 63 64 This extension provides two alternative name strings: 65 66 - GL_EXT_shader_framebuffer_fetch guarantees full coherency between 67 framebuffer reads and writes. If this extension string is exposed, the 68 result of reading from the framebuffer from a fragment shader invocation 69 is guaranteed to reflect values written by any previous overlapping 70 samples in API primitive order, unless requested otherwise in the shader 71 source using the noncoherent layout qualifier. 72 73 - GL_EXT_shader_framebuffer_fetch_non_coherent provides limited implicit 74 coherency guarantees. Instead, the application is expected to call the 75 FramebufferFetchBarrierEXT command for previous framebuffer writes to 76 become visible to subsequent fragment shader invocations. For this 77 extension to give well-defined results applications may have to split 78 rendering into multiple passes separated with FramebufferFetchBarrierEXT 79 calls. The functionality provided by this extension is requested in the 80 shader source using the noncoherent layout qualifier. 81 82Issues 83 84 1. How is framebuffer data treated during multisample rendering? 85 86 RESOLVED: Reading the value of gl_LastFragData produces a different 87 result for each sample. This implies that all or part of the shader be 88 run once for each sample, but has no additional implications on fragment 89 shader input variables which may still be interpolated per pixel by the 90 implementation. 91 92 2. How does the use of gl_LastFragData interact with fragment discard? 93 94 RESOLVED: Hardware may not necessarily support discarding on sample 95 granularity depending on API version and extension support. Therefore, 96 three options were considered for this functionality: 97 98 A) Allow discard based on variables calculated using the framebuffer 99 color when multisample rasterization is disabled, but disallow 100 discard in this manner when multisample rasterization is enabled. 101 102 B) Restrict usage of the framebuffer color until it is known whether 103 or not the pixel will be discarded. 104 105 C) Allow undefined results for fragment shaders that discard on a 106 per-sample basis on hardware that doesn't support it. 107 108 This extension has chosen option C where support for per-sample discard 109 is not provided by the GL. Restricting orthogonality of fragment shaders 110 between single-sample and multisample rendering is undesirable, as is 111 restricting usage of the framebuffer color, which can generally only be 112 done with detailed flow-control analysis. 113 114 If an overlapping specification guarantees well-defined results for 115 shaders that execute discard with sample granularity (e.g. 116 ARB_sample_shading), this extension won't reverse that guarantee, instead 117 the boolean query FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT defined by this 118 extension will return TRUE for consistency with current specifications. 119 120 3. What is the precision of gl_LastFragData in practice? 121 122 RESOLVED: Three options were considered for this functionality: 123 124 A) gl_LastFragData is always mediump. 125 126 B) gl_LastFragData takes the precision most closely matching the 127 actual storage format of the framebuffer. 128 129 C) Allow redeclaration of gl_LastFragData in order to change its 130 precision. 131 132 This extension has chosen option C. A fixed precision per option A 133 increases the likelihood of redundant conversion operations in the shader, 134 and option B does not provide for clear behavior with regard to the 135 precision of intermediate results from calculations using the 136 framebuffer color. 137 138 4. How does this extension iteract with conventional blending? 139 140 RESOLVED: There is no interaction. The two remain orthogonal. The rest 141 of the pipeline continues as usual after the fragment shader stage. 142 143 144 5. How does this extension work in ES 3.0? 145 146 RESOLVED: Differently than in ES 2.0. 147 148 The built-in fragment outputs of ES 2.0 are replaced in #version 300 es 149 shaders by user-declared outputs, to accomodate integer and MRT 150 framebuffers. Three options were considered: 151 152 A) Add built-ins similar to gl_LastFragData. 153 154 B) Add a layout to mark user-declared fragment outputs as having 155 defined content on entry to fragment shader. 156 157 C) Allow marking user-declared fragment outputs as "inout". 158 159 This extension has chosen option C. Adding built-ins per option A is 160 unwieldy for MRT framebuffers with mixed attachment types and precisions. 161 Options B and C are semantically identical, but C requires fewer 162 modifications to the specification and to user shaders. Note that the 163 inout qualifier is not allowed for re-declaring existing fragment outputs 164 such as gl_FragDepth. 165 166 6. How does this extension interact with sRGB rendering? 167 168 RESOLVED: If the current GL state would cause the corresponding destination 169 color to be converted from sRGB to linear at input to blending, 170 gl_LastFragData or fragment outputs with the inout storage qualifier will 171 contain framebuffer values converted from sRGB to linear upon entry to the 172 fragment shader. 173 174 7. How does this extension interact with derivative built-in functions? 175 176 RESOLVED: There is no direct interaction in principle, but because the 177 result of framebuffer fetch is undefined for helper invocations, derivative 178 functions may give non-deterministic results when the argument is dependent 179 on values read from the framebuffer. 180 181 To overcome this limitation the application may be able to calculate the 182 derivative of gl_HelperInvocation in order to determine whether any of the 183 invocations involved in the calculation are helper invocations, which 184 would invalidate the result of the same derivative applied to any 185 expression dependent on values read from the framebuffer. In particular, 186 if either dFdx(float(gl_HelperInvocation)) or 187 dFdy(float(gl_HelperInvocation)) is zero, the corresponding derivative of 188 a value read from the framebuffer should be well-defined. 189 190 8. Should we require the behavior of framebuffer fetch to be well-defined 191 for helper invocations in order to support calculating derivatives of 192 color outputs without restrictions? 193 194 RESOLVED: Not in this extension. It would be compelling from the 195 perspective of the API, and likely more consistent with the current 196 behavior of texture sampling and image loads for helper invocations, but 197 hardware support may be limited. With the non-coherent variant of this 198 extension there is the additional difficulty that derivatives could still 199 give non-deterministic results, because there is no way for the application 200 to determine whether there will be overlap between helper invocations and 201 previous rendering done in the same pass, since the set of helper 202 invocations executed during rendering is fully defined by the 203 implementation. 204 205 9. How should the implementation behave where framebuffer fetch coherency 206 cannot be enabled selectively for each fragment output due to hardware 207 or software limitations? 208 209 RESOLVED: Because the behavior specified for coherent framebuffer fetch 210 outputs is a strict subset of the behavior of non-coherent outputs, the 211 implementation is free to ignore any noncoherent layout qualifiers and 212 enable coherency globally when the fragment shader bound to the pipeline 213 has any color outputs requiring framebuffer fetch coherency. 214 215 10. Should the current coherent memory qualifier be reused to indicate 216 whether the application requires framebuffer fetch coherency for a given 217 fragment output? 218 219 RESOLVED: No, because that would imply breaking GLSL source-level 220 compatibility with earlier versions of the EXT_shader_framebuffer_fetch 221 extension. That said, it may make sense to reconsider this syntactic 222 compromise if this extension is used as starting point for another 223 specification text (e.g. a derived ARB/KHR extension). 224 225New Procedures and Functions 226 227 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 228 supported. ]] 229 230 void FramebufferFetchBarrierEXT(void); 231 232New Tokens 233 234 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 235 and GetDoublev: 236 237 FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT 0x8A52 238 239New Builtin Variables 240 241 [[ The following applies to OpenGL Shading Language 1.1 and 1.2 only. ]] 242 243 vec4 gl_LastFragData[gl_MaxDrawBuffers]; 244 245 [[ The following applies to OpenGL ES Shading Language 1.0 only. ]] 246 247 mediump vec4 gl_LastFragData[gl_MaxDrawBuffers] 248 249Changes to the OpenGL ES 2.0.24 Specification, Chapter 3 250 251 Remove the last sentence of Paragraph 2 of Section 3.8.1, page 84 ("These 252 built-in varying variables include [...]" and add: 253 254 These built-in varying variables include the fragment's position, eye z 255 coordinate, and front-facing flag, as well as the last data or color value 256 written to the framebuffer. When the value of SAMPLE_BUFFERS is 1 and the 257 current framebuffer color is accessed in the fragment shader, the fragment 258 shader will be invoked separately for each covered sample and a separate 259 value for the previous framebuffer color will be provided for each sample." 260 261 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 262 supported. ]] 263 264 Append new paragraph at the end of section 3.8.2, page 197 ("Shader 265 Execution"): 266 267 "The command 268 269 void FramebufferFetchBarrierEXT(void); 270 271 specifies a boundary between passes when reading existing framebuffer data 272 from fragment shaders via the gl_LastFragData built-in variable. Previous 273 framebuffer object writes regardless of the mechanism (including clears, 274 blits and primitive rendering) are guaranteed to be visible to subsequent 275 fragment shader invocations that read from the framebuffer once 276 FramebufferFetchBarrierEXT is executed." 277 278 [[ The following applies if both EXT_shader_framebuffer_fetch and 279 EXT_shader_framebuffer_fetch_non_coherent are supported. ]] 280 281 "Because the implementation guarantees coherency of framebuffer reads and 282 writes for color outputs not explicitly marked with the noncoherent layout 283 qualifier, calling the FramebufferFetchBarrierEXT command is not required 284 unless the application wishes to manage memory ordering of framebuffer 285 reads and writes explicitly, which may provide better performance on some 286 implementations in cases where rendering can be split into multiple passes 287 with non-self-overlapping geometry." 288 289 [[ The following applies to either variant of the extension unless 290 specified otherwise in the interactions sections. ]] 291 292 Add a new subsection to section 3.8.2, page 87 ("Shader Execution"): 293 294 "Discard 295 296 Fragment shaders may conditionally abandon operations using the discard 297 keyword. However, the ability of hardware to support abandoning operations 298 on a single sample when the shader is invoked once for each covered sample 299 is implementation-dependent. This capability can be determined by calling 300 GetBooleanv with the symbolic constant 301 FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT. If FALSE is returned, results from 302 shaders which discard based on per-sample logic are undefined." 303 304Changes to the OpenGL ES 2.0.24 Specification, Chapter 4 305 306 Replace first element of Figure 4.1, page 90 ("Fragment + Associated Data"): 307 308 "Fragment (or sample) + Associated Data" 309 310 Add a new section 4.1.lastfragcolor (Fragment Data Input) - immediately before section 4.1.4 (Stencil Test): 311 312 Prior to fragment shading, if GL_EXT_shader_framebuffer_fetch is enabled, 313 gl_LastFragData[] is populated with the value last written to the 314 framebuffer at the same (x,y,sample) position. 315 316 If the framebuffer attachment corresponding to a given element of 317 gl_LastFragData[] has a fixed-point format, each color component undergoes a 318 conversion to floating-point first. This conversion must leave the values 0 319 and 1 invariant. 320 321 [[If GL_EXT_sRGB is supported]] 322 323 If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING{_EXT} for the 324 framebuffer attachment corresponding to a given element of gl_LastFragData[] 325 is SRGB, 326 327 [[If GL_EXT_sRGB_write_control is supported]] 328 329 330 and FRAMEBUFFER_SRGB_EXT is enabled, 331 332 333 [[End GL_EXT_sRGB_write_control]] 334 335 336 the R, G, and B destination color values 337 (after conversion from fixedpoint to floating-point) are considered to be 338 encoded for the sRGB color space and hence must be linearized first. 339 Each R, G, and B component is converted in the same fashion described for 340 sRGB texture components in section 3.8.16. 341 342 [[End GL_EXT_sRGB]] 343 344New Implementation Dependent State 345 346 Add to table 6.19 (Implementation Dependent Values (cont.)): 347 348 Get Value Type Get Command Minimum Value Description Section 349 --------- ---- ----------- ------------- -------------- ------- 350 FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT B GetBooleanv - Samples may be 3.8.2 351 discarded 352 individually 353 354Changes to the OpenGL ES 3.0.4 Specification, Chapter 3 355 356 Append new paragraphs at the end of the "Shader Outputs" subsection under 357 section 3.9.2, Shader Execution, page 171: 358 359 "Prior to fragment shading, fragment outputs declared inout are populated 360 with the value last written to the framebuffer at the same (x,y,sample) 361 position. If the framebuffer attachment corresponding to an inout fragment 362 output has a fixed-point format, each color component undergoes a 363 conversion to floating-point first. This conversion must leave the values 364 0 and 1 invariant. 365 366 Reading from a user-defined fragment output declared inout causes the 367 shader to be evaluated per-sample, since the framebuffer potentially 368 contains different color values for each sample. 369 370 If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING{_EXT} for the 371 framebuffer attachment corresponding to a given inout fragment output is 372 SRGB (see section 6.1.13)," 373 374 [[If GL_EXT_sRGB_write_control is supported]] 375 376 "and FRAMEBUFFER_SRGB_EXT is enabled," 377 378 [[End GL_EXT_sRGB_write_control]] 379 380 "the R, G, and B destination color values (after conversion from 381 fixed-point to floating-point) are considered to be encoded for the sRGB 382 color space and hence must be linearized first. Each R, G, and B component 383 is converted in the same fashion described for sRGB texture components in 384 section 3.8.16." 385 386 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 387 supported. ]] 388 389 "The command 390 391 void FramebufferFetchBarrierEXT(void); 392 393 specifies a boundary between passes when reading existing framebuffer data 394 from fragment shaders via inout fragment outputs. Previous framebuffer 395 object writes regardless of the mechanism (including clears, blits and 396 primitive rendering) are guaranteed to be visible to subsequent fragment 397 shader invocations that read from the framebuffer once 398 FramebufferFetchBarrierEXT is executed." 399 400 [[ The following applies if both EXT_shader_framebuffer_fetch and 401 EXT_shader_framebuffer_fetch_non_coherent are supported. ]] 402 403 "Because the implementation guarantees coherency of framebuffer reads and 404 writes for color outputs not explicitly marked with the noncoherent layout 405 qualifier, calling the FramebufferFetchBarrierEXT command is not required 406 unless the application wishes to manage memory ordering of framebuffer 407 reads and writes explicitly, which may provide better performance on some 408 implementations in cases where rendering can be split into multiple passes 409 with non-self-overlapping geometry." 410 411Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 3 412 413 Remove Paragraph 2 of section 3.8, page 17, Identifiers ("Identifiers 414 starting with "gl_" are reserved [...]") and add: 415 416 "Identifiers starting with "gl_" are reserved for use by the Shading 417 Language, and may not be declared in a shader as either a variable or a 418 function. However, as noted in the specification, certain predeclared 419 "gl_" names are allowed to be redeclared in a shader for the specific 420 purpose of changing their precision or layout qualifier." 421 422Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 4 423 424 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 425 supported. ]] 426 427 Add a new Section 4.x (Layout Qualifiers) as follows: 428 429 "4.x Layout Qualifiers 430 431 Layout qualifiers can appear with an individual variable declaration: 432 433 <layout-qualifier> <declaration>; 434 435 <layout-qualifier>: 436 layout( <layout-qualifier-id-list> ) 437 438 <layout-qualifier-id-list>: 439 comma separated list of <layout-qualifier-id> 440 441 Declarations of layouts can only be made at global scope, and only where 442 indicated in the following subsection; their details are specific to what 443 the declaration interface is, and are discussed individually. 444 445 The tokens in any <layout-qualifier-id-list> are identifiers, not 446 keywords. Generally they can be listed in any order. Order-dependent 447 meanings exist only if explicitly called out below. Similarly, these 448 identifiers are not case-sensitive, unless explicitly noted otherwise. 449 450 4.x.1 Output Layout Qualifiers 451 452 Fragment shaders may specify the following layout qualifier only for 453 redeclaring the built-in gl_LastFragData array. The allowed layout 454 qualifier identifiers for gl_LastFragData are: 455 456 <layout-qualifier-id>: 457 noncoherent 458 459 Non-coherent framebuffer fetch outputs have relaxed memory ordering 460 requirements and may provide better performance on some implementations, 461 but they require FramebufferFetchBarrierEXT to be called explicitly for the 462 contents rendered to a color attachment to be visible to subsequent 463 fragment shader invocations. Redeclarations are done as follows: 464 465 layout(noncoherent) mediump vec4 gl_LastFragData[gl_MaxDrawBuffers];" 466 467Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 7 468 469 Add after the last sentence of Paragraph 2 of Section 7.2, page 60, 470 Fragment Shader Special Variables ("These variables may be written to 471 more [...]"): 472 473 "... To access the existing framebuffer values (e.g., to implement a 474 complex blend operation inside the shader), fragment shaders should use 475 the read-only input array gl_LastFragData." 476 477 [[ The following applies if EXT_shader_framebuffer_fetch is supported. ]] 478 479 "Unless it has been redeclared with the noncoherent layout qualifier, 480 gl_LastFragData contains the most recent value written to the attachments 481 bound to each color output at the current sample location. Access to 482 gl_LastFragData is optional and can be enabled by 483 484 #extension GL_EXT_shader_framebuffer_fetch : <behavior> 485 486 Where <behavior> is as specified in section 3.4. A new preprocessor 487 define is added to the Shading Language: 488 489 #define GL_EXT_shader_framebuffer_fetch 1" 490 491 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 492 supported. ]] 493 494 "If it has been redeclared with the noncoherent layout qualifier, 495 gl_LastFragData contains the most recent value written to the attachments 496 bound to each color output at the current sample location as long as 497 FramebufferFetchBarrierEXT has been executed between the last command that 498 updated the same location of the framebuffer attachment and the current 499 draw call. Its value is undefined for any outputs whose contents at the 500 current sample location have been modified since the last 501 FramebufferFetchBarrierEXT call. Access to gl_LastFragData and the ability 502 to use the layout(noncoherent) qualifier are optional and can be enabled by 503 504 #extension GL_EXT_shader_framebuffer_fetch_non_coherent : <behavior> 505 506 Where <behavior> is as specified in section 3.4. A new preprocessor 507 define is added to the Shading Language: 508 509 #define GL_EXT_shader_framebuffer_fetch_non_coherent 1" 510 511 [[ The following applies to either variant of the extension but shall be 512 omitted where precision qualifiers are not supported. ]] 513 514 "By default, gl_LastFragData is declared with the mediump precision 515 qualifier. This can be changed by redeclaring the corresponding variables 516 with the desired precision qualifier. 517 518 Redeclarations are done as follows 519 520 // Redeclaration that changes nothing is allowed 521 mediump vec4 gl_LastFragData[gl_MaxDrawBuffers]; 522 523 // All the following are allowed redeclaration that change behavior 524 lowp vec4 gl_LastFragData[gl_MaxDrawBuffers]; 525 highp vec4 gl_LastFragData[gl_MaxDrawBuffers]; 526 527 Redeclarations must not otherwise alter the declared type or array size of 528 gl_LastFragData." 529 530 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 531 supported. ]] 532 533 "Unless the GL_EXT_shader_framebuffer_fetch extension has been enabled in 534 addition, it's an error to use gl_LastFragData if it hasn't been 535 explicitly redeclared with layout(noncoherent)." 536 537Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 8 538 539 Add after paragraph 2 of section 8.7, Texture Lookup Functions, 540 page 57 ("Functions containing the bias parameter [...]"): 541 542 "Results are undefined if the coordinates passed to any of the built-in 543 functions below that compute an implicit LOD value are calculated based on 544 the result of reading from gl_LastFragData, and the texture bound to the 545 specified sampler is mip-mapped." 546 547Changes to the OpenGL Shading Language 1.10 Specification, Chapter 8 548 549 [[ The following applies in addition to the changes given above for the 550 same chapter of the OpenGL ES Shading Language 1.0.17 Specification. ]] 551 552 Append at the end of section 8.8, Fragment Processing Functions, 553 page 59: 554 555 "The result of the built-in derivative functions dFdx, dFdy and 556 fwidth is undefined if the value passed as argument was calculated 557 based on the result of reading from gl_LastFragData." 558 559Changes to the OpenGL ES Shading Language 3.00.3 Specification, Chapter 4 560 561 Modify Paragraph 2 of section 4.3.6: 562 "Except in the fragment stage, there is not an inout storage qualifier at 563 global scope for declaring a single variable name as both input and output 564 [...]" 565 566 Modify Paragraph 7 of section 4.3.6: 567 568 "Fragment outputs output per-fragment data and are declared using the out 569 or inout storage qualifier. It is a compile-time error to use auxiliary 570 storage qualifiers or interpolation qualifiers on an output in a fragment 571 shader [...]" and append new paragraphs at the end of the same section: 572 573 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 574 supported. ]] 575 576 "Fragment outputs declared inout may specify the following layout 577 qualifier: 578 579 <layout-qualifier-id>: 580 noncoherent 581 582 Non-coherent framebuffer fetch outputs have relaxed memory ordering 583 requirements and may provide better performance on some implementations, 584 but they require FramebufferFetchBarrierEXT to be called explicitly for the 585 contents rendered to a color attachment to be visible to subsequent 586 fragment shader invocations." 587 588 [[ The following applies if EXT_shader_framebuffer_fetch is supported. ]] 589 590 "Upon entry to the fragment shader, fragment outputs declared inout not 591 qualified with the noncoherent layout qualifier will contain the most 592 recent value written to the same framebuffer attachment at the current 593 sample location. This behavior and the ability to use the inout qualifier 594 at global scope in a fragment shader is optional and can be enabled by 595 596 #extension GL_EXT_shader_framebuffer_fetch : <behavior> 597 598 Where <behavior> is as specified in section 3.4. A new preprocessor 599 define is added to the Shading Language: 600 601 #define GL_EXT_shader_framebuffer_fetch 1" 602 603 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 604 supported. ]] 605 606 "Upon entry to the fragment shader, fragment outputs declared inout 607 qualified with the noncoherent layout qualifier will contain the most 608 recent value written to the same framebuffer attachment at the current 609 sample location, as long as FramebufferFetchBarrierEXT has been executed 610 between the last command that updated the framebuffer location and the 611 current draw call. The initial value is undefined for any fragment outputs 612 declared inout whose contents at the current sample location have been 613 modified since the last FramebufferFetchBarrierEXT call. This behavior and 614 the ability to use the inout and layout(noncoherent) qualifiers at global 615 scope in a fragment shader are optional and can be enabled by 616 617 #extension GL_EXT_shader_framebuffer_fetch_non_coherent : <behavior> 618 619 Where <behavior> is as specified in section 3.4. A new preprocessor 620 define is added to the Shading Language: 621 622 #define GL_EXT_shader_framebuffer_fetch_non_coherent 1" 623 624 [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is 625 supported. ]] 626 627 "It is an error to declare an inout fragment output not qualified with 628 layout(noncoherent) if the GL_EXT_shader_framebuffer_fetch extension hasn't 629 been enabled." 630 631Changes to the OpenGL ES Shading Language 3.00.3 Specification, Chapter 7 632 633 [[ The following shall be omitted if the changes given below for the same 634 chapter of the OpenGL ES Shading Language 3.10.4 Specification apply. ]] 635 636 Append at the end of section 7.2, Fragment Shader Special Variables, page 637 82: 638 639 "A helper invocation is a fragment shader invocation that is created solely 640 for the purposes of evaluating derivatives for the built-in functions 641 texture() (section 8.9 "Texture Functions"), dFdx(), dFdy(), and fwidth() 642 for other non-helper fragment shader invocations. 643 644 Fragment shader helper invocations execute the same shader code as 645 non-helper invocations, but will not have side effects that modify the 646 framebuffer or other shader-accessible memory. In particular fragments 647 corresponding to helper invocations are discarded when shader execution is 648 complete, without updating the framebuffer. The values returned when 649 reading from the framebuffer via inout fragment outputs are undefined for 650 helper invocations. 651 652 Helper invocations may be generated for pixels not covered by a primitive 653 being rendered. While fragment shader inputs qualified with "centroid" are 654 normally required to be sampled in the intersection of the pixel and the 655 primitive, the requirement is ignored for such pixels since there is no 656 intersection between the pixel and primitive. 657 658 Helper invocations may also be generated for fragments that are covered by 659 a primitive being rendered when the fragment is killed by early fragment 660 tests or where the implementation is able to determine that executing the 661 fragment shader would have no effect other than assisting in computing 662 derivatives for other fragment shader invocations. The set of helper 663 invocations generated when processing any set of primitives is 664 implementation-dependent." 665 666Changes to the OpenGL ES Shading Language 3.10.4 Specification, Chapter 7 667 668 Modify the first bullet point of paragraph 11 of section 7.1.2, Fragment 669 Shader Special Variables, page 96: 670 671 "* Fragments corresponding to helper invocations are discarded when shader 672 execution is complete, without updating the framebuffer. The values 673 returned when reading from the framebuffer via inout fragment outputs 674 are undefined for helper invocations." 675 676Interactions with OpenGL 2.0 677 678 If OpenGL 2.0 is supported, all changes given above for the OpenGL ES 679 2.0.24 and OpenGL ES Shading Language 1.0.17 specifications shall be 680 applied, in addition to any changes given specifically for the OpenGL 681 Shading Language 1.10 Specification. References to precision qualifiers 682 shall be omitted. 683 684Interactions with OpenGL 3.0 and later 685 686 If OpenGL 3.0 is supported, all changes given above for the OpenGL ES 3.0.4 687 and OpenGL ES Shading Language 3.00.3 specifications shall be applied. 688 Changes given for earlier OpenGL ES and OpenGL ES Shading Language versions 689 shall be ignored. References to auxiliary storage qualifiers shall be 690 omitted if they are not supported by the Shading Language. 691 692Interactions with OpenGL 4.0 and later 693 694 The interaction described below with ARB_sample_shading applies in 695 addition to any interactions enumerated for OpenGL 3.0 and above. 696 697Interactions with OpenGL 4.5 and later 698 699 The changes given above for the OpenGL Shading Language 3.10.4 700 Specification shall be applied in addition to any interactions enumerated 701 for OpenGL 4.0 and above. 702 703Interactions with OpenGL ES 2.0 704 705 If OpenGL ES 2.0 is supported, apply all changes given above for the OpenGL 706 ES 2.0.24 and OpenGL ES Shading Language 1.0.17 specifications. 707 708Interactions with OpenGL ES 3.0 and later 709 710 If OpenGL ES 3.0 is supported, all changes given above for the OpenGL ES 711 3.0.4 and OpenGL ES Shading Language 3.00.3 specifications shall be 712 applied. Changes given for earlier OpenGL ES and OpenGL ES Shading 713 Language versions shall be ignored. References to auxiliary storage 714 qualifiers shall be omitted if they are not supported by the Shading 715 Language. 716 717Interactions with OpenGL ES 3.1 and later 718 719 The changes given above for the OpenGL Shading Language 3.10.4 720 Specification shall be applied in addition to any interactions enumerated 721 for OpenGL ES 3.0 and above. 722 723Interactions with OpenGL ES 3.2 and later 724 725 The interaction described below with OES_sample_shading applies in 726 addition to any interactions enumerated for OpenGL ES 3.1 and above. 727 728Interactions with OES_standard_derivatives 729 730 Results from shaders which use the built-in derivative functions dFdx, 731 dFdy, and fwidth on variables calculated using the current framebuffer 732 color are undefined. 733 734Interactions with ARB_sample_shading and OES_sample_shading 735 736 The FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT query defined above is guaranteed 737 to return TRUE if any of these extensions is supported, since they 738 already provide well-defined behavior for discard jumps with sample 739 granularity. 740 741Revision History 742 743 Version 8, 2018/09/06 - Replace non-ASCII quote characters. 744 Version 7, 2017/11/13 - Specify interactions with desktop OpenGL APIs. 745 - Specify interaction with ARB/OES_sample_shading 746 and unextended GL versions that provide the same 747 functionality. Clarify resolution of 748 multisampling-related issues to avoid 749 contradicting recent versions of the spec. 750 - Explicitly require per-sample evaluation of the 751 fragment shader when an inout output is read in 752 OpenGL ES 3.0 and above. 753 - Specify undefined behavior of helper invocations 754 in OpenGL ES 3.0 and above. Add discussion 755 related to derivative computations in the issues 756 section. 757 - Specify undefined behavior of texture lookup 758 functions that compute implicit derivatives in 759 OpenGL (ES) 2.0. 760 - Define EXT_shader_framebuffer_fetch_non_coherent 761 variant of the extension. Add 762 FramebufferFetchBarrierEXT command. Define 763 noncoherent layout qualifier for finer-grained 764 control of framebuffer fetch coherency. 765 Version 6, 2017/10/04 - Clarified how gl_LastFragData is populated. 766 Version 5, 2016/09/08 - Added preprocessor defines. 767 Version 4, 2013/05/28 - Added ES3 interaction as requested in Bug 10236 768 Version 3, 2012/09/24 - Remove obsolete issue 3 about derivatives 769 Version 2, 2012/06/21 - Fix MULTISAMPLE enabled -> SAMPLE_BUFFERS = 1, 770 recast from APPLE to multivendor EXT, clarify that 771 gl_LastFragData reflects value written by previous 772 pixel at same coordinates. 773 Version 1, 2012/06/01 - Conversion from ARB_sync to APPLE_sync for ES. 774