1Name 2 3 KHR_blend_equation_advanced 4 5Name Strings 6 7 GL_KHR_blend_equation_advanced 8 GL_KHR_blend_equation_advanced_coherent 9 10Contact 11 12 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 13 14Notice 15 16 Copyright (c) 2012-2015 The Khronos Group Inc. Copyright terms at 17 http://www.khronos.org/registry/speccopyright.html 18 19Specification Update Policy 20 21 Khronos-approved extension specifications are updated in response to 22 issues and bugs prioritized by the Khronos OpenGL and OpenGL ES Working Groups. For 23 extensions which have been promoted to a core Specification, fixes will 24 first appear in the latest version of that core Specification, and will 25 eventually be backported to the extension document. This policy is 26 described in more detail at 27 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 28 29Contributors 30 31 OpenGL ES Working Group in Khronos 32 Jeff Bolz, NVIDIA Corporation 33 Mathias Heyer, NVIDIA Corporation 34 Mark Kilgard, NVIDIA Corporation 35 Daniel Koch, NVIDIA Corporation 36 Rik Cabanier, Adobe 37 Slawek Grajewski, Intel 38 39Status 40 41 Complete. 42 Ratified by the Khronos Board of Promoters on 2014/03/14. 43 44Version 45 46 Last Modified Date: February 14, 2018 47 Revision: 17 48 49Number 50 51 ARB Extension #174 52 OpenGL ES Extension #168 53 54Dependencies 55 56 This extension is written against the OpenGL 4.1 Specification 57 (Compatibility Profile). 58 59 This extension is written against the OpenGL Shading Language 60 Specification, Version 4.10 (Revision 6). 61 62 OpenGL 2.0 is required (for Desktop). 63 64 OpenGL ES 2.0 is required (for mobile). 65 66 EXT_blend_minmax is required (for mobile). 67 68 This extension interacts with OpenGL 4.0. 69 70 This extension interacts with OpenGL 4.1 (Core Profile). 71 72 This extension interacts with OpenGL 4.3 or later. 73 74 This extension interacts with OpenGL ES 2.0. 75 76 This extension interacts with OpenGL ES 3.0. 77 78 This extension interacts with NV_path_rendering. 79 80Overview 81 82 This extension adds a number of "advanced" blending equations that can be 83 used to perform new color blending operations, many of which are more 84 complex than the standard blend modes provided by unextended OpenGL. This 85 extension provides two different extension string entries: 86 87 - KHR_blend_equation_advanced: Provides the new blending equations, but 88 guarantees defined results only if each sample is touched no more than 89 once in any single rendering pass. The command BlendBarrierKHR() is 90 provided to indicate a boundary between passes. 91 92 - KHR_blend_equation_advanced_coherent: Provides the new blending 93 equations, and guarantees that blending is done coherently and in API 94 primitive order. An enable is provided to allow implementations to opt 95 out of fully coherent blending and instead behave as though only 96 KHR_blend_equation_advanced were supported. 97 98 Some implementations may support KHR_blend_equation_advanced without 99 supporting KHR_blend_equation_advanced_coherent. 100 101 In unextended OpenGL, the set of blending equations is limited, and can be 102 expressed very simply. The MIN and MAX blend equations simply compute 103 component-wise minimums or maximums of source and destination color 104 components. The FUNC_ADD, FUNC_SUBTRACT, and FUNC_REVERSE_SUBTRACT 105 multiply the source and destination colors by source and destination 106 factors and either add the two products together or subtract one from the 107 other. This limited set of operations supports many common blending 108 operations but precludes the use of more sophisticated transparency and 109 blending operations commonly available in many dedicated imaging APIs. 110 111 This extension provides a number of new "advanced" blending equations. 112 Unlike traditional blending operations using the FUNC_ADD equation, these 113 blending equations do not use source and destination factors specified by 114 BlendFunc. Instead, each blend equation specifies a complete equation 115 based on the source and destination colors. These new blend equations are 116 used for both RGB and alpha components; they may not be used to perform 117 separate RGB and alpha blending (via functions like 118 BlendEquationSeparate). 119 120 These blending operations are performed using premultiplied source and 121 destination colors, where RGB colors produced by the fragment shader and 122 stored in the framebuffer are considered to be multiplied by alpha 123 (coverage). Many of these advanced blending equations are formulated 124 where the result of blending source and destination colors with partial 125 coverage have three separate contributions: from the portions covered by 126 both the source and the destination, from the portion covered only by the 127 source, and from the portion covered only by the destination. Such 128 equations are defined assuming that the source and destination coverage 129 have no spatial correlation within the pixel. 130 131 In addition to the coherency issues on implementations not supporting 132 KHR_blend_equation_advanced_coherent, this extension has several 133 limitations worth noting. First, the new blend equations are not 134 supported while rendering to more than one color buffer at once; an 135 INVALID_OPERATION will be generated if an application attempts to render 136 any primitives in this unsupported configuration. Additionally, blending 137 precision may be limited to 16-bit floating-point, which could result in a 138 loss of precision and dynamic range for framebuffer formats with 32-bit 139 floating-point components, and in a loss of precision for formats with 12- 140 and 16-bit signed or unsigned normalized integer components. 141 142New Procedures and Functions 143 144 void BlendBarrierKHR(void); 145 146New Tokens 147 148 Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, and by 149 the <pname> parameter of GetIntegerv, GetBooleanv, GetFloatv, GetDoublev 150 and GetInteger64v: 151 152 BLEND_ADVANCED_COHERENT_KHR 0x9285 153 154 Note: The BLEND_ADVANCED_COHERENT_KHR enable is provided if and only if 155 the KHR_blend_equation_advanced_coherent extension is supported. On 156 implementations supporting only KHR_blend_equation_advanced, this enable 157 is considered not to exist. 158 159 Accepted by the <mode> parameter of BlendEquation and BlendEquationi: 160 161 MULTIPLY_KHR 0x9294 162 SCREEN_KHR 0x9295 163 OVERLAY_KHR 0x9296 164 DARKEN_KHR 0x9297 165 LIGHTEN_KHR 0x9298 166 COLORDODGE_KHR 0x9299 167 COLORBURN_KHR 0x929A 168 HARDLIGHT_KHR 0x929B 169 SOFTLIGHT_KHR 0x929C 170 DIFFERENCE_KHR 0x929E 171 EXCLUSION_KHR 0x92A0 172 173 HSL_HUE_KHR 0x92AD 174 HSL_SATURATION_KHR 0x92AE 175 HSL_COLOR_KHR 0x92AF 176 HSL_LUMINOSITY_KHR 0x92B0 177 178 NOTE: These enums are not accepted by the <modeRGB> or <modeAlpha> 179 parameters of BlendEquationSeparate or BlendEquationSeparatei. 180 181 182Additions to Chapter 2 of the OpenGL 4.1 Specification (OpenGL Operation) 183 184 None. 185 186Additions to Chapter 3 of the OpenGL 4.1 Specification (Rasterization) 187 188 None. 189 190Additions to Chapter 4 of the OpenGL 4.1 Specification (Per-Fragment 191Operations and the Frame Buffer) 192 193 Modify Section 4.1.8, Blending (p. 359). 194 195 (modify the first paragraph, p. 361, allowing for new values in the 196 <mode> parameter) ... <modeRGB> and <modeAlpha> must be one of 197 FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT, MIN, or MAX as listed 198 in Table 4.1. <mode> must be one of the mode values in Table 4.1, 199 or one of the blend equations listed in tables X.1 and X.2. ... 200 201 (modify the third paragraph, p. 361, specifying minimum precision and 202 dynamic range for blend operations) ... Blending computations are treated 203 as if carried out in floating-point. For the equations in table 4.1, 204 blending computations will be performed with a precision and dynamic range 205 no lower than that used to represent destination components. For the 206 equations in table X.1 and X.2, blending computations will be performed 207 with a precision and dynamic range no lower than the smaller of that used 208 to represent destination components or that used to represent 16-bit 209 floating-point values as described in section 2.1.1. 210 211 (add unnumbered subsection prior to "Dual Source Blending and Multiple 212 Draw Buffers", p. 363) 213 214 Advanced Blend Equations 215 216 The advanced blend equations are those listed in tables X.1 and X.2. When 217 using one of these equations, blending is performed according to the 218 following equations: 219 220 R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad) 221 G = f(Gs',Gd')*p0(As,Ad) + Y*Gs'*p1(As,Ad) + Z*Gd'*p2(As,Ad) 222 B = f(Bs',Bd')*p0(As,Ad) + Y*Bs'*p1(As,Ad) + Z*Bd'*p2(As,Ad) 223 A = X*p0(As,Ad) + Y*p1(As,Ad) + Z*p2(As,Ad) 224 225 where the function f and terms X, Y, and Z are specified in the table. 226 The R, G, and B components of the source color used for blending are 227 considered to have been premultiplied by the A component prior to 228 blending. The base source color (Rs',Gs',Bs') is obtained by dividing 229 through by the A component: 230 231 (Rs', Gs', Bs') = 232 (0, 0, 0), if As == 0 233 (Rs/As, Gs/As, Bs/As), otherwise 234 235 The destination color components are always considered to have been 236 premultiplied by the destination A component and the base destination 237 color (Rd', Gd', Bd') is obtained by dividing through by the A component: 238 239 (Rd', Gd', Bd') = 240 (0, 0, 0), if Ad == 0 241 (Rd/Ad, Gd/Ad, Bd/Ad), otherwise 242 243 When blending using advanced blend equations, we expect that the R, G, and 244 B components of premultiplied source and destination color inputs be 245 stored as the product of non-premultiplied R, G, and B components and the 246 A component of the color. If any R, G, or B component of a premultiplied 247 input color is non-zero and the A component is zero, the color is 248 considered ill-formed, and the corresponding component of the blend result 249 will be undefined. 250 251 The weighting functions p0, p1, and p2 are defined as follows: 252 253 p0(As,Ad) = As*Ad 254 p1(As,Ad) = As*(1-Ad) 255 p2(As,Ad) = Ad*(1-As) 256 257 In these functions, the A components of the source and destination colors 258 are taken to indicate the portion of the pixel covered by the fragment 259 (source) and the fragments previously accumulated in the pixel 260 (destination). The functions p0, p1, and p2 approximate the relative 261 portion of the pixel covered by the intersection of the source and 262 destination, covered only by the source, and covered only by the 263 destination, respectively. The equations defined here assume that there 264 is no correlation between the source and destination coverage. 265 266 267 Mode Blend Coefficients 268 -------------------- ----------------------------------- 269 MULTIPLY_KHR (X,Y,Z) = (1,1,1) 270 f(Cs,Cd) = Cs*Cd 271 272 SCREEN_KHR (X,Y,Z) = (1,1,1) 273 f(Cs,Cd) = Cs+Cd-Cs*Cd 274 275 OVERLAY_KHR (X,Y,Z) = (1,1,1) 276 f(Cs,Cd) = 2*Cs*Cd, if Cd <= 0.5 277 1-2*(1-Cs)*(1-Cd), otherwise 278 279 DARKEN_KHR (X,Y,Z) = (1,1,1) 280 f(Cs,Cd) = min(Cs,Cd) 281 282 LIGHTEN_KHR (X,Y,Z) = (1,1,1) 283 f(Cs,Cd) = max(Cs,Cd) 284 285 COLORDODGE_KHR (X,Y,Z) = (1,1,1) 286 f(Cs,Cd) = 287 0, if Cd <= 0 288 min(1,Cd/(1-Cs)), if Cd > 0 and Cs < 1 289 1, if Cd > 0 and Cs >= 1 290 291 COLORBURN_KHR (X,Y,Z) = (1,1,1) 292 f(Cs,Cd) = 293 1, if Cd >= 1 294 1 - min(1,(1-Cd)/Cs), if Cd < 1 and Cs > 0 295 0, if Cd < 1 and Cs <= 0 296 297 HARDLIGHT_KHR (X,Y,Z) = (1,1,1) 298 f(Cs,Cd) = 2*Cs*Cd, if Cs <= 0.5 299 1-2*(1-Cs)*(1-Cd), otherwise 300 301 SOFTLIGHT_KHR (X,Y,Z) = (1,1,1) 302 f(Cs,Cd) = 303 Cd-(1-2*Cs)*Cd*(1-Cd), 304 if Cs <= 0.5 305 Cd+(2*Cs-1)*Cd*((16*Cd-12)*Cd+3), 306 if Cs > 0.5 and Cd <= 0.25 307 Cd+(2*Cs-1)*(sqrt(Cd)-Cd), 308 if Cs > 0.5 and Cd > 0.25 309 310 DIFFERENCE_KHR (X,Y,Z) = (1,1,1) 311 f(Cs,Cd) = abs(Cd-Cs) 312 313 EXCLUSION_KHR (X,Y,Z) = (1,1,1) 314 f(Cs,Cd) = Cs+Cd-2*Cs*Cd 315 316 Table X.1, Advanced Blend Equations 317 318 319 When using one of the HSL blend equations in table X.2 as the blend 320 equation, the RGB color components produced by the function f() are 321 effectively obtained by converting both the non-premultiplied source and 322 destination colors to the HSL (hue, saturation, luminosity) color space, 323 generating a new HSL color by selecting H, S, and L components from the 324 source or destination according to the blend equation, and then converting 325 the result back to RGB. The HSL blend equations are only well defined 326 when the values of the input color components are in the range [0..1]. 327 In the equations below, a blended RGB color is produced according to the 328 following pseudocode: 329 330 float minv3(vec3 c) { 331 return min(min(c.r, c.g), c.b); 332 } 333 float maxv3(vec3 c) { 334 return max(max(c.r, c.g), c.b); 335 } 336 float lumv3(vec3 c) { 337 return dot(c, vec3(0.30, 0.59, 0.11)); 338 } 339 float satv3(vec3 c) { 340 return maxv3(c) - minv3(c); 341 } 342 343 // If any color components are outside [0,1], adjust the color to 344 // get the components in range. 345 vec3 ClipColor(vec3 color) { 346 float lum = lumv3(color); 347 float mincol = minv3(color); 348 float maxcol = maxv3(color); 349 if (mincol < 0.0) { 350 color = lum + ((color-lum)*lum) / (lum-mincol); 351 } 352 if (maxcol > 1.0) { 353 color = lum + ((color-lum)*(1-lum)) / (maxcol-lum); 354 } 355 return color; 356 } 357 358 // Take the base RGB color <cbase> and override its luminosity 359 // with that of the RGB color <clum>. 360 vec3 SetLum(vec3 cbase, vec3 clum) { 361 float lbase = lumv3(cbase); 362 float llum = lumv3(clum); 363 float ldiff = llum - lbase; 364 vec3 color = cbase + vec3(ldiff); 365 return ClipColor(color); 366 } 367 368 // Take the base RGB color <cbase> and override its saturation with 369 // that of the RGB color <csat>. The override the luminosity of the 370 // result with that of the RGB color <clum>. 371 vec3 SetLumSat(vec3 cbase, vec3 csat, vec3 clum) 372 { 373 float minbase = minv3(cbase); 374 float sbase = satv3(cbase); 375 float ssat = satv3(csat); 376 vec3 color; 377 if (sbase > 0) { 378 // Equivalent (modulo rounding errors) to setting the 379 // smallest (R,G,B) component to 0, the largest to <ssat>, 380 // and interpolating the "middle" component based on its 381 // original value relative to the smallest/largest. 382 color = (cbase - minbase) * ssat / sbase; 383 } else { 384 color = vec3(0.0); 385 } 386 return SetLum(color, clum); 387 } 388 389 390 Mode Result 391 -------------------- ---------------------------------------- 392 HSL_HUE_KHR (X,Y,Z) = (1,1,1) 393 f(Cs,Cd) = SetLumSat(Cs,Cd,Cd); 394 395 HSL_SATURATION_KHR (X,Y,Z) = (1,1,1) 396 f(Cs,Cd) = SetLumSat(Cd,Cs,Cd); 397 398 HSL_COLOR_KHR (X,Y,Z) = (1,1,1) 399 f(Cs,Cd) = SetLum(Cs,Cd); 400 401 HSL_LUMINOSITY_KHR (X,Y,Z) = (1,1,1) 402 f(Cs,Cd) = SetLum(Cd,Cs); 403 404 Table X.2, Hue-Saturation-Luminosity Advanced Blend Equations 405 406 407 Advanced blending equations are supported only when rendering to a single 408 color buffer using fragment color zero. If any non-NONE draw buffer uses 409 a blend equation found in table X.1 or X.2, the error INVALID_OPERATION is 410 generated by [[Compatibility Profile: Begin or any operation that 411 implicitly calls Begin (such as DrawElements)]] [[Core Profile and OpenGL 412 ES: DrawArrays and the other drawing commands defined in section 2.8.3]] 413 if: 414 415 * the draw buffer for color output zero selects multiple color buffers 416 (e.g., FRONT_AND_BACK in the default framebuffer); or 417 418 * the draw buffer for any other color output is not NONE. 419 420 [[ The following paragraph applies to KHR_blend_equation_advanced only. ]] 421 422 When using advanced blending equations, applications should split their 423 rendering into a collection of blending passes, none of which touch an 424 individual sample in the framebuffer more than once. The results of 425 blending are undefined if the sample being blended has been touched 426 previously in the same pass. The command 427 428 void BlendBarrierKHR(void); 429 430 specifies a boundary between passes when using advanced blend equations. 431 Any command that causes the value of a sample to be modified using the 432 framebuffer is considered to touch the sample, including clears, blended 433 or unblended primitives, and BlitFramebuffer copies. 434 435 [[ The following paragraph applies to KHR_blend_equation_advanced_coherent 436 only. ]] 437 438 When using advanced blending equations, blending is typically done 439 coherently and in primitive order. When an individual sample is covered 440 by multiple primitives, blending for that sample is performed sequentially 441 in the order in which the primitives were submitted. This coherent 442 blending is enabled by default, but can be enabled or disabled by calling 443 Enable or Disable with the symbolic constant BLEND_ADVANCED_COHERENT_KHR. 444 If coherent blending is disabled, applications should split their 445 rendering into a collection of blending passes, none of which touch an 446 individual sample in the framebuffer more than once. When coherent 447 blending is disabled, the results of blending are undefined if the sample 448 being blended has been touched previously in the same pass. The command 449 450 void BlendBarrierKHR(void); 451 452 specifies a boundary between passes when using advanced blend equations. 453 Any command that causes the value of a sample to be modified using the 454 framebuffer is considered to touch the sample, including clears, blended 455 or unblended primitives, and BlitFramebuffer copies. 456 457 Advanced blending equations require the use of a fragment shader with a 458 matching "blend_support" layout qualifier. If the current blend equation 459 is found in table X.1 or X.2, and the active fragment shader does not 460 include the layout qualifier matching the blend equation or 461 "blend_support_all_equations", the error INVALID_OPERATION is generated by 462 [[Compatibility Profile: Begin or any operation that implicitly calls 463 Begin (such as DrawElements)]] [[Core Profile and OpenGL ES: DrawArrays 464 and the other drawing commands defined in section 2.8.3]] The set of 465 layout qualifiers supported in fragment shaders is specified in sectino 466 4.3.8.2 of the OpenGL Shading Language Specification. 467 468 469Additions to Chapter 5 of the OpenGL 4.1 Specification (Special Functions) 470 471 None. 472 473Additions to Chapter 6 of the OpenGL 4.1 Specification (State and 474State Requests) 475 476 None. 477 478Additions to Appendix A of the OpenGL 4.1 Specification (Invariance) 479 480 None. 481 482Additions to the AGL/GLX/WGL/EGL Specifications 483 484 None. 485 486Additions to the OpenGL Shading Language Specification, Version 4.10 487 488 Including the following line in a shader can be used to control the 489 language features described in this extension: 490 491 #extension GL_KHR_blend_equation_advanced : <behavior> 492 493 where <behavior> is as specified in section 3.3. 494 495 A new preprocessor #define is added to the OpenGL Shading Language: 496 497 #define GL_KHR_blend_equation_advanced 1 498 499 Modify Section 4.3.8.2, Output Layout Qualifiers, p. 47 500 501 (add to the end of the section, p. 50) 502 503 Fragment shaders additionally support the following layout qualifiers, 504 specifying a set of advanced blend equations supported when the fragment 505 shader is used. These layout qualifiers are only permitted on the 506 interface qualifier out, and use the identifiers specified in the "Layout 507 Qualifier" column of Table X.3. 508 509 If a layout qualifier in Table X.3 is specified in the fragment shader, 510 the fragment shader may be used with the corresponding advanced blend 511 equation in the "Blend Equation(s) Supported" column. Additionally, the 512 special qualifier "blend_support_all_equations" indicates that the shader 513 may be used with any advanced blending equation supported by the OpenGL 514 Specification. It is not an error to specify more than one of these 515 identifiers in any fragment shader. Specifying more than one qualifier or 516 "blend_support_all_equations" means that the fragment shader may be used 517 with multiple advanced blend equations. Additionally, it is not an error 518 to specify any single any of these layout qualifiers more than once. 519 520 Layout Qualifier Blend Equation(s) Supported 521 ------------------------ ------------------------------ 522 blend_support_multiply MULTIPLY_KHR 523 blend_support_screen SCREEN_KHR 524 blend_support_overlay OVERLAY_KHR 525 blend_support_darken DARKEN_KHR 526 blend_support_lighten LIGHTEN_KHR 527 blend_support_colordodge COLORDODGE_KHR 528 blend_support_colorburn COLORBURN_KHR 529 blend_support_hardlight HARDLIGHT_KHR 530 blend_support_softlight SOFTLIGHT_KHR 531 blend_support_difference DIFFERENCE_KHR 532 blend_support_exclusion EXCLUSION_KHR 533 blend_support_hsl_hue HSL_HUE_KHR 534 blend_support_hsl_saturation HSL_SATURATION_KHR 535 blend_support_hsl_color HSL_COLOR_KHR 536 blend_support_hsl_luminosity HSL_LUMINOSITY_KHR 537 blend_support_all_equations /all blend equations/ 538 539 Table X.3, Fragment Shader Output Layout Qualifiers for Blend Support 540 541 A draw-time error will be generated in the OpenGL API if an application 542 attempts to render using an advanced blending equation without having a 543 matching layout qualifier specified in the active fragment shader. 544 545GLX Protocol 546 547 !!! TBD 548 549Dependencies on OpenGL 4.0 550 551 If OpenGL 4.0 is not supported, references to the BlendEquationi API should 552 be removed. 553 554Dependencies on OpenGL 4.1 (Core Profile) 555 556 This extension throws an INVALID_OPERATION when Begin is called if advanced 557 blend equations are used in conjunction with multiple draw buffers. For 558 the core profile of OpenGL 4.1 (and other versions of OpenGL), there is no 559 Begin command; instead, the error is thrown by other rendering commands 560 such as DrawArrays. The language in this specification documenting the 561 error has separate versions for the core and compatibility profiles. 562 563Dependencies on OpenGL 4.3 or later (any Profile) 564 565 References to Chapter 4 are replaced with references to Chapter 17 (Writing 566 Fragments and Samples to the Framebuffer). 567 References to section 4.1.8 are replaced with references to section 17.3.8. 568 References to Table 4.1 are replace with references to Table 17.1. 569 References to section 2.1.1 are replaced with references to section 2.3.3. 570 571Dependencies on OpenGL ES 2.0 572 573 If unextended OpenGL ES 2.0 is supported, references to BlendEquationi, 574 BlendEquationSeparatei, GetInteger64v, and GetDoublev should be ignored. 575 576 Ignore any references to multiple draw buffers if EXT_draw_buffers or 577 NV_draw_buffers is not supported. 578 579Dependencies on EXT_blend_minmax 580 581 Requires EXT_blend_minmax on OpenGL ES 2.0 implementations and references 582 to MIN and MAX should be replace by references to MIN_EXT and MAX_EXT as 583 introduced by that extension. 584 585Dependencies on OpenGL ES 3.0 586 587 If unextended OpenGL ES 3.0 is supported, references to BlendEquationi, 588 BlendEquationSeparatei, and GetDoublev should be ignored. 589 590Dependencies on NV_path_rendering 591 592 When NV_path_rendering is supported, covering geometry generated by the 593 commands CoverFillPathNV, CoverFillPathInstancedNV, CoverStrokePathNV, and 594 CoverStrokePathInstancedNV will automatically be blended coherently 595 relative to previous geometry when using the blend equations in this 596 extension. This guarantee is provided even on implementations supporting 597 only NV_blend_equation_advanced. 598 599 Insert the following language after the discussion of the 600 BlendBarrierKHR() command for both extensions: 601 602 [[ For KHR_blend_equation_advanced only: ]] 603 604 The commands CoverFillPathNV, CoverFillPathInstancedNV, 605 CoverStrokePathNV, and CoverStrokePathInstancedNV are considered to 606 start a new blending pass, as though BlendBarrierKHR were called prior 607 to the cover operation. If a cover primitive is followed by subsequent 608 non-cover primitives using advanced blend equations and touching the 609 same samples, applications must call BlendBarrierKHR after the cover 610 primitives to ensure defined blending results. 611 612 [[ For KHR_blend_equation_advanced_coherent, the language immediately 613 above should be used, but the first sentence should be prefixed with 614 "When coherent blending is disabled, ...". ]] 615 616 617Errors 618 619 If any non-NONE draw buffer uses a blend equation found in table X.1 or 620 X.2, the error INVALID_OPERATION is generated by Begin or any operation 621 that implicitly calls Begin (such as DrawElements) if: 622 623 * the draw buffer for color output zero selects multiple color buffers 624 (e.g., FRONT_AND_BACK in the default framebuffer); or 625 626 * the draw buffer for any other color output is not NONE. 627 628New State 629 Initial 630 Get Value Type Get Command Value Description Sec Attribute 631 -------------------- ---- ------------ ------------ ------------------------ ----- ------------ 632 BLEND_ADVANCED_ B IsEnabled TRUE are advanced blending 4.1.8 color-buffer 633 COHERENT_KHR equations guaranteed to 634 be evaluated coherently? 635 636 Note: The BLEND_ADVANCED_COHERENT_KHR enable is provided if and only if 637 the KHR_blend_equation_advanced_coherent extension is supported. On 638 implementations supporting only KHR_blend_equation_advanced, this enable 639 is considered not to exist. 640 641New Implementation Dependent State 642 643 None. 644 645Issues 646 647 Note: These issues apply specifically to the definition of the 648 KHR_blend_equation_advanced specification, which was derived from the 649 extension NV_blend_equation_advanced. The issues from the original 650 NV_blend_equation_advanced specification have been removed, but can be 651 found (as of August 2013) in the OpenGL Registry at: 652 653 http://www.opengl.org/registry/specs/NV/blend_equation_advanced.txt 654 655 (0) How does this extension differ from the NV_blend_equation_advanced 656 extension for OpenGL and OpenGL ES? 657 658 RESOLVED: A number of features have been removed from 659 NV_blend_equation_advanced, including: 660 661 * The BlendParameterivNV API has been removed, and with it, the 662 BLEND_PREMULTIPLIED_SRC_NV and BLEND_OVERLAP_NV parameters. The spec 663 has been refactored to assume premultipled source colors and 664 uncorrelated source and destination coverage. 665 666 * A number of less commonly used blend modes have been removed, 667 including: 668 669 - certain "X/Y/Z" blending modes supported by few, if any, standards 670 (INVERT, INVERT_RGB_NV, LINEARDODGE_NV, LINEARBURN_NV, 671 VIVIDLIGHT_NV, LINEARLIGHT_NV, PINLIGHT_NV, HARDMIX_NV) 672 673 - various versions of additive and subtractive modes (PLUS_NV, 674 PLUS_CLAMPED_NV, PLUS_CLAMPED_ALPHA_NV, PLUS_DARKER_NV, MINUS_NV, 675 MINUS_CLAMPED_NV) 676 677 - other uncommon miscellaneous modes (CONTRAST_NV, INVERT_OVG_NV, 678 RED, GREEN, BLUE) 679 680 Additionally, this extension adds blending support layout qualifiers to 681 the fragment shader (qualifying "out"). Each fragment shader can 682 specify a set of advanced blend equations that can be used when it is 683 active. For example: 684 685 layout(blend_support_hardlight, blend_support_softlight) out; 686 687 specifies that the HARDLIGHT_KHR and SOFTLIGHT_KHR equations are allowed 688 when using the shader. A draw-time error will be generated if an 689 advanced blend equation is enabled in the API and a matching layout 690 qualifier is not specified in the active fragment shader. 691 692 (1) What should we do about the BLEND_PREMULTIPLIED_SRC_NV blend parameter 693 from NV_blend_equation_advanced? 694 695 RESOLVED: Remove this parameter for simplicity. All equations in this 696 extension assume that the source and destination colors are both 697 premultiplied. 698 699 (2) What should we do about the BLEND_OVERLAP_NV blend parameter from 700 NV_blend_equation_advanced? 701 702 RESOLVED: Remove this parameter for simplicitly. All equations in this 703 extension assume an UNCORRELATED_NV overlap mode. Blending using the 704 UNCORRELATED_NV overlap mode is usually mathematically simpler than 705 blending using the DISJOINT_NV or CONJOINT_NV modes. 706 707 (3) What set of "complex" blending equations should we support in this 708 extension? 709 710 RESOLVED: During standardization of this extensions, the set of 711 equations provided in this extension has been reduced to a smaller 712 subset for simplicitly. The remaining equations are typically found in 713 a wide collection of compositing standards. In particular, the 714 standarization process removed several classes of blend equations from 715 the NV_blend_equation_advanced, as described in "differences" issue (0) 716 above. 717 718 (4) Should we support the "Porter-Duff" blend equations (e.g., 719 SRC_OVER_NV) from NV_blend_equation_advanced? 720 721 RESOLVED: All of these blend equations should be supportable in 722 unextended OpenGL ES 3.0, and have been removed for simplicity. The 723 primary rationale for this decision is to reduce the number of internal 724 paths required by the driver; some implementations may have separate 725 paths for traditional OpenGL blending and for the new advanced blending 726 equations. Redirecting "simple" advanced blending equations to 727 traditional fixed-function blending hardware may involved more driver 728 implementation work and may have different performance characteristics 729 than other "complex" blending equations. 730 731 This approach does mean that an application wanting to use both 732 Porter-Duff blend equations and advanced blending equations provided by 733 this extension will need GL_to program blending somewhat differently 734 when using the Porter-Duff equations: 735 736 if (isPorterDuff(equation)) { 737 glBlendEquation(GL_FUNC_ADD); // enable sf*S+df*D blending 738 glBlendFunc(srcFactor, dstFactor); // and program blend factors 739 } else { 740 glBlendEquation(equation); // advanced eqs. don't use BlendFunc 741 } 742 743 (5) Should we impose any requirements on fragment shaders when used in 744 conjunction with advanced blend equations? 745 746 RESOLVED: Yes. This extension adds fragment shader layout qualifiers 747 allowing individual shaders to specify that they will be used with one 748 or multiple advanced blending equations. When using an advanced 749 blending equation from this extension, it is necessary to use a fragment 750 shader with a matching layout qualifier. A draw-time error will be 751 generated if the current fragment shader doesn't include a layout 752 qualifier matching the current advanced blending mode. 753 754 The rationale for this decision is that some implementations of this 755 extension may require special fragment shader code when using advanced 756 blending equations, and may perhaps perform the entire blending 757 operation in the fragment shader. Knowing the set of blending equations 758 that a fragment shader will be used with at compile time may reduce the 759 extent of run-time fragment shader re-compilation when the shader is 760 used. 761 762 Note that NV_blend_equation_advanced doesn't include layout qualifiers 763 or the draw-time error specified here. 764 765 (6) How do we handle coherency when a fragment is hit multiple times? 766 767 RESOLVED: In this extension, blending equations will be done coherently 768 and in primitive order by default, as is the case with traditional 769 blending in OpenGL and OpenGL ES. 770 771 The NVIDIA extension provides two separate extension string entries: 772 773 * NV_blend_equation_advanced 774 * NV_blend_equation_advanced_coherent 775 776 Exposing the former without the latter signals that the implementation 777 can support blending with these equations, but is unable to ensure that 778 fragments are blended in order when the same (x,y) is touched multiple 779 times. To ensure coherent results and proper ordering using the 780 non-coherent version of the extension, an application must separate its 781 rendering into "passes" that touch each (x,y) at most once, and call 782 BlendBarrierNV between passes. There are important use cases (e.g., 783 many path rendering algorithms) where this limitation isn't too 784 restrictive, and NVIDIA chose to expose the non-coherent version to 785 allow the functionality to be used on a larger set of GPUs. 786 787 This extension is functionally comparable to an implementation of the 788 NVIDIA extension exposing both strings, where coherent behavior is 789 enabled by default. NV_blend_equation_advanced_coherent and this 790 extension both provide the ability to opt out of this automatic 791 coherence by disabling BLEND_ADVANCED_COHERENT_KHR and using 792 BlendBarrierKHR manually. This could theoretically result in higher 793 performance -- see issue (32) of the NVIDIA extension for more 794 discussion. 795 796 (7) How should the blend equations COLORDODGE_KHR and COLORBURN_KHR be 797 expressed mathematically? 798 799 RESOLVED: NVIDIA changed the definition of these equations after the 800 NV_blend_equation_advanced spec was originally published, as discussed 801 below. These changes add new special cases to the COLORDODGE_KHR and 802 COLORBURN_KHR equations that are found in newer compositing standard 803 specifications and in a number of implementations of old and new 804 standards. They believe that the omission of the special case in other 805 older specifications is a bug. They have no plans to add new blend 806 equation tokens to support "equivalent" modes without the new special 807 case. We are adopting the same approach in this extension. 808 809 Note, however, that older versions of this extension and older NVIDIA 810 drivers implementing it will lack these special cases. A driver update 811 may be required to get the new behavior. 812 813 There is some disagreement in different published specifications about 814 how these two blend equations should be handled. At the time the NVIDIA 815 extension was initially developed, all specifications they found that 816 specified blending equations mathematically (see issue 28 of 817 NV_blend_equation_advanced) were written the same way. Since then, they 818 discovered that newer working drafts of the W3C Compositing and Blending 819 Level 1 specification (for CSS and SVG) express "color-burn" as follows 820 (translated to our nomenclature): 821 822 if (Cd == 1) // their Cb (backdrop) is our Cd (destination) 823 f(Cs,Cd) = 1 // their B() is our f() 824 else if (Cs == 0) 825 f(Cs,Cd) = 0 826 else 827 f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs) 828 829 http://www.w3.org/TR/2013/WD-compositing-1-20131010/ 830 #blendingcolorburn 831 832 Earlier versions of the same W3C specification, an older SVG compositing 833 draft specification, the Adobe PDF specification (and the ISO 32000-1 834 standard), and the KHR_advanced_blending extension to OpenVG all specify 835 the following equation without the initial special case: 836 837 if (Cs == 0) 838 f(Cs,Cd) = 0 839 else 840 f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs) 841 842 http://www.w3.org/TR/2012/WD-compositing-20120816/ 843 #blendingcolorburn 844 http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/ 845 http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/ 846 pdfs/pdf_reference_1-7.pdf 847 http://www.khronos.org/registry/vg/extensions/KHR/ 848 advanced_blending.txt 849 850 For the Adobe PDF specification, the corrected blend equations are 851 published in an Adobe supplement to ISO 32000-1 and are expected to be 852 accepted in a future version of the standard: 853 854 http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/ 855 devnet/pdf/pdfs/adobe_supplement_iso32000_1.pdf 856 857 The author's understanding is that multiple shipping implementations of 858 these blending modes implement the special case for "Cd==1" above, 859 including various Adobe products and the open-source Ghostscript 860 project. 861 862 We believe that the extra special case in this specification is 863 consistent with the physical model of color burning. Burning is 864 described in 865 866 http://en.wikipedia.org/wiki/Dodging_and_burning 867 868 as making a print with normal exposure, and then adding additional 869 exposure to darken the overall image. In the general equation: 870 871 1 - min(1, (1-Cd)/Cs) 872 873 Cs operates as a sort of fudge factor where a value of 1.0 implies no 874 additional exposure time and 0.0 implies arbitrarily long additional 875 exposure time, where the initial amount of exposure (1-Cd) is multiplied 876 by 1/Cs and then clamped to maximum exposure by the min() operation. 877 The Cd==1 special case here implies that we get zero exposure in the 878 initial print, since 1-Cd==0. No amount of extra exposure time will 879 generate any additional exposure. This would imply that the final 880 result should have zero exposure and thus a final f() value of 1. This 881 matches the initial special case. Without that special case, we would 882 hit the second special case if Cs==0 (infinite exposure time), which 883 would yield an incorrect final value of 0 (full exposure). 884 885 A similar issue applies to COLORDODGE_KHR, where some specifications 886 include a special case for Cb==0 while others do not. We have added a 887 special case there as well. 888 889 (8) The NV_blend_equation_advanced extension has two variants: 890 NV_blend_equation_advanced and NV_blend_equation_advanced_coherent. 891 Some implementations of that extension are not capable of performing 892 fully coherent blending when samples are touched more than once 893 without a barrier, and may expose only the former. Should we follow 894 this pattern here or support only the "coherent" variant? 895 896 RESOLVED: Yes. The working group originally decided to support only 897 the "coherent" variant (revision 4) for simplicity but later decided to 898 support both extension string entries as some implementations on both 899 OpenGL and OpenGL ES are unable to support the "coherent" variant. 900 Applications not wanting to manage coherency manually should look for 901 the KHR_blend_equation_advanced_coherent extension and ignore 902 KHR_blend_equation_advanced. 903 904 (9) We don't permit the use of advanced blend equations with multiple draw 905 buffers. Should we produce compile-, link-, or draw-time errors if we 906 encounter a shader that includes both (a) one or more layout 907 qualifiers indicating that the shader wants to use advanced blending 908 and (b) a color output with a location other than zero? 909 910 RESOLVED: No. 911 912 In the current extension, there is a draw-time error generated if you 913 try to use one of the new blend equations with multiple color targets 914 (glDrawBuffers with a count > 1). With this restriction, any "extra" 915 fragment shader color outputs could never be successfully blended into 916 the framebuffer with one of these equations. 917 918 When only one draw buffer is enabled when using a shader with multiple 919 outputs, "extra" outputs will simply be dropped and have no effect on 920 the framebuffer. You can already do this in unextended OpenGL and 921 OpenGL ES without generating an error. We didn't feel that the value of 922 such a warning/error justifies the draw-time overhead needed to detect 923 and report such a condition. 924 925 Since this extension requires that you declare the intent to use 926 advanced blending using layout qualifers, it is possible to identify a 927 shader that may want to use "extra" color outputs with advanced blending 928 at compile time, with no draw-time overhead. We decided not to treat 929 this condition as an error for several reasons: 930 931 - Advanced blending layout qualifiers don't require that blending 932 actually be enabled. Multiple draw buffers with multiple outputs 933 work just fine in that case. 934 935 - If we treated this condition as an error and a future extension 936 relaxed the DrawBuffers restriction, it would be necessary to also 937 add a GLSL language feature to disable the now-undesirable error. 938 939 (10) What happens when converting a premultiplied color with an alpha of 940 zero to a non-premultiplied color? 941 942 RESOLVED: We specify that a premultiplied color of (0,0,0,0) should 943 produce non-premultiplied (R,G,B) values of (0,0,0). A premultiplied 944 color with an alpha of zero and a non-zero R, G, or B component is 945 considered to be ill-formed and will produce undefined blending results. 946 947 For a non-premultiplied color (R',G',B',A'), the corresponding 948 premultiplied color (R,G,B,A) should satisfy the equation: 949 950 (R,G,B,A) = (R'*A', G'*A', B'*A', A') 951 952 If the alpha of a non-premultiplied color is zero, the corresponding 953 premultiplied color (R,G,B,A) should be (0,0,0,0). 954 955 We specify that ill-formed premultiplied colors produce undefined 956 blending results to enable certain performance optimizations. In many 957 of these blending equations, the alpha component used as a denominator 958 to compute the non-premultiplied color ends up being multiplied by the 959 same alpha component in the coverage, resulting in cancellation. For 960 example, implementations may want to substitute a premultiplied 961 destination color into the last term of the basic blend equation: 962 963 R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad) 964 = ... + Z*Rd'*(Ad*(1-As)) 965 = ... + Z*(Rd'*Ad)*(1-As) 966 = ... + Z* Rd * (1-As) 967 968 This substitution would be invalid for ill-formed premultiplied 969 destination colors. We choose to specify undefined results for invalid 970 input colors rather than requiring implementations to skip such 971 optimizations or include logic to check for zero alpha values for each 972 input. 973 974 (11) For "HSL" blend equations, the blend equation involves a clipping 975 step where colors may be "clipped" if the blend would produce 976 components are outside the range [0,1]. Are there inputs where this 977 blend could produce ill-defined or nonsensical results? 978 979 RESOLVED: Yes, the results of HSL blend equations are undefined if the 980 input colors have components outside the range [0,1]. Even if the input 981 colors are in-range, the basic color adjustment done in these blends 982 could produce result components outside the range [0,1]. To compensate, 983 the ClipColor() function in the specification interpolates the result 984 color and a greyscale value that matches the luminance of the result. 985 The math for the clipping operation assumes the luminance of the result 986 color is in the range [0,1]. If that isn't the case, the clipping 987 operation could result in a divide by zero (when all result components 988 have the same out-of-bounds value) or perform an otherwise nonsensical 989 computation. 990 991 992Revision History 993 994 Revision 17, February 14, 2018 995 996 Fix ClipColor() equation where in the "if (maxcol > 1.0)" body the 997 "(color-lum)*lum" term should have been "(color-lum)*(1-lum)". Also 998 add new issue 11 for the case where the inputs to SetLum() are outside 999 the range [0..1] and could cause a divide-by-zero in ClipColor(). 1000 1001 Revision 16, April 16, 2016 (from a September 30, 2014 edit that wasn't 1002 published) 1003 1004 Fix incorrectly specified color clamping in the HSL blend modes. 1005 1006 Revision 15, May 9, 2015 1007 1008 Renumber as OpenGL ARB extension instead of vendor extension, by 1009 symmetry with other KHR Khronos-approved extensions. Add copyright 1010 notice. 1011 1012 Revision 14, March 14, 2014 1013 1014 Cast as KHR extension. 1015 1016 Revisions 12 and 13, March 5, 2014 1017 1018 For non-coherent blending, clarify that all writes to a sample are 1019 considered to "touch" that sample and require a BlendBarrierKHR call 1020 before blending overlapping geometry. Clears, non-blended geometry, and 1021 copies by BlitFramebuffer or TexSubImage are all considered to "touch" a 1022 sample (bug 11738). Specify that non-premultiplied values corresponding 1023 to ill-conditioned premultiplied colors such as (1,1,1,0) are undefined 1024 (bug 11739). Add issue (10) related to the ill-conditioned 1025 premultiplied color issue. 1026 1027 Revision 11, January 30, 2014 1028 1029 Cast as OES extension. 1030 1031 Revision 10, January 22, 2014 1032 1033 Add issue (9), where we decided not to add compile- or link-time errors 1034 when using both advanced blending and multiple color outputs (bug 1035 11468). 1036 1037 Revision 9, January 2, 2014 1038 1039 Fix typo in issue (0). 1040 1041 Revision 8, November 6, 2013 1042 1043 Restore support for non-coherent-only implementations that was removed 1044 in revision 4. Fix the language about non-coherent blending to specify 1045 that results are undefined only if an individual *sample* is touched 1046 more than once (instead of *pixel*). Minor language tweaks to use 1047 "equations" consistently, instead of sometimes using "modes". 1048 1049 Revision 7, October 21, 2013 1050 1051 Add a reference to the Adobe supplement to ISO 32000-1, which includes 1052 the corrected equations for COLORDODGE_NV and COLORBURN_NV. Move 1053 "NVIDIA Implementation Details" down a bit in the spec. 1054 1055 Revision 6, October 16, 2013 1056 1057 Add new special cases for COLORDODGE_KHR and COLORBURN_KHR, as described 1058 in issue (7). Mark issue (7) as resolved. 1059 1060 Revision 5, October 15, 2013 1061 1062 Remove Porter-Duff blend equations from the specification (issue 4). 1063 Add a Draw-time error if an advanced blending equation is used without 1064 specifying a matching layout qualifier in the fragment shader (issue 5). 1065 1066 Add issues for the spec issues discussed during standardization in 1067 Khronos. Remove OpenGL ES 2.0 and 3.0 interactions dealing with 1068 handling tokens present in OpenGL but not the core OpenGL ES 1069 specification, since the relevant equations (ZERO and XOR) have been 1070 removed. 1071 1072 Revision 4, September 6, 2013 1073 1074 Removed support for non-coherent-only implementations. Implementations 1075 that could support NV_blend_equation_advanced (app-managed coherency 1076 only) but not NV_blend_equation_advanced_coherent will be unable to 1077 support this extension. 1078 1079 Revision 3, August 19, 2013 1080 1081 Fixed typos in the OpenGL ES 2.0 and 3.0 interactions section of 1082 NV_blend_equation_advanced. 1083 1084 Revision 2, August 13, 2013 1085 1086 Removed issues from the original NV_blend_equation_advanced 1087 specification. Rename "NV" prefixes and suffixes to "XXX" since the 1088 future status of this extension is unknown. Remove the 1089 BlendParameterivNV function and the BLEND_PREMULTIPLIED_SRC_NV and 1090 BLEND_OVERLAP_NV parameters. Source colors are assumed to be 1091 premultiplied. The source and destination pixel coverage, derived from 1092 their respective alpha components, is assumed to be uncorrelated. 1093 Removed the miscellaneous blend modes (PLUS_NV, PLUS_CLAMPED_NV, 1094 PLUS_CLAMPED_ALPHA_NV, PLUS_DARKER_NV, MINUS_NV, MINUS_CLAMPED_NV, 1095 CONTRAST_NV, INVERT_OVG_NV, RED, GREEN, BLUE) from Table X.4 of 1096 NV_blend_equation_advanced. Removed some of the less common "X/Y/Z" 1097 blend modes (INVERT, INVERT_RGB_NV, LINEARDODGE_NV, LINEARBURN_NV, 1098 VIVIDLIGHT_NV, LINEARLIGHT_NV, PINLIGHT_NV, HARDMIX_NV). Add layout 1099 qualifiers to the OpenGL Shading Language to indicate the set of 1100 advanced blend equations are supported with a particular fragment 1101 shader; using blend equations not identified in the current fragment 1102 shader result in undefined blending results. 1103 1104 Revision 1, August 13, 2013 1105 1106 Forked the original NV_blend_equation_advanced specification. 1107