| Name |
| |
| EXT_blend_func_extended |
| |
| Name Strings |
| |
| GL_EXT_blend_func_extended |
| |
| Contact |
| |
| Mark Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) |
| |
| Contributors |
| |
| Daniel Koch, NVIDIA |
| Slawomir Grajewski, Intel |
| Chris Dalton, NVIDIA |
| Brian Salomon, Google |
| |
| From ARB_blend_func_extended... |
| |
| Graham Sellers, AMD |
| Mark Young, AMD |
| Nick Haemel, AMD |
| Pierre Boudier, AMD |
| Mais Alnasser, AMD |
| Jeff Bolz, NVIDIA |
| Pat Brown, NVIDIA |
| Ian Stewart, NVIDIA |
| Jon Leech, Khronos |
| |
| Status |
| |
| Draft, almost complete |
| |
| Version |
| |
| Last Modified Date: July 29, 2015 |
| Revision: 5 |
| |
| Number |
| |
| XXX |
| |
| Dependencies |
| |
| This extension is written against the OpenGL ES 3.1 (June 4, 2014) |
| specification, but can apply to earlier versions back to ES 2.0. |
| |
| GLSL version 300 and 310 language is written against The OpenGL ES |
| Shading Language (July 11, 2012). |
| |
| GLSL version 100 language is written against The OpenGL ES Shading |
| Language (May 12, 2009). |
| |
| The NV_draw_buffers and EXT_draw_buffers extensions trivially affect |
| the definition of this extension. |
| |
| The EXT_draw_buffers_indexed extension affects the definition of |
| this extension. |
| |
| Overview |
| |
| This extension provides an ES version of the ARB_blend_func_extended |
| functionality. |
| |
| Traditional OpenGL includes fixed-function blending that combines |
| source colors with the existing content of a render buffer in |
| a variety of ways. A number of extensions have enhanced this |
| functionality by adding further sources of blending weights and |
| methods to combine them. However, the inputs to the fixed-function |
| blending units are constrained to a source color (as output from |
| fragment shading), destination color (as the current content of the |
| frame buffer) or constants that may be used in their place. |
| |
| This extension adds new blending functions whereby a fragment |
| shader may output two colors, one of which is treated as the |
| source color, and the other used as a blending factor for either |
| source or destination colors. Furthermore, this extension increases |
| orthogonality by allowing the SRC_ALPHA_SATURATE function to be used |
| as the destination weight. |
| |
| Because of the limitations of the OpenGL ES 2.0 shading language, |
| new built-in variables (gl_SecondaryFragColorEXT, |
| gl_SecondaryFragDataEXT) are added to the ES 1.00 shading language |
| rather than introduce more complex features for user-defined fragment |
| outputs. Because such built-in variable are deprecated in ES 3.0, |
| these variables are NOT available in the OpenGL ES 3.xx shading |
| language verisons. |
| |
| IP Status |
| |
| No known IP claims. |
| |
| New Procedures and Functions |
| |
| void BindFragDataLocationIndexedEXT(uint program, uint colorNumber, |
| uint index, const char * name); |
| |
| int GetFragDataIndexEXT(uint program, const char * name); |
| |
| void BindFragDataLocationEXT(uint program, uint colorNumber, const char * name) |
| |
| int GetProgramResourceLocationIndexEXT(uint program, enum programInterface, const char *name); |
| |
| New Tokens |
| |
| Accepted by the <src> and <dst> parameters of BlendFunc and |
| BlendFunciEXT, and by the <srcRGB>, <dstRGB>, <srcAlpha> and <dstAlpha> |
| parameters of BlendFuncSeparate and BlendFuncSeparateiEXT: |
| |
| SRC1_COLOR_EXT 0x88F9 |
| SRC1_ALPHA_EXT 0x8589 // OpenGL 1.5 token value |
| ONE_MINUS_SRC1_COLOR_EXT 0x88FA |
| ONE_MINUS_SRC1_ALPHA_EXT 0x88FB |
| SRC_ALPHA_SATURATE_EXT 0x0308 |
| |
| Accepted in the <props> array of GetProgramResourceiv: |
| |
| LOCATION_INDEX_EXT 0x930F |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| and GetFloatv: |
| |
| MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT 0x88FC |
| |
| Additions to Chapter 7 of the OpenGL ES 3.1 Specification (Programs and |
| Shaders) |
| |
| Add a row to table 7.2 "GetProgramResourceiv properties and supported |
| interfaces" (page 82): |
| |
| Property Supported Interfaces |
| ------------------ -------------------- |
| LOCATION_INDEX_EXT PROGRAM_OUTPUT |
| |
| Modify section 7.3.1.1 "Naming Active Resources" subsection to include |
| after the LOCATION paragraph (page 84): |
| |
| "For the property LOCATION_INDEX_EXT, a single integer identifying the |
| fragment color index of an active fragment shader output variable |
| is written to params. If the active variable is not an output for a |
| fragment shader, the value -1 will be written to params." |
| |
| Modify (page 87) the paragraph introducing GetProgramResourceLocation |
| to begin: |
| |
| "The commands |
| |
| int GetProgramResourceLocation( uint program, |
| enum programInterface, const char *name ); |
| int GetProgramResourceLocationIndexEXT( uint program, |
| enum programInterface, const char *name ); |
| |
| return the location or the fragment color index, respectively, |
| assigned to the variable named name in interface programInterface |
| of program object program." |
| |
| Change the ending of the same paragraph to read: |
| |
| "For GetProgramResourceLocationIndexEXT, programInterface must be |
| PROGRAM_OUTPUT. The value -1 will be returned by either command if |
| an error occurs, if name does not identify an active variable on |
| programInterface, or if name identifies an active variable that |
| does not have a valid location assigned, as described above. The |
| locations returned by these commands are the same locations returned |
| when querying the LOCATION and LOCATION_INDEX resource properties." |
| |
| Change the next paragaph to begin: |
| |
| "A string provided to GetProgramResourceLocation or |
| GetProgramResourceLocationIndexEXT is considered to match an active |
| variable if ..." |
| |
| Change the last paragraph of the section (page 88) to read: |
| |
| ... "If the string specifies an element of an array variable, |
| GetProgramResourceLocation and GetProgramResourceLocationIndexEXT |
| return the location or fragment color index assigned to that |
| element. If it specifies the base name of an array, it identifies |
| the resources associated with the first element of the array." |
| |
| Additions to Chapter 14 of the OpenGL ES 3.1 Specification (Programmable |
| Fragment Processing) |
| |
| Modify section 14.2.3 "Shader Outputs" subsection to include: |
| |
| "The binding of a user-defined varying out variable to a fragment color number |
| can be specified explicitly. The command |
| |
| void BindFragDataLocationIndexedEXT(uint program, uint colorNumber, |
| uint index, const char * name); |
| |
| specifies that the varying out variable name in <program> should |
| be bound to fragment color <colorNumber> when the program is next |
| linked. <index> may be zero or one to specify that the color |
| be used as either the first or second color input to the blend |
| equation, respectively, as described in Section 15.1.5 (Blending). |
| If <name> was bound previously, its assigned binding is replaced |
| with colorNumber. <name> must be a null-terminated string. The error |
| INVALID_VALUE is generated if <colorNumber> is equal or greater |
| than the value of MAX_DRAW_BUFFERS and <index> is zero, |
| or if <colorNumber> is equal or greater than the value of |
| MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT and <index> is greater than or |
| equal to one. The command |
| |
| void BindFragDataLocationEXT(uint program, uint colorNumber, |
| const char * name) |
| |
| is equivalent to calling BindFragDataLocationIndexedEXT with the |
| same values for <program>, <colorNumber> and <name>, and with <index> |
| set to zero. |
| |
| When a program is linked, any varying out variables without |
| a binding specified through BindFragDataLocationIndexedEXT or |
| BindFragDataLocationEXT will automatically be bound to fragment |
| colors and indices by the GL. All such assignments will use color |
| indices of zero. Such bindings can be queried using the commands |
| GetFragDataLocation and GetFragDataIndexEXT. Output binding |
| assignments will cause LinkProgram to fail: |
| |
| * if the number of active outputs is greater than the value of |
| MAX_DRAW_BUFFERS_EXT; |
| |
| * if the program has an active output assigned to a location greater |
| than or equal to the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT |
| and has an active output assigned an index greater than or equal |
| to one; |
| |
| * if more than one varying out variable is bound to the same number |
| and index; or |
| |
| * if the explicit binding assignments do not leave enough space |
| for the linker to automatically assign a location for a varying |
| out array, which requires multiple contiguous locations. |
| |
| BindFragDataLocationIndexedEXT may be issued before any shader objects |
| are attached to a program object. Hence it is allowed to bind any |
| name (except a name starting with gl_) to a color number and index, |
| including a name that is never used as a varying out variable in |
| any fragment shader object. Assigned bindings for variables that |
| do not exist are ignored." |
| |
| Add to end of section: |
| |
| "The command |
| |
| int GetFragDataIndexEXT(uint program, const char * name); |
| |
| returns the index of the fragment color to which the variable <name> |
| was bound when the program object <program> was last linked. If |
| program has not been successfully linked, the error INVALID_OPERATION |
| is generated. If name is not a varying out variable, or if an error |
| occurs, -1 will be returned. The command is equivalent to |
| |
| GetProgramResourceLocationIndex(program, PROGRAM_OUTPUT, name);" |
| |
| Additions to Chapter 15 of the OpenGL ES 3.1 Specification (Writing |
| Fragments and Samples to the Framebuffer) |
| |
| Modify section 15.1.5.2 "Blend Functions": |
| |
| Change the first paragraph to read: |
| |
| "The weighting factors used by the blend equation are determined by |
| the blend functions. There are four possible sources for weighting |
| factors. These are the constant color (Rc, Gc, Bc, Ac) (see |
| BlendColor, p. 211), the first source color (Rs0, Gs0, Bs0, As0), |
| the second source color (Rs1, Gs1, Bs1, As1), and the destination |
| color (the existing content of the draw buffer). Additionally the |
| special constants ZERO and ONE are available as weighting factors." |
| |
| Modify Table 15.2 (RGB and ALPHA source and destination blend |
| functions ...) as follows |
| |
| RGB Blend Factors Alpha Blend Factors |
| Value (Sr, Sg, Sb) or (Dr, Dg, Db) Sa or Da |
| ----- ---------------------------- ------------------- |
| ZERO (0, 0, 0) 0 |
| ONE (1, 1, 1) 1 |
| SRC_COLOR (Rs0, Gs0, Bs0) As0 |
| ONE_MINUS_SRC_COLOR (1, 1, 1) - (Rs0, Gs0, Bs0) 1 - As0 |
| DST_COLOR (Rd, Gd, Bd) Ad |
| ONE_MINUS_DST_COLOR (1, 1, 1) - (Rd, Gd, Bd) 1 - Ad |
| SRC_ALPHA (As0, As0, As0) As0 |
| ONE_MINUS_SRC_ALPHA (1, 1, 1) - (As0, As0, As0) 1 - As0 |
| DST_ALPHA (Ad, Ad, Ad) Ad |
| ONE_MINUS_DST_ALPHA (1, 1, 1) - (Ad, Ad, Ad) 1 - Ad |
| CONSTANT_COLOR (Rc, Gc, Bc) Ac |
| ONE_MINUS_CONSTANT_COLOR (1, 1, 1) - (Rc, Gc, Bc) 1 - Ac |
| CONSTANT_ALPHA (Ac, Ac, Ac) Ac |
| ONE_MINUS_CONSTANT_ALPHA (1, 1, 1) - (Ac, Ac, Ac) 1 - Ac |
| SRC_ALPHA_SATURATE (f, f, f) 1 New (for ES 2.x) |
| SRC1_COLOR_EXT (Rs1, Gs1, Bs1) As1 New |
| ONE_MINUS_SRC1_COLOR_EXT (1, 1, 1) - (Rs1, Gs1, Bs1) 1 - As1 New |
| SRC1_ALPHA_EXT (As1, As1, As1) As1 New |
| ONE_MINUS_SRC1_ALPHA_EXT (1, 1, 1) - (As1, As1, As1) 1 - As1 New |
| |
| For ES 2.0, remove table's footnote saying (ES 3.x already has this |
| removed): |
| |
| SRC_ALPHA_SATURATE is valid only for source RGB and alpha |
| blending functions. |
| |
| Add the following subsections to Section 5.1.5 Blending, at the end |
| of the subsection 15.1.5.2 "Blend Functions": |
| |
| "15.1.5.X Dual Source Blending and Multiple Draw Buffers |
| |
| Blend functions that require the second color input, <Rs1, Gs1, Bs1, |
| As1> (SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or |
| ONE_MINUS_SRC1_ALPHA_EXT) may consume hardware resources that could |
| otherwise be used for rendering to multiple draw buffers. Therefore, |
| the number of draw buffers that can be attached to a frame buffer |
| may be lower when using dual-source blending. |
| |
| The maximum number of draw buffers that may be attached to a |
| single frame buffer when using dual-source blending functions is |
| implementation dependent and can be queried by calling GetIntegerv |
| with the symbolic constant MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT. When |
| using dual-source blending, MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT should be |
| used in place of MAX_DRAW_BUFFERS_EXT to determine the maximum number |
| of draw buffers that may be attached to a single frame buffer. The |
| value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must be at least 1. If |
| the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT is 1, then dual-source |
| blending and multiple draw buffers cannot be used simultaneously. |
| |
| If either blend function is set to one of the second source factors |
| (SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or |
| ONE_MINUS_SRC1_ALPHA_EXT) for any draw buffer and any draw buffers |
| equal to or greater than the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT |
| have values other than NONE, the error INVALID_OPERATION is generated |
| by drawing commands. |
| |
| 15.1.5.Y Generation of Second Color Source for Blending |
| |
| Rendering using any of the blend functions that consume the second |
| input color (SRC1_COLOR_EXT, ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT |
| or ONE_MINUS_SRC1_ALPHA_EXT) using a shader that does not output |
| a second source color will produce undefined results. To produce |
| input for the second source color, a shader must be used that outputs |
| a second source color. |
| |
| When using a GLSL version 300 es or higher fragment shader with |
| dual-source blending functions, the color output varyings are bound |
| to the first (index 0) and second (index 1) inputs of a draw buffer |
| using BindFragDataLocationIndexedEXT as described in the "Shader |
| Outputs" subsection of Section 3.12.2 or by layout qualifiers for |
| location=/n/ and index=/m/. Data written to the first of these outputs |
| becomes the first source color input to the blender (corresponding |
| to SRC_COLOR and SRC_ALPHA). Data written to the second of these |
| outputs generates the second source color input to the blender |
| (corresponding to SRC1_COLOR_EXT and SRC1_ALPHA_EXT). |
| |
| Alternatively if the GLSL version 100 fragment shader is used (where |
| user-defined color outputs are unsupported, hence a user-defined |
| color output is not available for BindFragDataLocationIndexEXT), the |
| gl_FragColor and gl_SecondaryFragColorEXT fragment outputs correspond |
| to the first and second source color respectively. Similarly the |
| gl_FragData and gl_SecondaryFragDataEXT fragment output arrays |
| correspond to the first and second source color respectively of each |
| color buffer output. |
| |
| If the second color input to the blender is not written in the |
| shader, or if no output is bound to the second input of a blender, |
| the result of the blending operation is not defined. |
| |
| Other shading languages may define similar methods for producing |
| the first and second color inputs to blending equations." |
| |
| Additions to the OpenGL ES Shading Language 1.00 Specification |
| |
| Including the following line in a shader can be used to control the |
| language features described in this extension: |
| |
| #extension GL_EXT_blend_func_extended : <behavior> |
| |
| where <behavior> is as specified in section 3.4. |
| |
| A new preprocessor #define is added to the OpenGL ES Shading Language: |
| |
| #define GL_EXT_blend_func_extended 1 |
| |
| Modify paragraphs in section 7.2 "Fragment Shader Special Variables" as follows: |
| |
| First paragraph, second sentence: |
| |
| "Fragment shaders output values to the OpenGL ES pipeline using |
| the built-in variables gl_FragColor, gl_SecondaryFragColorEXT, |
| gl_FragData, and gl_SecondaryFragDataEXT, unless the discard keyword |
| is executed." |
| |
| Second paragraph, first sentence: |
| |
| "It is not a requirement for the fragment shader to write to |
| either gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData, or |
| gl_SecondaryFragDataEXT." |
| |
| Add after the fourth paragraph: |
| |
| "Writing to gl_SecondaryFragColorEXT specifies a second fragment color |
| that will be used by the subsequent fixed functionality pipeline for |
| dual source blending. If subsequent fixed functionality consumes the |
| second fragment color and an execution of a fragment shader does |
| not write a value to gl_SecondaryFragColorEXT then the secondary |
| fragment color consumed is undefined." |
| |
| Add after the fifth paragraph: |
| |
| "The variable gl_SecondaryFragDataEXT is an array. Writing to |
| gl_SecondaryFragDataEXT[n] specifies the secondary fragment data that |
| will be used by the subsequent fixed functionality pipeline for data n |
| for dual source blending. If subsequent fixed functionality consumes |
| secondary fragment data and an execution of a fragment shader does |
| not write a value to it, then the secondary fragment data consumed |
| is undefined." |
| |
| Modify the sixth paragraph to read: |
| |
| "If a shader statically assigns a value to gl_FragColor or |
| gl_SecondaryFragColorEXT, it may not assign a value to any |
| element of gl_FragData or gl_SecondaryFragDataEXT. If a shader |
| statically writes a value to any element of gl_FragData or |
| gl_SecondaryFragDataEXT, it may not assign a value to gl_FragColor |
| or gl_SecondaryFragColorEXT. That is, a shader may assign values to |
| either the set of gl_FragColor and gl_SecondaryFragColorEXT or the |
| set of gl_FragData and gl_SecondaryFragDataEXT, but not both." |
| |
| Modify the eighth paragraph to read: |
| |
| "If a shader executes the discard keyword, the fragment is discarded, |
| and the values of gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData, |
| and gl_SecondaryFragDataEXT become irrelevant." |
| |
| Add these built-in variable to the list "accessible from a fragment shader": |
| |
| mediump vec4 gl_SecondaryFragColorEXT; |
| mediump vec4 gl_SecondaryFragDataEXT[gl_MaxDualSourceDrawBuffersEXT]; |
| |
| Add to section 7.4 "Built-In Constants" the following constant: |
| |
| const mediump int gl_MaxDualSourceDrawBuffersEXT = 1; |
| |
| Additions to the OpenGL ES Shading Language 3.00 and 3.10 Specification |
| |
| Including the following line in a shader can be used to control the |
| language features described in this extension: |
| |
| #extension GL_EXT_blend_func_extended : <behavior> |
| |
| where <behavior> is as specified in section 3.4. |
| |
| A new preprocessor #define is added to the OpenGL ES Shading Language: |
| |
| #define GL_EXT_blend_func_extended 1 |
| |
| Modify section 4.4.2 "Output Layout Qualifiers": |
| |
| Change the second paragraph to read: |
| |
| "Fragment shaders allow output layout qualifiers only on the interface |
| qualifier out. The layout qualifier identifier for fragment shader |
| outputs is: |
| |
| layout-qualifier-id |
| location = integer-constant |
| index = integer-constant |
| |
| Each of these qualifiers may appear at most once. If index is |
| specified, location must also be specified. If index is not |
| specified, the value 0 is used." |
| |
| Add an additional example to the end of the fourth paragraph's example: |
| |
| "And, |
| |
| layout(location = 3, index = 1) out vec4 factor; |
| |
| will establish that the fragment shader output factor is copied out |
| to fragment color 3 as the second (index one) input to the blend |
| equation." |
| |
| Change the first sentence of the second to last paragraph to read: |
| |
| "If there is more than one fragment output, the location must |
| be specified for all outputs unless the EXT_blend_func_extended |
| extension is enabled in which case more than one unassigned fragment |
| output locations are allowed though they must be assigned to unique |
| locations assigned with glBindFragDataLocationIndexedEXT prior to |
| linking." |
| |
| Add to section 7.4 "Built-In Constants" the following constant: |
| |
| const mediump int gl_MaxDualSourceDrawBuffersEXT = 1; |
| |
| Dependencies on OpenGL ES 3.0 |
| |
| If OpenGL ES 3.0 or higher is not supported (meaning OpenGL ES 2.0 |
| support only), remove all references to the functions: |
| |
| BindFragDataLocationIndexedEXT |
| GetFragDataIndexEXT |
| BindFragDataLocationEXT |
| GetProgramResourceLocationIndexEXT |
| |
| Also ignore the additions to chapters 7 and 14 and the paragraph in |
| section 15.1.5.Y related to GLSL version 300 es or higher. |
| |
| When OpenGL ES 3.0 or higher, the "Additions to the OpenGL ES |
| Shading Language 1.00 Specification" applies to the version 100 |
| shading language, but not later versions. |
| |
| Dependencies on OpenGL ES 3.1 |
| |
| If OpenGL ES 3.1 or higher is not supported (meaning OpenGL ES 3.0 |
| or earlier), remove all references to the function |
| |
| GetProgramResourceLocationIndexEXT |
| |
| because program resource queries are added by ES 3.1. |
| |
| Also ignore the additions to chapter 7. |
| |
| Dependencies on EXT_draw_buffers or NV_draw_buffers |
| |
| Using dual-source blending functions may consume additional outputs |
| from hardware shading units and therefore can reduce the number |
| of draw buffers that may be attached to a single frame buffer when |
| dual-source blending functions are enabled. In this case, the value |
| of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT may be less than the value of |
| MAX_DRAW_BUFFERS_EXT. If EXT_draw_buffers or NV_draw_buffers is not |
| supported then the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must |
| be 1. Furthermore, the discussion in the subsection entitled "Dual |
| Source Blending and Multiple Draw Buffers" may be discarded. |
| |
| Dependencies on EXT_draw_buffers_indexed |
| |
| If EXT_draw_buffers_indexed is not supported, all references to |
| BlendFunciEXT and BlendFuncSeparateiEXT should be removed. In this |
| case, the blend functions for all attached draw buffers will be the |
| same. |
| |
| Errors |
| |
| The error INVALID_OPERATION is generated by Begin or any |
| procedure that implicitly calls Begin if any draw buffer has a |
| blend function requiring the second color input (SRC1_COLOR_EXT, |
| ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT or ONE_MINUS_SRC1_ALPHA_EXT), |
| and a framebuffer is bound that has more than the value of |
| MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT-1 active color attachments. |
| |
| New State |
| |
| None |
| |
| While no changes to table 20.12 (Pixel Operations) are strictly |
| necessary, new enumerations are supported for the BLEND_SRC_RGB, |
| BLEND_SRC_ALPHA, BLEND_DST_RGB, and BLEND_DST_ALPHA state to support |
| SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, and |
| ONE_MINUS_SRC1_ALPHA_EXT (and for ES 2.0, SRC_ALPHA_SATURATE_EXT). |
| |
| New Implementation Dependent State |
| |
| Get Value Type Get Command Minimum Value Description Sec. |
| --------- ---- ----------- ------------- ------------------- ------ |
| MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT Z+ GetIntegerv 1 Maximum number of 15.1.5 |
| active draw buffers |
| when using dual-source |
| blending |
| |
| Example Use Cases |
| |
| There are several potential uses for this functionality. A first |
| example is in the implementation of sub-pixel accurate font rendering |
| algorithms. Given a known layout of pixel elements (red, green |
| and blue components), coverage may be calculated independently for |
| each element and passed to the blender in the second source color |
| as a per-channel opacity. To use this mode, use the following blend |
| functions: |
| |
| glBlendFunc(GL_SRC1_COLOR_EXT, GL_ONE_MINUS_SRC1_COLOR_EXT); |
| |
| As a second example, consider a partially reflective colored glass |
| window. It will attenuate light passing through it, and reflect |
| some of the light that strikes it. Using an appropriate combination |
| of functions, this effect may be simulated in a single pass using |
| only fixed-function blending hardware. In this case, the following |
| blend functions may be used: |
| |
| glBlendFunc(GL_SRC_ALPHA, GL_SRC1_COLOR_EXT); |
| |
| Issues |
| |
| 0. What should this extension be named? |
| |
| RESOLVED: EXT_blend_func_extended, matching the name of |
| ARB_blend_func_extended upon which this extension is based but |
| providing a multi-vendor extension for ES implementations. |
| |
| 1. Is this extension compatible with the ARB_blend_func_extended |
| version? |
| |
| RESOLVED: Yes. This extension is 100% functionally identical to |
| ARB_blend_func_extended but for the ES 2.x and 3.x APIs. |
| |
| The token values are _EXT suffixed but have the same values as |
| the ARB_blend_func_extended tokens. |
| |
| Philosophically if this extension is going for 100% parity and |
| functionality with ARB_blend_func_extended, it should simply add |
| all the stuff in ARB_blend_func_extended... |
| |
| 2. Should the next commands be EXT suffixed? |
| |
| RESOLVED: Yes. This is not an OES extension. |
| |
| This means source code coming from a desktop environment should |
| call eglGetProcAddress on function names with the EXT suffix. |
| However because extension functions are called through function |
| pointers, this is only a minor change isolated to function pointer |
| initialization. |
| |
| 2. Should this extension allow ES 2.0 contexts to use |
| GL_SRC_ALPHA_SATURATE for the destination blend function? |
| |
| RESOLVED: Yes, the ARB_blend_func_extended extension adds support |
| for using GL_SRC_ALPHA_SATURATE as the destination factor as "bonus" |
| functionality. |
| |
| ES 3.x already allows GL_SRC_ALPHA_SATURATE for the destination |
| factor so this additional functionality is new only to ES 2.0 contexts |
| supporting this extension. |
| |
| We expect no GPU hardware capable of dual-source blending to not |
| also support GL_SRC_ALPHA_SATURATE as the destination factor. |
| |
| 3. Should this extension provide the glBindFragDataLocation and |
| glBindFragDataLocationIndexed functionality? |
| |
| RESOLVED: Yes. With EXT suffixes. |
| |
| 4. Should this really be OES_blend_func_extended? |
| |
| RESOLVED: Go with EXT is for expediency. |
| |
| Additionally this extension supports functionality such |
| GL_SRC_ALPHA_SATURATE that all desktop GPU hardware is assumed to |
| have. ES-only vendors might not want this in an OES extension. |
| |
| The same could be said for the glBindFragDataLocation* functionality. |
| |
| 5. Does this extension need an interaction with |
| OES_blend_equation_separate? |
| |
| RESOLVED: No, that's an ES 1.1 extension. ES 2.0 and on all support |
| separate blend functions. |
| |
| 6. Are there any OpenGL ES Shading Language interactions? |
| |
| RESOLVED: Yes, to use this extension, a #extension line will be needed |
| in the shader requesting the EXT_blend_func_extended functionality. |
| Example: |
| |
| #extension GL_EXT_blend_func_extended : require |
| |
| The ARB_blend_func_extended functionality does NOT require a special |
| #extension line to use its functionality because the ARB version |
| relies on existing GLSL functionality that allows for multiple |
| fragment outputs as part of supporting multiple render targets. |
| In the ARB version, then glBindFragDataLocationIndexed can bind |
| these unassigned locations to different source output colors. |
| But GLSL OpenGL ES 3.00 and 3.10 both explicitly preclude more than |
| one fragment shader output with an unassigned location. Hence a |
| #extension is needed to relax this error condition. And then this |
| extension's glBindFragDataLocationIndexedEXT must be used to assign |
| locations as necessary. |
| |
| 7. Can the indexed location be assigned explicitly in the shader? |
| |
| RESOLVED: Yes, for ES 3.x shaders where the GLSL ES 3.x supports |
| layout qualifiers. ES 2.0 does not support the layout qualifier or |
| user-defined fragment outputs. |
| |
| 8. Should both the layout qualifier mechanism and the |
| glBindFragDataLocationIndexed-style API for specifying the index of |
| a user-defined fragment shader output be supported? |
| |
| RESOLVED: Yes, both should be supported. This makes it easier |
| for existing applications to port to ES 3.0 as both mechanisms are |
| available. |
| |
| FYI: The "layout(location=0,index=1)" type syntax for dual-source |
| blending was introduced to OpenGL in GLSL 3.30 and 4.00 in |
| conjunction with OpenGL 3.3 and 4.0 respectively. The original |
| ARB_blend_func_extended was written with respect to OpenGL 3.2 and |
| intended to support dual-source blending without the need to extend |
| the GLSL language by instead supporting assignment if the fragment |
| output index via glBindFragDataLocationIndexed. |
| |
| 9. How to support OpenGL ES 2.0 where user-defined fragment shader |
| outputs are not supported? |
| |
| RESOLVED: Introduce new gl_SecondaryFragColorEXT and |
| gl_SecondaryFragDataEXT built-in variables for specifying the second |
| source color. |
| |
| These built-ins are only available in the ES 1.00 shader language |
| version. |
| |
| It is important to provide an ES 2.0 mechanism because WebGL 1.0 is |
| based on ES 2.0. Chrome's internal command buffer mechanism is also |
| based around ES 2.0 and Skia intends to use this extension. |
| |
| This includes adding a gl_MaxDualSourceDrawBuffersEXT |
| implementation-dependent constant. |
| |
| 10. Does the version 100 syntax (gl_SecondaryFragColorEXT, |
| gl_SecondaryFragDataEXT) work in an ES 3.0 context? |
| |
| RESOLVED: Yes. For compatibility reasons, an ES 3.0 context |
| advertising EXT_blend_func_extended must support the built-ins for |
| the fragment shader secondary color outputs. |
| |
| 11. How many elements should be in the gl_SecondaryFragDataEXT array? |
| |
| RESOLVED: The gl_SecondaryFragDataEXT array should have as |
| many elements as the GLSL built-in implementation constant |
| gl_MaxDualSourceDrawBuffersEXT which should be the value of the |
| context's GL_MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT implementation-dependent |
| constant. |
| |
| This means the number of elements in gl_SecondaryFragDataEXT is |
| different than the number of gl_FragData elements. |
| |
| 12. What precision should the gl_SecondaryFragColorEXT and |
| gl_SecondaryFragDataEXT be? |
| |
| RESOLVED: mediump. This is consistent with gl_FragColor and |
| gl_FragData. |
| |
| 13. Should gl_MaxDualSourceDrawBuffersEXT be exposed in both ES 2.0 |
| (where it sizes the gl_SecondaryFragDataEXT array) and also 3.x |
| contexts (where there is no fixed-function array)? |
| |
| RESOLVED: Implementation-wise, it is easiest to expose this |
| implementation-dependent constant for all ES contexts. |
| |
| As a practical matter, we don't expect any implementations will |
| advertise any value other than 1 for this constant. |
| |
| Note: There is no implementation-dependent GLSL constant comparable |
| to gl_MaxDualSourceDrawBuffersEXT in ARB_blend_func_extended |
| (or OpenGL 3.3/4.0 introducing the ARB_blend_func_extended |
| functionality). |
| |
| 14. Any more issues? |
| |
| RESOLVED: See the issues in the ARB_blend_func_extended |
| specification. This extension resolves those issues to match the |
| ARB extension version. |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- --------- ----------------------------------------- |
| 1 05/22/15 mjk Initial revision. |
| 2 07/06/15 mjk Proper ES 2.0 interactions; complete. |
| 3 07/08/15 mjk Feedback from Brian |
| 4 07/08/15 mjk Feedback from Daniel |
| 5 07/29/15 mjk ES 3.x contexts (as well as 2.0) expose |
| gl_MaxDualSourceDrawBuffersEXT |
