Edit
kc3-lang/angle/extensions/EXT_blend_func_extended.txt
Branch :
-
Show log
Commit
-
Author :
Kimmo Kinnunen
Date : 2015-07-16 14:13:11
Hash : b18609b9
Message : Implement ES 2,3 parts of EXT_blend_func_extended for shader translation Exposes gl_SecondaryFragColor, glSecondaryFragData[] and gl_MaxDualSourceDrawBuffers to GLES SL 1.0. Relaxes rules for undefined output locations for GLES SL 3.0 and exposes gl_MaxDualSourceDrawBuffers. If the output GL context is GL ES 2.0 or 3.0: The emulation layer is expected to turn on EXT_blend_func_extended if the output GL context supports it. If the output GL context is GL: The emulation layer is expected to turn on EXT_blend_func_extended if the output GL context supports ARB_blend_func_extended or if GL context is 3.2 or later. If the source shader spec is GLES SL 2.0: The emulation layer is expected to inspect the shader compilation output variables upon linking. If output target is GL SL, the emulation layer should bind color location 0, index 1 to "angle_SecondaryFragColor" if variable "gl_SecondaryFragColorEXT" is used. Alternatively, emulation layer should bind "angle_SecondaryFragData" to locations 0,1,2,3,..., all color index 1, if "gl_SecondaryFragData" array is used. (The caller can not bind the locations or specify output variables.) If the source shader spec is GLES SL 3.0: The emulation layer is expected to do location auto-resolve of the the output variables that have undefined output locations that have not been bound by the caller. (The caller can not use gl_ built-ins, so nothing to do with those.) BUG=angleproject:1085 TEST=angle_unittest Change-Id: I5cafe205b0c29478b0dcd24aa89a7b0000f5d046 Reviewed-on: https://chromium-review.googlesource.com/287580 Reviewed-by: Zhenyao Mo <zmo@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Tested-by: Kimmo Kinnunen <kkinnunen@nvidia.com>
- extensions/EXT_blend_func_extended.txt
-
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